本文邀請阿裡雲CDN HTTPS技術專家金九，分享Tengine的一些HTTPS實踐經驗。内容主要有四個方面：HTTPS趨勢、HTTPS基礎、HTTPS實踐、HTTPS調試。
一、HTTPS趨勢
這一章節主要介紹近幾年和未來HTTPS的趨勢，包括兩大浏覽器chrome和firefix對HTTPS的态度，以及淘寶天貓和阿裡雲CDN的HTTPS實踐情況。
上圖是 chrome 統計的HTTPS網頁占比的趨勢，2015年的時候，大多數國家的HTTPS網頁加載次數隻占了不到 50%，2016年美國這個占比到了将近60%，去年就已經超過 70%，目前已經超過 80%。最下面是日本，目前是60%左右，這裡面沒有統計到中國的資料，我估計中國的占比會更少，空間還有很大，但未來HTTPS趨勢是明顯的。
同樣，Firefox 浏覽器加載HTTPS網頁的統計跟 chrome 差不多，全球 HTTPS網頁加載占比在 70% 左右，上升趨勢也很明顯。
更值得關注的是，Google 在今年年初的時候在其安全部落格上表明，在今年7月份左右釋出的 chrome68 浏覽器會将所有HTTP網站标記為不安全，現在是5月份底了，離這個時間也就一個多月的時間了。右邊的截圖可以看出本來是綠色的小鎖變成了不安全，這種網頁在輸入密碼時就很不安全了。
早期天貓淘寶隻是在關鍵的登入和交易的環節上了HTTPS，但随着網際網路的發展，劫持、篡改等等問題也越來越嚴重，試想在天貓淘寶上看的商品圖檔被惡意人替換了或者價格被篡改了會怎麼樣？這樣使用者、商家和平台都受到傷害，隻有上了 HTTPS才能從根本上解決這些問題。是以，天貓和淘寶在2015年7月份的時候已經完成了全站HTTPS。
二、HTTPS基礎
本章節主要介紹HTTPS為什麼安全，包括對稱加密、非對稱加密、簽名、證書&證書鍊、SSL是怎麼握手的、以及私鑰密鑰在HTTPS中發揮什麼樣的作用、keyless又是解決什麼樣的問題等等。
HTTPS的定義
簡單來講，HTTPS就是安全的HTTP，我們知道HTTP是運作在TCP層之上的，HTTPS在HTTP層和TCP層之間加了一個SSL層，SSL向上提供加密和解密的服務，對HTTP比較透明，這樣也便于伺服器和用戶端的實作以及更新。
HTTPS為什麼安全？
HTTPS安全是由一套安全機制來保證的，主要包含這4個特性：機密性、完整性、真實性和不可否認性。
- 機密性是指傳輸的資料是采用Session Key（會話密鑰）加密的，在網絡上是看不到明文的。
- 完整性是指為了避免網絡中傳輸的資料被非法篡改，使用MAC算法來保證消息的完整性。
- 真實性是指通信的對方是可信的，利用了PKI（Public Key Infrastructure 即『公鑰基礎設施』）來保證公鑰的真實性。
- 不可否認性是這個消息就是你給我發的，無法僞裝和否認，是因為使用了簽名的技術來保證的。
對稱加密和非對稱加密
HTTPS有對稱加密和非對稱加密兩種算法，目的都是把明文加密成密文，差別是密鑰的個數不一樣，對稱加密是一把密鑰，這把密鑰可以加密明文，也可以解密加密後的密文，常見的對稱加密算法有AES、DES、RC4，目前最常用的是AES。
非對稱加密是兩把密鑰，分别是公鑰和私鑰，公鑰加密的密文隻有相對應的私鑰才能解密，私鑰加密的内容也隻有相對應的公鑰才能解密，其中公鑰是公開的，私鑰是自己儲存，不能公開，常見的非對稱加密算法有RSA和ECC（橢圓曲線算法）。
SSL結合了這兩種加密算法的優點，通過非對稱加密來協商對稱加密的密鑰，握手成功之後便可使用對稱加密來做加密通信，對于RSA來說，用戶端是用RSA的公鑰把預主密鑰加密後傳給伺服器，伺服器再用私鑰來解密，雙方再通過相同的算法來生成會話密鑰，之後的應用層資料就可以通過會話密鑰來加密通信。
簽名
SSL中還有一個使用非對稱加密的地方就是簽名，簽名的目的是讓對方相信這個資料是我發送的，而不是其他人發送的。
密鑰安全強度與性能對比
加密之後的資料破解難度就展現在密鑰的長度上，密鑰越長，破解難度也越大，但是運算的時間也越長，性能也就越差。相同安全強度下，對稱密鑰長度在最短，ECC次之，RSA密鑰長度則最長。
目前比較常用的密鑰長度是：對稱密鑰128位、ECC 256位、RSA 2048位。
RSA和ECC在SSL中更多的是用來簽名，通過測試發現，ECC 的簽名性能比RSA好很多，但是RSA的驗簽性能比ECC更好，是以RSA更适合于驗證簽名頻繁而簽名頻度較低的場景，ECC更适合于簽名頻繁的場景，在SSL場景中，ECC算法性能更好。
公鑰基礎設施（PKI）
簡單的說，PKI就是浏覽器和CA，CA是整個安全機制的重要保障，我們平時用的證書就是由CA機構頒發，其實就是用CA的私鑰給使用者的證書簽名，然後在證書的簽名字段中填充這個簽名值，浏覽器在驗證這個證書的時候就是使用CA的公鑰進行驗簽。
證書
那CA在PKI中又是怎樣發揮作用的呢，首先，CA的作用就是頒發證書，頒發證書其實就是使用CA的私鑰對證書請求簽名檔案進行簽名，其次，CA頒發的證書浏覽器要信任，浏覽器隻需要用CA的公鑰進行驗簽成功就表示這個證書是合法可信的，這就需要浏覽器内置CA的公鑰，也就是内置CA的證書。一般來說，作業系統都會内置權威CA的證書，有的浏覽器會使用作業系統内置的CA憑證清單，有的浏覽器則自己維護的CA憑證清單，比如Firefox。
CA分為根CA，二級CA，三級CA，三級CA憑證由二級CA的私鑰簽名，二級CA憑證由根CA的私鑰簽名，根CA是自簽名的，不會給使用者證書簽名，我們平時用的證書都是由二級CA或者三級CA簽名的，這樣就形成了一個證書鍊，浏覽器在驗簽的時侯一層層往上驗證，直到用内置的根CA憑證的公鑰來驗簽成功就可以表示使用者證書是合法的證書。
根證書已經内置在浏覽器或者作業系統裡了，在SSL握手時就不需要發根CA憑證了，隻需要提供中間二級三級CA憑證和使用者證書就可以。
交叉證書
交叉證書的應用場景是這樣的：假如現在阿裡雲成為一個新的根CA機構，那阿裡雲簽發的證書想要浏覽器信任的話，阿裡雲的根證書就需要内置在各大作業系統和浏覽器中，這需要較長時間的部署，那在沒有完全部署完成之前，阿裡雲簽發的證書怎麼才能讓浏覽器信任呢，這就需要用到交叉證書了。
上圖中，根證書A是一個所有浏覽器都内置了的根證書，B是一個新的根證書，使用者證書D是由根證書 B的二級CA B1來簽發的，但是根證書B并沒有在浏覽器中内置，是以浏覽器不會信任使用者證書D，這是因為浏覽器在驗簽時隻驗證到B1這一層然後找不到根證書B就無法驗證下去了。
如果二級CA B1證書是由根證書A來簽名，那這個問題就解了，是以新的根證書機構B會将二級CA憑證（準确地講是二級CA的證書簽名請求檔案）給老的根證書A來簽名，然後得到一個新的中間證書就是交叉證書。
浏覽器在驗證的時侯用了新的信任鍊，這樣就可以解決使用者證書的信任問題。
當B的根證書全部部署完成後，再替換成自己的二級CA就可以了。
證書分類
證書分有三類：DV、OV、EV
DV證書隻校驗域名的所有權，是以我們在申請DV證書的時候CA會提供幾種驗證域名所有權的方法：比如檔案校驗、DNS校驗、郵件校驗，DV證書支援單域名、多域名和泛域名，但不支援多個泛域名，隻支援一個泛域名，一般價格比較便宜，具體價格跟域名的數量有關，域名越多價格越高。
OV證書要驗證組織機構，在申請證書時CA會打電話确認這個域名是否真的屬于相應的公司或者機構，OV證書是單域名、多域名、泛域名和多個泛域名都支援，價格一般比DV證書要貴。
EV證書的校驗就更細了，比如組織機構的位址之類的，EV證書會在位址欄上顯示組織機構的名稱，EV證書隻支援單域名或者多個域名，不支援泛域名，而且更貴，是以普通使用者一般不會用EV證書。
證書吊銷
證書是有生命周期的，如果證書的私鑰洩漏了那這個證書就得吊銷，一般有兩種吊銷方式：CRL和OCSP。
CRL是CA機構維護的一個已經被吊銷的證書序列号清單，浏覽器需要定時更新這個清單，浏覽器在驗證證書合法性的時候也會在證書吊銷清單中查詢是否已經被吊銷，如果被吊銷了那這個證書也是不可信的。可以看出，這個清單随着被吊銷證書的增加而增加，清單會越來越大，浏覽器還需要定時更新，實時性也比較差。
是以，後來就有了 OCSP 線上證書狀态協定，這個協定就是解決了 CRL 清單越來越大和實時性差的問題而生的。有了這個協定，浏覽器就可以不用定期更新CRL了，在驗證證書的時候直接去CA伺服器實時校驗一下證書有沒有被吊銷就可以，是解決了CRL的問題，但是每次都要去CA伺服器上校驗也會很慢，在網絡環境較差的時候或者跨國通路的時候，體驗就非常差了，OCSP雖然解決了CRL的問題但是性能卻很差。是以後來就有了OCSP stapling。
OCSP stapling主要解決浏覽器OCSP查詢性能差的問題，本來由浏覽器去CA的OCSP伺服器查詢證書狀态的，現在改由域名的伺服器去查詢，将OCSP的結果告訴浏覽器即可，一般伺服器的網絡性能要好于使用者電腦的網絡，是以OCSP stapling的性能是最好的。但是并不是所有的伺服器都支援OCSP stapling，是以目前浏覽器還是比較依賴CRL，證書吊銷的實時性要求也不是特别高，是以定期更新問題也不大。
HTTPS工作模式
對于用戶端和伺服器來講，應用層協定還是HTTP，隻是加了一個SSL層來做加密解密的邏輯，對應用層來說是透明的，在網絡上傳輸的都是加密的請求和加密的響應，進而達到安全傳輸的目的。
這是SSL層在網絡模型的位置，SSL屬于應用層協定。接管應用層的資料加解密，并通過網絡層發送給對方。
更細地分，SSL協定分握手協定和記錄協定，握手協定用來協商會話參數（比如會話密鑰、應用層協定等等），記錄協定主要用來傳輸應用層資料和握手協定消息資料，以及做加解密處理。我們應用層的的消息資料在SSL記錄協定會給分成很多段，然後再對這個片段進行加密，最後在加上記錄頭後就發送出去。
TLS握手協定
SSL/TLS 握手協定又細分為四個子協定，分别是握手協定、密碼規格變更協定、警告協定和應用資料協定。
完整的握手流程
首先是TCP握手，TCP三次完成之後才進入SSL握手，SSL握手總是以ClientHello消息開始，就跟TCP握手總是以SYN包開始一樣；
ClientHello主要包含用戶端支援的協定、密鑰套件、session id、用戶端随機數、sni、應用層協定清單（http/1.1、h2）、簽名算法等等；
伺服器收到ClientHello之後會從中選取本次通信的協定版本、密鑰套件、應用層協定、簽名算法，以及伺服器随機數，然後通過ServerHello消息響應，如果沒有session複用，那将伺服器的證書通過Certificate消息響應，如果是選用了ECC算法來做密鑰交換的話，那還會将橢圓曲線參數以及簽名值通過ServerKeyExchange消息發送給對方，最後通過ServerHelloDone消息來結束本次協商過程；
用戶端收到這些消息之後，會生成預主密鑰、主密鑰和會話密鑰，然後将橢圓曲線參數通過ClientKeyExchange發送給伺服器，伺服器拿到用戶端的橢圓曲線參數也會生成預主密鑰，如果是RSA的話ClientKeyExchange用來發送公鑰加密的預主密鑰，伺服器用私鑰來解密一下就可以得到預主密鑰，再由預主密鑰生成主密鑰和會話密鑰。最後雙方都以ChangeCipherSpce和Finished消息來告知對方，自己已經準備好了可以進行加密通信了，然後握手完成。
可以看出，完整的SSL握手需要2個RTT，而且每次握手都用到了非對稱加密算法簽名或者解密的操作，比較耗CPU，是以後來就有了session複用的優化手段，後面會做介紹。
SSL的握手消息雖然比較多，但很多消息都是放在一個TCP包中發送的，從抓包可以看出完整的SSL握手需要2個RTT。
剛才通過完整的SSL握手可以看出幾個缺點：
1、2個RTT，首包時間較長
2、每次都要做非對稱加密，比較耗CPU，影響性能
3、每次都要傳證書，證書一般都比較大，浪費帶寬
SSL握手的目的是協商會話密鑰以及參數，如果能把這些會話參數緩存那就可以沒有必要每次都傳證書和做非對稱加密計算，這樣就可以提高握手性能，而且可以将RTT減到1個，提高使用者體驗。
是以就有了session id的複用方式，每次完整握手之後都将協商好的會話參數緩存在伺服器中，用戶端下次握手時會将上次握手的session id帶上，伺服器通過session id查詢是否有會話緩存，有的話就直接複用，沒有的話就重新走完整握手流程。但是session id這種方式也有缺點，比較難支援分布式緩存以及耗費伺服器的記憶體。
而session ticket 方案，其原理可以了解為跟 http cookie 一樣，伺服器将協商好的會話參數加密成 session ticket，然後發送給用戶端，用戶端下次握手時會将這個session ticket帶上，伺服器解密成功就複用上次的會話參數，否則就重新走完整握手流程。可以看出session ticket這種方式不需要伺服器緩存什麼，支援分布式環境，有很大的優勢。這種方式有一個缺點是并不是所有用戶端都支援，支援率比較低，但随着用戶端版本的更新疊代，以後各種用戶端會都支援。因為session id用戶端支援率比較高，是以目前這兩種方式都在使用。
這是 session ticket 的複用，跟 session id 的差別是 client hello 會帶上 Session ticket ，将近200個位元組的加密資料，伺服器會用session ticket 密鑰來解密，解密成功則直接複用，也簡化了握手流程，提升效率和性能。
這是我們上了分布式 Session id 複用的效果，session id複用的比例在沒有開啟分布式緩存時隻占了3%左右，複用率很低，上了分布式session緩存之後，這個比例提升到20%多。握手時間也從75ms左右降低到65ms左右，性能提升效果還是很明顯的。
SSL/TLS握手時的私鑰用途（RSA、ECDHE）
我們知道私鑰是整個SSL中最重要的東西，那私鑰在SSL握手裡面又是怎麼使用的呢？兩種使用方式分别是：使用RSA來做密鑰交換和使用ECDHE來做密鑰交換。對于RSA來說，用戶端生成預主密鑰，然後用公鑰加密再發給伺服器，伺服器用私鑰來解密得到預主密鑰，然後由預主密鑰生成主密鑰，再由主密鑰生會話密鑰，最後用會話密鑰來通信。
對于ECDHE來說，用戶端和伺服器雙方是交換橢圓曲線參數，私鑰隻是用來簽名，這是為了保證這個消息是持有私鑰的人給我發的，而不是冒充的。雙方交換完參數之後生成預主密鑰，再生成主密鑰和會話密鑰。這就跟剛才RSA後面的流程一樣了。
可以看出RSA和橢圓曲線密鑰交換算法的私鑰用途是不一樣的，RSA密鑰交換時是用來做加解密的，橢圓曲線密鑰交換時是用來做簽名的。
SSL/TLS中的密鑰
預主密鑰、主密鑰和會話密鑰，這幾個密鑰都是有聯系的。
對于RSA來說，預主密鑰是用戶端生成，加密之後發給伺服器，伺服器用私鑰來解密。對于ECDHE來說，預主密鑰是雙方通過橢圓曲線算法來生成。
主密鑰是由預主密鑰、用戶端随機數和伺服器随機數通過PRF函數來生成；會話密鑰是由主密鑰、用戶端随機數和伺服器随機數通過PRF函數來生成，會話密鑰裡面包含對稱加密密鑰、消息認證和CBC模式的初始化向量，但對于非CBC模式的加密算法來說，就沒有用到這個初始化向量。
session 緩存和session ticket裡面儲存的是主密鑰，而不是會話密鑰，這是為了保證每次會話都是獨立的，這樣才安全，即使一個主密鑰洩漏了也不影響其他會話。
Keyless
剛才提到RSA和ECDHE的私鑰用途，對于伺服器來說，密鑰交換算法是RSA時，私鑰是用來做解密的，ECDHE時，私鑰是用來簽名的。
Keyless就是将私鑰參與運算的部分分離遠端伺服器，這樣可以解決兩個問題：
1，公私鑰分離，使用者不需要将私鑰給第三方，減少私鑰洩露的風險。
2，将非對稱加密運算這種cpu密集型運算剝離到keyserver，可以在keyserver中安裝ssl加速卡做硬體加速，提高性能。
HTTP/2
HTTP/2主要有這幾個特性：
一、二進制協定，可以做更多的優化；
二、多路複用，一定程度上解決了隊頭阻塞的問題，提高并發和總的加載時間
三、頭部壓縮，很多請求頭或者響應頭都沒有必要重複傳輸浪費帶寬，比如user-agent、cookie還有其他沒有必要每次都傳的頭部在http2中都做了優化
四、安全，雖然RFC規定HTTP/2可以運作在明文之上，但目前所有浏覽器都隻支援https之上的http/2，是以是安全的。
開啟HTTP/2會有這幾個收益：
一、加載時間的提升，我們做了這麼一個測試，一張大圖檔分割成幾百個小圖檔，然後用http/1.1和http/2打開，http/1.1加載完所有小圖檔用了五六秒，但http/2加載完所有小圖檔隻需要不到1s的時間，有5倍左右的提升，效果還是很明顯的，具體提升百分之多少這得具體看具體的業務類型。
二、頭部壓縮有95%左右的提升，http/1.1的平均響應頭大小有500個位元組左右，而http/2的平均響應頭大小隻有20多個位元組，提升非常大，是以http/2非常适合小圖檔小檔案的業務類型，因為小檔案的http頭部比重較大，而http/2對頭部的壓縮做了非常好的優化。
三、伺服器QPS的性能有60%多的提升，這是因為http/2的連接配接複用和多路複用機制，可以處理更多的并發請求。
三、HTTPS實踐
本章節會重點給大家講講 Tengine 如何配置 https、HTTP/2、TLSv1.3，以及如何實作動态證書。
Tengine如何開啟HTTPS
http {
ssl_session_tickets on;
ssl_session_ticket_key ticket.key;
server {
listen 443 ssl;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers on;
ssl_certificate www.alicdn.com.crt;
ssl_certificate_key www.alicdn.com.key;
ssl_session_cache shared:SSL:256M;
ssl_session_timeout 15m;
#……
}
} 在Tengine中開啟http2，隻需要在listen的後面加上http2參數就可以了。
server {
listen 443 ssl http2;
http2 on;
server_name a.com;
#……
}
server {
listen 443 ssl;
http2 off;
server_name b.com;
#……
} 但是有一個場景需要注意，因為有些域名并不想開啟http2，比如上面這個配置的b.com并不想開http2，但是因為a.com開啟了http2，是以b.com也被自動開啟了，這是因為http2這個參數作用在ip和端口上，在ssl握手時用了a.com的配置參數，是以tengine針對這種情況做了一個域名級别的開關來做控制。
TLSv1.3——更快、更安全
1、1-RTT & 0-RTT
2、隻支援完全前向安全性的密鑰交換算法
3、ServerHello 之後的所有消息都是加密的
4、淘汰 Session ID 和 Session Ticket，用 PSK 代替
5、Chrome 63+, Firefox 58+
Tengine也支援了TLSv1.3，開啟方式：
server {
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers TLS13-AES-128-GCM-SHA256:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-CCM-8-SHA256:TLS13-AES-128-CCM-SHA256:EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+ECDSA+AES128:EECDH+aRSA+AES128:RSA+AES128:EECDH+ECDSA+AES256:EECDH+aRSA+AES256:RSA+AES256:EECDH+ECDSA+3DES:EECDH+aRSA+3DES:RSA+3DES:!MD5;
#……
} Tengine 實作與配置動态證書
動态證書主要解決的問題是接入域名太多，server塊過多導緻tengine reload慢的問題，lua-nginx子產品提供了一個證書的lua階段，可以在這個階段來做證書的熱加載，不需要reload tengine，這樣可以提高效率和性能。
配置也比較簡單，在ssl_cert.lua裡面做證書的管理，在ssl握手時拿到sni，去拿這個域名的證書和私鑰，再調用lua ffi接口就可以完成證書和私鑰的切換。
server {
ssl_certificate www.alicdn.com.crt;
ssl_certificate_key www.alicdn.com.key;
ssl_certificate_by_lua_file ssl_cert.lua;
#……
} ssl_cert.lua:
調用 lua ffi 接口設定證書和私鑰
四、HTTPS調試
我們知道HTTP是明文傳輸，調試就很簡單，抓包就可以看得清清楚楚，但HTTPS是加密的，抓包看到的是密文，這一節我告訴大家怎麼去解密HTTPS抓封包件。
抓包解密
方法一：
配置Wireshark：
Wireshark preferences… Protocols SSL (Pre)-Master-Secret log filename => /tmp/sslkey.txt （一）：
export SSLKEYLOGFILE=/tmp/sslkey.txt （二）：
openssl s_client -connect 127.0.0.1:443 -servername www.alicdn.com -keylogfile /tmp/sslkey.txt （三）：
echo “CLIENT_RANDOM 7EC0498BCF09E8300A1E9F8BA6C81E2A4383D7CDCFB10907B4074520FA8DF680 FA2457782F6FAECE47CF8E01BF9E0A441CEA8DCC91664F42F45F1EF5AB18ED902E35825713FF2D4D9651CE51ED885BB4
”>> /tmp/sslkey.txt 方法二：
強制使用RSA密鑰交換算法，Wireshark配置私鑰。
抓包解密-wireshark設定
常用指令及參數
curl
寫在最後
證書的購買和申請是非常複雜耗時的，為了縮短開通周期，為開發者提供最大化便利，簡化HTTPS加速設定環節，目前阿裡雲CDN已經支援控制台可實作一鍵開通HTTPS，背景将完成代理免費證書購買、證書節點部署以及證書到期之前自動續簽，幫助開發者更便捷的完成全站HTTPS通路加速。
本文作者：樰籬