9. TLS協(xié)議的安全分析
安全分析键科，重中之重钙勃，也是大家最關(guān)心的。
安全分析的第一步是建立攻擊模型慈参，TLS的攻擊模式是：
攻擊者有充足的計算資源
攻擊者無法得到私鑰玩讳，無法得到客戶端和服務(wù)器內(nèi)存里面的密鑰等保密信息
攻擊者可以抓包涩蜘，修改包，刪除包熏纯，重放包同诫，篡改包。
這個模型其實就是密碼學(xué)里面一般假定的攻擊模型豆巨。
好了剩辟，在這個模型下，TLS的安全性分析如下：
9.1. 認(rèn)證和密鑰交換 的安全性
TLS有三種認(rèn)證模式：雙方認(rèn)證往扔，服務(wù)器認(rèn)證，無認(rèn)證熊户。只要包含了有服務(wù)器端認(rèn)證萍膛，就可以免疫 man-in-the-middle 攻擊。但是完全匿名的會話是可以被 MITM 攻擊的嚷堡。匿名的服務(wù)器不能認(rèn)證客戶端蝗罗。
密鑰交換的目的，是產(chǎn)生一個只有通信雙方知道的共享密鑰 pre_master_secret 蝌戒。pre_master_secret 用來生成 master_secret 串塑。 master_secret 用來生成 Finished 消息，加密key北苟，和MAC key桩匪。通過發(fā)送正確的Finished消息，雙方可以證明自己知道正確的 pre_master_key友鼻。
9.1.1 匿名密鑰交換
匿名密鑰交換是一種歷史遺留的不安全方式傻昙。 匿名密鑰交換缺失認(rèn)證(Authentication)闺骚，所以絕大多數(shù)場景下，我們應(yīng)該禁用這種方式妆档。
9.1.2. RSA 密鑰交換和認(rèn)證
當(dāng)使用RSA的時候僻爽，合并了密鑰交換 和 服務(wù)器端認(rèn)證。RSA公鑰包含在服務(wù)器證書中贾惦。要注意的是胸梆，一旦服務(wù)器證書的RSA私鑰泄露，之前用該證書保護的所有流量都會變成可以破解的须板，即沒有前向安全性(Perfect Forward Secrecy)碰镜。需要前向安全性的TLS用戶，應(yīng)該使用 DHE 或者 EC TLS users desiring Perfect Forward Secrecy should use DHE 類的CcipherSuite逼纸。這樣洋措，如果私鑰泄露，只需要更換私鑰和證書就行杰刽，不會有更大的損失菠发。
RSA密鑰交換和認(rèn)證的安全性基于，在驗證了服務(wù)器的證書之后贺嫂，客戶端用服務(wù)器的公鑰加密一個 pre_master_secret 滓鸠。成功地解密 pre_master_secret 并產(chǎn)生正確地 Finished 消息之后，就可以確信服務(wù)器擁有證書對應(yīng)的私鑰第喳。
如果使用了客戶端認(rèn)證糜俗，通過 CertificateVerify 消息來認(rèn)證客戶端∏ィ客戶端會簽署一個之前所有握手消息的hash值悠抹，這些握手消息包括 服務(wù)器的證書，ServerHello.random 扩淀。其中服務(wù)器證書確毙ǖ校客戶端簽署了和本服務(wù)器有關(guān)的綁定(即不能重放和別的服務(wù)器的握手)，ServerHello.random 確保簽名和當(dāng)前握手流程綁定(即不能重放)驻谆。
9.1.3. Diffie-Hellman 密鑰交換和認(rèn)證
當(dāng)使用 DH 密鑰交換的時候卵凑，服務(wù)器:
或者發(fā)送包含固定 DH參數(shù)的證書
或者發(fā)送一組臨時DH參數(shù)，并用 ECDSA/RSA/DSA 證書的私鑰簽署胜臊。而且在簽署之前勺卢，臨時DH參數(shù)和 hello.random 都參與hash計算，來確保攻擊者不能重放老的簽名值象对。
無論如何黑忱，客戶端都可以通過驗證證書，或者驗證簽名，來確保收到的DH參數(shù)確實來自真正的服務(wù)器杨何。
如果客戶端有一個包含固定 Diffie-Hellman 參數(shù)的證書酱塔，則證書包含完成密鑰交換所需的參數(shù)。要注意的是危虱，這種情況下羊娃，客戶端和服務(wù)器每次都會協(xié)商出相同的 DH 結(jié)果(就是 pre_master_secret)。為了盡可能減少 pre_master_secret 存在在內(nèi)存里面的時間埃跷，當(dāng)不再需要的時候蕊玷，盡快將其清除，pre_master_secret 應(yīng)該盡早轉(zhuǎn)換成 master_secret 的形式弥雹。為了進行密鑰交換垃帅，客戶端發(fā)送的 Diffie-Hellman 參數(shù)必須和服務(wù)器發(fā)送的兼容。
如果客戶端有一個標(biāo)準(zhǔn)的 DSA 或者 RSA 證書剪勿，或者 客戶端沒有被認(rèn)證贸诚，那么客戶端在ClientKeyExchange中發(fā)送一組臨時參數(shù)，或者可選地發(fā)送一個CertificateVerify消息來證明自己的身份厕吉。
如果相同的 DH 密鑰對酱固，被多次用于握手協(xié)商，不管是由于客戶端或服務(wù)器使用了固定DH密鑰的證書头朱，還是服務(wù)器在重用 DH 密鑰运悲，都必須小心避免 small subgroup 攻擊。實現(xiàn)都必須遵循 rfc2785 中的標(biāo)準(zhǔn)项钮。
最簡單避免 small subgroup 攻擊的方法是使用一種 DHE CipherSuite班眯，并且每次都握手都生成一個新的 DH 私鑰 X。如果選擇了一個合適的base（例如2）烁巫，g^X mod p 的計算可以非呈鸢快，因而性能開銷會最小化亚隙。并且每次都使用一個新的DH密鑰定踱，可以提供前向安全性。當(dāng)使用? DHE 類的CipherSuite時恃鞋，實現(xiàn)必須每次握手都生成一個全新的DH私鑰（即 X ）。
由于TLS允許服務(wù)器提供任意的 DH 群亦歉，客戶端必須確認(rèn)服務(wù)器提供的DH 群的大小適合本地策略恤浪。客戶端必須確認(rèn) DH 公共指數(shù)有足夠的大小肴楷。如果DH群已知的話水由，客戶端做簡單比對就行了，因此服務(wù)器可以使用一個已知的群赛蔫，來方便客戶端的檢查砂客。
9.2. 版本回退攻擊
由于 TLS 歷史上出現(xiàn)過多個版本泥张，服務(wù)器端實現(xiàn)可能會兼容多個版本的協(xié)議，而像 SSL 2.0 這樣的版本是有嚴(yán)重安全問題的鞠值，因此攻擊者可能會嘗試誘騙客戶端和服務(wù)器媚创，來使TLS連接回退到 SSL 2.0這種老版本。
TLS 對此的解決辦法彤恶，就是PreMasterSecret里面包含版本號钞钙。
9.3. 針對握手過程的攻擊
攻擊者可能會嘗試影響握手過程，來使雙方選擇不安全的加密算法声离。
對這種攻擊的解決辦法是芒炼，如果握手消息被篡改了，那么在Finished消息里术徊，客戶端和服務(wù)器都會計算 握手消息的hash本刽，如果攻擊者篡改了握手消息，那么雙方得出的hash就不一樣赠涮，這樣Finished消息就會驗證不過子寓。就會發(fā)現(xiàn)攻擊。
9.4. 針對 Resuming Sessions 的攻擊
當(dāng)使用 session resuming的時候世囊，會產(chǎn)生新的 ClientHello.random 和 ServerHello.random 别瞭，并和session的 master_secret 一同被hash。只要master_secret沒有泄漏株憾，并且PRF中用來生成加密key和MAC key的hash算法是安全的蝙寨，連接就是安全的，并且獨立于前一個連接(被恢復(fù)的前一個連接)嗤瞎。
只有在客戶端和服務(wù)器都同意的情況下墙歪，才會做session resuming。只要有任意一方懷疑 session 泄漏贝奇，或者證書過期/被吊銷虹菲，就可以要求對端做完整的握手。一個session的生命周期建議定位24小時掉瞳。由于如果攻擊者獲得了 master_secret 就可以在session ID過期之前偽裝成被泄漏者毕源，所以要加一個生命期限制。運行在不安全環(huán)境的應(yīng)用程序陕习，不應(yīng)該把session ID寫入持久存儲霎褐。
9.5. 針對應(yīng)用數(shù)據(jù)保護的攻擊
master_secret 和 ClientHello.random 及? ServerHello.random 一起做 hash，來生成每個連接唯一的加密key和MAC key（就算是session resuming得到的連接该镣，也是不同的）冻璃。
在CBC和stream cipher的情況下，發(fā)送出去的數(shù)據(jù)，在發(fā)送前用MAC保護省艳，來避免消息重放娘纷，避免篡改。MAC根據(jù) MAC key跋炕，序列號赖晶，消息長度，消息內(nèi)容枣购，固定字符串算出嬉探。消息類型字段（content type）是必須的，來確保握手消息棉圈，ChangeCipherSpec消息涩堤，應(yīng)用數(shù)據(jù)消息不會被混淆。序列號用來確保刪除包或者打亂包順序的攻擊無法得逞分瘾。由于序列號是64位的胎围，可以認(rèn)為不會回繞。從一方發(fā)給對端的消息德召，不能被插入對端發(fā)來的字節(jié)流中白魂，這是用于兩端使用不同的 MAC key。類似地上岗，server write key 和 client write key相互獨立福荸。因此stream cipher的key只使用了一次，避免了類似問題肴掷。
如果攻擊者獲取了加密key敬锐，那么就可以解密所有的消息。類似地呆瞻，泄漏MAC key台夺，會使攻擊者可以篡改消息。
AEAD就簡單了痴脾。
9.6. 顯式 IV的安全性
如前文所述颤介，TLS 1.0是把前一條消息的最后一個block，當(dāng)作下一條消息的第一個IV的赞赖，這促成了2004年公開的 BEAST 攻擊滚朵，后來就改成這種顯式IV的更安全的方式了。
9.7. 加密和MAC組合模式的安全性
前文介紹CBC和AEAD時已有分析前域，此處略過始绍。
9.8. DOS 攻擊下的安全性
TLS容易遭受某些 DoS 攻擊。例如话侄，攻擊者創(chuàng)建很多TCP連接，就可以讓服務(wù)器忙于做 RSA 解密計算。然而年堆，由于TLS運行在TCP之上吞杭，只要操作系統(tǒng)TCP棧的 SYN-ACK里seqnum是隨機的，攻擊者就無法隱藏自己的ip变丧，這樣就可以和一般的TCP連接一樣做DOS防御芽狗。
由于TLS運行在TCP上，每個獨立的連接都可能遭受一系列DOS攻擊痒蓬。尤其是童擎，攻擊者可以偽造RST包，來中斷一條TCP+TLS連接攻晒」烁矗或者偽造部分TLS記錄，導(dǎo)致連接阻塞掛起鲁捏。不過這些攻擊都是任何TCP協(xié)議都有問題芯砸，不是TLS特有的。
9.9.Session Ticket 的安全分析
Ticket必須: 1.有MAC （即 authenticated给梅，不可篡改）假丧，2.加密（即保密）。
下面分析在各種攻擊方法下的安全性动羽。
9.9.1. 無效的Session
TLS協(xié)議要求當(dāng)發(fā)現(xiàn)錯誤的時候包帚，把TLS session變?yōu)闊o效。
這不會影響到ticket的安全性运吓。
9.9.1. 竊取 Tickets
攻擊者或者中間人渴邦，可能會竊取到ticket，并且嘗試用來和server建立會話羽德。然而几莽，由于ticket是加密過的，并且攻擊者不知道密鑰宅静，竊取到的ticket無法使攻擊者恢復(fù)會話章蚣。TLS服務(wù)器必須使用強加密和MAC算法，來保護ticket姨夹。
9.9.2. 偽造 Tickets
一個惡意用戶可能會偽造纤垂，或者篡改一個ticket，來恢復(fù)一個會話磷账，來延長ticket的生命周期峭沦，或者假裝成另一個用戶。
然而逃糟，由于服務(wù)器使用了強的校驗保護算法吼鱼，比如帶密碼的 HMAC-SHA1 蓬豁，因此無法得逞。
9.9.3. DoS 攻擊
推薦ticket 格式中的 key_name 字段幫助服務(wù)器有效地拒絕不是自己簽發(fā)的票據(jù)菇肃。因此地粪，一個攻擊者可能發(fā)送大量的ticket，讓服務(wù)器忙于驗證ticket琐谤。然而蟆技，只要服務(wù)器使用了高效的加密和MAC算法，就不會有問題斗忌。（現(xiàn)實中质礼，加密和MAC算法效率都極高，這根本不是問題）
9.9.4. 加密 Ticket 的key 的管理
加密ticket的key的管理织阳，推薦的做法：
key 應(yīng)該用密碼學(xué)安全的隨機數(shù)生成器生成眶蕉，按照RFC4086。
key 和加密算法最少應(yīng)該是 128 比特安全程度的陈哑。
key 除了加密和解密ticket以外妻坝，不應(yīng)該有其他用途。
key 應(yīng)該定期更換
當(dāng)ticket格式更換惊窖，或者算法更換時刽宪，應(yīng)該更換key
9.9.5. Ticket 的有效期
TLS服務(wù)器控制ticket的生命周期。服務(wù)器根據(jù)配置來決定可以接受的ticket生命周期界酒。ticket的生命周期可能會長于24小時圣拄。TLS客戶端可能會接受到一個ticket生命周期的提示，當(dāng)然毁欣，客戶端本地的策略最終決定ticket保存多久庇谆。
9.9.6. 其他的 Ticket 格式和分發(fā)方法
如果沒使用推薦的ticket格式，那必須小心地分析方案的安全性凭疮。尤其是饭耳，如果保密數(shù)據(jù)比如保密密鑰傳輸給了客戶端，那必須用加密方式傳輸执解，來防止泄露或篡改寞肖。
9.9.7. Identity Privacy, Anonymity, and Unlinkability
ticket的加密和加MAC，就保證了敏感信息不會泄露衰腌。
由于在ticket解密之前的TLS握手新蟆，無法隱藏客戶端的特征，因此中間人可能根據(jù)相同的ticket被復(fù)用右蕊，發(fā)現(xiàn)相同的ticket屬于相同的用戶琼稻。TLS對這種情況不提供保證。
10. TLS擴展:
https://tools.ietf.org/html/rfc6066
幾個比較重要的TLS擴展：
Server Name Indication (SNI)由于在SNI提出之前饶囚，tls握手過程中沒有字段標(biāo)明客戶端希望連接服務(wù)器端的哪個域名帕翻，這樣如果一個服務(wù)器端口上有多個域名鸠补，服務(wù)器就無法給出正確的證書。隨著ipv4地址空間緊張熊咽，這個問題越發(fā)突出莫鸭。因此提出了SNI。
TLSEXT_ALPN上層協(xié)議協(xié)商横殴，就是在握手過程中，標(biāo)明TLS里面是什么協(xié)議卿拴，例如 http2就是 h2
Maximum Fragment Length Negotiation主要用于嵌入式環(huán)境衫仑，需要客戶端發(fā)送。
Session TicketSession Ticket堕花，就是把session cache加密后存入客戶端文狱，這樣服務(wù)器端就不需要任何存儲了。
TLSEXT_SAFE_RENEGOTIATION重協(xié)商
Certificate Status Request:OCSP 缘挽，OCSP 主要是為了減少客戶端查詢 證書撤銷列表（Ceritificate Revoke List)的網(wǎng)絡(luò)調(diào)用瞄崇，而提出的。
11. TLS的配套：PKI體系
11.1. X.509? 證書
X.509是PKI的一個標(biāo)準(zhǔn)壕曼，其中內(nèi)容包括：
公鑰證書
證書撤銷列表苏研，CRL
證書路徑驗證算法（CA/證書 鏈的格式）
X.509使用ASN.1語法做序列化/反序列化
ASN1 就是一個數(shù)據(jù)序列化/反序列化格式，跟 protobuf 差不多腮郊，可以算作競爭對手摹蘑。
DER 就是用 ASN1 序列化某些數(shù)據(jù)結(jié)構(gòu)的格式。
PEM 就是 DER做base64轧飞，加上一些其他字段衅鹿。
證書鏈，以一個或多個CA證書開頭的證書的列表过咬，其中:
每一個證書的 Issuer 和下一個證書的 Subject 相同
每一個證書都被下一個證書的私鑰簽署
最后一個證書是 根證書(“root CA”)大渤，在TLS握手中不會被發(fā)送
證書里面包含公鑰，和其它一些字段（比如證書用途掸绞，有效期泵三，簽發(fā)者等等）x509.v3證書的字段：
mozilla的ca證書列表https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
https://www.apple.com/certificateauthority/ca_program.html蘋果對CA提的要求：
1.CA必須取得完整的 WebTrust for Certification Authorities audit （WebTrust CA審計：http://www.webtrust.org/）2.你的root CA證書必須為apple平臺的用戶提供廣泛的商業(yè)價值。例如集漾，一個組織內(nèi)內(nèi)部使用的證書不能被接受為root證書切黔。3.你簽的證書必須含有可以公開訪問的CRL地址。
Webtrust審計介紹：Webtrust是由世界兩大著名注冊會計師協(xié)會（美國注冊會計師協(xié)會具篇，AICPA和加拿大注冊會計師協(xié)會纬霞，CICA）制定的安全審計標(biāo)準(zhǔn)，主要對申請對象的系統(tǒng)及業(yè)務(wù)運作邏輯安全性驱显、保密性等共計七項內(nèi)容進行近乎嚴(yán)苛的審查和鑒證诗芜。只有通過Webtrust國際安全審計認(rèn)證瞳抓，才有可能成為全球主流瀏覽器根信任的證書簽發(fā)機構(gòu)。
https://www.geotrust.com/的網(wǎng)站上右下角伏恐，有個圖標(biāo): 點開就可以看到 KPMG 對 geotrust 公司的 webtrust 審計報告:https://cert.webtrust.org/SealFile?seal=1567&file=pdf
2011年 荷蘭CA公司DigiNotar頒發(fā)假google孩哑，F(xiàn)acebook，微軟證書被發(fā)現(xiàn)翠桦，后發(fā)現(xiàn)被入侵横蜒，導(dǎo)致該公司破產(chǎn)。http://www.cnbeta.com/articles/154375.htm
11.2.現(xiàn)有PKI體系暴露出的問題
http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html
https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/
https://www.dfn-cert.de/dokumente/workshop/2013/FolienSmith.pdf
https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
解決方案：
(1). public key pin
https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
(2). HSTS
http://www.chromium.org/hsts收錄進chrome的默認(rèn)HSTS列表：? https://hstspreload.appspot.com/
(3).? Certificate Transparency
https://www.certificate-transparency.org/
12. TLS協(xié)議歷史上出現(xiàn)過的漏洞销凑，密碼學(xué)常見陷阱
12.1. TLS的漏洞
漏洞分析很耗時間丛晌，這里總結(jié)一些資料，有興趣的自己看吧斗幼。
雖然TLS的設(shè)計已經(jīng)盡可能的嚴(yán)密澎蛛，但是隨著技術(shù)進步的滾滾車輪，歷史上還是出現(xiàn)過很多漏洞蜕窿，可以參看這個rfc谋逻，做了總結(jié)：
[Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)] 鏈接 https://tools.ietf.org/html/rfc7457
還有這個文檔：[The Sorry State Of SSL] 鏈接 https://hynek.me/talks/tls/
http://hyperelliptic.org/internetcrypto/OpenSSLPresentation.pdf
TLS 協(xié)議最近一些年被爆出過的設(shè)計缺陷，尤其是在用的最多的 AES-CBC 和 RC4 上桐经。
AES-CBC 發(fā)現(xiàn)了:
padding oracle 攻擊
BEAST 攻擊
Lucky 13 攻擊
TIME 攻擊
POODLE攻擊
2013 年, AlFardan發(fā)表了對 RC4 的一個攻擊分析毁兆，展示如何恢復(fù) RC4 傳輸?shù)倪B接上的數(shù)據(jù)。這種恢復(fù)攻擊利用了RC4的一些已知弱點次询，例如RC4最初的一些字節(jié)的顯著統(tǒng)計特征荧恍。
最近幾年，TLS的代碼實現(xiàn)引起了安全研究者的關(guān)注屯吊，這導(dǎo)致了新漏洞不斷發(fā)現(xiàn)送巡。2014年，OpenSSL庫爆出了好幾個漏洞盒卸，例如 HeartBleed骗爆，還有 CVE-2014-6321 ( Microsoft SChannel 的實現(xiàn)漏洞)等.
TLS的問題:
? 很多問題是由于TLS使用了一些“史前時代”的密碼學(xué)算法(- Eric Rescorla)? CBC 和 Mac-Pad-then-Encrypt? RSA-PKCS#1v1.5 的 RSA padding? RC4 的任何使用? 很蠢的設(shè)計：臨時 RSA 密鑰協(xié)商，GOST 類CipherSuite蔽介，Snap Start 等? 可怕的向后兼容要求摘投，導(dǎo)致遲遲不能廢棄一些老算法。
The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software
http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
[Why Eve and Mallory Love Android An Analysis of Android SSL (In)Security] 鏈接 https://www.dfn-cert.de/dokumente/workshop/2013/FolienSmith.pdf
12.2. 密碼學(xué)常見陷阱
先舉幾個加密協(xié)議被破解的例子虹蓄，給大家助興：
[人人網(wǎng)使用256比特RSA加密登錄密碼犀呼，3分鐘可破] 鏈接 https://www.91ri.org/8928.html
[Flickr length extension attack 漏洞] 鏈接 http://www.happybearsoftware.com/you-are-dangerously-bad-at-cryptography.html
[分析whatsapp協(xié)議缺陷的一個文章] 鏈接 https://blog.thijsalkema.de/blog/2013/10/08/piercing-through-whatsapp-s-encryption/
[衛(wèi)星電話的私有g(shù)mr-1/gmr-2加密算法被逆向并破解] 鏈接 https://cryptanalysis.eu/blog/2012/02/02/dont-trust-satellite-phones-the-gmr-1-and-gmr-2-ciphers-have-been-broken/
http://cryptofails.blogspot.ca/2013/07/cakephp-using-iv-as-key.html
http://cryptofails.blogspot.ca/2013/07/saltstack-rsa-e-d-1.html
網(wǎng)上有一些資料，有興趣自己看吧:
https://www.schneier.com/essays/archives/1998/01/security_pitfalls_in.html
https://www.schneier.com/essays/archives/1999/03/cryptography_the_imp.html
http://www.lauradhamilton.com/10-cryptography-mistakes-amateurs-make
http://cryptofails.blogspot.ca/
密碼學(xué)常見應(yīng)用錯誤http://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology
不要自己發(fā)明加密算法薇组。Don’t roll your own crypto.
不要使用不帶MAC的加密 Don’t use encryption without message authentication.
在拼接多個字符串做hash之前外臂，要特別小心 Be careful when concatenating multiple strings, before hashing.
要特別小心使用的隨機數(shù)生成器，確保有足夠的熵 Make sure you seed random number generators with enough entropy.
不要重用 nonce 或者律胀。IV Don’t reuse nonces or IVs.
加密和MAC不要使用同樣的key宋光，非對稱加密和簽名不要使用相同的key Don’t use the same key for both encryption and authentication. Don’t use the same key for both encryption and signing.
不要使用ECB模式做對稱加密 Don’t use a block cipher with ECB for symmetric encryption
Kerckhoffs定律貌矿，一個密碼學(xué)系統(tǒng)的安全性必須建立在密碼保密的基礎(chǔ)上，其他都是公開的罪佳。Kerckhoffs’s principle: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge
不要把用戶產(chǎn)生的密碼作為加密的key逛漫。Try to avoid using passwords as encryption keys.
在密碼學(xué)協(xié)議中，任何2條消息的密文都不應(yīng)該一樣赘艳。In a cryptographic protocol: Make every authenticated message recognisable: no two messages should look the same
不要把相同的key用在通信的2個方向上酌毡。Don’t use the same key in both directions.
不要使用不安全的key長度。Don’t use insecure key lengths.
…
13. 下一代TLS: TLS 1.3
tls 1.3的草案在 http://tlswg.github.io/tls13-spec/相比tls 1.2,? 1.3改動巨大蕾管，這些改動對加密通信協(xié)議的一般設(shè)計也有重要啟發(fā)阔馋。
TLS 1.3 的改動值得關(guān)注的重大改進有：
0-RTT支持
1-RTT握手支持
改為使用HKDF做密鑰拓展
徹底禁止RC4
徹底禁止壓縮
徹底禁止aead以外的其他算法
去除aead的顯式IV
去除了AEAD的AD中的長度字段
去除ChangeCipherSpec
去除重協(xié)商
去除靜態(tài)RSA和DH密鑰協(xié)商
移動互聯(lián)網(wǎng)興起之后，rtt延遲變得更重要娇掏，可以看到，tls 1.3 的各項改進勋眯，主要就是針對移動互聯(lián)網(wǎng)場景的婴梧。
TLS 1.3 去掉了 ChangeCipherSpec ，這樣record之上有3個協(xié)議：handshake客蹋，alert塞蹭，application data
13.1. record層的密碼學(xué)保護的改動
由于只保留了aead，所以不需要MAC key了讶坯。
aead的具體參數(shù)用法也有調(diào)整番电，前文有。
KDF 換成了標(biāo)準(zhǔn)的HKDF辆琅，有2種 tls_kdf_sha256, tls_kdf_sha384
13.2.handshake協(xié)議的改動
鑒于session ticket如此之好用漱办，簡直人見人愛，所以 TLS 1.3 直接把session ticket內(nèi)置了婉烟，并改名叫 PSK
要注意的是娩井，此 PSK 和 tls 1.2中一個很生僻的psk(見 [rfc4279] 鏈接 https://tools.ietf.org/html/rfc4279 )并不是一回事。
綜合考慮了 session resuming 似袁，session ticket后洞辣，TLS 1.3 提出了3種handshake模式：
Diffie-Hellman （ 包含 DH 和 ECDH 兩種，下文說到 ECDH 的地方昙衅，請自行腦補成 “ECDH/DH”）.
A pre-shared symmetric key (PSK) 扬霜，預(yù)先共享的對稱密鑰，此處用統(tǒng)一的模型來處理session resuming 和 rfc4279的psk
A combination of a symmetric key and Diffie-Hellman 而涉，前兩者合體
13.3. 1-RTT 握手
首先著瓶，TLS 1.2 的握手有2個rtt，第一個rtt是 ClientHello/ServerHello婴谱，第二個rtt是ClientKeyExchange/ServerKeyExchange蟹但，之所以KeyExchange要放在第二個rtt躯泰，是由于tls1.2要支持多種密鑰交換算法，和各種不同參數(shù)(比如 DH還是ECDH還是RSA华糖，ECDHE用什么曲線麦向，DH用什么群生成元，用什么模數(shù)客叉，等等)诵竭，這些算法和參數(shù)都依賴第一個rtt去協(xié)商出來，TLS1.3大刀闊斧地砍掉了各種自定義DH群兼搏，砍掉了ECDH的自定義曲線卵慰，砍掉了RSA協(xié)商，密鑰協(xié)商的算法只剩下不多幾個佛呻，而且其實大家實際應(yīng)用中基本都用 ECDH P-256裳朋，也沒啥人用別的，所以干脆讓客戶端緩存服務(wù)器上一次用的是啥協(xié)商算法吓著，把 KeyExchange直接和入第一個rtt鲤嫡，客戶端在第一個rtt里直接就用緩存的這個算法發(fā)KeyExchange的公鑰，如果服務(wù)器發(fā)現(xiàn)客戶端發(fā)上來的算法不對绑莺，那么再告訴正確的暖眼，讓客戶端重試好了。這樣纺裁，就引入了 HelloRetryRequest 這個消息诫肠。
這樣，基本沒有副作用欺缘，就可以降到 1-RTT栋豫。這是TLS 1.3 的完整握手。
顯然浪南，如果一個協(xié)議只有一種密鑰協(xié)商算法笼才，比如定死為 ECDH P-256，那一定可以做到 1-RTT
13.4.? 有副作用的 0-RTT握手
0-RTT應(yīng)該是受Google的QUIC協(xié)議的啟發(fā)络凿，如果服務(wù)器把自己的 ECDH 公鑰長期緩存在客戶端骡送，那么客戶端就可以用緩存里的ECDHE公鑰，構(gòu)造一個電子信封絮记，在第一個RTT里摔踱，直接就發(fā)送應(yīng)用層數(shù)據(jù)了。這個長期緩存在客戶端的ECDH公鑰怨愤，稱為 半靜態(tài) ECDH 公鑰（ semi-static (EC)DH share ）ECDH公鑰通過 ServerConfiguration 消息發(fā)送給客戶端派敷。
這個0-rtt優(yōu)化是有副作用的：
0-RTT發(fā)送的應(yīng)用數(shù)據(jù)沒有前向安全性。
跨連接可以重放0-RTT里的應(yīng)用數(shù)據(jù)（任何服務(wù)器端無共享狀態(tài)的協(xié)議，都無法做到跨連接防重放）
如果服務(wù)器端 半靜態(tài) ECDH公鑰對應(yīng)的私鑰泄露了篮愉，攻擊者就可以偽裝成客戶端隨意篡改數(shù)據(jù)了峡钓。
服務(wù)器在 ServerConfiguration 消息里把半靜態(tài) ECDH 公鑰發(fā)送給客戶端催植。ServerConfiguration 值得關(guān)注一下：
struct {
?? opaque configuration_id<1..2^16-1>;
?? uint32 expiration_date;
?? NamedGroup group;
?? opaque server_key<1..2^16-1>;
?? EarlyDataType early_data_type;
?? ConfigurationExtension extensions<0..2^16-1>;
} ServerConfiguration;
其中的 expiration_date 是本 ServerConfiguration 最后的有效期限。這個值絕對不允許大于7天≡壳客戶端絕對不允許存儲 ServerConfiguration 大于7天倡缠，不管服務(wù)器怎么填這個值垦沉。
0-RTT 中的應(yīng)用數(shù)據(jù)辈讶，放在 EarlyDataIndication 中發(fā)送，
TLS 1.3 還特意給 EarlyDataIndication? 定義了一種 ContentType : early_handshake（共四種 alert(21), handshake(22),? ? application_data(23), early_handshake(25) ）
13.5.? Resumption 和? PSK
TLS 1.3 里面犀被，把session resumption/session ticket 恢復(fù)出來的key椅您，和 psk (rfc4279)， 統(tǒng)一在一個 handshake PSK 模式下處理寡键。
PSK CipherSuite可以 把PSK和ECDHE結(jié)合起來用掀泳，這樣是有前向安全性的。也可以僅僅使用PSK西轩，這樣就沒有前向安全性开伏。
13.6. Key Schedule 過程的改動
TLS 1.3 中，綜合考慮的 session ticket的各種情況后遭商，提出了 ES，SS 兩個概念捅伤，統(tǒng)一處理密鑰協(xié)商的各種情況劫流。在各種handshake模式下，ES和SS的取值來源不同丛忆。
Ephemeral Secret (ES):? 每個連接新鮮的 ECDHE 協(xié)商得出的值祠汇。凡是從 ES 得出的值，都是前向安全的（當(dāng)然熄诡，在 PSK only模式下可很，不是前向安全的）。
Static Secret (SS):? 從靜態(tài)凰浮，或者半靜態(tài)key得出的值我抠。例如psk，或者服務(wù)器的半靜態(tài) ECDH 公鑰袜茧。
在各種 handshake 模式下：
Key ExchangeStatic Secret (SS)Ephemeral Secret (ES)
(EC)DHE (完整握手)Client ephemeral? w/ server ephemeralClient ephemeral w/ server ephemeral
(EC)DHE (w/ 0-RTT)Client ephemeral w/ server staticClient ephemeral w/ server ephemeral
PSKPre-Shared KeyPre-shared key
PSK + (EC)DHEPre-Shared KeyClient ephemeral? w/ server ephemeral
如上表所示：
完整的 1-RTT握手的時候菜拓， SS 和 ES 都是用的 ephemeral key ，這樣是一定有前向安全性的笛厦。
使用 0-RTT 的握手的時候纳鼎，使用客戶端的 ephemeral key 和 服務(wù)器端的半靜態(tài) ECDH 公鑰生成 SS，
純 PSK，這種場景完全沒有前向安全性贱鄙，應(yīng)該避免劝贸。
PSK + ECDHE，這種場景比較有意思逗宁，SS是用的Pre-Shared Key映九，沒有前向安全性，ES 用的 ephemeral key疙剑，有前向安全性氯迂。
可以看到，相比 TLS 1.2 的 session ticket言缤，TLS 1.3 中 的 PSK + ECDHE嚼蚀，是結(jié)合了 ES 的，這樣就有了前向安全性管挟，相對更安全轿曙。
和 TLS 1.2 不同的是，TLS 1.3的 master_secret 是使用 ES和SS 兩個得出的僻孝。
HKDF-Expand-Label(Secret, Label, HashValue, Length) =
? ? HKDF-Expand(Secret, Label + '\0' + HashValue, Length)1. xSS = HKDF(0, SS, "extractedSS", L)2. xES = HKDF(0, ES, "extractedES", L)3. master_secret = HKDF(xSS, xES, "master secret", L)4. finished_secret = HKDF-Expand-Label(xSS, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "finished secret",
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? handshake_hash, L)
Traffic Key Calculation
加密流量用的key导帝，在 TLS 1.3 里面稱為 Traffic Key，由于多引入了一種ContentType穿铆，在不同的ContentType下您单，Traffic Key 并不相同。如下表：
Record TypeSecretLabelHandshake Hash
Early dataxSS“early data key expansion”ClientHello
HandshakexES“handshake key expansion”ClientHello…? ? ServerKeyShare
Applicationmaster secret“application data key expansion”All handshake messages but? Finished
要關(guān)注的是荞雏， Early Data 的 Traffic Key 是用 xSS 算出來的虐秦。也就是說，是用 Pre-Shared Key決定的凤优。因此是沒有前向安全性的悦陋。
在一個TLS 連接中，究竟是用哪種 handshake 模式筑辨，是由 CipherSuite 協(xié)商決定的俺驶。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 本文轉(zhuǎn)自微信后臺團隊,如有侵犯,請聯(lián)系我們立即刪除
OpenIMgithub開源地址：
https://github.com/OpenIMSDK/Open-IM-Server
OpenIM官網(wǎng) ： https://www.rentsoft.cn
OpenIM官方論壇： https://forum.rentsoft.cn/
更多技術(shù)文章：
開源OpenIM：高性能、可伸縮棍辕、易擴展的即時通訊架構(gòu)https://forum.rentsoft.cn/thread/3
【OpenIM原創(chuàng)】簡單輕松入門 一文講解WebRTC實現(xiàn)1對1音視頻通信原理https://forum.rentsoft.cn/thread/4
【OpenIM原創(chuàng)】開源OpenIM：輕量暮现、高效、實時楚昭、可靠送矩、低成本的消息模型https://forum.rentsoft.cn/thread/1
