一聲驚雷，今天爆出了一個(gè)關(guān)于SSL協(xié)議的驚天大漏洞，在用完各種poc工具后，我們不妨來(lái)深入了解下這個(gè)高危漏洞的機理。
不管你是用網(wǎng)上公布的檢測網(wǎng)站還是各個(gè)QQ群瘋傳的poc 腳本，知其然還要知其所以然，讓我們知道漏洞形成的條件，以及漏洞產(chǎn)生的原理，如何修復這個(gè)驚天大漏洞。
這一次，騰訊的個(gè)別站點(diǎn)也沒(méi)有幸免，果斷是坑爹啊。點(diǎn)評ssl服務(wù)沒(méi)有開(kāi)啟TLS heartbeat擴展，所以避過(guò)一劫，當然任何時(shí)候都不能說(shuō)我們可以高枕無(wú)憂(yōu)了，時(shí)刻得關(guān)注各種漏洞的發(fā)布與修復。
首先我們看一下某個(gè)有問(wèn)題站點(diǎn)的SSL信息，當我們用openssl 以客戶(hù)端模式連接對應網(wǎng)站的443端口的時(shí)候，會(huì )獲取到對應服務(wù)器ssl協(xié)議中與TLS擴展相關(guān)的信息。
[root@king tests]# /usr/bin/openssl s_client -connect mail.xxx.com:443 -tlsextdebug 2>&1| grep 'TLS'
TLS server extension "renegotiation info" (id=65281), len=1
TLS server extension "session ticket" (id=35), len=0
TLS server extension "heartbeat" (id=15), len=1
我們看到該站點(diǎn)開(kāi)啟了heartbeat的TLS擴展，而造成本次漏洞問(wèn)題的根源就是OpenSSL對他的實(shí)現。
什么是SSL協(xié)議？
什么是openssl？
ssl和open ssl有什么關(guān)系？
TLS是什么？
造成這次漏洞的TLS服務(wù)擴展"heartbeat"又是什么？
當這么多的疑問(wèn)迎面而來(lái)，我們還是見(jiàn)招拆招，逐一了解：
SSL是Secure Socket Layer（安全套接層協(xié)議）的縮寫(xiě)，可以在Internet上提供加密性傳輸通道。
SSL協(xié)議保證兩個(gè)應用間通信的保密性和可靠性,可在服務(wù)器端和用戶(hù)端同時(shí)實(shí)現支持。使用戶(hù)/服務(wù)器應用之間的通信不被攻擊者竊聽(tīng)，并且始終對服務(wù)器進(jìn)行認證還可選擇對用戶(hù)進(jìn)行認證。
ssl體系結構：
看圖可以知道，SSL協(xié)議是建立在TCP協(xié)議上的，我們知道TCP較UDP協(xié)議是可靠地傳輸協(xié)議，可以保證整個(gè)傳輸過(guò)程數據的完整性。
ssl協(xié)議時(shí)一套理論，最后要應用到實(shí)際的生活中，還得靠具體的人編寫(xiě)程序來(lái)實(shí)現。實(shí)現一個(gè)算法或者說(shuō)協(xié)議是非常龐大艱巨的工程，這個(gè)時(shí)候就有兩個(gè)大牛開(kāi)始編寫(xiě)后來(lái)具有巨大影響的OpenSSL軟件包，然后開(kāi)源出來(lái)，后人不斷完善，最后OpenSSL項目組來(lái)接手繼續完善。
OpenSSL: The Open Source toolkit for SSL/TLS
OpenSSL是互聯(lián)網(wǎng)上最流行的開(kāi)源密碼庫和TLS實(shí)現，不僅是諸多Linux和BSD版本操作系統的默認安全通信機制，也是Apache和nginx等Web服務(wù)器的加密引擎。
OpenSSL提供的功能相當強大和全面，囊括了主要的密碼算法、常用的密鑰和證書(shū)封裝管理功能以及SSL協(xié)議，并提供了豐富的應用程序供測試或其它目的使用。
隨著(zhù)科學(xué)技術(shù)和網(wǎng)絡(luò )規模的發(fā)展，SSL協(xié)議經(jīng)歷了，SSL 1.0 ，SSL2.0、SSL3.0以及TLS1.0等演變，OpenSSL軟件包也是在不斷更新升級，從而支持實(shí)現SSL協(xié)議的升級版本。
SSL是理論協(xié)議，OpenSSL是對其的具體實(shí)現。這就跟http協(xié)議和apache httpd的關(guān)系差不多。
TLS是什么？
TLS：安全傳輸層協(xié)議
（TLS：Transport Layer Security Protocol）
安全傳輸層協(xié)議（TLS）用于在兩個(gè)通信應用程序之間提供保密性和數據完整性。該協(xié)議由兩層組成： TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）。
初看標準定義，感覺(jué)TLS和SSL貌似沒(méi)有什么區別啊.
是，你可以理解TLS協(xié)議時(shí)SSL協(xié)議的增強版本。
最新版本的TLS（Transport Layer Security，傳輸層安全協(xié)議）是IETF（Internet Engineering Task Force，Internet工程任務(wù)組）制定的一種新的協(xié)議，它建立在SSL 3.0協(xié)議規范之上，是SSL 3.0的后續版本。在TLS與SSL3.0之間存在著(zhù)顯著(zhù)的差別，主要是它們所支持的加密算法不同，所以TLS與SSL3.0不能互操作。
1．TLS與SSL的差異
1）版本號：TLS記錄格式與SSL記錄格式相同，但版本號的值不同，TLS的版本1.0使用的版本號為SSLv3.1。
2）報文鑒別碼：SSLv3.0和TLS的MAC算法及MAC計算的范圍不同。TLS使用了RFC-2104定義的HMAC算法。SSLv3.0使用了相似的算法，兩者差別在于SSLv3.0中，填充字節與密鑰之間采用的是連接運算，而HMAC算法采用的是異或運算。但是兩者的安全程度是相同的。
3）偽隨機函數：TLS使用了稱(chēng)為PRF的偽隨機函數來(lái)將密鑰擴展成數據塊，是更安全的方式。
4）報警代碼：TLS支持幾乎所有的SSLv3.0報警代碼，而且TLS還補充定義了很多報警代碼，如解密失?。╠ecryption_failed）、記錄溢出（record_overflow）、未知CA（unknown_ca）、拒絕訪(fǎng)問(wèn)（access_denied）等。
5）密文族和客戶(hù)證書(shū)：SSLv3.0和TLS存在少量差別，即TLS不支持Fortezza密鑰交換、加密算法和客戶(hù)證書(shū)。
6）certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息計算MD5和SHA-1散列碼時(shí)，計算的輸入有少許差別，但安全性相當。
7）加密計算：TLS與SSLv3.0在計算主密值（master secret）時(shí)采用的方式不同。
8）填充：用戶(hù)數據加密之前需要增加的填充字節。在SSL中，填充后的數據長(cháng)度要達到密文塊長(cháng)度的最小整數倍。而在TLS中，填充后的數據長(cháng)度可以是密文塊長(cháng)度的任意整數倍（但填充的最大長(cháng)度為255字節），這種方式可以防止基于對報文長(cháng)度進(jìn)行分析的攻擊。
造成這次漏洞的TLS服務(wù)擴展“heartbeat”又是什么？
The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS.
TLS心跳擴展為T(mén)LS/DTLS提供了一種允許在不重新進(jìn)行商議和發(fā)送路徑MTU探索包(PMTU)的情況下而使用保持持續通信功能的新協(xié)議。
A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.
漏洞出在OpenSSL對TLS的心跳擴展（RFC6520）的實(shí)現代碼中，由于漏了一處邊界檢查，可能在每次心跳中暴露客戶(hù)端與服務(wù)器通信中的64K內存。
網(wǎng)上提供的漏洞細節，看不懂可有忽略，反正我沒(méi)有完全看懂，原理機制明白了就ok了。
Hacker News網(wǎng)友drv在閱讀了漏洞代碼后指出，這是一個(gè)低級錯誤。他解釋說(shuō)：
TLS心跳由一個(gè)請求包組成，其中包括有效載荷（payload），通信的另一方將讀取這個(gè)包并發(fā)送一個(gè)響應，其中包含同樣的載荷。在處理心跳請求的代碼中，載荷大小是從攻擊者可能控制的包中讀取的：
n2s(p, payload);
pl = p;
這里p是指向請求包的指針，payload是載荷的期望長(cháng)度（16位短整數，也就是每次請求64K）。pl指針指向實(shí)際的載荷。
然后響應包是這樣構造的：
/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);
載荷長(cháng)度保存在目標包里，然后從源包pl將載荷復制到目標包bp。
bug出在載荷長(cháng)度沒(méi)有根據請求包的大小進(jìn)行檢查。因此，memcpy()發(fā)送任意載荷長(cháng)度（最大64K）加上一個(gè)小載荷，就能讀取請求存儲位置之外的任意數據。
下面為演示圖：
這次漏洞只是影響到了https服務(wù)嗎？當然不是了，所有開(kāi)啟了“heartbeat” TLS擴展的SSL協(xié)議中封裝的其他協(xié)議（http,ftp,ssh,smtp等協(xié)議）都相當于是明文傳輸了。
面對此次OpenSSL漏洞問(wèn)題如何處理？
官方說(shuō)了，升級到 OpenSSL 1.0.1g 版本。
除此之外，還可以在邊界設備上做一些行為攔截，以及對“heartbeat”擴展做處理（重新編譯openssl，添加 -DOPENSSL_NO_HEARTBEATS 參數即可）。
官方漏洞信息：
http://www.openssl.org/news/secadv_20140407.txt
https://tools.ietf.org/html/rfc6520
我們只是科普，更專(zhuān)業(yè)更詳細的漏洞細節信息，感興趣的同學(xué)請自行g(shù)oogle。
倉促間從文，難免有紕漏和錯誤之處，歡迎指正。
本文原創(chuàng )作者為大眾點(diǎn)評高級運維工程師：劉群英 轉載請注明出處！
本文出自 “馬哥教育Linux運維培訓” 博客，請務(wù)必保留此出處http://mageedu.blog.51cto.com/4265610/1393588
聯(lián)系客服
