一儿子、Https介紹
1. 什么是Https
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer）郑原，是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版茸习。即HTTP下加入SSL層畜隶，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL
2. Https的作用
- 內(nèi)容加密 建立一個(gè)信息安全通道号胚，來(lái)保證數(shù)據(jù)傳輸?shù)陌踩?/li>
- 身份驗(yàn)證 確認(rèn)網(wǎng)站的真實(shí)性籽慢；
- 數(shù)據(jù)完整性 防止內(nèi)容被第三方冒充或者篡改
3. Https的劣勢(shì)
對(duì)數(shù)據(jù)進(jìn)行加密決定了它比http慢
需要進(jìn)行非對(duì)稱的加解密，且需要三次握手猫胁。首次連接比較慢箱亿，當(dāng)然現(xiàn)在也有很多的優(yōu)化。
出于安全考慮弃秆，瀏覽器不會(huì)在本地保存HTTPS緩存届惋。實(shí)際上髓帽，只要在HTTP頭中使用特定命令，HTTPS是可以緩存的脑豹。Firefox默認(rèn)只在內(nèi)存中緩存HTTPS郑藏。但是，只要頭命令中有Cache-Control: Public瘩欺，緩存就會(huì)被寫到硬盤上必盖。IE只要http頭允許就可以緩存https內(nèi)容，緩存策略與是否使用HTTPS協(xié)議無(wú)關(guān)击碗。
4. HTTPS和HTTP的區(qū)別
- https協(xié)議需要到CA申請(qǐng)證書(shū)
- http是超文本傳輸協(xié)議筑悴，信息時(shí)明文傳輸；https則是具有安全性的ssl加密傳輸協(xié)議
- http和https使用的是完全不同的連接方式稍途，用的端口也不一樣，前者是80砚婆，后者是443
- http的連接很簡(jiǎn)單械拍，是無(wú)狀態(tài)的；https協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸装盯、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議坷虑，比http協(xié)議安全
下面就是https的整個(gè)構(gòu)架，現(xiàn)在的https基本都使用TLS了埂奈，因?yàn)楦影踩穑韵聢D中SSL應(yīng)該換成SSL/TLS。
下面就上圖中的知識(shí)點(diǎn)進(jìn)行一個(gè)大概的介紹账磺。
二芹敌、加解密相關(guān)知識(shí)
1. 對(duì)稱加密
對(duì)稱加密（也叫私鑰加密）指加密和解密使用相同密鑰的加密算法。有時(shí)又叫傳統(tǒng)密碼算法垮抗，就是加密密鑰能夠從解密密鑰中推算出來(lái)氏捞，同時(shí)解密密鑰也可以從加密密鑰中推算出來(lái)。而在大多數(shù)的對(duì)稱算法中冒版，加密秘鑰和解密密鑰是相同的液茎，所以也稱這種加密算法為秘密密鑰算法或者單密鑰算法。
常見(jiàn)的對(duì)稱加密有：DES（Data Encryption Standard）辞嗡、AES（Advanced Encryption Standard）捆等、RC4、IDEA
2. 非對(duì)稱加密
與對(duì)稱加密算法不同续室，非對(duì)稱加密算法需要兩個(gè)密鑰：公開(kāi)密鑰（publickey）和私有密鑰（privatekey）栋烤；并且加密密鑰和解密密鑰是成對(duì)出現(xiàn)的。非對(duì)稱加密算法在加密和解密過(guò)程使用了不同的密鑰猎贴，非對(duì)稱加密也稱為公鑰加密班缎，在密鑰對(duì)中蝴光，其中一個(gè)密鑰是對(duì)外公開(kāi)的，所有人都可以獲取到达址，稱為公鑰蔑祟，另一個(gè)密鑰是不公開(kāi)的稱為私鑰。
非對(duì)稱加密算法對(duì)加密內(nèi)容的長(zhǎng)度有限制沉唠，不能超過(guò)公鑰長(zhǎng)度疆虚。比如現(xiàn)在常用的公鑰長(zhǎng)度是2048位，意味著加密內(nèi)容不能超過(guò)256個(gè)字節(jié)满葛。
3. 摘要算法
數(shù)字摘要是采用單項(xiàng)Hash函數(shù)將需要加密的明文“摘要”成一串固定長(zhǎng)度（128位）的密文径簿，這一串密文又稱為數(shù)字指紋，它有固定的長(zhǎng)度嘀韧，而且不同的明文摘要成密文篇亭，其結(jié)果總是不同的，而同樣的明文其摘要必定一致锄贷∫氲伲“數(shù)字摘要”是https能確保數(shù)據(jù)完整性和防篡改的根本原因。
4. 數(shù)字簽名
數(shù)字簽名技術(shù)就和對(duì)“非對(duì)稱密鑰加解密”和“數(shù)字摘要”兩項(xiàng)技術(shù)的應(yīng)用谊却，它將摘要信息用發(fā)送者的私鑰加密柔昼，與原文一起傳送給接收者。接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息炎辨，然后用HASH函數(shù)對(duì)收到的原文產(chǎn)生一個(gè)摘要信息捕透，與解密的摘要信息對(duì)比。如果相同碴萧，則說(shuō)明收到的信息是完整的乙嘀，在傳輸過(guò)程中沒(méi)有被修改，否則說(shuō)明信息被修改過(guò)勿决，因此數(shù)字簽名能夠驗(yàn)證信息的完整性乒躺。
數(shù)字簽名的過(guò)程如下：
明文 ——> hash算法 ——> 摘要 ——> 私鑰加密 ——> 數(shù)字簽名
數(shù)字簽名有兩種功效：
一、能確定消息確實(shí)是由發(fā)送方簽名并發(fā)出來(lái)的低缩，因?yàn)閯e人假冒不了發(fā)送方的簽名嘉冒。
二、數(shù)字簽名能確定消息的完整性咆繁。
注意：
數(shù)字簽名只能驗(yàn)證數(shù)據(jù)的完整性讳推，數(shù)據(jù)本身是否加密不屬于數(shù)字簽名的控制范圍
5. 數(shù)字證書(shū)
1）為什么要有數(shù)字證書(shū)？
對(duì)于請(qǐng)求方來(lái)說(shuō)玩般，它怎么能確定它所得到的公鑰一定是從目標(biāo)主機(jī)那里發(fā)布的银觅，而且沒(méi)有篡改過(guò)呢？亦或這請(qǐng)求的目標(biāo)主機(jī)本身就從事竊取用戶信息的不正當(dāng)行為呢坏为？這時(shí)候究驴，我們需要有一個(gè)權(quán)威的值得信賴的第三方機(jī)構(gòu)（一般由政府審核并授權(quán)的機(jī)構(gòu)）來(lái)統(tǒng)一對(duì)外發(fā)放主機(jī)機(jī)構(gòu)的公鑰镊绪，只要請(qǐng)求方這種機(jī)構(gòu)獲取公鑰，就避免了上述問(wèn)題的發(fā)生洒忧。
2）數(shù)字證書(shū)的頒發(fā)過(guò)程
用戶首先產(chǎn)生自己的密鑰對(duì)蝴韭，并將公鑰及部分個(gè)人身份信息傳送給認(rèn)證中心。認(rèn)證中心在核實(shí)身份后熙侍，將執(zhí)行一些必要的步驟榄鉴，以確信請(qǐng)求確實(shí)由用戶發(fā)送而來(lái)，然后認(rèn)證中心將發(fā)給用戶一個(gè)數(shù)字證書(shū)蛉抓，該證書(shū)包含用戶的個(gè)人信息和他的公鑰信息庆尘，同時(shí)還附有認(rèn)證中心的簽名信息（根證書(shū)私鑰簽名）。用戶就可以使用該證書(shū)進(jìn)行相關(guān)的各種活動(dòng)巷送。數(shù)字證書(shū)由獨(dú)立的證書(shū)頒發(fā)機(jī)構(gòu)發(fā)布驶忌，數(shù)字證書(shū)各不相同，每種證書(shū)可提供不同級(jí)別的可信度笑跛。
3）證書(shū)包含哪些內(nèi)容
- 證書(shū)頒發(fā)機(jī)構(gòu)的名稱
- 證書(shū)本身的數(shù)字簽名
- 證書(shū)持有者公鑰
- 證書(shū)簽名用到的Hash算法（轉(zhuǎn)載者理解：原文轉(zhuǎn)摘要用到位岔，參見(jiàn)下面驗(yàn)證證書(shū)的有效性第3條）
4）驗(yàn)證證書(shū)的有效性
瀏覽器默認(rèn)都會(huì)內(nèi)置CA根證書(shū)，其中根證書(shū)包含了CA的公鑰
- 證書(shū)頒發(fā)的機(jī)構(gòu)時(shí)偽造的：瀏覽器不認(rèn)識(shí)堡牡，直接認(rèn)為是危險(xiǎn)證書(shū)
- 證書(shū)頒發(fā)的機(jī)構(gòu)確實(shí)存在，于是根據(jù)CA名杨刨，找到對(duì)應(yīng)內(nèi)置的CA根證書(shū)晤柄、CA的公鑰。用CA的公鑰妖胀，對(duì)偽造的證書(shū)的摘要進(jìn)行解密芥颈，發(fā)現(xiàn)解不了，認(rèn)為是危險(xiǎn)證書(shū)赚抡。
- 對(duì)于篡改的證書(shū)爬坑，是喲CA的公鑰對(duì)數(shù)字簽名進(jìn)行解密得到摘要A，然后再根據(jù)簽名的HASH算法計(jì)算出證書(shū)的摘要B涂臣，對(duì)比A與B盾计，若相等則正常，否則就是被篡改過(guò)的赁遗。
- 證書(shū)可在其過(guò)期前被吊銷署辉，通常情況是該證書(shū)的私鑰已經(jīng)失密。較新的瀏覽器如Chrome岩四、Firefox哭尝、Opera和Internet Explorer都實(shí)現(xiàn)了在線證書(shū)狀態(tài)協(xié)議（OCSP）以排除這種情況：瀏覽器將網(wǎng)站提供的證書(shū)的序列號(hào)通過(guò)OCSP發(fā)送給證書(shū)頒發(fā)機(jī)構(gòu)，后者會(huì)告訴瀏覽器證書(shū)是否還是有效的剖煌。
三材鹦、SSL與TLS
1. SSL（Secure Socket Layer逝淹，安全套接字層）
SSL為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸之安全桶唐，利用數(shù)據(jù)加密技術(shù)栅葡，可確保數(shù)據(jù)在網(wǎng)絡(luò)上傳輸過(guò)程中不會(huì)被截取，當(dāng)前為3.0版本莽红。
SSL協(xié)議可分為兩層：SSL記錄協(xié)議（SSL Recore Protocol）：它建立在可靠地傳輸協(xié)議（如TCP）之上妥畏，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮安吁、加密等基本功能的支持醉蚁。SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開(kāi)始前鬼店，通訊雙方進(jìn)行身份證网棍、協(xié)商加密算法、交換加密密鑰等妇智。
2. TLS（Transport Layer Security滥玷，傳輸層安全協(xié)議）
用于兩個(gè)應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。
TLS 1.0是IETF（Internet Engineering Task Force巍棱，Internet工程任務(wù)組）制定的一種新的協(xié)議惑畴，它建立在SSL 3.0協(xié)議規(guī)范之上，是SSL 3.0的后續(xù)版本航徙，可以理解為SSL 3.1如贷，它是寫入了RFC的。該協(xié)議由兩層組成：TLS記錄協(xié)議（TLS Recore）和TLS握手協(xié)議（TLS Handshake）到踏。較低的層為TLS記錄協(xié)議杠袱，位于某個(gè)可靠的傳輸協(xié)議（例如TCP）上面。
3. SSL/TLS協(xié)議作用：
- 認(rèn)證用戶和服務(wù)器窝稿，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器楣富；（意思是HTTP的可能會(huì)發(fā)送到不正確的客戶機(jī)和服務(wù)器）
- 加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取伴榔；
- 維護(hù)數(shù)據(jù)的完整性纹蝴，確保數(shù)據(jù)在傳輸過(guò)程中不被改變。
4. TLS比SSL的優(yōu)勢(shì)
對(duì)于消息認(rèn)證使用密鑰散列法：TLS使用“
消息認(rèn)證代碼的密鑰散列法”（HMAC）潮梯，當(dāng)記錄在開(kāi)放的網(wǎng)絡(luò)（如因特網(wǎng)）上傳送時(shí)骗灶，該代碼確保記錄不會(huì)被變更。SSLv3.0使用的是鍵控消息認(rèn)證（MAC）秉馏，但HMAC比MAC功能更安全耙旦。增強(qiáng)的偽隨機(jī)功能（PRF）：PRF生成密鑰數(shù)據(jù)。在TLS中，HMAC定義PRF免都。PRF使用兩種散列算法保證其安全性锉罐。如果任一算法暴露了，只要第二種算法未暴露绕娘，則數(shù)據(jù)仍然是安全的脓规。
改進(jìn)的已完成消息驗(yàn)證：TLS和SSLv3.0都對(duì)兩個(gè)端點(diǎn)提供已完成的消息，該消息認(rèn)證交換的消息沒(méi)有被變更险领。然而侨舆，TLS將此已完成消息基于PRF和HMAC值之上，這也比SSLv3.0更安全绢陌。
一致證書(shū)處理：與SSLv3.0不同挨下，TLS試圖指定必須在TLS之間實(shí)現(xiàn)交換的證書(shū)類型。
特定警報(bào)消息：TLS提供更多的特定和附加警報(bào)脐湾，以指示任一會(huì)話端點(diǎn)檢測(cè)到的問(wèn)題臭笆。TLS還對(duì)何時(shí)應(yīng)該發(fā)送某些警報(bào)進(jìn)行記錄。
5. SSL秤掌、TLS的握手過(guò)程
SSL與TLS握手整個(gè)過(guò)程如下圖所示愁铺，下面會(huì)詳細(xì)介紹每一步的具體內(nèi)容：
1）客戶端首次發(fā)出請(qǐng)求
由于客戶端（如瀏覽器）對(duì)一些加密算法的支持程度不一樣，但在TLS協(xié)議傳輸過(guò)程中必須使用同一套加解密算法才能保證數(shù)據(jù)能夠正常的加解密闻鉴。在TLS握手階段茵乱，客戶端首先要告知服務(wù)器端，自己支持哪些加密算法孟岛，所以客戶端需要將本地支持的加密套件（Cipher Suite）的列表傳送給服務(wù)端似将。除此之外，客戶端還要產(chǎn)生一個(gè)隨機(jī)數(shù)蚀苛，這個(gè)隨機(jī)數(shù)一方面需要在客戶端保存，另一方面需要傳送給服務(wù)端玷氏，客戶端的隨機(jī)數(shù)需要跟服務(wù)端產(chǎn)生的隨機(jī)數(shù)結(jié)合起來(lái)產(chǎn)生后邊要講的Master Secret堵未。
客戶端需要提供如下信息：
- 支持的協(xié)議版本，比如TLS 1.0版本
- 一個(gè)客戶端生成的隨機(jī)數(shù)盏触，稍后用于生成“對(duì)話密鑰”
- 支持的加密方法渗蟹，比如RSA公鑰加密
- 支持的壓縮方法
2）服務(wù)端首次回應(yīng)
服務(wù)端在接收到客戶端的Client Hello之后，服務(wù)端需要確定加密協(xié)議的版本赞辩，以及加密的算法雌芽，然后也生成一個(gè)隨機(jī)數(shù)，以及將自己的證書(shū)發(fā)送給客戶端辨嗽，這里的隨機(jī)數(shù)是整個(gè)過(guò)程的第二個(gè)隨機(jī)數(shù)世落。
服務(wù)端需要提供的信息：
- 協(xié)議的版本
- 加密的算法
- 隨機(jī)數(shù)
- 服務(wù)器證書(shū)
3）客戶端再次回應(yīng)
客戶端首先會(huì)對(duì)服務(wù)器下發(fā)的證書(shū)進(jìn)行驗(yàn)證，驗(yàn)證通過(guò)后糟需，則會(huì)繼續(xù)下面的操作屉佳，客戶端再次產(chǎn)生一個(gè)隨機(jī)數(shù)（第三個(gè)隨機(jī)數(shù)）谷朝，然后使用服務(wù)器證書(shū)中的公鑰加密，以及放一個(gè)ChangeCipherSpec消息即編碼改變的消息武花，還有整個(gè)前面所有消息的hash值圆凰，進(jìn)行服務(wù)器驗(yàn)證，然后用新密鑰（轉(zhuǎn)載者的理解：使用第二次握手后服務(wù)器端返回的支持的加密算法隨機(jī)生成的對(duì)稱密鑰）加密一段數(shù)據(jù)一并發(fā)送到服務(wù)器体箕，確保正式通信前無(wú)誤专钉。
客戶端使用前面的兩個(gè)隨機(jī)數(shù)以及剛剛生成的新隨機(jī)數(shù)，使用與服務(wù)器確定的加密算法累铅，生成一個(gè)Session Secret跃须。
ChangeCipherSpec是一個(gè)獨(dú)立的協(xié)議，體現(xiàn)在數(shù)據(jù)包中就是一個(gè)字節(jié)的數(shù)據(jù)争群，用于告知服務(wù)端回怜，客戶端已經(jīng)切換到之前協(xié)商好的加密套件（Cipher Suite）的狀態(tài)，準(zhǔn)備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了换薄。
4）服務(wù)器再次響應(yīng)
服務(wù)端在接收到客戶端傳過(guò)來(lái)的第三個(gè)隨機(jī)數(shù)的加密數(shù)據(jù)后玉雾，使用私鑰對(duì)解密這段加密數(shù)據(jù)，并對(duì)數(shù)據(jù)進(jìn)行驗(yàn)證轻要，也會(huì)使用和客戶端同樣的方式生成密鑰复旬。一切準(zhǔn)備好后，也會(huì)給客戶端發(fā)送一個(gè)ChangeCipherSpec冲泥，告知客戶端已經(jīng)切換到協(xié)商過(guò)的加密套件狀態(tài)驹碍，準(zhǔn)備使用加密套件和Session Secret加密數(shù)據(jù)了。之后凡恍，服務(wù)端也會(huì)使用Session Secret加密一段Finish消息發(fā)送給客戶端志秃，以驗(yàn)證之前通過(guò)握手建立起來(lái)的加解密通道是否成功。
轉(zhuǎn)載者疑問(wèn)：這里的Session Secret是不是就是對(duì)稱密鑰嚼酝？
會(huì)話密鑰：https://baike.baidu.com/item/%E4%BC%9A%E8%AF%9D%E5%AF%86%E9%92%A5/8831495?fr=aladdin
5）后續(xù)客戶端與服務(wù)期間通信
確定密鑰后浮还，服務(wù)器與客戶端之間就會(huì)通過(guò)商定的密鑰加密數(shù)據(jù)，進(jìn)行通訊了闽巩。這個(gè)握手過(guò)程也就基本完成了钧舌。
6. 其他補(bǔ)充
對(duì)于非常重要的保密數(shù)據(jù)，服務(wù)端還需要對(duì)客戶端進(jìn)行驗(yàn)證涎跨，以保證數(shù)據(jù)傳送給了安全的合法客戶端洼冻。服務(wù)端可以向客戶端發(fā)出Cerficate Request消息，要求客戶端發(fā)送證書(shū)對(duì)客戶端的合法性進(jìn)行驗(yàn)證隅很。比如撞牢，金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會(huì)向正式客戶提供USB密鑰，里面就包含了一張客戶端證書(shū)普泡。
PreMaster Secret前兩個(gè)字節(jié)是TLS的版本號(hào)播掷，這是一個(gè)比較重要的用來(lái)核對(duì)握手?jǐn)?shù)據(jù)的版本號(hào)，因?yàn)樵贑lient Hello階段撼班，客戶端會(huì)發(fā)送一份加密套件列表和當(dāng)前支持的SSL/TLS的版本號(hào)給服務(wù)端歧匈，而且是使用明文傳送的，如果握手的數(shù)據(jù)包被破解之后砰嘁，攻擊者很有可能篡改數(shù)據(jù)包件炉，選擇一個(gè)安全性較低的加密套件和版本給服務(wù)端，從而對(duì)數(shù)據(jù)進(jìn)行破解矮湘。所以斟冕，服務(wù)端需要對(duì)密文中解密出來(lái)的PreMaster版本號(hào)跟之前Client Hello階段的版本號(hào)進(jìn)行對(duì)比，如果版本號(hào)變低缅阳，則說(shuō)明被篡改磕蛇，則立即停止發(fā)送任何消息。
session的恢復(fù)
有兩種方法可以恢復(fù)原來(lái)的session：一種叫做session ID十办，另一種叫做session ticket秀撇。
1）session ID
session ID的思想很簡(jiǎn)單，就是每一次對(duì)話都有一個(gè)編號(hào)（session ID）向族。如果對(duì)話中斷呵燕，下次重連的時(shí)候，只要客戶端給出這個(gè)編號(hào)件相，且服務(wù)器有這個(gè)編號(hào)的記錄再扭，雙方就可以重新使用已有的“對(duì)話密鑰”，而不必重新生成一把夜矗。
session ID是目前所有瀏覽器都支持的方法泛范，但是它的缺點(diǎn)在于session ID往往只保留在一臺(tái)服務(wù)器上。所以紊撕，如果客戶端的請(qǐng)求發(fā)送到另一臺(tái)服務(wù)器敦跌，就無(wú)法恢復(fù)對(duì)話。
2）session ticket
客戶端發(fā)送一個(gè)服務(wù)器在上一次對(duì)話中發(fā)送過(guò)來(lái)的session ticket逛揩。這個(gè)session ticket是加密的，只有服務(wù)器才能解密麸俘，其中包括本次對(duì)話的主要信息辩稽，比如對(duì)話密鑰和加密方法。當(dāng)服務(wù)器收到session ticket以后从媚，解密后就不必重新生成對(duì)話密鑰了逞泄。
目前只有Firefox和Chrome瀏覽器支持。
總結(jié)
https實(shí)際上就是在TCP層與http層之間加入了SSL/TLS來(lái)為上層的安全保駕護(hù)航，主要用到對(duì)稱加密喷众、非對(duì)稱加密各谚、證書(shū)等技術(shù)進(jìn)行客戶端與服務(wù)器的數(shù)據(jù)加密傳輸，最終達(dá)到保證整個(gè)通信的安全性到千。
參考文章
數(shù)字證書(shū)的基礎(chǔ)知識(shí)
HTTPS科普掃盲貼
和安全有關(guān)的那些事
OpenSSL與SSL數(shù)字證書(shū)概念貼
基于OpenSSL自建CA和頒發(fā)SSL證書(shū)
聊聊HTTPS和SSL/TLS協(xié)議
SSL/TLS協(xié)議運(yùn)行機(jī)制的概述
圖解SSL/TLS協(xié)議
大型網(wǎng)站的HTTPS實(shí)踐
SSL/TLS原理詳解
扒一扒HTTPS網(wǎng)站的內(nèi)幕
白話解釋OSI模型昌渤，TLS/SSL及HTTPS
OpenSSL HearBleed漏洞原理漫畫(huà)圖解
