HTTPS

一伤溉、SSL/TLS協(xié)議運行機制的概述

握手階段的詳細(xì)過程

握手階段所有的通訊都是明文的

（一） 第一階段 客戶端和服務(wù)器端安全信息的互相發(fā)送

1.1 客戶端發(fā)出請求（ClientHello）

首先般码，客戶端（通常是瀏覽器）先向服務(wù)器發(fā)出加密通信的請求，這被叫做ClientHello請求乱顾。
在這一步板祝，客戶端主要向服務(wù)器提供以下信息。
（1）客戶端可以支持的SSL的最高版本號
（2）一個用于生成密鑰的32字節(jié)的隨機數(shù)
（3）一個確定會話的會話ID
（4）一個客戶端可以支持的密碼套件列表
（5）一個客戶端可以支持的壓縮算法列表

1.2 服務(wù)端回應(yīng) （serverHello）

服務(wù)器收到客戶端請求后走净，向客戶端發(fā)出回應(yīng)扔字，這叫做SeverHello囊嘉。服務(wù)器的回應(yīng)包含以下內(nèi)容。
（1）SSL版本號革为，取客戶端支持的最高版本號和服務(wù)器端支持的最高版本號中的較低者
（2）一個用于生成密鑰的32字節(jié)的隨機數(shù)
（3）會話ID
（4）從客戶端的密碼套件列表中選擇的一個密碼套件
（5）從客戶端的壓縮方法列表中選擇的壓縮方法

這個階段之后扭粱，客戶端服務(wù)端知道了下列內(nèi)容：
（1）SSL版本
（2）密鑰交換算法（也就是，非對稱加密算法）震檩、信息驗證算法（也就是琢蛤，HASH算法）和加密算法（也就是，對稱加密算法）
（3）壓縮方法
（4）有關(guān)密鑰生成的兩個隨機數(shù)

握手階段所有的通訊都是明文的

（二） 第二階段 服務(wù)器推送證書到客戶端進行密鑰交換與客戶端證書鑒別

（a）證書：服務(wù)器將數(shù)字證書和到根CA的整個證書鏈發(fā)給客戶端抛虏，使客戶端能夠認(rèn)證服務(wù)器
（b）服務(wù)器密鑰交換（可選）：這里視密鑰交換算法而定
（c）證書請求：服務(wù)器可能要求客戶端發(fā)送客戶端證書
（d）服務(wù)器握手完成：第二階段結(jié)束博其，第三階段開始
上圖中省略了：客戶端利用服務(wù)器傳過來的信息驗證服務(wù)器的合法性，服務(wù)器的合法性包括：證書是否過期迂猴，發(fā)行服務(wù)器證書的 CA 是否可靠慕淡，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書上的域名是否和服務(wù)器的實際域名相匹配沸毁。如果合法性驗證沒有通過峰髓，通訊將斷開；如果合法性驗證通過息尺，通訊將繼續(xù)携兵。

（三） 第三階段 客戶端推送證書密鑰到服務(wù)器端

客戶端收到服務(wù)器回應(yīng)以后，首先驗證服務(wù)器證書搂誉。如果證書不是可信機構(gòu)頒布徐紧、或者證書中的域名與實際域名不一致、或者證書已經(jīng)過期炭懊，就會向訪問者顯示一個警告并级，由其選擇是否還要繼續(xù)通信。

與上一步類似侮腹，上一步是服務(wù)器端向客戶端推送證書嘲碧，客戶端已經(jīng)信任了服務(wù)器端，但是服務(wù)器端還要驗證客戶端凯旋，這一步的操作完成后，雙向的SSL就完成了钉迷。

