介紹完加密的SSH連線,今天就來介紹另一個之前曾經提過的加密連線協定超文本傳輸安全協定(Hypertext Transfer Protocol Secure, HTTPS)。接下來就測試看看如果是在HTTPS加密連線的狀況下登入會收到怎樣的封包吧。
如果網站可以支援HTTPS加密連線的話,在你連到該網站的時候,瀏覽器會告訴你這個網站是安全的。
這次來收收看使用HTTPS連線的Facebook網站流量吧,在帳號輸入iamtesting,並在密碼的地方輸入testtest後按下送出。
HTTPS身為加密連線,會以安全套接層(Secure Sockets Layer, SSL)及傳輸層安全性協定(Transport Layer Security, TLS)等加密方式來進行加密,TLS其實就是SSL的升級版,SSL目前也已經不再更新,且最高的版本是3.0,TLS目前仍在持續發展中,最高的版本則是1.2。也因為TLS是SSL下一代的版本,所以會有人把TLS 1.0稱做SSL 3.1,TLS 1.1稱做SSL 3.2,並把TLS 1.2稱做SSL 3.3。SSL 3.0前已經是很過時的加密方式,且也曾被發現嚴重的漏洞,所以建議現在網站的加密方式都要是TLS起跳的才安全。
接著來看看Wireshark收到的流量有什麼吧,首先我們在條件過濾欄位輸入ssl,以過濾出所有利用SSL跟TLS作為HTTPS加密方式的封包。雖然SSL跟TLS的名字不一樣,不過如果需要在Wireshark中過濾出這些封包的話一樣是下ssl這個指令。
順帶一提,使用ssl這種過濾法會把所有版本的SSL及TLS連線都列出來,如果是想列出特定SSL版本的話可以使用「ssl.record.version == 版本十六進位」這個指令,例如SSL 3.0 是ssl.record.version == 0x0300、TLS 1.0(SSL 3.1) 是 ssl.record.version == 0x0301 TLS 1.1(SSL 3.2)是ssl.record.version == 0x0302 、TLS 1.2(SSL 3.3) 則是ssl.record.version == 0x0303。
不過就我的電腦的狀況,第一個封包的提供TLS版本是TLS 1.0(SSL 3.1),接下來的封包裡的版本開始卻都是TLS 1.2(SSL 3.3),這又是為什麼呢?
在解釋之前我必須先大概說明一下TLS加密方式的流程。
上面提到的Finished訊息在Wireshark看起來會像是下面這樣:
根據剛剛的說明,我的電腦在第一步的時候會傳送可以接受的加密通訊協定版本給Facebook伺服器,這時依照RFC5246 Appendix E.1. 的規範,如果我的電腦傳送的版本大於伺服器可以接受的版本,則伺服器必須回覆我他們能接受的最高版本或是一些告警,但因為實際上很多伺服器如果遇到這種狀況並不一定會回覆可用的警告資訊,所以用戶端常常會提供最低可接受的加密通訊協定版本,如果伺服器要求使用更高版本的話在照著使用就好,這也是為什麼第一個封包的提供TLS版本是TLS 1.0(SSL 3.1),接下來的封包裡的版本開始卻都是TLS 1.2(SSL 3.3)。
接著照慣例,我們在第一個封包按右鍵,並選擇Follow>TCP Stream,接著就可以得到一個以ASCII編碼所呈現的封包內容。
依照TLS Handshake流程,紅框的部分是我的電腦向Facebook送出ClientHello的封包,籃框的部分是Facebook回覆給我的ServerHello封包,綠色則是我的電腦向Facebook送出ClientKeyExchange的訊息。由上述的這些封包,雙方確認加密的演算法版本,並在這之後的則是雙方開始傳輸加密後的封包。
如此一來,沒有密鑰的人就算擷取了這些封包,也無法看出傳送的內容是什麼。但也不是所有使用HTTPS的網站都是安全的喔,例如昨天提到的Chrome版PTT程式,他雖然表面上是使用HTTPS進行加密連線,但因為裡面的程式實際使用的卻是TELNET的協定,所以還是有可能造成未加密的資料外洩,所以在使用不明網站的服務時還是要注意喔!