前言
HTTPS是什么相信大家都知道古今，如果你不知道。滔以。沧卢。請關閉此文！Ｗ碚摺但狭！
HTTP的數(shù)據(jù)是明文傳輸?shù)模瑳]有安全性可言撬即。HTTPS是秘文傳輸立磁，那么HTTPS是怎么實現(xiàn)數(shù)據(jù)的安全(加密)傳輸?shù)模磕鞘且驗镠TTPS比HTTP多了個'S'剥槐。 即HTTP下加入SSL層唱歧，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。
SSL/TLS協(xié)議是網(wǎng)絡安全通信的重要基石颅崩，本文將簡單介紹SSL/TLS協(xié)議几于，主要關注SSL/TLS協(xié)議的安全性，特別是SSL規(guī)范的正確實現(xiàn)沿后。 本系列的文章大體分為幾個部分：
1沿彭、SSL/TLS簡介
2、SSL/TLS協(xié)議的基本流程
3尖滚、從SSL到TLS
4喉刘、SSL/TLS的流行實現(xiàn)庫
一： 什么是SSL/TLS?
SSL全稱是Secure Sockets Layer，安全套接字層漆弄，它是由網(wǎng)景公司(Netscape)設計的主要用于Web的安全傳輸協(xié)議睦裳，目的是為網(wǎng)絡通信提供機密性、認證性及數(shù)據(jù)完整性保障撼唾。如今廉邑，SSL已經成為互聯(lián)網(wǎng)保密通信的工業(yè)標準。
SSL最初的幾個版本(SSL 1.0倒谷、SSL2.0鬓催、SSL 3.0)由網(wǎng)景公司設計和維護，從3.1版本開始恨锚，SSL協(xié)議由因特網(wǎng)工程任務小組(IETF)正式接管宇驾，并更名為TLS(Transport Layer Security)，發(fā)展至今已有TLS 1.0猴伶、TLS1.1课舍、TLS1.2這幾個版本。
如TLS名字所說他挎，SSL/TLS協(xié)議僅保障傳輸層安全筝尾。同時，由于協(xié)議自身特性(數(shù)字證書機制)办桨，SSL/TLS不能被用于保護多跳(multi-hop)端到端通信筹淫，而只能保護點到點通信。
SSL/TLS協(xié)議能夠提供的安全目標主要包括如下幾個：
認證性——借助數(shù)字證書認證服務器端和客戶端身份呢撞，防止身份偽造
機密性——借助加密防止第三方竊聽
完整性——借助消息認證碼(MAC)保障數(shù)據(jù)完整性损姜，防止消息篡改
重放保護——通過使用隱式序列號防止重放攻擊
為了實現(xiàn)這些安全目標，SSL/TLS協(xié)議被設計為一個兩階段協(xié)議殊霞，分為握手階段和應用階段：
握手階段也稱協(xié)商階段摧阅，在這一階段，客戶端和服務器端會認證對方身份(依賴于PKI體系绷蹲，利用數(shù)字證書進行身份認證)棒卷，并協(xié)商通信中使用的安全參數(shù)顾孽、密碼套件以及MasterSecret。后續(xù)通信使用的所有密鑰都是通過MasterSecret生成比规。
在握手階段完成后若厚，進入應用階段。在應用階段通信雙方使用握手階段協(xié)商好的密鑰進行安全通信蜒什。
SSL/TLS協(xié)議有一個高度模塊化的架構测秸，分為很多子協(xié)議，如下圖所示：
Handshake協(xié)議：包括協(xié)商安全參數(shù)和密碼套件吃谣、服務器身份認證(客戶端身份認證可選)乞封、密鑰交換;
ChangeCipherSpec 協(xié)議：一條消息表明握手協(xié)議已經完成;
Alert 協(xié)議：對握手協(xié)議中一些異常的錯誤提醒做裙，分為fatal和warning兩個級別岗憋，fatal類型的錯誤會直接中斷SSL鏈接，而warning級別的錯誤SSL鏈接仍可繼續(xù)锚贱，只是會給出錯誤警告;
Record 協(xié)議：包括對消息的分段仔戈、壓縮、消息認證和完整性保護拧廊、加密等监徘。
二：協(xié)議流程詳解
本節(jié)對SSL/TLS協(xié)議的流程進行詳細介紹。一個典型的TLS 1.0協(xié)議交互流程如下圖所示：
圖2吧碾、圖3都是表示的協(xié)議流程凰盔，大同小異【氪海可以對比著看加深理解户敬。
每一個SSL/TLS鏈接都是從握手開始的，握手過程包含一個消息序列睁本，用以協(xié)商安全參數(shù)尿庐、密碼套件，進行身份認證以及密鑰交換呢堰。握手過程中的消息必須嚴格按照預先定義的順序發(fā)生抄瑟，否則就會帶來潛在的安全威脅。今年頂級安全會議CCS 有文章提出了建立綜合狀態(tài)機來檢查SSL鏈接中消息序列……
2.1 握手過程中的消息序列
ClientHello：ClientHello通常是握手過程中的第一條消息枉疼，用于告知服務器客戶端所支持的密碼套件種類皮假、最高SSL/TLS協(xié)議版本以及壓縮算法。
ClientHello中還包含一個隨機數(shù)骂维，這個隨機數(shù)由4個字節(jié)的當前GMT UNIX時間以及28個隨機選擇的字節(jié)組成钞翔，共32字節(jié)。該隨機數(shù)會在密鑰生成過程中被使用席舍。
另外布轿，ClientHello中還可能包含客戶端支持的TLS擴展。(TLS擴展可以被用來豐富TLS協(xié)議的功能或者增強協(xié)議的安全性)
ServerHello：服務器接受到ClientHello后，會返回ServerHello汰扭。服務器從客戶端在ClientHello中提供的密碼套件稠肘、SSL/TLS版本、壓縮算法列表里選擇它所支持的項萝毛，并把它的選擇包含在ServerHello中告知客戶端项阴。接下來SSL協(xié)議的建立就基于服務器選擇的密碼套件類型、SSL/TLS協(xié)議版本以及壓縮算法笆包。
ServerHello中同樣會包含一個隨機數(shù)环揽，同樣4+28 字節(jié)類型，由服務器生成庵佣。
Certificate：客戶端和服務器都可以發(fā)送證書消息來證明自己的身份歉胶，但是通常客戶端證書不被使用巴粪。 服務器一般在ServerHello后會接一條Certificate消息通今，Certificate消息中會包含一條證書鏈，從服務器證書開始肛根，到Certificate authority(CA)或者最新的自簽名證書結束辫塌。下圖形象地描述了證書鏈：
SSL中使用的證書通常是X.509類型證書，X.509證書的內容如下表所示：
在用的X.509證書包含Version 1和Version 3兩種版本派哲，其中v1版本的證書存在安全隱患臼氨，同時不支持TLS擴展，被逐漸棄用“沤欤現(xiàn)在大多數(shù)在用的SSL證書都是V3版本储矩。
同時證書會附帶與協(xié)商好的密鑰交換算法對應的密鑰。密鑰交換算法以及它們所要求的密鑰類型如下表所示喉脖。
ServerKeyExchange：該消息僅當以下密鑰交換算法被使用時由服務器發(fā)出：
RSA_EXPORT(僅當服務器的公鑰大于512bit時)椰苟、DHE_DSS、DHE_DSS_EXPORT树叽、DHE_RSA舆蝴、DHE_RSA_EXPORT、DH_anon 使用其它密鑰交換算法時题诵，服務器不能發(fā)送此消息洁仗。
ServerkeyExchange消息會攜帶這些密鑰交換算法所需要的額外參數(shù)，以在后續(xù)步驟中協(xié)商PreMasterSecret性锭。這些參數(shù)需要被簽過名赠潦。
CertificateRequest：這個消息通常在要求認證客戶端身份時才會有。消息中包含了證書類型以及可接受的CA列表草冈。
ServerHelloDone：服務器發(fā)送這條消息表明服務器部分的密鑰交換信息已經發(fā)送完了她奥，等待客戶端的消息以繼續(xù)接下來的步驟瓮增。這條消息只用作提醒，不包含數(shù)據(jù)域哩俭。
ClientKeyExchange：這條消息包含的數(shù)據(jù)與所選用的密鑰交換算法有關绷跑。
如果選擇的密鑰交換算法是RSA，那么消息包含的參數(shù)為用服務器RSA公鑰(包含在之前證書中的或者是ServerKeyExchange中的)加密過的PreMasterSecret凡资，它有48個字節(jié)砸捏，前2個字節(jié)表示客戶端支持的最高協(xié)議版本，后46個字節(jié)是隨機選擇的隙赁。
如果選擇的密鑰交換算法是DH或者DHE垦藏，則可能有兩種情況：
隱式DH公開值：包含在Certificate消息里;
顯示DH公開值：公開值是本消息的一部分。
CertificateVerify：這條消息用來證明客戶端擁有之前提交的客戶端證書的私鑰伞访。
Finished：表明握手階段結束掂骏。這是第一條用協(xié)商的算法和密鑰保護的消息。
因為是用協(xié)商好的密鑰加密的消息咐扭，它可以用來確認已經協(xié)商好的密鑰芭挽。
同時Finished消息包含一個verify_data域滑废，可以用來校驗之前發(fā)送和接收的信息蝗肪。
Verify_data域是一個PRF函數(shù)的輸出(pseudo-random function)。這個偽隨機函數(shù)的輸入為：(1)兩個hash值：一個SHA-1蠕趁，一個MD5薛闪，對之前握手過程中交換的所有消息做哈希;(2)the MasterSecret，由預備主密鑰生成;(3)finished_label俺陋，如果客戶端發(fā)送的則是”client finished”豁延，服務器發(fā)送的則是”server finished”。關于這個PRF的細節(jié)在3.3節(jié)中會具體描述腊状。 此外诱咏，F(xiàn)inished 消息不能夠在ChangeCipherSpec前發(fā)送。
2.2 不同密鑰交換算法對應的握手過程
不同的密鑰交換算法對應的握手過程中的消息序列是不同的缴挖，相應的實現(xiàn)方式也不同袋狞，本節(jié)介紹幾個常見密鑰交換算法對應的握手過程。
TLS-RSA：在這個場景下映屋，PreMasterSecret是由客戶端指定的苟鸯，并用RSA公鑰加密發(fā)送給服務器。服務器不影響PReMasterSecret的生成棚点。
TLS-DH：基于DH的密鑰交換也被稱為靜態(tài)Diffie-Hellman早处。在這種場景下，可能是雙方各自提交一個證書包含DH公開值瘫析，或者服務器端提交證書包含DH公開值砌梆，客戶端在每次會話中選擇一個值默责。協(xié)商好的DH值被用作PreMasterSecret。顯然證書中的參數(shù)是固定的咸包，那么每次鏈接的PreMasterSecret也是相同的傻丝。
TLS-DH不能提供前向安全性。
TLS-DHE：基于DHE的TLS握手中會有ServerKeyExchange消息诉儒。握手過程中交換參數(shù)的認證通過數(shù)字簽名來實現(xiàn)葡缰，支持的簽名算法包括RSA和DSS。DH參數(shù)會有它的數(shù)字簽名一起被包含在ServerKeyExchange中被發(fā)送出去忱反》菏停客戶端在ClientKeyExchange中返回它的公開DH參數(shù)，但沒有簽名保護温算。同樣協(xié)商出來的DH密鑰被用作PreMasterSecret怜校。
2.3 密鑰生成
Pseudo-random Function(PRF)：偽隨機函數(shù)是SSL協(xié)議中的一個重要組成部分，它被用來秘密擴展以及生成密鑰注竿。在3.1節(jié)講解Finished消息時已經簡單提及PRF茄茁，在這里我們詳細討論PRF的工作原理。SSL/TLS協(xié)議中的PRF如下圖所示：
這個PRF基于兩個hash函數(shù)：MD5和SHA-1巩割，它有3個輸入裙顽，一個Secret(比如PreMasterSecret)，一個標志符(比如”client finished”, “server finished”)宣谈，還有一個種子值(比如客戶端隨機數(shù)+服務器端隨機數(shù))愈犹。
Secret在使用時被分為長度相同的兩半：S1和S2，分別作為P_MD5和P_SHA-1的輸入闻丑。
PRF的輸出按如下方式處理得到：
PRF( secret , label , seed ) = P_MD5( S1 , label + seed ) XOR P_SHA?1(S2 , label + seed ) ;
P_MD5和P_SHA-1都是擴展函數(shù)漩怎，用來擴展秘密值以用于密鑰生成，它們的計算方式如下：
P hash ( secret , seed ) = HMAC hash(secret , A( 1 ) + seed ) +HMAC hash(secret , A( 2 ) + seed ) +HMAC hash(secret , A( 3 ) + seed ) + . . .
其中A(0) = seed, A(i) = HMAC hash( secret, A( i ?1) )
這個秘密擴展會一直進行直到得到足夠多的擴展數(shù)據(jù)嗦嗡。 Key Derivation：主密鑰(MasterSecret)是利用上述PRF從預備主密鑰(PreMasterSecret)生成的勋锤。每個MasterSecret為48字節(jié)，生成方式如下：
mastersecret = PRF( pre mastersecret , ” mastersecret ” , ClientHello.random + ServerHello.random)
得到MasterSecret后侥祭，它會被進一步處理最后生成4個不同的密鑰和2個初始向量(IV)叁执。處理過程如下：
keyblock = PRF( SecurityParameters.mastersecret , ”key expansion ” , SecurityParameters.server random +SecurityParameters.client random ) ;
處理過程一直持續(xù)到足夠多的輸出被生成，然后把輸出分為4個key和2個IV：
client_write_MAC_secret卑硫，server_write_MAC_secret, client_wriete_key, server_write_key, client_write_IV, server_write_IV.
下圖完整闡述了SSL/TLS協(xié)議中的密鑰生成過程徒恋。
三：從SSL到TLS
本節(jié)介紹SSL/TLS協(xié)議的版本變遷，不同版本的區(qū)別以及安全特性等欢伏。
SSL 1.0由于從來沒有被公開過入挣，并且存在嚴重安全漏洞，我們就不討論了硝拧。
SSL 2.0：SSL 2.0于1995年4月被發(fā)布径筏。SSL 2.0中主要存在的問題如下：
MAC不能覆蓋填充長度域葛假，攻擊者可能利用這點破壞消息完整性;
缺乏握手認證，攻擊者可以篡改密碼套件列表滋恬，誘騙通信雙方使用較弱的密碼套件;
使用較弱的或有問題的密碼算法(如MD5聊训，RC4等)，或者使用不安全的分組模式(如CBC模式);
對于不同的密碼學基元使用相同的密鑰恢氯，違背基本安全常識带斑。
由于以上安全問題，RFC 6176已經明確提出避免使用SSL 2.0勋拟，但是現(xiàn)實生活中還有少量客戶端和服務器支持SSL 2.0.
SSL 3.0：SSL 3.0引入了一些新的特性和機制解決了很多之前版本存在的漏洞勋磕。此外，SSL 3.0中引入了ChangeCipherSpec子協(xié)議敢靡。SSL 3.0向后兼容SSL 2.0挂滓，相對于SSL 2.0，它的主要改變包括以下幾點：
支持更多的密碼套件(支持更多的密碼算法如DSS啸胧，SHA-1)
在握手階段支持密鑰協(xié)商(DH和FORTEZZA)
支持密碼學參數(shù)的重協(xié)商
增加了消息壓縮選項
MAC能夠覆蓋填充長度域了赶站，同時MAC可以使用MD5或者SHA-1
不同的密碼學基元使用不同的key
Alert子協(xié)議能對任何錯誤給出兩種提示：Warning和Fatal
中止鏈接的時候會用一個close_notify警告通知通信雙方
支持證書鏈，而非單個證書
通過Finished消息認證所有發(fā)送和接收的消息
加密了的PreMasterSecret包含當前使用的協(xié)議版本纺念，防止協(xié)議回滾
TLS 1.0：TLS 1.0和SSL 3.0差別非常小贝椿。實際上，TLS 1.0是SSL 3.1柠辞，在IETF接手后改名為TLS团秽。TLS 1.0版本是目前使用最廣泛的SSL/TLS協(xié)議版本主胧。
TLS 1.0不再支持使用FORTEZZA的密碼套件叭首。
TLS 1.0中MAC被替換成HMAC。
之前提到ChangeCipherSpec消息必須在Finished消息前發(fā)送踪栋，在TLS 1.0中焙格，如果消息序列不符合這個要求，會產生FATAL警告并終止鏈接夷都。
TLS 1.1：這個版本相比之前改動也很小眷唉。最重要的改動是預防了針對CBC分組模式的一些攻擊。現(xiàn)在的填充錯誤變的和非法MAC錯誤不可區(qū)分了囤官，防止攻擊者利用可區(qū)分錯誤響應建立解密預言機對密文進行攻擊冬阳。
在每次加密過程中，使用CBC分組模式時党饮，都需要顯示給出IV肝陪，而不用再密鑰生成時使用PRF生成IV。
此外刑顺，TLS 1.1禁止為適應之前出口限制而使用弱化的密碼套件氯窍。
TLS 1.2：這是最新的版本饲常，部署的還比較少。這個版本禁用了PRF中的MD5和SHA-1狼讨，而用一個可配置的hash函數(shù)取代了它們贝淤，這樣的修改簡化了計算過程。修改后的PRF風格如下：
此外政供，TLS 1.2的一個重要變化是支持認證加密模式(支持GCM等)播聪。但是由于一些AEAD(Authenticated Encryption with Associated Data)密碼算法要求IV為隱式的，所以IV又恢復到由MasterSecret生成布隔，即TLS 1.0以前的風格犬耻。
TLS 1.2支持使用GCM、CCM的新密碼套件执泰。
同時SSL 2.0被宣布放棄枕磁，不再向后兼容SSL 2.0.
四：SSL/TLS的流行實現(xiàn)庫
本節(jié)簡單介紹一下流行的SSL/TLS實現(xiàn)庫，SSL協(xié)議非常復雜术吝，由開發(fā)者自己實現(xiàn)常常會出錯计济，開發(fā)者在具體實現(xiàn)SSL協(xié)議時通常會依賴于這些密碼學庫。
4.1 常見的SSL/TLS 實現(xiàn)
OpenSSL：這是非常流行的開源SSL/TLS實現(xiàn)排苍。
OpenSSLim完全用C語言實現(xiàn)沦寂，支持SSL 2.0/3.0，TLS 1.0/1.1/1.2以及DTLS 1.0淘衙。
OpenSSL 近年來出現(xiàn)了很多的安全漏洞传藏，比如2014年曝出的著名的Heartbleed漏洞等。
JSSE：這是使用Java實現(xiàn)的彤守，支持SSL 3.0毯侦，TLS 1.0/1.1/1.2.
Bouncy Castle：它不僅僅支持SSL/TLS，它是一個完整的密碼學庫具垫，支持各種密碼學算法和協(xié)議侈离。不過它僅僅支持TLS 1.0版本。
Android平臺主要使用這個密碼學庫筝蚕。
GnuTLS：這是另一個用C語言實現(xiàn)的庫卦碾，支持SSL 3.0，TLS 1.0/1.1/1.2以及DTLS 1.0起宽。主要在Unix世界被使用洲胖。同時以各種安全漏洞多而聞名。
NSS：這是最初由網(wǎng)景公司(Netscape)開發(fā)的庫坯沪，支持SSL 2.0/3.0绿映，TLS 1.0/1.1，現(xiàn)在主要被瀏覽器和客戶端軟件使用屏箍，比如Firefox使用的就是NSS庫绘梦，Chrome使用的是一個NSS庫的修正版橘忱。
下表是一些常見軟件以及它們所使用的SSL/TLS實現(xiàn)庫的情況：
其它還有一些常用的SSL實現(xiàn)庫，如cryptlib卸奉、CyaSSL钝诚、MatrixSSL、PolarSSL等榄棵，由于市場占有率不高凝颇，我們這里就不多做介紹了。
4.2 流行SSL/TLS實現(xiàn)庫的安全研究
最近幾年曝出的高風險SSL安全漏洞大多跟SSL實現(xiàn)庫有關疹鳄，比如2014年4月曝出的“心臟滴血”漏洞拧略，存在于OpenSSL 1.0.1-1.0.1f版本中，影響全球近17%的Web服務器;同樣是2014年曝出的蘋果公司iOS 7.0.6版本系統(tǒng)中存在的“gotofail”漏洞瘪弓，因為程序員的疏忽導致SSL證書校驗中的簽名校驗失效;包括今年曝出的SSL Freak攻擊也是由于SSL實現(xiàn)庫的安全漏洞導致的攻擊垫蛆，我們研究小組的同學對這個攻擊有詳細的分析，參見《SSL Freak來襲：如何實施一個具體的SSL Freak攻擊》腺怯。同時我們還開發(fā)了一個基于python的中間人代理攻擊框架“風聲”對某國內知名電商的服務器進行具體的攻擊袱饭，并上報了漏洞。
考慮到大量SSL/TLS實現(xiàn)庫中存在安全問題呛占，同時這些主流的SSL/TLS實現(xiàn)庫對開發(fā)者而言使用難度較高虑乖，比如有些SSL/TLS實現(xiàn)庫要求開發(fā)者自己進行隨機數(shù)生成或密鑰管理，讓缺乏系統(tǒng)信息安全知識培訓的開發(fā)者去使用這樣高度復雜的密碼學庫容易產生很多安全問題晾虑。我們在這里推薦一些高級密碼學庫：Google keycazer疹味、NaCl、Cryptlib帜篇、GPGME糙捺。這些密碼學庫存在的安全問題較少，同時封裝了一些底層的密碼學操作坠狡，降低了開發(fā)者的使用難度继找。
以上就是本次要介紹的SSL /TLS協(xié)議基本知識，后續(xù)的文章我們會對一些典型SSL/TLS攻擊進行具體介紹逃沿。
參考：
1、http://netsecurity.51cto.com/art/201505/476337.htm
2幻锁、http://www.cnblogs.com/NathanYang/p/9183300.html
3凯亮、https://www.cnblogs.com/bhlsheji/p/4586597.html