如果證書沒有問題至非，客戶端就會從證書中取出服務(wù)器的公鑰
（a）證書（可選）：為了向服務(wù)器證明自身，客戶端要發(fā)送客戶端證書
（b）預(yù)備主密鑰（Pre-master-secret）：客戶端生成預(yù)備主密鑰糠聪，并將其發(fā)送給服務(wù)端荒椭，注意這里會使用服務(wù)端的公鑰進行加密
（c）證書驗證（可選）：對預(yù)備主密鑰和隨機數(shù)進行簽名，證明客戶端擁有（a）證書的公鑰
至此舰蟆，服務(wù)器端和客戶端各有一把私鑰和公鑰趣惠，私鑰都是自己的狸棍，公鑰都是對方的。
上面第一項的隨機數(shù)味悄，是整個握手階段出現(xiàn)的第三個隨機數(shù)草戈，又稱"pre-master key"。有了它以后侍瑟，客戶端和服務(wù)器就同時有了三個隨機數(shù)唐片，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"涨颜。

（四） 第四階段 服務(wù)器確認(rèn)费韭，SSL通訊建立，定期修改密碼規(guī)范

服務(wù)器收到客戶端的第三個隨機數(shù)pre-master key之后庭瑰，計算生成本次會話所用的"會話密鑰"星持。然后，向客戶端最后發(fā)送下面信息
（1）編碼改變通知弹灭，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送督暂。
（2）服務(wù)器握手結(jié)束通知，表示服務(wù)器的握手階段已經(jīng)結(jié)束鲤屡。這一項同時也是前面發(fā)送的所有內(nèi)容的hash值损痰，用來供客戶端校驗。

但是酒来，每一次后期的傳輸堂污，也可以通過設(shè)置實現(xiàn)：不使用同一個密碼督怜，而是像上圖中最后一步一樣，將摘要散列值和密碼定期更換。
至此雷滋，SSL通道就建立成功了。

二廷粒、HTTPS中的密碼學(xué)

2.1 概念

HTTPS 在證書的數(shù)字簽名中使用了哈希算法和非對稱加密算法鸳址，在加密通信的過程中使用了對稱加密算法，為了防止傳輸?shù)臄?shù)據(jù)被篡改和重放還使用了 MAC（消息認(rèn)證碼）等就乓。

• 哈希 --散列算法
• 哈希算法又稱散列汉匙，它是一種將任意長度的數(shù)據(jù)轉(zhuǎn)化為固定長度的算法
• 哈希算法是不可逆的
• 常見的哈希算法有 MD5 和 SHA1
• 對稱加密 --加密算法
• 對稱加密指的是加密和解密使用相同一個密鑰
• 對稱加密的優(yōu)點是速度快，缺點是密鑰管理不方便生蚁，必須共享密鑰
• 常見的對稱加密算法有 DES噩翠、AES、Blowfish 等
• 非對稱加密 --秘鑰交換
• 非對稱加密指的是加密和解密使用不同的密鑰邦投，其中一個是公鑰伤锚，另一個是私鑰，公鑰是公開的志衣，私鑰只有自己知道
• 使用公鑰加密的數(shù)據(jù)必須使用私鑰解密屯援，使用私鑰加密的數(shù)據(jù)必須使用公鑰解密
• 公鑰和私鑰之間存在著某種聯(lián)系猛们，但是從公鑰不能（或很難）推導(dǎo)出私鑰
• 非對稱加密的缺點是速度慢，優(yōu)點是密鑰管理很方便
• 常見的非對稱加密算法有 RSA狞洋、ECC 等
• **公鑰密碼體制(public-key cryptography) **
  
  公鑰密碼體制的公鑰和算法都是公開的(這是為什么叫公鑰密碼體制的原因)弯淘，私鑰是保密的。大家都以使用公鑰進行加密徘铝，但是只有私鑰的持有者才能解密耳胎。在實際的使用中，有需要的人會生成一對公鑰和私鑰惕它，把公鑰發(fā)布出去給別人使用怕午，自己保留私鑰。
  
  公鑰密碼體制分為三個部分淹魄，公鑰郁惜、私鑰、加密解密算法甲锡，它的加密解密過程如下：
