作者：阮一峰
日期：2014年9月20日
本周，CloudFlare宣布掀抹，開始提供Keyless服務(wù)蹬竖，即你把網(wǎng)站放到它們的CDN上，不用提供自己的私鑰丈冬，也能使用SSL加密鏈接嘱函。
我看了CloudFlare的說明（這里和這里），突然意識到這是絕好的例子埂蕊，可以用來說明SSL/TLS協(xié)議的運(yùn)行機(jī)制往弓。它配有插圖，很容易看懂蓄氧。
下面函似，我就用這些圖片作為例子，配合我半年前寫的《SSL/TLS協(xié)議運(yùn)行機(jī)制的概述》喉童，來解釋SSL協(xié)議撇寞。
一、SSL協(xié)議的握手過程
開始加密通信之前堂氯，客戶端和服務(wù)器首先必須建立連接和交換參數(shù)蔑担，這個過程叫做握手（handshake）。
假定客戶端叫做愛麗絲咽白，服務(wù)器叫做鮑勃钟沛，整個握手過程可以用下圖說明（點(diǎn)擊看大圖）。
握手階段分成五步局扶。
第一步恨统，愛麗絲給出協(xié)議版本號、一個客戶端生成的隨機(jī)數(shù)（Client random）三妈，以及客戶端支持的加密方法畜埋。
第二步，鮑勃確認(rèn)雙方使用的加密方法畴蒲，并給出數(shù)字證書悠鞍、以及一個服務(wù)器生成的隨機(jī)數(shù)（Server random）。
第三步模燥，愛麗絲確認(rèn)數(shù)字證書有效咖祭，然后生成一個新的隨機(jī)數(shù)（Premaster
secret），并使用數(shù)字證書中的公鑰蔫骂，加密這個隨機(jī)數(shù)么翰，發(fā)給鮑勃。
第四步辽旋，鮑勃使用自己的私鑰浩嫌，獲取愛麗絲發(fā)來的隨機(jī)數(shù)（即Premaster secret）檐迟。
第五步，愛麗絲和鮑勃根據(jù)約定的加密方法码耐，使用前面的三個隨機(jī)數(shù)追迟，生成"對話密鑰"（session key），用來加密接下來的整個對話過程骚腥。
上面的五步敦间，畫成一張圖，就是下面這樣束铭。
二每瞒、私鑰的作用
握手階段有三點(diǎn)需要注意。
（1）生成對話密鑰一共需要三個隨機(jī)數(shù)纯露。
（2）握手之后的對話使用"對話密鑰"加密（對稱加密）剿骨，服務(wù)器的公鑰和私鑰只用于加密和解密"對話密鑰"（非對稱加密），無其他作用埠褪。
（3）服務(wù)器公鑰放在服務(wù)器的數(shù)字證書之中浓利。
從上面第二點(diǎn)可知，整個對話過程中（握手階段和其后的對話）钞速，服務(wù)器的公鑰和私鑰只需要用到一次贷掖。這就是CloudFlare能夠提供Keyless服務(wù)的根本原因。
某些客戶（比如銀行）想要使用外部CDN渴语，加快自家網(wǎng)站的訪問速度苹威，但是出于安全考慮，不能把私鑰交給CDN服務(wù)商驾凶。這時牙甫，完全可以把私鑰留在自家服務(wù)器，只用來解密對話密鑰调违，其他步驟都讓CDN服務(wù)商去完成窟哺。
上圖中，銀行的服務(wù)器只參與第四步技肩，后面的對話都不再會用到私鑰了且轨。
三、DH算法的握手階段
整個握手階段都不加密（也沒法加密）虚婿，都是明文的旋奢。因此，如果有人竊聽通信然痊，他可以知道雙方選擇的加密方法至朗，以及三個隨機(jī)數(shù)中的兩個。整個通話的安全玷过，只取決于第三個隨機(jī)數(shù)（Premaster secret）能不能被破解爽丹。
雖然理論上，只要服務(wù)器的公鑰足夠長（比如2048位）辛蚊，那么Premaster secret可以保證不被破解粤蝎。但是為了足夠安全，我們可以考慮把握手階段的算法從默認(rèn)的RSA算法袋马，改為Diffie-Hellman算法（簡稱DH算法）初澎。
采用DH算法后，Premaster secret不需要傳遞虑凛，雙方只要交換各自的參數(shù)碑宴，就可以算出這個隨機(jī)數(shù)。
上圖中桑谍，第三步和第四步由傳遞Premaster secret變成了傳遞DH算法所需的參數(shù)延柠，然后雙方各自算出Premaster secret。這樣就提高了安全性锣披。
四贞间、session的恢復(fù)
握手階段用來建立SSL連接。如果出于某種原因雹仿，對話中斷增热，就需要重新握手。
這時有兩種方法可以恢復(fù)原來的session：一種叫做session ID胧辽，另一種叫做session ticket峻仇。
session ID的思想很簡單，就是每一次對話都有一個編號（session ID）邑商。如果對話中斷摄咆，下次重連的時候，只要客戶端給出這個編號人断，且服務(wù)器有這個編號的記錄豆同，雙方就可以重新使用已有的"對話密鑰"，而不必重新生成一把含鳞。
上圖中影锈，客戶端給出session ID，服務(wù)器確認(rèn)該編號存在蝉绷，雙方就不再進(jìn)行握手階段剩余的步驟鸭廷，而直接用已有的對話密鑰進(jìn)行加密通信。
session ID是目前所有瀏覽器都支持的方法熔吗，但是它的缺點(diǎn)在于session
ID往往只保留在一臺服務(wù)器上辆床。所以，如果客戶端的請求發(fā)到另一臺服務(wù)器桅狠，就無法恢復(fù)對話讼载。session
ticket就是為了解決這個問題而誕生的轿秧，目前只有Firefox和Chrome瀏覽器支持。
上圖中咨堤，客戶端不再發(fā)送session ID菇篡，而是發(fā)送一個服務(wù)器在上一次對話中發(fā)送過來的session ticket。這個session
ticket是加密的一喘，只有服務(wù)器才能解密驱还，其中包括本次對話的主要信息，比如對話密鑰和加密方法凸克。當(dāng)服務(wù)器收到session
ticket以后议蟆，解密后就不必重新生成對話密鑰了。
（完）
留言（37條）
瑞意說：
阮兄萎战，深入淺出的講解咐容，很好理解了
c說：
我看了 CloudFlare 的說明（這里和這里）
兩個這里是同一個鏈接
阮一峰說：
@c：
謝謝指出，已經(jīng)改過來了蚂维。
xzy說：
session ID是目前所有瀏覽器都支持的方法疟丙，但是它的缺點(diǎn)在于session ID往往只保留在一臺服務(wù)器上。所以鸟雏，如果客戶端的請求發(fā)到另一臺服務(wù)器享郊，就無法恢復(fù)對話。
這段話比較牽強(qiáng)了,有不同方案的集群session保存方案.
qianqian說：
個人理解孝鹊，這應(yīng)該算是CloudFlare產(chǎn)品創(chuàng)新炊琉，相當(dāng)于他能提供一個PKI正常驗(yàn)證體系下的證書頒發(fā)機(jī)構(gòu)，這個機(jī)構(gòu)可以用來為開啟KeyLess服務(wù)的站頒發(fā)證書
qalong說：
引用xzy的發(fā)言：
這段話比較牽強(qiáng)了,有不同方案的集群session保存方案.
同意又活，現(xiàn)在大型應(yīng)用基本上都是集群環(huán)境苔咪，session很少保存在一臺服務(wù)器上。很多都是用集中式session管理
林晨說：
深入淺出柳骄，受教团赏。
zjhiphop說：
阮哥的每篇文章都是必看的！耐薯！
ciciywg說：
安全系列的科普文章寫的真是不錯舔清，圖文并茂，深入淺出曲初，贊体谒！
hilyb說：
不錯的文章。感覺使用SSL好煩人臼婆，證書生成什么的煩死了抒痒。
xiongxiong說：
引用qianqian的發(fā)言：
個人理解，這應(yīng)該算是CloudFlare產(chǎn)品創(chuàng)新，相當(dāng)于他能提供一個PKI正常驗(yàn)證體系下的證書頒發(fā)機(jī)構(gòu)趾访，這個機(jī)構(gòu)可以用來為開啟KeyLess服務(wù)的站頒發(fā)證書
恩纷责，我也想知道cloudflare怎么解決證書的網(wǎng)站簽名問題掏熬。
銅礦說：
阮兄的頁面對手機(jī)瀏覽器支持不太好,現(xiàn)在很多人會用手機(jī)閱讀,建議針對移動瀏覽器做一些優(yōu)化
愛國者說：
DH算法雖然無需從客戶端發(fā)送pre-master key, 但server DH參數(shù)和client
DH參數(shù)應(yīng)該是明文發(fā)送的吧，加上前面兩個隨機(jī)數(shù)也是明文發(fā)送的改基，那第三者完全能通過抓包的辦法拿到server DH暑诸，client
DH以及前兩個隨機(jī)數(shù)县恕，然后自己生成會話密鑰惨缆。這樣后續(xù)的加密通信豈不是不安全糜值？
xoxo說：
引用xzy的發(fā)言：
這段話比較牽強(qiáng)了,有不同方案的集群session保存方案.
HTTPS服務(wù)器的底層SESSION內(nèi)存 很難集群丰捷。
楊歷說：
引用xzy的發(fā)言：
這段話比較牽強(qiáng)了,有不同方案的集群session保存方案.
作者說的是rfc5077坯墨，是傳輸層TLS通信的Session。不是應(yīng)用層HTTP的Session病往。
小勝說：
引用愛國者的發(fā)言：
DH算法雖然無需從客戶端發(fā)送pre-master key, 但server DH參數(shù)和client
DH參數(shù)應(yīng)該是明文發(fā)送的吧捣染，加上前面兩個隨機(jī)數(shù)也是明文發(fā)送的，那第三者完全能通過抓包的辦法拿到server DH停巷，client
DH以及前兩個隨機(jī)數(shù)耍攘，然后自己生成會話密鑰。這樣后續(xù)的加密通信豈不是不安全畔勤？
這里DH算法有說蕾各，有限域內(nèi)計(jì)算離散對數(shù)是幾乎不可能的任務(wù)；得到這些參數(shù)是比較難算出密鑰的庆揪；另外式曲，我覺得這篇文章只說明了SSL協(xié)議使用DH算法的情況吧，在試用RSA等其他算法的時候缸榛，是不是不用再生成密鑰對吝羞？服務(wù)器直接把公鑰傳給客戶端就直接傳輸數(shù)據(jù)了？求解惑内颗！
pimgeek說：
引用愛國者的發(fā)言：
DH算法雖然無需從客戶端發(fā)送pre-master key, 但server DH參數(shù)和client
DH參數(shù)應(yīng)該是明文發(fā)送的吧钧排，加上前面兩個隨機(jī)數(shù)也是明文發(fā)送的，那第三者完全能通過抓包的辦法拿到server DH均澳，client
DH以及前兩個隨機(jī)數(shù)恨溜，然后自己生成會話密鑰。這樣后續(xù)的加密通信豈不是不安全找前？
我也有同樣的困惑筒捺。后面小勝的回答，雖然聽起來很專業(yè)纸厉，信度很高系吭，但是他沒有因循作者的講解思路。
作者阮一峰的講解思路是說采用 DH 算法颗品，可以繞開Premaster secret被強(qiáng)行破解的風(fēng)險：
雖然理論上肯尺，只要服務(wù)器的公鑰足夠長（比如2048位）沃缘，那么Premaster secret可以保證不被破解。但是為了足夠安全则吟，………… 可以采用 DH 算法
而小勝的回答思路是：是說采用 DH 算法槐臀，在理論上也能保證Premaster secret不被破解，而且并沒說明從理論上看【原始算法】和【DH算法】哪個更容易被強(qiáng)行破解氓仲。
賈島說：
引用楊歷的發(fā)言：
作者說的是rfc5077水慨，是傳輸層TLS通信的Session。不是應(yīng)用層HTTP的Session敬扛。
是的晰洒，session ticket是保存在客戶端的，無需在服務(wù)端保存啥箭，因?yàn)閟ession ticket就是對話密鑰和加密方法經(jīng)過加密后的信息谍珊。
引用qalong的發(fā)言：
同意，現(xiàn)在大型應(yīng)用基本上都是集群環(huán)境急侥，session很少保存在一臺服務(wù)器上砌滞。很多都是用集中式session管理
是分布式緩存吧? 加上session容易丟失? 使用分布式緩存是非常好的? 也解決了只能在一臺機(jī)子上的問題
ranger_ray說：
引用pimgeek的發(fā)言：
而小勝的回答思路是：是說采用 DH 算法，在理論上也能保證Premaster secret不被破解坏怪，而且并沒說明從理論上看【原始算法】和【DH算法】哪個更容易被強(qiáng)行破解贝润。
這是DH算法的一個簡單描述：
1)? A隨機(jī)產(chǎn)生一個大整數(shù)a，然后計(jì)算Ka=ga mod n铝宵。（a需要保密）
2)? B隨機(jī)產(chǎn)生一個大整數(shù)b打掘，然后計(jì)算Kb=gb mod n。（b需要保密）
3)? A把Ka發(fā)送給B,B把Kb發(fā)送給A
4)? A計(jì)算K=Kba mod n
5)? B計(jì)算K=Kab mod n
由于Kba mod n= （gb mod n）a mod n= （ga mod n）b mod n捉超，因此可以保證雙方得到的K是相同的胧卤，K即是共享的密鑰。
意思是說client與server端都有一個隨機(jī)數(shù)是不會通過網(wǎng)絡(luò)傳輸?shù)钠丛馈Ｋ员ＷC了安全枝誊。
（所以感覺說明DH原理的那張圖，不是很貼切惜纸，不知道自己理解對不）
aya說：
如果服務(wù)器對客戶端認(rèn)證叶撒，而客戶端不用對服務(wù)器認(rèn)證，那么握手的過程應(yīng)該什么樣的呢耐版？
WT說：
真的好難啊祠够，和以前的學(xué)的東西混在一起，徹底暈了粪牲！
gg說：
這幾張圖的確說明的超級詳細(xì)容易理解~ DH那里原圖沒有具體說明不容易被破解的原因古瓤，現(xiàn)在實(shí)際使用起來配合其他工具的確保密性更高。話說，看完整篇文章落君，只看到SSL了穿香，沒看到TLS。绎速。皮获。
御劍飛星說：
引用gg的發(fā)言：
這幾張圖的確說明的超級詳細(xì)容易理解~ DH那里原圖沒有具體說明不容易被破解的原因，現(xiàn)在實(shí)際使用起來配合其他工具的確保密性更高纹冤。話說洒宝，看完整篇文章，只看到SSL了萌京，沒看到TLS雁歌。。枫夺。
TLS就是SSL的升級版将宪，原理都一樣的
鬼知道說：
我想知道绘闷，既然是用DH作為共享密鑰的生成和交換DH所需的隨機(jī)函數(shù)橡庞，那為什么還需要第一和第二階段的隨機(jī)函數(shù)呢？
Edem說：
ssl的流程寫的很清楚 贊一個
byronhe說：
https://blog.helong.info/blog/2015/09/06/tls-protocol-analysis-and-crypto-protocol-design/
供參考
mk說：
引用愛國者的發(fā)言：
DH算法雖然無需從客戶端發(fā)送pre-master key, 但server DH參數(shù)和client
DH參數(shù)應(yīng)該是明文發(fā)送的吧印蔗，加上前面兩個隨機(jī)數(shù)也是明文發(fā)送的扒最，那第三者完全能通過抓包的辦法拿到server DH，client
DH以及前兩個隨機(jī)數(shù)华嘹，然后自己生成會話密鑰吧趣。這樣后續(xù)的加密通信豈不是不安全？
CA的作用之一是來確保server的合法性 如果僅僅使用DH無法確保server的合法性耙厚，另外依舊存在被中間人攻擊的可能性
bobjiao說：
引用愛國者的發(fā)言：
DH算法雖然無需從客戶端發(fā)送pre-master key, 但server DH參數(shù)和client
DH參數(shù)應(yīng)該是明文發(fā)送的吧强挫，加上前面兩個隨機(jī)數(shù)也是明文發(fā)送的，那第三者完全能通過抓包的辦法拿到server DH薛躬，client
DH以及前兩個隨機(jī)數(shù)俯渤，然后自己生成會話密鑰。這樣后續(xù)的加密通信豈不是不安全型宝？
其實(shí)我也有同問,查了DH算法明白了.其實(shí)DH還是有自己的密鑰,這個密鑰由于計(jì)算離散對數(shù)是十分困難的,所以第三方很難破解或者說現(xiàn)今是不可能的.
load說：
引用xzy的發(fā)言：
這段話比較牽強(qiáng)了,有不同方案的集群session保存方案.
有大廠就是這種方案八匠，需要proxy server去一個共享存儲里面讀取
還有幾個請問下，就是如何跟源站之間協(xié)商session key趴酣，
源站的web server也需要做相應(yīng)改造吧
cloudflare的做法是否已經(jīng)被ssl的rfc文檔接受梨树？
字節(jié)流說：
第三節(jié)DH算法的握手階段的配圖，Visitor 是通過兩個隨機(jī)數(shù)生成的 session key岖寞，而 CloudFlare 是通過兩個隨機(jī)數(shù)和 Premaster secret 生成的 session key, 這兩個 session key 不應(yīng)該是相等的嗎抡四？不太理解，求指教仗谆。謝謝
xgqfrms說：
Defined
ProtocolYear
SSL 1.0n/a
SSL 2.01995
SSL 3.01996
TLS 1.01999
TLS 1.12006
TLS 1.22008
TLS 1.3TBD
別扭的鍵盤說：
敢問那個圖片是用什么軟件生成的
董光金說：
寫的很好指巡，很美跨释！大贊一個
mactec說：
阮老師
DH算法實(shí)際在TLS/SSL部署中并沒有RSA可靠，原因在于RSA的主要風(fēng)險在于服務(wù)器私鑰丟失后的第三方監(jiān)聽攻擊
而DH算法本身有缺陷厌处，中間人攻擊更為常見鳖谈，導(dǎo)致其實(shí)更為少用
pure說：
大圖不知道是掛了還是要VPN啊
振宇說：
引用mactec的發(fā)言：
阮老師
DH算法實(shí)際在TLS/SSL部署中并沒有RSA可靠，原因在于RSA的主要風(fēng)險在于服務(wù)器私鑰丟失后的第三方監(jiān)聽攻擊
而DH算法本身有缺陷阔涉，中間人攻擊更為常見缆娃，導(dǎo)致其實(shí)更為少用
朋友我對你的說法稍有異議，Server端的私鑰丟失這個屬于很大的故障了吧瑰排？
我認(rèn)為RSA算法的缺陷就是無法證明共匙被替換后贯要，導(dǎo)致的中間人攻擊問題。而DH算法本身也是無法避免中間人攻擊問題的椭住，所以在上面的實(shí)例圖中崇渗，阮老師加入了數(shù)字證書的邏輯。無論是RSA還是DH都需要客戶端通過CA的公共鑰匙解析到數(shù)字證書中存在的server端公鑰（rsa）京郑，說明一下這邊DH算法傳遞的公共數(shù)據(jù)我們也可當(dāng)公鑰來看（理解方便）宅广。
另外想請教一下層主，為什么DH更容易被中間人攻擊些举？
