HTTPS網(wǎng)站相信對很多工程師來講并不陌生，各大Web服務(wù)器產(chǎn)品都提供了詳細的配置方案，搭建起來也并不很難。但要說出其中的安全原理，卻不是件容易的事。今天我們就來談一談它后面的密碼學原理，希望通過這篇文章，大家能夠真正了解掌握相關(guān)的安全技術(shù)。強烈建議您讀這篇文章下面的內(nèi)容之前，先看一下之前關(guān)于非對稱加密、數(shù)字簽名、數(shù)字證書的文章，做為相關(guān)知識儲備。
我們談HTTPS的安全，實際上是談SSL的安全，因為HTTPS實質(zhì)就是HTTP+SSL。而其實SSL也不是完全準確的說法，因為作為協(xié)議的SSL(Secure Sockets Layer 安全套接層)已經(jīng)及其繼任者TLS協(xié)議（Transport Layer Security傳輸層安全）取代了。習慣使然，我們?nèi)园堰@一套相關(guān)技術(shù)叫做SSL。SSL將非對稱加解密、數(shù)字簽名、數(shù)字證書等核心PKI技術(shù)應(yīng)用在網(wǎng)絡(luò)通信的傳輸層，實現(xiàn)了服務(wù)器/客戶端認證和數(shù)據(jù)加密，保證了網(wǎng)絡(luò)中傳輸數(shù)據(jù)的安全。
先介紹一下應(yīng)用最廣的服務(wù)器認證。服務(wù)器認證也叫單向認證，即客戶端瀏覽器訪問HTTPS網(wǎng)站時，先要對網(wǎng)站的真實性進行認證，認證通過后，客戶端與網(wǎng)站之間的數(shù)據(jù)交換以密文形式進行。具體的認證過程，不是本文的重點，因為你在其他很多介紹SSL的文章上都可以看到詳細的描述。本文重點是它的密碼學原理，先看下圖。
這張圖畫出了單向認證的核心過程。認證時，網(wǎng)站服務(wù)器先將自己的服務(wù)器證書發(fā)送給客戶端，客戶端收到證書后進行以下四項檢查：
· 證書是否過期就是檢查當前時間是否在證書有效期內(nèi)；
· 證書是否由可信任CA頒發(fā)在數(shù)字證書那一篇里介紹過；
· 證書是否被吊銷就是指當前證書是不是已經(jīng)被頒發(fā)它的CA吊銷了。客戶端檢查證書是否吊銷有CRL和OCSP兩種方法。CRL即證書吊銷列表，里面有CA已經(jīng)吊銷了的證書集合，客戶端通過檢查CRL就可以判斷證書是否被吊銷。CRL是可以根據(jù)一定的算法更新的。OCSP是在線證書狀態(tài)檢查協(xié)議，客戶端直接向證書簽發(fā)機構(gòu)發(fā)起查詢請求以確認該證書是否有效；
· 證書主題（持有人）名稱中的域名與你要訪問網(wǎng)站的域名是否一致。
如果上面四項有任何一項檢查結(jié)果為否，瀏覽器就會給出相關(guān)警告提示，如下圖是頒發(fā)證書的CA不被信任時的提示。
而這是網(wǎng)站域名與證書持有人的名稱不一致的情況。注意，這里并不要求持有人的名稱和網(wǎng)站名稱一致，而是指持有人的域名和完整域名一致。
一旦出現(xiàn)了這些警告，瀏覽器都會強烈建議用戶不要繼續(xù)訪問（當然Chrome比IE更強烈，下圖是IE打開同一個網(wǎng)站的提示，請細品個中的不同），
但最終要不要繼續(xù)訪問，決定權(quán)還在用戶手里。因此，客戶端驗證服務(wù)器證書這一步，實際上是由客戶端瀏覽器檢查和用戶自行判斷共同完成的。很多人在學習SSL時總問驗證服務(wù)器證書這一步是怎么驗證的，其實就是由用戶自己人工完成的，我們也可以叫它"人肉驗證"。你如果無視這些警告，繼續(xù)訪問，就表明你已經(jīng)認同了這張服務(wù)器證書，也就等于認同了這個網(wǎng)站。相信很多人和我以前一樣，遇到這樣的警告都是馬上找繼續(xù)訪問的按鈕，基本不看到底警告了什么。如果自己開發(fā)的業(yè)務(wù)系統(tǒng)這樣做問題不大，但要是在互聯(lián)網(wǎng)上訪問第三方的網(wǎng)站，遇到這樣的警告還是要小心謹慎，一定要確保真的沒問題才可以訪問。很多中間人攻擊就是利用了用戶這種麻痹大意的心理得手的。
完成了服務(wù)器證書驗證最重要的一步后，下面的工作就是水到渠成了。客戶端會生成一個隨機數(shù)作為生成對稱密鑰的數(shù)據(jù)，叫預主密鑰，然后用服務(wù)器證書的公鑰加密這個密鑰，并把這個加密的密鑰傳送給服務(wù)器，服務(wù)器用自己的私鑰解密。客戶端與服務(wù)器根據(jù)相同的預主密鑰計算出對稱密鑰（其實這一步還有其他隨機數(shù)參與，這里就不再展開了），雙方使用對稱密鑰加密發(fā)送的數(shù)據(jù)，解密接收的數(shù)據(jù)，最終建立了網(wǎng)絡(luò)傳輸?shù)陌踩ǖ馈?/p>
在服務(wù)器認證的基礎(chǔ)上，SSL支持對客戶端的認證，這樣單向認證就變成了雙向認證。實現(xiàn)雙向認證要先做一個準備工作：用戶需要先將其證書登記在服務(wù)器的證書信任庫或數(shù)據(jù)庫中，并與被授權(quán)訪問服務(wù)器的用戶賬戶綁定。
與單向認證相比，紅色步驟就是雙向認證增加的部分。客戶端會進行對數(shù)據(jù)的簽名，在TLS協(xié)議中這個生成簽名的數(shù)據(jù)是之前的握手信息，然后把簽名結(jié)果（包括用戶證書）和加密的隨機數(shù)一起發(fā)送給服務(wù)器。服務(wù)器收到后，要驗證簽名后及用戶的證書。這個驗證過程除了有效期、是否被吊銷以及頒發(fā)CA是否被可信外，還需要在服務(wù)器的證書信任庫或數(shù)據(jù)庫里進行對比，以確定當前用戶的身份。驗證通過后，再按照單向認證的步驟解密隨機數(shù)，生成對稱密鑰。在實際使用時，瀏覽器會彈出窗體讓用戶選擇要發(fā)送的證書，如下圖。如果證書是用USBKey載體，則會彈出輸入口令對話框，完成數(shù)字簽名。這就是雙因素認證。
上述雙向認證過程可能和有些網(wǎng)上文章描述的不同，那些文章描述的是在雙向認證中，客戶端直接把自己的證書發(fā)送給服務(wù)器，而不是簽名，之后服務(wù)器先用客戶端公鑰加密服務(wù)器選定的對稱加密方案，客戶端收到后使用私鑰解密得到。上述描述應(yīng)該是之前SSL協(xié)議的內(nèi)容，并不是現(xiàn)在TLS協(xié)議的雙向認證過程。
SSL的優(yōu)點在于配置相對簡單，應(yīng)用層改動很小。如果是單向認證，你的網(wǎng)站甚至不用改一行代碼，配置服務(wù)器即可，因為它作用在傳輸層，對應(yīng)用層來講是透明的。但也正是因為這樣，使用SSL的HTTPS也有以下缺點：
多次握手協(xié)議和傳輸數(shù)據(jù)的加解密會帶來網(wǎng)頁訪問速度變慢，網(wǎng)絡(luò)資源消耗增大；
使用界面（如客戶端認證時的證書選擇的對話框）無法與應(yīng)用層的界面保持一致，影響用戶瀏覽體驗；
在網(wǎng)頁中不能引用其他非安全資源，說白了就是不能嵌入http協(xié)議的鏈接。這并不是跨域的問題，而是瀏覽器認為不安全。不過，如果訪問的是本地資源，比如，大部分瀏覽器是認為沒問題的；
SSL證書需要花錢。雖然你自己也可以簽發(fā)一個SSL證書做服務(wù)器認證，技術(shù)上和那些大廠SSL證書沒有任何區(qū)別。但自己簽發(fā)證書的CA是不被信任的，你也不可能一個個通知用戶去手動把簽發(fā)CA的根證書裝到信任頒發(fā)機構(gòu)里。所以，使用windows已經(jīng)預裝的那些受信任根CA或它們的分支機構(gòu)簽發(fā)的SSL證書是普遍的選擇。SSL證書按年收費，費用在每年幾百元到幾千元不等。具體使用哪一種證書，要看網(wǎng)站的定位；
早期的SSL1.0、SSL2.0都有漏洞，相信做過平臺漏掃的同學對此都不陌生；
另外有些觀點認為SSL不能隱藏用戶隱私信息，不能認證用戶真實身份。我個人認為這并不是SSL做的事，這是應(yīng)用層的問題。總之，使用基于SSL的HTTPS，能夠有效地降低傳輸數(shù)據(jù)被竊取的風險，增加網(wǎng)站被中間人劫持攻擊的難度。各位老鐵，能用還是都用了吧。