• 加密：通過加密算法和公鑰對內(nèi)容(或者說明文)進行加密兆蕉，得到密文。加密過程需要用到公鑰缤沦。
• 解密：通過解密算法和私鑰對密文進行解密虎韵，得到明文。解密過程需要用到解密算法和私鑰缸废。注意包蓝，由公鑰加密的內(nèi)容，只能由私鑰進行解密企量，也就是說测萎，由公鑰加密的內(nèi)容，如果不知道私鑰届巩，是無法解密的硅瞧。
  
• 簽名和加密
• 加密：某個內(nèi)容加密，加密后的內(nèi)容還可以通過解密進行還原
• 簽名：簽名就是在信息的后面再加上一段內(nèi)容恕汇，可以證明信息沒有被修改過腕唧。
  一般是對信息做一個hash計算得到一個hash值，注意瘾英，這個過程是不可逆的枣接，在把信息發(fā)送出去時，把這個hash值加密后做為一個簽名和信息一起發(fā)出去方咆。 接收方在收到信息后月腋，會重新計算信息的hash值蟀架，并和信息所附帶的hash值(解密后)進行對比瓣赂，如果一致榆骚，就說明信息的內(nèi)容沒有被修改過，因為這里hash計算可以保證不同的內(nèi)容一定會得到不同的hash值
  為了防止攻擊者修改信息內(nèi)容的同時也修改hash值煌集，從而讓他們匹配妓肢，hash值一般都會加密后(也就是簽名)再和信息一起發(fā)送，以保證這個hash值不被修改

• 數(shù)字證書
  是用于公開密鑰基礎(chǔ)建設(shè)的電子文件苫纤，用來證明公開密鑰擁有者的身份碉钠。此文件包含了公鑰信息、擁有者身份信息（主體）卷拘、以及數(shù)字證書認(rèn)證機構(gòu)（發(fā)行者）對這份文件的數(shù)字簽名喊废，以保證這個文件的整體內(nèi)容正確無誤

• 術(shù)語
  ECDH - 橢圓曲線 Diffie-Hellman
  DH - Diffie-Hellman
  RSA - Rivest, Shamir, Adleman
  ECDSA - 橢圓曲線數(shù)字簽名算法
  AES - 高級加密標(biāo)準(zhǔn)
  GCM - Galois/計數(shù)器模式 - 密碼區(qū)塊加密的操作模式
  CBC - 密碼塊鏈接
  3DES - 三重數(shù)據(jù)加密算法
  SHA - 安全散列算法

2.2 關(guān)于證書

• 什么是證書
  證書 （digital certificate / public key certificate）：數(shù)字證書就好比介紹信上的公章，有了它栗弟，就可以證明這份介紹信確實是由某個公司發(fā)出的污筷，而證書可以用來證明任何一個東西的身份，只要這個東西能出示一份證明自己身份的證書即可乍赫，譬如可以用來驗證某個網(wǎng)站的身份瓣蛀，可以驗證某個文件是否可信等等;
• 數(shù)字證書
  是用于公開密鑰基礎(chǔ)建設(shè)的電子文件，用來證明公開密鑰擁有者的身份雷厂。此文件包含了公鑰信息惋增、擁有者身份信息（主體）、以及數(shù)字證書認(rèn)證機構(gòu)（發(fā)行者）對這份文件的數(shù)字簽名改鲫，以保證這個文件的整體內(nèi)容正確無誤
  證書之間的信任關(guān)系诈皿，是可以嵌套的，叫做證書信任鏈
• 什么是CA
  CA 是“Certificate Authority”的縮寫钩杰，也叫“證書授權(quán)中心”纫塌。是負(fù)責(zé)管理和簽發(fā)證書的第三方機構(gòu)
• 什么是根證書
  根證書（root certificate）是屬于根證書頒發(fā)機構(gòu)（CA）的公鑰證書，是在公開密鑰基礎(chǔ)建設(shè)中讲弄，信任鏈的起點

三措左、Keyless服務(wù)

• 即你把網(wǎng)站放到它們的CDN上，不用提供自己的私鑰避除，也能使用SSL加密鏈接怎披。

