Carl May 1, 2018 1 min read 有了前面的基礎知識後, 現在可以來看一下憑證的結構了, 在寫這篇文章的當下, 我是用MAC, 所以接下來的指令操作都是以OSX為主. 首先, 先來看一下憑證的結構, 其概圖如下: Structure of certificate由此可知一個憑證基本上可以分成兩塊: 資料與簽章. 再來, 輸入以下指令以取得特定domain的憑證, 這邊以google.com為範例: 然後你就會看到以下內容: 可以跟上面那張簡圖對照著看, 有點冗長, 但其實還滿有條理的. References
在開始看SSL/TLS技術層面的內容之前, 先簡單介紹一下SSL certificates帶來的四個好處以及這些好處替我們解決了什麼問題: Source identity verification 當你登入到一些比較重要的網站時, 如銀行的網頁, 你會需要確認你所到達的頁面確實是這個銀行的網頁, 想想你在上面輸入password的時候, 若當下的網頁並不是這個銀行所提供的頁面, 那就很危險了. 換句話說, 你會想要避免任何在相同的domain name下看到相似的網站之可能性. 攻擊者通常會藉由攔截往來於正牌網站之間的流量來達到此目的. SSL可以協助我們驗證你正在存取的網站到底是正牌的還是假冒的. 這背後的機制是在瀏覽器上透過一些密碼學機制來達成的. 瀏覽器會通過驗證SSL憑證裡的簽章來確認其真實性. 一旦你的瀏覽器確定這個簽章是正確的, 你就可以在瀏覽器的address bar的左邊看到綠色的鎖頭: 有CA認證過的憑證Security against Man-in-the-middle (MITM) attacks 要想建立客人對你的信賴, 保護好線上的敏感資料是很重要的. 個人識別資訊(Personally Identifiable Information, a.k.a. PII)如信用卡卡號, 身分證字號, password, 生日, 醫療紀錄, 電話號碼, 地址等等. 這些都需要在各種的稽核標準/法律之下被安全的儲存/保護著. SSL通訊可以確保透過其傳輸的資料都是由某個secret key加密過的, 且此secret key只有client與server才知道, 並且對於每個唯一的session, 其secret key都是不同的. Client/Server authentication SSL允許雙向的認證. 瀏覽器可以驗證其正在存取的網站的身份, 網站也可以透過client憑證來驗證client的真實性. 在SSL通訊中, client憑證是一個選擇性的步驟, 其並不是那麼的常見. 不過對於封閉式網站來說, 這些就是必要的了, 畢竟對封閉式網站來說, 其必須確保從外界來存取其內容的client之身份. Non-Repudiation 在SSL連線建立後, 一旦瀏覽器驗證了server的SSL憑證中的簽章後, 這個server就被認為是已認證的了. 在這個時間點開始, 任何跟此server之間發生的通訊與行為都具有不可否定性, 即不管在未來的任何時間點, 該server都不可以否定其之前所做過的事. 最後要補充的一點就是: SSL的另一個目的是作為server的public key的載體. 對於SSL通訊中的”信任鏈驗證(chain of trust validation)”階段與金鑰交換過程來說, server的public key都扮演了非常重要的角色. References
HTTP 與 Cookie 都是明碼傳輸,這對做身分驗證並不是件有利的事。這就像是結帳刷卡的時候,大喊自己的帳號密碼一樣,路人聽到就能盜刷了。 最理想的情況當然是「天知地知,你知我知」。在網路世界裡,因為大家都在同一個載體上傳輸資料,因此任何資料都有被截取的機會,因此只能退而求其次:「我講只有你聽得懂的話,你講只有我聽得懂的話」。現實社會中,比較難做到這種程度,但電腦的世界裡,這正是密碼學主要在討論的。 今天會先討論密碼學實際的應用--SSL/TLS,後面再討論細節。
SSL 全名為 Secure Sockets Layer,TLS 全名為 Transport Layer Security。以下參考維基百科的資料。
值得一提的是,HTTP/2 協定是允許非加密的,同時也允許 TLS 1.2 或更新的版本,但目前主流瀏覽器都只實作加密的 HTTP/2,這讓 HTTP/2 + TLS 變成了強制標準。 TLS 運作原理TLS 在 OSI 模型裡,它屬於傳輸層的協定,而簡介 HTTP 是有提到 HTTP 是應用層協定。而 OSI 模型在設計上是符合里氏替換原則與依賴反轉原則的,這代表傳輸層是否有 TLS 是不會影響應用層的 HTTP;反之,不管應用層是 HTTP、FTP 或 SMTP 等,都能使用 TLS 加密。 TCP Three-way Handshake傳輸層上還有另一個廣泛使用的協定--RFC 793 - Transmission Control Protocol(TCP),裡面有提到一開始建立連線的方法,即為 Three-way Handshake。 時序圖如下:
簡單來說,這過程有點像在打電話:
然後就可以開始正常講話了。 SSL Handshake在 TCP Three-way Handshake 完成之後,如果 Alice 有希望使用 SSL 加密時就會開始做 SSL Handshake。時序圖如下:
小結以上是簡單版的 HTTP + TLS 傳輸流程,有省略非常多細節沒說明,如加密演算法或 Certificate 如何驗證等,未來會再補充說明這些細節,有興趣的讀者可以參考下面的補充資料了解。 參考資料
|