前言
http和https對于web developers來說肯定都不陌生醉锄，甚至是每天都在接觸承二，然而在我接觸的一些相關(guān)群體中（包括我自己），能準確說出http協(xié)議的各種頭字段的含義妆够、緩存原理负蚊，https建立安全連接過程的人很少。本文是我對最近學(xué)習(xí)的https知識點的一些整理鸵荠。
關(guān)于HTTPS
HTTPS = HTTP+SSL/TLS（TLS是SSL的升級版）伤极， 即 HTTP 下加入 SSL 層進行通信加密哨坪，不經(jīng)過SSL協(xié)議加密的HTTP通訊有以下幾個問題：
- 竊聽風(fēng)險（eavesdropping）：第三方可以獲知通信內(nèi)容。
- 篡改風(fēng)險（tampering）：第三方可以修改通信內(nèi)容届慈。
- 冒充風(fēng)險（pretending）：第三方可以冒充他人身份參與通信。
SSL/TLS協(xié)議是為了解決這三大風(fēng)險而設(shè)計的臊泌，希望達到：
- 所有信息都是加密傳播揍拆，第三方無法竊聽。
- 具有校驗機制高氮，一旦被篡改顷牌，通信雙方會立刻發(fā)現(xiàn)塞淹。
- 配備身份證書饱普，防止身份被冒充。
HTTPS如何保證通信的安全性
首先講下HTTP在通信過程谁帕，直接是明文傳輸冯袍，就像這樣：
很明顯， 你不想你的銀行卡密碼這么輕易的被黑客獲取吧儡循？于是想到對內(nèi)容進行加密征冷，客戶端和服務(wù)端約定一種加密算法就行了检激，就像這樣：
上面的加密方式中，通信雙方使用同一種加密算法和密鑰齿穗，這種加密方式稱為對稱加密今穿，典型的對稱加密算法有：DES、RC5腮出、IDEA（分組加密），RC4（序列加密）
ok作儿，現(xiàn)在乍看之下馋劈，內(nèi)容加密之后銀行卡密碼沒有暴露了妓雾，但是僅僅是這樣還是有問題：試想，如果所有的客戶端都使用同一種加密算法妒蛇，那還加個毛線密肛宋？這種此地?zé)o銀三百兩的做法毫無實際意義。但是聰明的你很快也能想到欢揖，每個客戶端都使用不同的加密算法吧陶耍！就像這樣：
現(xiàn)在只要讓客戶端和服務(wù)器協(xié)議雙方要用的加密算法就行了烈钞，就像這樣：
嗯棵磷，好像還不錯晋涣，但是客戶端和服務(wù)器協(xié)商要用什么加密算法這條通信本身是沒有加密的呀谢鹊？還是存在被攔截并被破解密文的可能性。ok佃扼，現(xiàn)在需要對協(xié)商加密算法這條信息進行加密了兼耀，這里需要用到另一種加密方式了求冷，我們稱之為“非對稱加密”：
非對稱加密需要兩個密鑰來進行加密和解密窍霞，這兩個秘鑰是公開密鑰（public key但金，簡稱公鑰）和私有密鑰（private key，簡稱私鑰）钱磅。私鑰加密后的密文似枕，只要是公鑰，都可以解密禁舷，但是反過來公鑰加密后的密文毅往，只有私鑰可以解密派近。私鑰只有一個人有渴丸，而公鑰可以發(fā)給所有的人。典型的算法有RSA戒幔，DSA土童，DH。
服務(wù)器和各個客戶端的關(guān)系就像這樣：
服務(wù)器擁有一把私鑰敢订，每個客戶端在與服務(wù)器連接時罢吃，服務(wù)器會返回給客戶端一把公鑰尿招，客戶端通過自己手中的公鑰加密后的密文阱驾，只有擁有私鑰的服務(wù)器才能破解怪蔑，所以此時需要客戶端決定此后雙方通信需要用到的對稱加密算法饮睬，并用公鑰進行加密后發(fā)送給服務(wù)器，協(xié)定好之后捆愁，雙方就使用對稱加密算法進行加密通信了昼丑。上述的過程大致如下圖所示：
現(xiàn)在菩帝，通信時的加密過程已經(jīng)差不多完美了，但是細心的人可能會發(fā)出疑問：一開始的公鑰是服務(wù)器分發(fā)給各個客戶端的宜雀，那如何保證分發(fā)的過程中公鑰不被黑客劫持并偽造自己的公鑰給客戶端呢握础？就像這樣：
這里就需要權(quán)威的機構(gòu)進行認證了：CA機構(gòu)數(shù)字證書（需要花錢購買的）禀综。
數(shù)字證書如何工作
CA證書包含以下內(nèi)容：
- 證書頒發(fā)機構(gòu)的名稱
- 證書的有效期
- 公鑰
- 證書所有者（Subject）
- 證書本身的數(shù)字簽名
- 指紋以及指紋算法
一、驗證證書的有效性
瀏覽器默認都會內(nèi)置CA根證書孤澎，其中根證書包含了CA的公鑰欠窒。
- 證書頒發(fā)的機構(gòu)是偽造的：瀏覽器不認識，直接認為是危險證書姐扮；
- 證書頒發(fā)的機構(gòu)是確實存在的衣吠，于是根據(jù)CA名缚俏，找到對應(yīng)內(nèi)置的CA根證書贮乳、CA的公鑰恬惯。用CA的公鑰酪耳，對偽造的證書的摘要進行解密，發(fā)現(xiàn)解不了碗暗，認為是危險證書言疗；
- 對于篡改的證書，使用CA的公鑰對數(shù)字簽名進行解密得到摘要A,然后再根據(jù)簽名的Hash算法計算出證書的摘要B死姚，對比A與B勤篮，若相等則正常，若不相等則是被篡改過的温鸽；
- 證書可在其過期前被吊銷手负，通常情況是該證書的私鑰已經(jīng)失密竟终。較新的瀏覽器如Chrome切蟋、Firefox、Opera和Internet Explorer都實現(xiàn)了在線證書狀態(tài)協(xié)議（OCSP）以排除這種情形：瀏覽器將網(wǎng)站提供的證書的序列號通過OCSP發(fā)送給證書頒發(fā)機構(gòu)喘鸟，后者會告訴瀏覽器證書是否還是有效的驻右。
里面涉及到一些比較重要的概念堪夭，比如數(shù)字簽名拣凹，這里需要大致解釋下什么是數(shù)字簽名：
數(shù)字簽名技術(shù)就是對“非對稱密鑰加解密”和“數(shù)字摘要“兩項技術(shù)的應(yīng)用恨豁，它將摘要信息用發(fā)送者的私鑰加密橘蜜，與原文一起傳送給接收者。接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息跌捆，然后用HASH函數(shù)對收到的原文產(chǎn)生一個摘要信息棒搜，與解密的摘要信息對比。如果相同可款，則說明收到的信息是完整的克蚂，在傳輸過程中沒有被修改埃叭，否則說明信息被修改過，因此數(shù)字簽名能夠驗證信息的完整性立镶。
簡單說类早，數(shù)字簽名有兩種功效：
- 能確定消息確實是由發(fā)送方簽名并發(fā)出來的涩僻，因為別人假冒不了發(fā)送方的簽名。
- 數(shù)字簽名能確定消息的完整性逆日。
關(guān)于數(shù)字簽名室抽，可以看看阮一峰翻譯過的一篇文章，寫得很通俗易懂：數(shù)字簽名是什么噩死。
注意：數(shù)字簽名只能驗證數(shù)據(jù)的完整性，數(shù)據(jù)本身是否加密不屬于數(shù)字簽名的控制范圍
安全地獲取公鑰
如上述行嗤，數(shù)字證書在HTTPS通信過程中扮演身份認證和密鑰分發(fā)的功能栅屏，我們可以簡單模擬一下客戶端與服務(wù)器之間信息交換的過程：
- 客戶端：hello堂鲜，我要跟你（xxx.com）進行數(shù)據(jù)通信;
- 服務(wù)器：好的，我就是xxx.com哥纫，這是我的證書痴奏，里面有我的名字和公鑰等各種信息读拆，你驗證下。
- 客戶端：（查看證書上的信息是否有誤暑诸，并根據(jù)上述驗證方法驗證證書的有效性辟灰，如果有問題芥喇，發(fā)出警告并斷開連接），Di*6D&T^@BD#H75dJ （公鑰加密后的內(nèi)容，翻譯：我們用DES和RSA加密算法進行之后的通信）
- 服務(wù)器：7HUW&@O#DD#G@B（對稱加密后的內(nèi)容湿诊，不翻譯了）
- 客戶端：UDW@J@DH&76589DHUD（對稱加密后的內(nèi)容）
至此瘦材，整個HTTPS的安全通信過程已經(jīng)大致講完了，當(dāng)然朗和，還有很多細節(jié)值得深挖眶拉，比如SSL協(xié)議的握手過程等，有時間再做更細致的整理放可。
