HTTPS的傳輸綁架事件

有標示著金鎖的網頁也不一定是安全的，尤其是在一個注重安全的企業內使用的話，你有空更應該看看金鎖的內容有沒有問題。

關於HTTPS/TLS加密傳輸：
一般來說，透過HTTS/TLS連線是很安全的，也就是說連線的過程有經過加密，以確保傳輸的資料並不會被第三者竊取，HTTPS的簡單連線程序如下：

1.用戶端欲連到HTTPS網站A
2.用戶端經由第三方公證單位，得到網站A的公鑰
3.用戶端把認證資料經網站A的公鑰加密，送給網站A(例如345+1=?)
4.網站A收到用戶端的資料後，用私鑰解密，回答用戶端的問題後，再將結果用私鑰加密(回答345+1=346)
5.用戶端收到加密後的資料後，用網站A的公鑰解密後，看答案對不對，如果對的話，雙方協調，用金鑰加密一組只在這次連線有用的Session Key，以後資料都用Session Key來加解密。由於Session Key是對稱式加解密，故加解密速度快很多。

RFC 2246中有關TLS傳輸協定的簡圖


HTTPS的傳輸資料綁架

如果在第三步驟時，第三者把用戶端要連線到網站A時，就假造自己是網站A，然後有如中介者一般，回應和處理用戶和網站A的資料傳輸，如此第三者就能完全知道用戶端和網站A之間的任何傳輸內容；首先它自己產生一對金鑰，回傳給用戶端，然後再把自己扮成用戶端，和網站A溝通，如此一來就沒有任何資料可逃過第三者的查緝。
第三者如果是代理伺服器的話，那麼就代表任何資料通過此代理伺服器後，沒有任何秘密可言。例如網路銀行的交易，都不再是安全的。


綁架事件實例
IE對這方面的處理並不是很完善，IE 7沒試過，不過IE 6在畫面的右下角，還是出現一個表示安全的金鎖，點擊金鎖，才會發現憑證大有問題，例如連到https://www.chinatrust.com.tw，由下方可看出發行者是The same as above，真是敷衍的發行者名稱!
這不代表上述網站有問題，而是憑證已經不是原網站的憑證了。原網站對外發行的憑證還是對的，只是被中間的代理伺服器動過手腳。

大有問題的憑證，發行者單位怪怪的：



讓我們來看看正確的憑證應長得像這樣，下方IE為英文介面，不過發行者可看出是VeriSign：



皆著，看一下假造的憑證詳細資料，真是隨便到不行，全都是The same as above：



正確的發行者應像這樣：



信有朝一日，假的憑證資料應該也會長得像真的一樣，讓你在IE中認不出來。最後的防線，請使用Firefox，Firefox在憑證檢查方面嚴謹了不少，一旦發現憑證有問題，是不會先連上網站的，因為憑證有問題，代表如果不是傳輸過程中有人動了手腳，不然就是這個網站，不是本來應該去的那一個，而是一個釣魚網站，來看看Firefox怎麼說：


結論是，還是乖乖用Firefox吧! 至少以這例子來說，IE 6並不能檢查出問題。