昨天順手把站點(diǎn)上了HTTPS，但是為什么要上HTTPS诵闭，不能因?yàn)槟銥g覽器給我顯示‘安全’，我就認(rèn)為他是安全的澎嚣，還是要知根知底疏尿，不能知其然而不知其所以然，因此抽空了解一下易桃。
本文所涉及的加密算法原理不做詳解褥琐，具體可Google
先來(lái)了解下相關(guān)的基本術(shù)語(yǔ)
對(duì)稱加密
symmetric encryption
對(duì)稱加密所指的是加密和解密使用的相同密鑰的加密算法，即使用密鑰S加密的數(shù)據(jù)同時(shí)用密鑰S解密晤郑。這種加密方法通常效率較高敌呈，但要求兩個(gè)交換數(shù)據(jù)的實(shí)體都要持有相同的密鑰贸宏。對(duì)稱加密的關(guān)鍵問(wèn)題是，密鑰如何傳遞磕洪。
常見(jiàn)的對(duì)稱加密算法有DES吭练、AES、RC4等褐鸥。
非對(duì)稱加密
asymmetric cryptographic
非對(duì)稱加密與對(duì)稱加密相反线脚，非對(duì)稱加密需要2個(gè)密鑰：私鑰(Private Key)和公鑰(Public Key)，這兩者總是成對(duì)出現(xiàn)叫榕，并且公鑰加密的數(shù)據(jù)只有私鑰能夠解密浑侥，相反，私鑰加密的內(nèi)容只有公鑰能夠解密晰绎；通常公鑰是對(duì)外公開(kāi)的寓落，任何人都可以獲取到，私鑰不對(duì)外公開(kāi)的荞下。由于公鑰是對(duì)外公開(kāi)的伶选，因此私鑰加密的內(nèi)容只要獲得公鑰的任何人都可以解開(kāi)。
非對(duì)稱加密與對(duì)稱加密相比尖昏，因?yàn)槠溆?jì)算復(fù)雜仰税，因此速度較慢。非對(duì)稱加密對(duì)加密內(nèi)容的長(zhǎng)度還有限制抽诉，被加密的內(nèi)容長(zhǎng)度不能大于密鑰長(zhǎng)度陨簇。比如現(xiàn)在的密鑰長(zhǎng)度時(shí)2048位，那么被加密的內(nèi)容長(zhǎng)度不能超過(guò)256字節(jié)迹淌。
常見(jiàn)的非對(duì)稱加密算法有RSA河绽、Elgamal、ECC等唉窃。
非對(duì)稱加密的作用：
- 防止信息泄露：公鑰加密的只有私鑰能解
- 身份驗(yàn)證：利用數(shù)字簽名
數(shù)字摘要/消息摘要
digital digest/message digest
數(shù)字摘要是將數(shù)據(jù)通過(guò)單向HASH函數(shù)進(jìn)行計(jì)算生成一串固定長(zhǎng)度的散列值耙饰，不同數(shù)據(jù)產(chǎn)生的散列值是不同的（應(yīng)該說(shuō)是基本不可能相同，但還是存在“碰撞的概率”纹份，比如MD5已經(jīng)證明可以快速生成相同散列值的不同明文）苟跪，相同的數(shù)據(jù)產(chǎn)生的散列值一定是相同的，因此可以通過(guò)該散列值用來(lái)保證數(shù)據(jù)防篡改和完整性（因?yàn)槎紩?huì)導(dǎo)致數(shù)字摘要發(fā)生改變）蔓涧。
常用的數(shù)字摘要算法有MD5削咆、SHA1、SHA256等蠢笋。
消息認(rèn)證
信息摘要只能用來(lái)解決數(shù)據(jù)的完整性問(wèn)題，卻無(wú)法解決消息的認(rèn)證問(wèn)題鳞陨，因?yàn)镠ASH函數(shù)是任何人都可以使用的昨寞，第三方偽裝發(fā)送者發(fā)送數(shù)據(jù)和數(shù)字摘要也能通過(guò)接收者的完整檢查瞻惋，卻無(wú)法識(shí)別第三方的偽裝，這是就需要消息認(rèn)證了援岩。
消息認(rèn)證碼MAC
message authentication code
消息認(rèn)證碼是將對(duì)稱加密和數(shù)字摘要相結(jié)合起來(lái)的技術(shù)歼狼，首先將數(shù)據(jù)通過(guò)HASH函數(shù)生成數(shù)字摘要，然后將摘要通過(guò)雙方共享的密鑰加密生成消息認(rèn)證碼享怀，最后將認(rèn)證碼一起發(fā)送給接受者羽峰。
接受者在收到消息后，使用相同的方法生成消息認(rèn)證碼添瓷，然后與收到的消息認(rèn)證碼進(jìn)行對(duì)比梅屉，如果認(rèn)證碼一致，那么數(shù)據(jù)則通過(guò)認(rèn)證鳞贷。
存在2個(gè)問(wèn)題：
- 因?yàn)槭褂玫氖菍?duì)稱加密算法坯汤，那么依然存在密鑰如何傳輸?shù)膯?wèn)題；
-
無(wú)法防止否認(rèn)搀愧，因?yàn)槊荑€是雙方共享的惰聂，而接收者認(rèn)為數(shù)據(jù)是對(duì)方傳遞過(guò)來(lái)的，而對(duì)方可以否認(rèn)傳輸過(guò)該條信息咱筛，并且可以生成該條信息是由接收者自己產(chǎn)生的搓幌。
消息認(rèn)證碼
數(shù)字簽名
Digital Signature
數(shù)字簽名是將非對(duì)稱加密和數(shù)字摘要相結(jié)合起來(lái)的技術(shù)，首先將數(shù)據(jù)通過(guò)HASH函數(shù)生成數(shù)字摘要迅箩，然后將摘要用私鑰進(jìn)行加密生成數(shù)字簽名溉愁，最后將數(shù)據(jù)和數(shù)字簽名一起發(fā)送給接收者（私鑰進(jìn)行簽名，公鑰只能用來(lái)驗(yàn)證簽名）沙热。
接收者在收到消息后叉钥，通過(guò)公鑰解密數(shù)字簽名，獲得數(shù)字摘要篙贸，然后對(duì)數(shù)據(jù)用相同的HASH函數(shù)計(jì)算數(shù)字摘要投队，然后與解密獲得的數(shù)字摘要進(jìn)行對(duì)比，如果一樣證明數(shù)據(jù)沒(méi)有被篡改過(guò)爵川。
- 通過(guò)非對(duì)稱加密傳遞數(shù)字摘要敷鸦，能保證摘要一定是私鑰擁有者發(fā)送的；
- 通過(guò)數(shù)字摘要寝贡，能夠確數(shù)據(jù)一定是沒(méi)有被篡改過(guò)的扒披。
如何保證數(shù)據(jù)傳輸?shù)陌踩?/h4>
使用對(duì)稱加密
對(duì)稱加密計(jì)算簡(jiǎn)單，速度快圃泡，是用來(lái)加密數(shù)據(jù)的好方法碟案，但是對(duì)于互聯(lián)網(wǎng)上節(jié)點(diǎn)，要保證數(shù)據(jù)安全颇蜡，就必須保證節(jié)點(diǎn)與節(jié)點(diǎn)之間通信所使用的密鑰是不一樣的价说。那么對(duì)于互聯(lián)網(wǎng)上的服務(wù)節(jié)點(diǎn)辆亏，要對(duì)其他網(wǎng)絡(luò)節(jié)點(diǎn)提供服務(wù)，就需要知道對(duì)方所使用的密鑰鳖目，即服務(wù)器需要知道網(wǎng)絡(luò)所有客戶端所使用的密鑰扮叨；這顯然是不現(xiàn)實(shí)的。
使用非對(duì)稱加密
那么既然對(duì)稱機(jī)密不行领迈，那么使用非對(duì)稱加密呢彻磁？私鑰由服務(wù)器擁有，并將公鑰公開(kāi)狸捅，那么客戶端將請(qǐng)求用公鑰加密衷蜓，傳遞給服務(wù)器，服務(wù)器用私鑰解密獲得請(qǐng)求薪贫，處理請(qǐng)求后恍箭，再通過(guò)私鑰加密，返回給客戶端瞧省。這樣看起來(lái)貌似還可以扯夭，但不要忘了，公鑰可是公開(kāi)的鞍匾，公鑰加密的固然只有擁有私鑰的服務(wù)器才能解交洗，但服務(wù)器的返回?cái)?shù)據(jù)，卻可以被任意擁有公鑰的節(jié)點(diǎn)解開(kāi)橡淑，因此非對(duì)稱加密僅能保證單向安全构拳。不僅如此，非對(duì)稱加密還有以下限制：
- 計(jì)算復(fù)雜梁棠，速度較慢置森；
-
長(zhǎng)度有所限制，所加密的內(nèi)容不能超過(guò)密鑰長(zhǎng)度符糊。
非對(duì)稱加密傳輸
混合加密
使用對(duì)稱加密不行凫海，使用非對(duì)稱加密也不行，那么還有其他辦法嗎男娄？
既然對(duì)稱加密沒(méi)辦法一開(kāi)始就存儲(chǔ)下來(lái)行贪，那么在通信的時(shí)候協(xié)商好不久行了，由客戶端告訴服務(wù)器端對(duì)稱加密的密鑰模闲，該密鑰通過(guò)非對(duì)稱加密來(lái)傳遞建瘫，這樣就能保證密鑰只能被服務(wù)端獲取，之后雙方在通過(guò)協(xié)商好的對(duì)稱密鑰進(jìn)行通信尸折，既能滿足雙向通信安全啰脚，又能提高加解密的速度，めでたしめでたし实夹。
這就是HTTPS傳輸數(shù)據(jù)的基本原理橄浓，當(dāng)然實(shí)現(xiàn)還要考慮各種各樣的事情晾咪。
HTTPS協(xié)議
HTTPS默認(rèn)使用443端口
HTTPS的提出主要解決以下3個(gè)問(wèn)題：
- 內(nèi)容加密：保證數(shù)據(jù)傳輸安全
- 身份認(rèn)證：確認(rèn)網(wǎng)站的真實(shí)性
- 數(shù)據(jù)完整：防止內(nèi)容被篡改
TLS/SSL
HTTP是基于TCP/IP協(xié)議的，TCP/IP在網(wǎng)絡(luò)中傳播需要經(jīng)過(guò)多個(gè)節(jié)點(diǎn)贮配，而HTTP請(qǐng)求又是明文傳輸?shù)模敲从行闹溯p易的可以獲得請(qǐng)求包和返回包塞赂，并且對(duì)其進(jìn)行篡改泪勒，因此HTTP是不安全的協(xié)議。
HTTP--明文-->TCP/IP---明文--->TCP/IP--明文-->HTTP
以安全為目標(biāo)宴猾，HTTPS就此產(chǎn)生圆存，HTTPS是HTTP的升級(jí)版本，最上層還是HTTP協(xié)議仇哆，只不過(guò)在HTTP和TCP/IP之間加入了一層加密層TSL/SSL沦辙，TLS/SSL負(fù)責(zé)對(duì)數(shù)據(jù)進(jìn)行加解密，可以看做是HTTP over TLS/SSL讹剔。
HTTP--明文-->TLS/SSL--密文-->TCP/IP---密文--->TCP/IP--密文-->TLS/SSL--明文-->HTTP
TLS網(wǎng)絡(luò)協(xié)議
TLS位于應(yīng)用層油讯，連接應(yīng)用層高級(jí)協(xié)議和TCP/IP協(xié)議，從而提供安全通信延欠。
TLS/SSL協(xié)議的版本
SSL(Secure Socket Layer)由網(wǎng)景公司設(shè)計(jì)陌兑，現(xiàn)主流使用的是SSL3.0，Google發(fā)現(xiàn)SSL3.0存在設(shè)計(jì)缺陷由捎，建議禁用此協(xié)議兔综，現(xiàn)目前大多數(shù)瀏覽器要么禁止使用SSL3.0要么會(huì)對(duì)使用SSL3.0的請(qǐng)求提出安全警告。
TLS(Transport Layer Security)是由IETF制定的基于SSL3.0之上的狞玛，可以看做是SSL3.0的后續(xù)版本软驰，目前已經(jīng)制定了TLS1.0、TLS1.2心肪、TLS1.3锭亏，目前較為主流的是使用TLS1.0協(xié)議。
TLS協(xié)議握手
1. 客戶端發(fā)起連接 Client-hello
由于版本蒙畴、實(shí)現(xiàn)贰镣、操作系統(tǒng)等差異的存在，通信雙方所能夠支持的加解密算法和TSL/SSL版本客觀上會(huì)存在不一致膳凝，那么通信的雙方就必須要協(xié)商好使用雙方的版本和加解密算法碑隆；為了節(jié)省網(wǎng)絡(luò)帶寬，雙方會(huì)在網(wǎng)絡(luò)上進(jìn)行數(shù)據(jù)壓縮傳輸蹬音，因此還會(huì)協(xié)商雙方都支持的壓縮算法上煤；除這些外再愈，客戶端還會(huì)生成一個(gè)隨機(jī)數(shù)Random_A娇哆，用于后續(xù)密鑰的生成却盘。
客戶端提供的信息
- 協(xié)議版本
- 加密算法
- 壓縮算法
- 隨機(jī)數(shù)
Random_A
2. 服務(wù)器端回應(yīng) Server-hello
服務(wù)在收到客戶端的請(qǐng)求后骚揍，將客戶端生成的Random_A存儲(chǔ)在本地，然后從客戶端支持的加密算法和壓縮算法選擇合適的算法独泞，并且服務(wù)器也生成一個(gè)隨機(jī)數(shù)Random_B呐矾，然后將選擇的算法、隨機(jī)數(shù)懦砂、和自己的證書(shū)發(fā)送給客戶端蜒犯。
服務(wù)端提供的信息：
- 數(shù)字證書(shū)
- 協(xié)議版本
- 加密算法
- 壓縮算法
- 隨機(jī)數(shù)
Random_B
3. 客戶端回應(yīng)
如果服務(wù)端要求客戶端提供證書(shū)，那么客戶端會(huì)先發(fā)送客戶端的證書(shū)信息荞膘。
客戶端為驗(yàn)證服務(wù)器的證書(shū)是否合法罚随，驗(yàn)證合法之后，從證書(shū)中獲取服務(wù)器的公鑰羽资√云校客戶端生成新的隨機(jī)數(shù)Pre-Master，然后用服務(wù)器的公鑰對(duì)該隨機(jī)數(shù)進(jìn)行加密發(fā)送給服務(wù)器端屠升。通過(guò)Random_A潮改、Random_B、Premaster Secret和之前協(xié)商的對(duì)稱加密算法弥激，就可以得到對(duì)稱加密密鑰enc_key=Fuc(Random_A, Random_B, Pre-Master)进陡。
接著發(fā)送change cipher spec命令通知服務(wù)器端表示客戶端已經(jīng)準(zhǔn)備好使用協(xié)商好的加密方式進(jìn)行數(shù)據(jù)通信。
最后客戶端計(jì)算前面發(fā)送的所有內(nèi)容的MAC發(fā)送給服務(wù)器端微服，該信息為finish命令信息趾疚。
4. 服務(wù)器回應(yīng)客戶端
服務(wù)器收到客戶端發(fā)送過(guò)來(lái)的Pre-Master加密數(shù)據(jù)后，用私鑰進(jìn)行解密以蕴，然后之前協(xié)商好的方法生成對(duì)稱加密密鑰糙麦，首先發(fā)送change cipher spec命令通知客戶端表示服務(wù)端已經(jīng)準(zhǔn)備好使用協(xié)商好的加密方式進(jìn)行數(shù)據(jù)通信，然后利用對(duì)稱密鑰計(jì)算前面發(fā)送所有內(nèi)容的MAC發(fā)送給客戶端丛肮，該信息為finish命令信息赡磅。
5. 數(shù)據(jù)通信
如果客戶端和服務(wù)器端都能夠?qū)inish信息進(jìn)行正常的加解密及其驗(yàn)證，證明該加密通道已經(jīng)建立完成宝与。雙方可以使用約定好的對(duì)稱加密密鑰加密HTTP請(qǐng)求焚廊，進(jìn)行通信。
由于Random_A和Random_B在網(wǎng)絡(luò)中是通過(guò)明文傳播的习劫，而握手階段是通過(guò)非對(duì)稱機(jī)密來(lái)傳遞Pre-Master的咆瘟，因此后續(xù)通訊對(duì)稱加密密鑰的破解取決與Pre-Master是否能夠被破解。
為什么要使用3個(gè)隨機(jī)數(shù)诽里，因?yàn)橥ㄐ烹p發(fā)都不相信對(duì)方的隨機(jī)數(shù)是真的隨機(jī)袒餐，而最后一個(gè)隨機(jī)數(shù)則是因?yàn)榍懊鎯蓚€(gè)隨機(jī)數(shù)都是明文傳播，需要一個(gè)不能被第三方獲取的加密參數(shù)。
數(shù)字證書(shū)
上面說(shuō)過(guò)灸眼，傳遞第三個(gè)隨機(jī)數(shù)的時(shí)候使用了從服務(wù)器獲取的公鑰進(jìn)行加密傳輸給客戶端卧檐。既然公鑰是由服務(wù)器提供的，萬(wàn)一我們所連接的是惡意的中間人呢焰宣，此時(shí)是中間人與我們進(jìn)行HTTPS通信霉囚，中間人在于目的服務(wù)器進(jìn)行HTTPS通信，那數(shù)據(jù)就暴露給了中間人眼中了匕积，因此直接使用來(lái)自對(duì)方的公鑰是不行佛嬉，我們還需要驗(yàn)證該公鑰的合法性。
此時(shí)闸天，就需要有一個(gè)值得信賴的第三方權(quán)威機(jī)構(gòu)(Certificate Authority)來(lái)告訴我們?cè)摲?wù)器信息是可以信任的，而這個(gè)方式就是通過(guò)第三方機(jī)構(gòu)頒給服務(wù)的數(shù)字證書(shū)來(lái)證明斜做，權(quán)威第三方機(jī)構(gòu)頒發(fā)的證書(shū)成為CA證書(shū)苞氮。
證書(shū)的主要組成
- 頒發(fā)證書(shū)的機(jī)構(gòu)名稱
- 證書(shū)持有者的公鑰
- 證書(shū)使用的HASH算法
- 證書(shū)內(nèi)容的數(shù)字簽名
由證書(shū)頒發(fā)方的私鑰加密計(jì)算證書(shū)內(nèi)容消息摘要得出，使得證書(shū)內(nèi)容無(wú)法被偽造和篡改瓤逼。
驗(yàn)證證書(shū)的有效性
一般瀏覽器都會(huì)內(nèi)置大多數(shù)主流權(quán)威CA的根證書(shū)笼吟，所謂根證書(shū)及其有效性不需要驗(yàn)證，雖然它也是一份普通的數(shù)字證書(shū)霸旗。
驗(yàn)證的過(guò)程：
- 利用證書(shū)使用的HASH算法計(jì)算出證書(shū)內(nèi)容的消息摘要贷帮；
- 使用根證書(shū)的公鑰解密證書(shū)內(nèi)容的數(shù)字簽名得到證書(shū)提供的消息摘要；
- 比較1和2的消息摘要是否一致诱告，如一致撵枢，表示驗(yàn)證通過(guò)，該證書(shū)可信任精居，其公鑰是由服務(wù)器提供的锄禽。
只要證書(shū)頒發(fā)方是權(quán)威的，并且生成證書(shū)數(shù)字簽名的私鑰只有CA擁有靴姿，那么驗(yàn)證成功的數(shù)字證書(shū)是不可能被偽造的沃但，即是可信任的。即使中間人拿到了數(shù)字證書(shū)佛吓，也無(wú)法冒充服務(wù)器宵晚，因?yàn)樗麤](méi)有數(shù)字證書(shū)中公鑰對(duì)應(yīng)的私鑰，無(wú)法得到Pre-Master维雇，從而無(wú)法建立連接淤刃。
通過(guò)引入權(quán)威的第三方可以保證HTTPS客戶端和服務(wù)器的通信是安全可信任的。
自簽發(fā)證書(shū)與雙向認(rèn)證
有時(shí)候谆沃，不希望使用第三方證書(shū)钝凶，想自己簽發(fā)證書(shū)，那么就需要自己手動(dòng)生成跟證書(shū)和CA證書(shū)，并將根證書(shū)安裝到對(duì)方的系統(tǒng)中耕陷，對(duì)方就可以對(duì)自己進(jìn)行HTTPS請(qǐng)求掂名，如果對(duì)方也自簽字發(fā)證書(shū)，并將證書(shū)安裝我方系統(tǒng)哟沫，那么雙方就可以進(jìn)行HTTPS雙向認(rèn)證饺蔑。
總結(jié)
本篇只講解了HTTPS的基本原理，具體的實(shí)現(xiàn)還需要看RFC嗜诀，因?yàn)楸救瞬皇前踩较虻幕c(diǎn)到即止即可÷「遥總的來(lái)說(shuō)发皿，上了HTTPS可以保證雙方通信的安全，國(guó)內(nèi)外的大型網(wǎng)站大部分已經(jīng)切換到HTTPS拂蝎，沒(méi)切換的也在切換的路上了穴墅，這是未來(lái)的趨勢(shì)。
