您好,登錄后才能下訂單哦!
博文說(shuō)明【前言】:
本文將通過(guò)個(gè)人口吻介紹TLS ,SSL等相關(guān)知識(shí),在目前時(shí)間點(diǎn)【2017年5月21號(hào)】下,所掌握的技術(shù)水平有限,可能會(huì)存在不少知識(shí)理解不夠深入或全面,望大家指出問(wèn)題共同交流,在后續(xù)工作及學(xué)習(xí)中如發(fā)現(xiàn)本文內(nèi)容與實(shí)際情況有所偏差,將會(huì)完善該博文內(nèi)容。
1、第一彈:實(shí)現(xiàn)HTTPS系列第一彈之【http,https,www,web等概念簡(jiǎn)介】
博文鏈接:http://watchmen.blog.51cto.com/6091957/1922919
2、第二彈:實(shí)現(xiàn)HTTPS系列第二彈之【非對(duì)稱加密,公鑰私鑰,數(shù)字簽名,OpenSSL及HTTPS等概念簡(jiǎn)介】
博文鏈接:http://watchmen.blog.51cto.com/6091957/1923426
3、第三彈:實(shí)現(xiàn)HTTPS系列第三彈之【數(shù)字簽名,數(shù)字證書(shū),CA認(rèn)證等概念理解】
博文鏈接:http://watchmen.blog.51cto.com/6091957/1924747
本文參考文獻(xiàn)引用鏈接及其他資料:
1、https://www.openssl.org/docs/
2、https://www.feistyduck.com/?【經(jīng)典,強(qiáng)烈推薦,TLS/SSL技術(shù)文檔網(wǎng)站】
3、https://www.ssllabs.com 【經(jīng)典,強(qiáng)烈推薦,在線檢測(cè)網(wǎng)站SSL/TLS安全強(qiáng)度】
該網(wǎng)站屬于qualys公司,qualiy's ssl labs,這是一家云安全公司,網(wǎng)址:www.qualys.com
4、推薦圖書(shū):《Bulletproof SSL and TLS》-作者Ivan Ristic,資料我已上傳,可從站內(nèi)搜索下載
下載路徑:http://down.51cto.com/data/2306452
5、http://www.techug.com/post/https-ssl-tls.html【必讀】
6、http://kb.cnblogs.com/page/197396/
7、http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html【必讀】
8、https://technet.microsoft.com/en-us/library/cc784450(v=ws.10).aspx
正文:
首先,HTTP 是一個(gè)網(wǎng)絡(luò)協(xié)議,是專門(mén)用來(lái)傳輸 Web 內(nèi)容。關(guān)于這個(gè)協(xié)議,就算你不了解,至少也聽(tīng)說(shuō)過(guò),比如你訪問(wèn)百度的主頁(yè),瀏覽器地址欄會(huì)出現(xiàn)如下的網(wǎng)址http://www.baidu.com/,
這就是指通過(guò)HTTP 協(xié)議訪問(wèn)該百度的web服務(wù)器的內(nèi)容。在Internet發(fā)展前期,大部分網(wǎng)站都是通過(guò) HTTP 協(xié)議來(lái)傳輸 Web 頁(yè)面以及 Web 頁(yè)面上包含的各種東西(圖片、CSS 樣式、JS 腳本等)。這部分內(nèi)容可以查看的我的第一彈博文簡(jiǎn)單了解,好,基礎(chǔ)知識(shí)介紹完畢,故事開(kāi)始。
一:SSL/TLS是什么?:
SSL(Security Socket Layer,安全套接層),它是在上世紀(jì)90年代中期,由網(wǎng)景公司設(shè)計(jì)的。(網(wǎng)景公司不光發(fā)明了 SSL,還發(fā)明了很多 Web 的基礎(chǔ)設(shè)施,比如“CSS 樣式表”和“JS 腳本”)
TLS(Transport Layer Security,傳輸層安全協(xié)議)是SSL的后繼版本,在SSL的基礎(chǔ)上發(fā)展優(yōu)化。
TLS的主要目標(biāo)是使SSL更安全,并使協(xié)議的規(guī)范更精確和完善,因此TLS 在SSL v3.0 的基礎(chǔ)上,提供了一些增強(qiáng)功能(包括更安全的MAC算法,更嚴(yán)密的警報(bào),“灰色區(qū)域”規(guī)范的更明確的定義等等)
TLS允許協(xié)商失敗的時(shí)候降級(jí)使用SSLv3,但是由于出現(xiàn)漏洞,目前大部分廠商的瀏覽器已經(jīng)禁用該功能。也即現(xiàn)在主流是使用TLS,但是由于歷史遺留問(wèn)題,仍然有部分服務(wù)器在使用SSL
在當(dāng)時(shí),不使用SSL/TLS的HTTP通信,就是不加密的通信。所有信息通過(guò)明文傳播,帶來(lái)了三大風(fēng)險(xiǎn)。
(1) 竊聽(tīng)風(fēng)險(xiǎn)(eavesdropping):第三方可以獲知通信內(nèi)容。
(2) 篡改風(fēng)險(xiǎn)(tampering):第三方可以修改通信內(nèi)容。
(3) 冒充風(fēng)險(xiǎn)(pretending):第三方可以冒充他人身份參與通信。
SSL/TLS協(xié)議是為了解決這三大風(fēng)險(xiǎn)而設(shè)計(jì)的,達(dá)到:
(1)認(rèn)證用戶和服務(wù)器,確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器,防止身份被冒充。
(2)加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取,所有信息都是加密傳播,第三方無(wú)法竊聽(tīng)
(3)維護(hù)數(shù)據(jù)的完整性,確保數(shù)據(jù)在傳輸過(guò)程中不被改變,具有校驗(yàn)機(jī)制,一旦被篡改,通信雙方會(huì)立刻發(fā)現(xiàn)。。
咱們通常所說(shuō)的 HTTPS 協(xié)議,其實(shí)就是“HTTP 協(xié)議”和“SSL/TLS 協(xié)議”的組合。你可以進(jìn)行因式分解,把 HTTPS 理解為是HTTP over SSL”或“HTTP over TLS”
總結(jié)1:SSL/TLS是在互聯(lián)網(wǎng)中實(shí)現(xiàn)通信安全的一個(gè)網(wǎng)絡(luò)協(xié)議。
二:SSL/TLS的發(fā)展歷史:
1994年,NetScape公司設(shè)計(jì)了SSL協(xié)議(Secure Sockets Layer)的1.0版,但是未發(fā)布。
1995年,NetScape公司發(fā)布SSL 2.0版,很快發(fā)現(xiàn)有嚴(yán)重漏洞。
1996年,SSL 3.0版問(wèn)世,得到大規(guī)模應(yīng)用。
1999年,互聯(lián)網(wǎng)標(biāo)準(zhǔn)化組織ISOC接替NetScape公司,發(fā)布了SSL的升級(jí)版TLS 1.0版。
2006年和2008年,TLS進(jìn)行了兩次升級(jí),分別為T(mén)LS 1.1版和TLS 1.2版。最新的變動(dòng)是2011年TLS 1.2的修訂版。
目前,應(yīng)用最廣泛的是TLS 1.2/TLS1.3,接下來(lái)是SSL 3.0。目前主流瀏覽器都已經(jīng)實(shí)現(xiàn)了TLS 1.2的支持。對(duì)老玩家來(lái)說(shuō),TLS 1.0通常被標(biāo)示為SSL 3.1,TLS 1.1為SSL 3.2,TLS 1.2為SSL 3.3。
三:SSL/TLS協(xié)議實(shí)現(xiàn)簡(jiǎn)介?
應(yīng)用層(HTTP,SMTP,IMAP) 應(yīng)用層(HTTP,SMTP,IMAP)
| |
表示層(SSL,TLS) <-------------> 表示層(SSL,TLS)
| |
會(huì)話層(-) 會(huì)話層(-)
| |
傳輸層(TCP,UDP) 傳輸層(TCP,UDP)
| |
網(wǎng)絡(luò)層(IP,IPSec) 網(wǎng)絡(luò)層(IP,IPSec)
| |
數(shù)據(jù)鏈路層(Ethernet) 數(shù)據(jù)鏈路層(Ethernet)
| |
物理層(CAT5) 物理層(CAT5)
從上面我們可以看出,SSL和TLS都是工作在第6層,也就是表示層(presentation),在實(shí)際的數(shù)據(jù)走向時(shí),OSI中的層數(shù)是邏輯可變的,如果不需要可以刪除,因此如果HTTP需要加密實(shí)現(xiàn)HTTPS,那么我們就會(huì)加上表示層,因?yàn)镠TTP所在層為應(yīng)用層,可以控制下層的層數(shù),那么這個(gè)時(shí)候我們的數(shù)據(jù)流是:應(yīng)用層--->TLS--->TCP-->IP-->物理層--->對(duì)端物理層-->......-->對(duì)端應(yīng)用層,也即通過(guò)TLS再連接到TCP如果我們只是需要HTTP,那么我們舍棄表示層,HTTP直接發(fā)送數(shù)據(jù)到TCP,也就是7層到4層。
從上面我們可以簡(jiǎn)單地看出,TCP 協(xié)議是 HTTP 協(xié)議的基石---HTTP 協(xié)議需要依靠 TCP 協(xié)議來(lái)傳輸數(shù)據(jù)。因此,你在配置了https的服務(wù)器,查看加密端口對(duì)應(yīng)的PID,你會(huì)發(fā)現(xiàn)就是80對(duì)應(yīng)的PID,這是因?yàn)榧用苁浅休d的http的基礎(chǔ)之上的。也就是,數(shù)據(jù)先到80,然后80到443,443把80包裹起來(lái)把數(shù)據(jù)傳下去。
總結(jié)2:
1、考慮到HTTP的兼容性問(wèn)題(這里所說(shuō)的兼容性包括很多方面比如已有的 Web 應(yīng)用要盡可能無(wú)縫地遷移到 HTTPS;比如對(duì)瀏覽器廠商而言,改動(dòng)要盡可能小),因此 HTTPS 還是要基于 TCP 來(lái)傳輸(如果改為 UDP 作傳輸層,無(wú)論是 Web 服務(wù)端還是瀏覽器客戶端,都需要大改)
2、實(shí)現(xiàn)過(guò)程是單獨(dú)使用一個(gè)新的協(xié)議,把 HTTP 協(xié)議包裹起來(lái)(所謂的“HTTP over SSL”,實(shí)際上是在原有的 HTTP 數(shù)據(jù)外面加了一層 SSL 的封裝。HTTP 協(xié)議原有的 GET、POST 之類的機(jī)制,基本上原封不動(dòng))
例如:如果原來(lái)的 HTTP 是塑料水管,容易被戳破;那么如今新設(shè)計(jì)的 HTTPS 就像是在原有的塑料水管之外,再包一層金屬水管。一來(lái),原有的塑料水管照樣運(yùn)行;二來(lái),用金屬加固了之后,不容易被戳破。
注意:前面說(shuō)了,HTTPS 相當(dāng)于是“HTTP over SSL”,SSL 這個(gè)協(xié)議在“可擴(kuò)展性”方面的設(shè)計(jì)也足夠牛逼,它除了能跟 HTTP 搭配,還能夠跟其它的應(yīng)用層協(xié)議搭配。如今的 SSL/TLS 可以跟很多常用的應(yīng)用層協(xié)議(比如:FTP、SMTP、POP、Telnet)搭配,來(lái)強(qiáng)化這些應(yīng)用層協(xié)議的安全性。
再說(shuō)一句:其實(shí)SSL和TLS協(xié)議都是由2個(gè)子協(xié)議組成的
SSL協(xié)議可分為兩層:
SSL記錄協(xié)議(SSL Record Protocol):它建立在可靠的傳輸協(xié)議(如TCP)之上,為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。
SSL握手協(xié)議(SSL Handshake Protocol):它建立在SSL記錄協(xié)議之上,用于在實(shí)際的數(shù)據(jù)傳輸開(kāi)始前,通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。
TLS也分為兩層:
TLS 記錄協(xié)議(TLS Record):用于封裝各種高層協(xié)議。記錄協(xié)議支持信息傳輸、將數(shù)據(jù)分段到可處理塊、壓縮數(shù)據(jù)、應(yīng)用MAC 、加密以及傳輸結(jié)果等。對(duì)接收到的數(shù)據(jù)進(jìn)行解密、校驗(yàn)、解壓縮、重組等,然后將它們傳送到高層客戶機(jī)。TLS記錄協(xié)議是一種分層協(xié)議。每一層中的信息可能包含長(zhǎng)度、描述和內(nèi)容等字段。
TLS 握手協(xié)議(TLS Handshake):允許服務(wù)器與客戶機(jī)在應(yīng)用程序協(xié)議傳輸和接收其第一個(gè)數(shù)據(jù)字節(jié)前彼此之間相互認(rèn)證,協(xié)商加密算法和加密密鑰。
四:SSL/TLS實(shí)現(xiàn)過(guò)程?
SSL/TLS協(xié)議的基本思路是采用公鑰加密法,也就是說(shuō),客戶端先向服務(wù)器端索要公鑰,然后用公鑰加密信息,服務(wù)器收到密文后,用自己的私鑰解密。
但是,這里有兩個(gè)問(wèn)題。
(1)如何保證公鑰不被篡改?
解決方法:將公鑰放在數(shù)字證書(shū)中。只要證書(shū)是可信的,公鑰就是可信的。
(2)公鑰加密計(jì)算量太大,如何減少耗用的時(shí)間?
解決方法:每一次對(duì)話(session),客戶端和服務(wù)器端都生成一個(gè)"對(duì)話密鑰"(session key),用它來(lái)加密信息。由于"對(duì)話密鑰"是對(duì)稱加密,所以運(yùn)算速度非常快,而服務(wù)器公鑰只用于加密"對(duì)話密鑰"本身,這樣就減少了加密運(yùn)算的消耗時(shí)間。
因此,SSL/TLS協(xié)議的基本過(guò)程是這樣的:
(1) 客戶端向服務(wù)器端索要并驗(yàn)證公鑰。
(2) 雙方協(xié)商生成"對(duì)話密鑰"。
(3) 雙方采用"對(duì)話密鑰"進(jìn)行加密通信。
上面過(guò)程的前兩步,又稱為"握手階段"(handshake)。
握手階段的詳細(xì)過(guò)程
"握手階段"涉及四次通信,我們一個(gè)個(gè)來(lái)看。需要注意的是,"握手階段"的所有通信都是明文的。
1、客戶端發(fā)出請(qǐng)求(ClientHello)
首先,客戶端(通常是瀏覽器)先向服務(wù)器發(fā)出加密通信的請(qǐng)求,這被叫做ClientHello請(qǐng)求。
在這一步,客戶端主要向服務(wù)器提供以下信息。
(1) 客戶端支持的協(xié)議版本,比如TLS 1.0版。
(2) 一個(gè)客戶端生成的隨機(jī)數(shù)(第1個(gè)隨機(jī)數(shù)),稍后用于生成"對(duì)話密鑰"。
(3) 支持的加密方法,比如RSA公鑰加密。
(4) 支持的壓縮方法。
這里需要注意的是,客戶端發(fā)送的信息之中不包括服務(wù)器的域名。也就是說(shuō),理論上服務(wù)器只能包含一個(gè)網(wǎng)站,否則會(huì)分不清應(yīng)該向客戶端提供哪一個(gè)網(wǎng)站的數(shù)字證書(shū)。這就是為什么通常一臺(tái)服務(wù)器只能有一張數(shù)字證書(shū)的原因。
對(duì)于虛擬主機(jī)的用戶來(lái)說(shuō),這當(dāng)然很不方便。2006年,TLS協(xié)議加入了一個(gè)Server Name Indication擴(kuò)展,允許客戶端向服務(wù)器提供它所請(qǐng)求的域名。
2、服務(wù)器回應(yīng)(SeverHello)
服務(wù)器收到客戶端請(qǐng)求后,向客戶端發(fā)出回應(yīng),這叫做SeverHello。服務(wù)器的回應(yīng)包含以下內(nèi)容。
(1) 確認(rèn)使用的加密通信協(xié)議版本,比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致,服務(wù)器關(guān)閉加密通信。
(2) 一個(gè)服務(wù)器生成的隨機(jī)數(shù)(第2個(gè)隨機(jī)數(shù)),稍后用于生成"對(duì)話密鑰"。
(3) 確認(rèn)使用的加密方法,比如RSA公鑰加密。
(4) 服務(wù)器證書(shū)。
除了上面這些信息,如果服務(wù)器需要確認(rèn)客戶端的身份,就會(huì)再包含一項(xiàng)請(qǐng)求,要求客戶端提供"客戶端證書(shū)"。比如,金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò),就會(huì)向正式客戶提供USB密鑰,里面就包含了一張客戶端證書(shū)。
注意:此處還會(huì)涉及數(shù)字簽名,也即數(shù)字簽名的驗(yàn)證只在TLS協(xié)議的握手過(guò)程中使用,握手結(jié)束的時(shí)候,這個(gè)數(shù)字簽名就失效了。
3、客戶端回應(yīng)
客戶端收到服務(wù)器回應(yīng)以后,首先驗(yàn)證服務(wù)器證書(shū)。如果證書(shū)不是可信機(jī)構(gòu)頒布、或者證書(shū)中的域名與實(shí)際域名不一致、或者證書(shū)已經(jīng)過(guò)期,就會(huì)向訪問(wèn)者顯示一個(gè)警告,由其選擇是否還要繼續(xù)通信。
如果證書(shū)沒(méi)有問(wèn)題,客戶端就會(huì)從證書(shū)中取出服務(wù)器的公鑰。然后,向服務(wù)器發(fā)送下面三項(xiàng)信息。
(1) 一個(gè)隨機(jī)數(shù)(第3個(gè)隨機(jī)數(shù))。該隨機(jī)數(shù)用服務(wù)器公鑰加密,防止被竊聽(tīng)。
(2) 編碼改變通知,表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
(3) 客戶端握手結(jié)束通知,表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值,用來(lái)供服務(wù)器校驗(yàn)。
上面第一項(xiàng)的隨機(jī)數(shù),是整個(gè)握手階段出現(xiàn)的第三個(gè)隨機(jī)數(shù),又稱"pre-master key"。有了它以后,客戶端和服務(wù)器就同時(shí)有了三個(gè)隨機(jī)數(shù),接著雙方就用事先商定的加密方法,各自生成本次會(huì)話所用的同一把"會(huì)話密鑰"。
為什么一定要用三個(gè)隨機(jī)數(shù),來(lái)生成"會(huì)話密鑰"?
解釋:"不管是客戶端還是服務(wù)器,都需要隨機(jī)數(shù),這樣生成的密鑰才不會(huì)每次都一樣。由于SSL協(xié)議中證書(shū)是靜態(tài)的,因此十分有必要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性。
對(duì)于RSA密鑰交換算法來(lái)說(shuō),pre-master-key本身就是一個(gè)隨機(jī)數(shù),再加上hello消息中的隨機(jī),三個(gè)隨機(jī)數(shù)通過(guò)一個(gè)密鑰導(dǎo)出器最終導(dǎo)出一個(gè)對(duì)稱密鑰。
pre master的存在在于SSL協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù),如果隨機(jī)數(shù)不隨機(jī),那么pre master secret就有可能被猜出來(lái),那么僅適用pre master secret作為密鑰就不合適了,因此必須引入新的隨機(jī)因素,那么客戶端和服務(wù)器加上pre master secret三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了,一個(gè)偽隨機(jī)可能完全不隨機(jī),可是是三個(gè)偽隨機(jī)就十分接近隨機(jī)了,每增加一個(gè)自由度,隨機(jī)性增加的可不是一。"
此外,如果前一步,服務(wù)器要求客戶端證書(shū),客戶端會(huì)在這一步發(fā)送證書(shū)及相關(guān)信息。
4、服務(wù)器的最后回應(yīng)
服務(wù)器收到客戶端的第三個(gè)隨機(jī)數(shù)pre-master key之后,計(jì)算生成本次會(huì)話所用的"會(huì)話密鑰"。然后,向客戶端最后發(fā)送下面信息。
(1)編碼改變通知,表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送。
(2)服務(wù)器握手結(jié)束通知,表示服務(wù)器的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的hash值,用來(lái)供客戶端校驗(yàn)。
至此,整個(gè)握手階段全部結(jié)束。接下來(lái),客戶端與服務(wù)器進(jìn)入加密通信,就完全是使用普通的HTTP協(xié)議,只不過(guò)用"會(huì)話密鑰"加密內(nèi)容。
總結(jié)3:實(shí)際數(shù)據(jù)傳輸所使用的對(duì)稱密鑰是通過(guò)雙方協(xié)商,根據(jù)產(chǎn)生的3個(gè)隨機(jī)數(shù)計(jì)算得出的。
結(jié)尾:
下一篇:實(shí)現(xiàn)HTTPS系列第五彈(終章)之【通過(guò)OpenSSL實(shí)現(xiàn)HTTPS】
博文地址:http://watchmen.blog.51cto.com/6091957/1933161
感謝閱讀,祝有收獲的一天,謝謝!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。