一、概述
最近幾年曝出的高風險SSL/TLS安全漏洞大多跟SSL實現庫相關,比如2011年曝出的SSL/TLS默認重協商漏洞,可導致DOS攻擊, 比如2014年4月曝出的“心臟滴血”漏洞, 存在OpenSSL 1.0.1`1.0.1f版本中.影響全球近17%的web服務器; 同樣是2014年曝出的蘋果公司IOS 7.0.6版本系統中存在“gotofail"漏洞, 因為程序員的疏忽導致SSL證書校驗中的簽名校驗失效; 包括曝出的SSL Freak攻擊也是由於SSL實現庫的安全漏洞導致的攻擊.
考慮到大量SSL/TLS實現庫中存在安全問題, 同時這些主流的SSL/TLS實現庫對開發者而言使用難度較高, 比如有些SSL/TLS實現庫要求開發者自己進行隨機數生成或密鑰管理,讓缺乏系統信息安全知識培訓的開發者去使用這樣高度復雜的密碼學庫容易產生很多安全問題. 推薦的一些高級密碼學庫:Google keycazer、NACI、Cryptlib、GPGME. 這些密碼學庫存在的安全問題較多, 同時也封裝了一些底層密碼學操作,.
二、SSL/TLS默認重協商漏洞
2.1 重協商介紹
在SSL/TLS協議中, 協商是指通信雙方客戶端和服務器, 選取相同算法、傳遞數字證書、互驗對方身份、交換共享密鑰等一系列的動作. 重協商是指在已經協商好的SSL/TLS TCP連接上重新協商, 用以更換算法、更換數字證書、重新驗證對方身份、更新共享密鑰等. SSL/TLS協議本身支持重協商, 且RFC文檔建議SSL/TLS實現(指OpenSSL等庫)也應該默認支持重協商.
重協商包括兩種方式, 分別如圖A和B .
* 圖A是客戶端主動發送分ClientHello2進行重協商.
* 圖B是服務器通過發送Hello Request消息, 請求客戶端發起重協商. 如果客戶端同意重協商, 則才會發起ClientHello2.
不管是哪一方發起重協商, 如果接收方不同意的話, 都會通過SSL Alert響應以拒絕重協商.
2.2 中間人介紹
所謂中間人, 通常可能有如下三種形式:
1、偽造ARP消息, 對局域網內用戶流量進行重定向, 令其所有流量都通過中間人中轉, 從而中間人有機會對流量的內容進行監視或篡改.
2、偽造DNS消息, 對互聯網用戶訪問指定網站的流量重定向, 令其與該網站之間的流量都通過中間人中轉, 從而中間人有機會對該網站相關的流量內容進行監視或篡改.
3、企業網關、企業防火牆、電信運營商GGSN/PGW網關設備等, 用戶的流量必須經過這些設備才能正常上網.
2.3 重協商安全漏洞原理
1、客戶端首先發出一個ClientHello1,，客戶端期待進行首次協商。（注意：客戶端認為ClientHello1是首次協商）。
2、中間人收到ClientHello1之后，按理說它應該將其轉發給服務器。但是中間人這時決定“作惡”，將ClientHello1緩存起來暫不轉發。中間人自己構造一個ClientHello2,對其
服務器發起首次協商，協商好后中間人將精心偽造的數據發送給服務器。（注意：服務器認為ClientHello2是首次協商）
3、服務器收到這些數據，會認為這是正常的數據。因為服務器的APP程序通常需要處理黏包，所以中間人如果了解APP協議（如HTTPS）的話，則會精心構造不完整的數據，
讓服務器的APP程序認為發生黏包，將數據暫緩不處理，繼續等到后續的數據上來。
4、這時中間人調出暫緩的ClientHello1，將其在同一個SSL/TLS TCP連接中，發送給服務器。（注意：ClientHello1消息本身是加密的，因為其實在ClientHello2協商好后的加密
SSL/TLS連接中傳輸）。
5、服務器收到ClientHello1后，認為這是一次重協商，協商好后，客戶端發送真正的數據給服務器。
6、服務器的APP程序，收到客戶端的真正數據后，將其與之前緩存的中間人精心構造的數據粘合起來，進行業務處理。
從而，中間人在不需要劫持、解密SSL/TLS連接情況下，成功地將自己偽造的數據插入到用戶真正數據之前。這個安全漏洞可以做好多漏洞：
比如偽造一個HTTP GET消息，然后用HTTP的IGNORE字段屏蔽掉真正數據的HTTP GET頭，但是卻保留了用戶的Cookie信息，從而利用用戶cookie去
訪問網站內容，比如可能利用此法刪掉用戶之前發的帖子等。
這個漏洞成因在於，客戶端認為的首次協商卻被服務器認為是重協商，以及首次協商和重協商直接缺少關聯性。RFC 5746引入明確首次協商與重協商的方法，以及確認
首次協商和重協商的關聯校驗，從而確保中間人的攻擊行為可以被識別並拒絕，保證重協商安全。
1、客戶端發起ClientHello1.
2、中間人緩存ClientHello1，精心構造ClientHello2，與服務器進行首次協商。這里假設中間人在ClientHello2中不攜帶安全重協商標識。
3、中間人與服務器協商成功，發送偽造的數據給服務器。
4、中間人將之前緩存的ClientHello1發送給服務器。
5、如果服務器禁止重協商，則這時看到ClientHello1，會認為發生了重協商，不允許，所以中斷連接。
6、如果服務器禁止不安全的重協商、但允許安全的重協商，則因為之前中間人構造的首次協商消息ClientHello2中指示不支持安全重協商，所以
現在收到ClientHello1認為發生了不安全的重協商，所以中斷連接。
因此，這種情況以及各種子情景都沒有問題，不會有安全漏洞。
1、客戶端發起Clienthello1.
2、中間人緩存Clienthello1,精心構造ClientHello2，與服務器進行首次協商。這里假設中間人在ClientHello2中攜帶支持安全重協商標識。
3、中間人與服務器協商成功，發起偽造的數據給服務器。在這時，因為雙方都支持安全重協商，所以服務器會要求中間人將服務器發送的Fininsh消息找那個
的首次協商會話摘要信息記錄下來，以便重協商時再帶給服務器；當然，服務器自己也會將這個首次協商會話摘要信息記錄到自己內存中。
4、中間人將之前緩存的ClientHello1發送給服務器。
5、如果服務器禁用不安全的重協商，但是允許安全的重協商，且如果ClientHello1中支持安全重協商。則按照RFC 5746是不合理的，只有首次協商ClientHello才允許
帶有支持安全重協商標識，重協商階段的ClientHello是不允許攜帶該標識的。所以，服務器認為可能是遇到攻擊，中斷連接。
6、如果服務器禁止不安全的重協商、但允許安全的重協商，且如果ClientHello1中不攜帶支持安全重協商標識，則服務器會認為這是正常的重協商。然后，服務器會提取出
前邊第三步中記錄的首次協商會話摘要信息，按照RFC 5746，ClientHello1中應該帶有相同的這個首次協商會話摘要信息。但是，一方面客戶端的ClientHello1是不可能帶有這個
信息的，所以服務器校驗失敗；另一方面，如果中間人將這個信息插入給ClientHello1，那么雖然服務器現在校驗成功，但是后續服務器校驗協商會話完整性時還是會失敗。
https://blog.csdn.net/o4dc8ojo7zl6/article/details/78537550