|
SSL的工作層面，以HTTPS為例： SSL協(xié)議使用不對稱加密技術(shù)實現(xiàn)會話雙方之間信息的安全傳遞?？梢员ＷC信息的保密性、完整性，并且會話雙方能鑒別對方身份。下面是一個通過瀏覽器與Web網(wǎng)站建立HTTPS連接時，瀏覽器與Web服務(wù)器之間經(jīng)過一個握手的過程來完成身份鑒定與密鑰交換，從而建立安全連接的具體過程，如下：
1. 用戶瀏覽器將其SSL版本號、加密設(shè)置參數(shù)、與Session有關(guān)的數(shù)據(jù)以及其它一些必要信息發(fā)送到服務(wù)器。
2. 服務(wù)器將其SSL版本號、加密設(shè)置參數(shù)、與Session有關(guān)的數(shù)據(jù)以及其它一些必要信息發(fā)送給瀏覽器，同時發(fā)給瀏覽器的還有服務(wù)器的證書。如果配置服務(wù)器的SSL需要驗證用戶身份，還要發(fā)出請求要求瀏覽器提供用戶證書。
3. 客戶端檢查服務(wù)器證書，如果檢查失敗，則提示不能建立SSL連接。如果成功，則繼續(xù)。
4. 客戶端瀏覽器為本次會話生成Pre-master secret，并將其用服務(wù)器公鑰加密后發(fā)送給服務(wù)器。
5. 如果服務(wù)器要求鑒別客戶身份，客戶端還要再對另外一些數(shù)據(jù)簽名后并將其與客戶端證書一起發(fā)送給服務(wù)器。
6. 如果服務(wù)器要求鑒別客戶身份，則檢查簽署客戶證書的CA是否可信。如果不在信任列表中，結(jié)束本次會話。如果檢查通過，服務(wù)器用自己的私鑰解密收到的Pre-master Secret，并用它通過某些算法生成本次會話的Master secret。
7. 客戶端與服務(wù)器均使用此Master secret生成本次會話的會話密鑰(對稱密鑰)。在雙方SSL握手結(jié)束后傳遞任何消息均使用此會話密鑰。這樣做的主要原因是對稱加密比非對稱加密的運算量低一個數(shù)量級以上，能夠顯著提高雙方會話時加密解密的運算速度。
8. 客戶端通知服務(wù)器此后發(fā)送的消息都使用這個會話密鑰進行加密。并通知服務(wù)器客戶端已經(jīng)完成本次SSL握手。
9. 服務(wù)器通知客戶端此后發(fā)送的消息都使用這個會話密鑰進行加密，并通知客戶端服務(wù)器已經(jīng)完成本次SSL握手。
10. 本次握手過程結(jié)束，會話已經(jīng)建立。雙方使用同一個會話密鑰分別對發(fā)送以及接收的信息進行加、解密。
有很多實現(xiàn)ssl mitm（中間人攻擊，Man In The Middle）攻擊的工具，具體實現(xiàn)是這樣的：
1、攻擊軟件通過arp或http代理截取http流量
2、當客戶端服務(wù)器請求https頁面時，攻擊軟件截獲證書，并使用該證書的相關(guān)信息及自己產(chǎn)生的public key生成新的證書替換服務(wù)器的證書，并把新證書發(fā)給客戶端。 3、客戶端使用收到證書中的public對數(shù)據(jù)進行加密并傳送給服務(wù)器。 4、攻擊軟件使用之前自己生成的private key進行解密，并使用服務(wù)器的public key 進行加密后傳送到服務(wù)器。 5、攻擊軟件使用服務(wù)器的public key 解密服務(wù)器返回的數(shù)據(jù)，并使用自己生存的private key 對數(shù)據(jù)進行加密后傳給客戶端。 大概就是這樣，瀏覽器如果遇到ssl MITM攻擊會提示證書錯誤：
A proper web browsing client will warn the user of a certificate problems if any of the
following are not true: A. the certificate has been signed by a recognized certificate authority B. the certificate is currently valid and has not expired C. the common name on the certificate matches the DNS name of the server 其中A是關(guān)鍵。
在局域網(wǎng)中防范此類攻擊，技術(shù)上首先杜絕ARP欺騙的發(fā)生，另外要教育用戶在使用Https網(wǎng)站時注意證書錯誤提示。
還有就是不能讓用戶使用那些亂七八糟的瀏覽器，那些瀏覽器安全性不高而且可能留有后門。 這種中間人攻擊理論上不可避免，除非服務(wù)器對客戶端進行驗證，如我們網(wǎng)銀使用的數(shù)字證書就是用來對客戶端進行驗證避免受到中間人攻擊。
中間人攻擊，用戶會收到證書無效的警告。用戶如果忽略警告，那么簡單的說，HTTPS等于HTTP
如果用戶不忽略警告，那么HTTPS可以防止網(wǎng)絡(luò)上的竊聽。當然也存在一些類似最近發(fā)現(xiàn)的SSL prefix攻擊的一些漏洞，在一定條件下可以達到一定程度的攻擊。但是還是比HTTP好多了
ssl過程：
我們知道，https的安全性主要是由SSL證書中的公鑰和私鑰來保證的。瀏覽器與服務(wù)器經(jīng)過https建立通訊的時候（不考慮SSL代理方式需要用戶提交證書的情況，因為我們現(xiàn)在討論的是瀏覽器訪問網(wǎng)站，和SSL代理無關(guān)）會按照以下步驟保證通訊的安全性： 1、瀏覽器連接服務(wù)器，服務(wù)器把SSL證書的公鑰發(fā)送給瀏覽器 2、瀏覽器驗證此證書中的域是否和訪問的域一致（比如用戶訪問https://mail.google.com/時，瀏覽器驗證服務(wù)器發(fā)送過來的SSL證書的公鑰中的域是否為mail.google.com或*.google.com）并沒有過期 3、如果瀏覽器驗證失敗，瀏覽器通知用戶證書有問題，讓用戶選擇是否繼續(xù) 4、如果瀏覽器驗證成功，那么瀏覽器隨機生成一個對稱密鑰并使用接收到的SSL證書的公鑰進行加密并發(fā)送給服務(wù)器 5、服務(wù)器通過SSL證書的私鑰對收到的信息進行解密并得到瀏覽器隨機生成的對稱密鑰 6、最后服務(wù)器和瀏覽器都通過這個對稱密鑰進行通訊了（為什么不直接使用公鑰和私鑰進行通訊？因為非對稱加密比對稱加密效率低） 這個方案看似完美，卻無法抵御中間人攻擊，攻擊者可以按以下步驟實施攻擊截取https通訊中的所有數(shù)據(jù)： 1、攻擊者偽造一個Gmail的SSL證書，使其中的域為mail.google.com或*.google.com，并設(shè)置合適的證書過期時間 2、攻擊者等待訪問者的瀏覽器訪問Gmail時，通過DNS劫持或IP偽造（對于有路由器控制權(quán)限的黑客來說簡直輕而易舉）的方法使其訪問到攻擊者的服務(wù)器上 3、攻擊者把偽造的SSL證書公鑰發(fā)送給瀏覽器 4、瀏覽器驗證SSL證書的域和過期時間都沒錯，認為訪問到的就是Gmail本身，從而把對稱密鑰發(fā)送給黑客服務(wù)器 5、黑客服務(wù)器把偽造的Gmail網(wǎng)頁通過收到的對稱密鑰加密后發(fā)送給瀏覽器 6、訪問者通過瀏覽器輸入Gmail帳戶，發(fā)送給黑客服務(wù)器，黑客服務(wù)器通過收到的對稱密鑰解密后成功獲得訪問者的Gmail密碼 為了抵御這種中間人攻擊，SSL證書需要由可信的SSL證書頒發(fā)機構(gòu)頒發(fā)，形成一個證書鏈（比如Gmail的證書鏈為：最底層為網(wǎng)域mail.google.com，上一層為Thawte SGC CA證書頒發(fā)機構(gòu)，最頂層為很有名的VeriSign證書頒發(fā)機構(gòu)）。那么，瀏覽器除了需要驗證域和有效期外，還要檢查證書鏈中的上級證書公鑰是否有效，上級的上級證書公鑰是否有效，直至根證書公鑰為止。這樣就可以有效避免中間人攻擊了，因為根證書公鑰都是預(yù)裝在操作系統(tǒng)中的，黑客如果不是暴力破解，無法得到根證書的私鑰，如果黑客自己生成一個私鑰，瀏覽器驗證根證書公鑰的時候發(fā)現(xiàn)無法通過操作系統(tǒng)中預(yù)裝的公鑰加密數(shù)據(jù)后使用這個私鑰進行解密，從而判定這個公鑰是無效的。這個方案也是現(xiàn)在https通訊通常的方案。 那么，這個現(xiàn)在所有的瀏覽器正在使用的https通訊方案就無懈可擊了嗎？答案仍是否定的。我們可以看到，在后一個方案中，https的安全性需要在證書頒發(fā)機構(gòu)公信力的強有力保障前提下才能發(fā)揮作用。如果證書頒發(fā)機構(gòu)在沒有驗證黑客為mail.google.com的持游者的情況下，給黑客頒發(fā)了網(wǎng)域為mail.google.com的證書，那么黑客的中間人攻擊又可以順利實施： |
|
|
來自： saintfei > 《挨踢技術(shù)》