1.SSL協(xié)議的握手過程

SSL協(xié)議握手過程

• （一）、客戶端給出協(xié)議版本號瓶摆、一個客戶端生成的隨機數(shù)（Client random）凉逛，以及客戶端支持的加密方法。
• （二）群井、服務(wù)端確認(rèn)雙方使用的加密方法状飞，并給出數(shù)字證書、以及一個服務(wù)器生成的隨機數(shù)（Server random）。
• （三）诬辈、客戶端確認(rèn)數(shù)字證書有效酵使，然后生成一個新的隨機數(shù)（Premaster secret），并使用數(shù)字證書中的公鑰焙糟，加密這個隨機數(shù)口渔，發(fā)給服務(wù)端。
• （四）穿撮、服務(wù)端使用自己的私鑰缺脉，獲取客戶端發(fā)來的隨機數(shù)（即Premaster secret）。

• （五）悦穿、客戶端和服務(wù)端根據(jù)約定的加密方法攻礼，使用前面的三個隨機數(shù)，生成"對話密鑰"（session key）栗柒，用來加密接下來的整個對話過程秘蛔。

  
  
  without keyless

2.私鑰的作用

握手階段有三點需要注意。
（1）生成對話密鑰一共需要三個隨機數(shù)傍衡。
（2）握手之后的對話使用"對話密鑰"加密（對稱加密）深员，服務(wù)器的公鑰和私鑰只用于加密和解密"對話密鑰"（非對稱加密），無其他作用蛙埂。
（3）服務(wù)器公鑰放在服務(wù)器的數(shù)字證書之中倦畅。
從上面第二點可知，整個對話過程中（握手階段和其后的對話）绣的，服務(wù)器的公鑰和私鑰只需要用到一次叠赐。這就是CloudFlare能夠提供Keyless服務(wù)的根本原因。
某些客戶（比如銀行）想要使用外部CDN屡江，加快自家網(wǎng)站的訪問速度芭概，但是出于安全考慮，不能把私鑰交給CDN服務(wù)商惩嘉。這時罢洲，完全可以把私鑰留在自家服務(wù)器，只用來解密對話密鑰文黎，其他步驟都讓CDN服務(wù)商去完成惹苗。

with keyless

3.session恢復(fù)

握手階段用來建立SSL連接。如果出于某種原因耸峭，對話中斷桩蓉，就需要重新握手。
這時有兩種方法可以恢復(fù)原來的session：一種叫做session ID劳闹，另一種叫做session ticket院究。
session ID的思想很簡單洽瞬，就是每一次對話都有一個編號（session ID）。如果對話中斷业汰，下次重連的時候片任，只要客戶端給出這個編號，且服務(wù)器有這個編號的記錄蔬胯，雙方就可以重新使用已有的"對話密鑰"，而不必重新生成一把位他。

session ID

上圖中氛濒，客戶端給出session ID，服務(wù)器確認(rèn)該編號存在鹅髓，雙方就不再進行握手階段剩余的步驟舞竿，而直接用已有的對話密鑰進行加密通信。
session ID是目前所有瀏覽器都支持的方法窿冯，但是它的缺點在于session ID往往只保留在一臺服務(wù)器上骗奖。所以，如果客戶端的請求發(fā)到另一臺服務(wù)器醒串，就無法恢復(fù)對話执桌。session ticket就是為了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持芜赌。

session ticket

上圖中仰挣，客戶端不再發(fā)送session ID，而是發(fā)送一個服務(wù)器在上一次對話中發(fā)送過來的session ticket缠沈。這個session ticket是加密的膘壶，只有服務(wù)器才能解密，其中包括本次對話的主要信息洲愤，比如對話密鑰和加密方法颓芭。當(dāng)服務(wù)器收到session ticket以后，解密后就不必重新生成對話密鑰了柬赐。

四 參考鏈接

圖解SSL/TLS協(xié)議
HTTPS和Nginx的HTTPS配置