本文邀請阿里云CDN HTTPS技術(shù)專家金九，分享Tengine的一些HTTPS實(shí)踐經(jīng)驗(yàn)。內(nèi)容主要有四個(gè)方面：HTTPS趨勢、HTTPS基礎(chǔ)、HTTPS實(shí)踐、HTTPS調(diào)試。

一、HTTPS趨勢

這一章節(jié)主要介紹近幾年和未來HTTPS的趨勢，包括兩大瀏覽器chrome和firefox對HTTPS的態(tài)度，以及淘寶天貓和阿里云CDN的HTTPS實(shí)踐情況。

上圖是 chrome 統(tǒng)計(jì)的HTTPS網(wǎng)頁占比的趨勢，2015年的時(shí)候，大多數(shù)國家的HTTPS網(wǎng)頁加載次數(shù)只占了不到 50%，2016年美國這個(gè)占比到了將近60%，去年就已經(jīng)超過 70%，目前已經(jīng)超過 80%。最下面是日本，目前是60%左右，這里面沒有統(tǒng)計(jì)到中國的數(shù)據(jù)，我估計(jì)中國的占比會(huì)更少，空間還有很大，但未來HTTPS趨勢是明顯的。

同樣，Firefox 瀏覽器加載HTTPS網(wǎng)頁的統(tǒng)計(jì)跟 chrome 差不多，全球 HTTPS網(wǎng)頁加載占比在 70% 左右，上升趨勢也很明顯。

更值得關(guān)注的是，Google 在今年年初的時(shí)候在其安全博客上表明，在今年7月份左右發(fā)布的 chrome68 瀏覽器會(huì)將所有HTTP網(wǎng)站標(biāo)記為不安全，現(xiàn)在是5月份底了，離這個(gè)時(shí)間也就一個(gè)多月的時(shí)間了。右邊的截圖可以看出本來是綠色的小鎖變成了不安全，這種網(wǎng)頁在輸入密碼時(shí)就很不安全了。

早期天貓?zhí)詫氈皇窃陉P(guān)鍵的登錄和交易的環(huán)節(jié)上了HTTPS，但隨著互聯(lián)網(wǎng)的發(fā)展，劫持、篡改等等問題也越來越嚴(yán)重，試想在天貓?zhí)詫毶峡吹纳唐穲D片被惡意人替換了或者價(jià)格被篡改了會(huì)怎么樣？這樣用戶、商家和平臺(tái)都受到傷害，只有上了 HTTPS才能從根本上解決這些問題。所以，天貓和淘寶在2015年7月份的時(shí)候已經(jīng)完成了全站HTTPS。

二、HTTPS基礎(chǔ)

本章節(jié)主要介紹HTTPS為什么安全，包括對稱加密、非對稱加密、簽名、證書&證書鏈、SSL是怎么握手的、以及私鑰密鑰在HTTPS中發(fā)揮什么樣的作用、keyless又是解決什么樣的問題等等。

HTTPS的定義

簡單來講，HTTPS就是安全的HTTP，我們知道HTTP是運(yùn)行在TCP層之上的，HTTPS在HTTP層和TCP層之間加了一個(gè)SSL層，SSL向上提供加密和解密的服務(wù)，對HTTP比較透明，這樣也便于服務(wù)器和客戶端的實(shí)現(xiàn)以及升級。

HTTPS為什么安全？

HTTPS安全是由一套安全機(jī)制來保證的，主要包含這4個(gè)特性：機(jī)密性、完整性、真實(shí)性和不可否認(rèn)性。

• 機(jī)密性是指傳輸?shù)臄?shù)據(jù)是采用Session Key（會(huì)話密鑰）加密的，在網(wǎng)絡(luò)上是看不到明文的。
• 完整性是指為了避免網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)被非法篡改，使用MAC算法來保證消息的完整性。
• 真實(shí)性是指通信的對方是可信的，利用了PKI（Public Key Infrastructure 即『公鑰基礎(chǔ)設(shè)施』）來保證公鑰的真實(shí)性。
• 不可否認(rèn)性是這個(gè)消息就是你給我發(fā)的，無法偽裝和否認(rèn)，是因?yàn)槭褂昧撕灻募夹g(shù)來保證的。

對稱加密和非對稱加密

HTTPS有對稱加密和非對稱加密兩種算法，目的都是把明文加密成密文，區(qū)別是密鑰的個(gè)數(shù)不一樣，對稱加密是一把密鑰，這把密鑰可以加密明文，也可以解密加密后的密文，常見的對稱加密算法有AES、DES、RC4，目前最常用的是AES。

非對稱加密是兩把密鑰，分別是公鑰和私鑰，公鑰加密的密文只有相對應(yīng)的私鑰才能解密，私鑰加密的內(nèi)容也只有相對應(yīng)的公鑰才能解密，其中公鑰是公開的，私鑰是自己保存，不能公開，常見的非對稱加密算法有RSA和ECC（橢圓曲線算法）。

SSL結(jié)合了這兩種加密算法的優(yōu)點(diǎn)，通過非對稱加密來協(xié)商對稱加密的密鑰，握手成功之后便可使用對稱加密來做加密通信，對于RSA來說，客戶端是用RSA的公鑰把預(yù)主密鑰加密后傳給服務(wù)器，服務(wù)器再用私鑰來解密，雙方再通過相同的算法來生成會(huì)話密鑰，之后的應(yīng)用層數(shù)據(jù)就可以通過會(huì)話密鑰來加密通信。

簽名

SSL中還有一個(gè)使用非對稱加密的地方就是簽名，簽名的目的是讓對方相信這個(gè)數(shù)據(jù)是我發(fā)送的，而不是其他人發(fā)送的。

密鑰安全強(qiáng)度與性能對比

加密之后的數(shù)據(jù)破解難度就體現(xiàn)在密鑰的長度上，密鑰越長，破解難度也越大，但是運(yùn)算的時(shí)間也越長，性能也就越差。相同安全強(qiáng)度下，對稱密鑰長度在最短，ECC次之，RSA密鑰長度則最長。

目前比較常用的密鑰長度是：對稱密鑰128位、ECC 256位、RSA 2048位。

RSA和ECC在SSL中更多的是用來簽名，通過測試發(fā)現(xiàn)，ECC 的簽名性能比RSA好很多，但是RSA的驗(yàn)簽性能比ECC更好，所以RSA更適合于驗(yàn)證簽名頻繁而簽名頻度較低的場景，ECC更適合于簽名頻繁的場景，在SSL場景中，ECC算法性能更好。

公鑰基礎(chǔ)設(shè)施（PKI）

簡單的說，PKI就是瀏覽器和CA，CA是整個(gè)安全機(jī)制的重要保障，我們平時(shí)用的證書就是由CA機(jī)構(gòu)頒發(fā)，其實(shí)就是用CA的私鑰給用戶的證書簽名，然后在證書的簽名字段中填充這個(gè)簽名值，瀏覽器在驗(yàn)證這個(gè)證書的時(shí)候就是使用CA的公鑰進(jìn)行驗(yàn)簽。

證書

那CA在PKI中又是怎樣發(fā)揮作用的呢，首先，CA的作用就是頒發(fā)證書，頒發(fā)證書其實(shí)就是使用CA的私鑰對證書請求簽名文件進(jìn)行簽名，其次，CA頒發(fā)的證書瀏覽器要信任，瀏覽器只需要用CA的公鑰進(jìn)行驗(yàn)簽成功就表示這個(gè)證書是合法可信的，這就需要瀏覽器內(nèi)置CA的公鑰，也就是內(nèi)置CA的證書。一般來說，操作系統(tǒng)都會(huì)內(nèi)置權(quán)威CA的證書，有的瀏覽器會(huì)使用操作系統(tǒng)內(nèi)置的CA證書列表，有的瀏覽器則自己維護(hù)的CA證書列表，比如Firefox。

CA分為根CA，二級CA，三級CA，三級CA證書由二級CA的私鑰簽名，二級CA證書由根CA的私鑰簽名，根CA是自簽名的，不會(huì)給用戶證書簽名，我們平時(shí)用的證書都是由二級CA或者三級CA簽名的，這樣就形成了一個(gè)證書鏈，瀏覽器在驗(yàn)簽的時(shí)侯一層層往上驗(yàn)證，直到用內(nèi)置的根CA證書的公鑰來驗(yàn)簽成功就可以表示用戶證書是合法的證書。
根證書已經(jīng)內(nèi)置在瀏覽器或者操作系統(tǒng)里了，在SSL握手時(shí)就不需要發(fā)根CA證書了，只需要提供中間二級三級CA證書和用戶證書就可以。

交叉證書

交叉證書的應(yīng)用場景是這樣的：假如現(xiàn)在阿里云成為一個(gè)新的根CA機(jī)構(gòu)，那阿里云簽發(fā)的證書想要瀏覽器信任的話，阿里云的根證書就需要內(nèi)置在各大操作系統(tǒng)和瀏覽器中，這需要較長時(shí)間的部署，那在沒有完全部署完成之前，阿里云簽發(fā)的證書怎么才能讓瀏覽器信任呢，這就需要用到交叉證書了。

上圖中，根證書A是一個(gè)所有瀏覽器都內(nèi)置了的根證書，B是一個(gè)新的根證書，用戶證書D是由根證書 B的二級CA B1來簽發(fā)的，但是根證書B并沒有在瀏覽器中內(nèi)置，所以瀏覽器不會(huì)信任用戶證書D，這是因?yàn)闉g覽器在驗(yàn)簽時(shí)只驗(yàn)證到B1這一層然后找不到根證書B就無法驗(yàn)證下去了。
如果二級CA B1證書是由根證書A來簽名，那這個(gè)問題就解了，所以新的根證書機(jī)構(gòu)B會(huì)將二級CA證書（準(zhǔn)確地講是二級CA的證書簽名請求文件）給老的根證書A來簽名，然后得到一個(gè)新的中間證書就是交叉證書。
瀏覽器在驗(yàn)證的時(shí)侯用了新的信任鏈，這樣就可以解決用戶證書的信任問題。

當(dāng)B的根證書全部部署完成后，再替換成自己的二級CA就可以了。

證書分類

證書分有三類：DV、OV、EV

DV證書只校驗(yàn)域名的所有權(quán)，所以我們在申請DV證書的時(shí)候CA會(huì)提供幾種驗(yàn)證域名所有權(quán)的方法：比如文件校驗(yàn)、DNS校驗(yàn)、郵件校驗(yàn)，DV證書支持單域名、多域名和泛域名，但不支持多個(gè)泛域名，只支持一個(gè)泛域名，一般價(jià)格比較便宜，具體價(jià)格跟域名的數(shù)量有關(guān)，域名越多價(jià)格越高。

OV證書要驗(yàn)證組織機(jī)構(gòu)，在申請證書時(shí)CA會(huì)打電話確認(rèn)這個(gè)域名是否真的屬于相應(yīng)的公司或者機(jī)構(gòu)，OV證書是單域名、多域名、泛域名和多個(gè)泛域名都支持，價(jià)格一般比DV證書要貴。

EV證書的校驗(yàn)就更細(xì)了，比如組織機(jī)構(gòu)的地址之類的，EV證書會(huì)在地址欄上顯示組織機(jī)構(gòu)的名稱，EV證書只支持單域名或者多個(gè)域名，不支持泛域名，而且更貴，所以普通用戶一般不會(huì)用EV證書。

證書吊銷

證書是有生命周期的，如果證書的私鑰泄漏了那這個(gè)證書就得吊銷，一般有兩種吊銷方式：CRL和OCSP。

CRL是CA機(jī)構(gòu)維護(hù)的一個(gè)已經(jīng)被吊銷的證書序列號列表，瀏覽器需要定時(shí)更新這個(gè)列表，瀏覽器在驗(yàn)證證書合法性的時(shí)候也會(huì)在證書吊銷列表中查詢是否已經(jīng)被吊銷，如果被吊銷了那這個(gè)證書也是不可信的。可以看出，這個(gè)列表隨著被吊銷證書的增加而增加，列表會(huì)越來越大，瀏覽器還需要定時(shí)更新，實(shí)時(shí)性也比較差。

所以，后來就有了 OCSP 在線證書狀態(tài)協(xié)議，這個(gè)協(xié)議就是解決了 CRL 列表越來越大和實(shí)時(shí)性差的問題而生的。有了這個(gè)協(xié)議，瀏覽器就可以不用定期更新CRL了，在驗(yàn)證證書的時(shí)候直接去CA服務(wù)器實(shí)時(shí)校驗(yàn)一下證書有沒有被吊銷就可以，是解決了CRL的問題，但是每次都要去CA服務(wù)器上校驗(yàn)也會(huì)很慢，在網(wǎng)絡(luò)環(huán)境較差的時(shí)候或者跨國訪問的時(shí)候，體驗(yàn)就非常差了，OCSP雖然解決了CRL的問題但是性能卻很差。所以后來就有了OCSP stapling。

OCSP stapling主要解決瀏覽器OCSP查詢性能差的問題，本來由瀏覽器去CA的OCSP服務(wù)器查詢證書狀態(tài)的，現(xiàn)在改由域名的服務(wù)器去查詢，將OCSP的結(jié)果告訴瀏覽器即可，一般服務(wù)器的網(wǎng)絡(luò)性能要好于用戶電腦的網(wǎng)絡(luò)，所以O(shè)CSP stapling的性能是最好的。但是并不是所有的服務(wù)器都支持OCSP stapling，所以目前瀏覽器還是比較依賴CRL，證書吊銷的實(shí)時(shí)性要求也不是特別高，所以定期更新問題也不大。

HTTPS工作模式

對于客戶端和服務(wù)器來講，應(yīng)用層協(xié)議還是HTTP，只是加了一個(gè)SSL層來做加密解密的邏輯，對應(yīng)用層來說是透明的，在網(wǎng)絡(luò)上傳輸?shù)亩际羌用艿恼埱蠛图用艿捻憫?yīng)，從而達(dá)到安全傳輸?shù)哪康摹?/p>

這是SSL層在網(wǎng)絡(luò)模型的位置，SSL屬于應(yīng)用層協(xié)議。接管應(yīng)用層的數(shù)據(jù)加解密，并通過網(wǎng)絡(luò)層發(fā)送給對方。

更細(xì)地分，SSL協(xié)議分握手協(xié)議和記錄協(xié)議，握手協(xié)議用來協(xié)商會(huì)話參數(shù)（比如會(huì)話密鑰、應(yīng)用層協(xié)議等等），記錄協(xié)議主要用來傳輸應(yīng)用層數(shù)據(jù)和握手協(xié)議消息數(shù)據(jù)，以及做加解密處理。我們應(yīng)用層的的消息數(shù)據(jù)在SSL記錄協(xié)議會(huì)給分成很多段，然后再對這個(gè)片段進(jìn)行加密，最后在加上記錄頭后就發(fā)送出去。

TLS握手協(xié)議

SSL/TLS 握手協(xié)議又細(xì)分為四個(gè)子協(xié)議，分別是握手協(xié)議、密碼規(guī)格變更協(xié)議、警告協(xié)議和應(yīng)用數(shù)據(jù)協(xié)議。

完整的握手流程

首先是TCP握手，TCP三次完成之后才進(jìn)入SSL握手，SSL握手總是以ClientHello消息開始，就跟TCP握手總是以SYN包開始一樣；

ClientHello主要包含客戶端支持的協(xié)議、密鑰套件、session id、客戶端隨機(jī)數(shù)、sni、應(yīng)用層協(xié)議列表（http/1.1、h2）、簽名算法等等；
服務(wù)器收到ClientHello之后會(huì)從中選取本次通信的協(xié)議版本、密鑰套件、應(yīng)用層協(xié)議、簽名算法，以及服務(wù)器隨機(jī)數(shù)，然后通過ServerHello消息響應(yīng)，如果沒有session復(fù)用，那將服務(wù)器的證書通過Certificate消息響應(yīng)，如果是選用了ECC算法來做密鑰交換的話，那還會(huì)將橢圓曲線參數(shù)以及簽名值通過ServerKeyExchange消息發(fā)送給對方，最后通過ServerHelloDone消息來結(jié)束本次協(xié)商過程；

客戶端收到這些消息之后，會(huì)生成預(yù)主密鑰、主密鑰和會(huì)話密鑰，然后將橢圓曲線參數(shù)通過ClientKeyExchange發(fā)送給服務(wù)器，服務(wù)器拿到客戶端的橢圓曲線參數(shù)也會(huì)生成預(yù)主密鑰，如果是RSA的話ClientKeyExchange用來發(fā)送公鑰加密的預(yù)主密鑰，服務(wù)器用私鑰來解密一下就可以得到預(yù)主密鑰，再由預(yù)主密鑰生成主密鑰和會(huì)話密鑰。最后雙方都以ChangeCipherSpce和Finished消息來告知對方，自己已經(jīng)準(zhǔn)備好了可以進(jìn)行加密通信了，然后握手完成。

可以看出，完整的SSL握手需要2個(gè)RTT，而且每次握手都用到了非對稱加密算法簽名或者解密的操作，比較耗CPU，所以后來就有了session復(fù)用的優(yōu)化手段，后面會(huì)做介紹。

SSL的握手消息雖然比較多，但很多消息都是放在一個(gè)TCP包中發(fā)送的，從抓包可以看出完整的SSL握手需要2個(gè)RTT。

剛才通過完整的SSL握手可以看出幾個(gè)缺點(diǎn)：
1、2個(gè)RTT，首包時(shí)間較長
2、每次都要做非對稱加密，比較耗CPU，影響性能
3、每次都要傳證書，證書一般都比較大，浪費(fèi)帶寬

SSL握手的目的是協(xié)商會(huì)話密鑰以及參數(shù)，如果能把這些會(huì)話參數(shù)緩存那就可以沒有必要每次都傳證書和做非對稱加密計(jì)算，這樣就可以提高握手性能，而且可以將RTT減到1個(gè)，提高用戶體驗(yàn)。

所以就有了session id的復(fù)用方式，每次完整握手之后都將協(xié)商好的會(huì)話參數(shù)緩存在服務(wù)器中，客戶端下次握手時(shí)會(huì)將上次握手的session id帶上，服務(wù)器通過session id查詢是否有會(huì)話緩存，有的話就直接復(fù)用，沒有的話就重新走完整握手流程。但是session id這種方式也有缺點(diǎn)，比較難支持分布式緩存以及耗費(fèi)服務(wù)器的內(nèi)存。

而session ticket 方案，其原理可以理解為跟 http cookie 一樣，服務(wù)器將協(xié)商好的會(huì)話參數(shù)加密成 session ticket，然后發(fā)送給客戶端，客戶端下次握手時(shí)會(huì)將這個(gè)session ticket帶上，服務(wù)器解密成功就復(fù)用上次的會(huì)話參數(shù)，否則就重新走完整握手流程。可以看出session ticket這種方式不需要服務(wù)器緩存什么，支持分布式環(huán)境，有很大的優(yōu)勢。這種方式有一個(gè)缺點(diǎn)是并不是所有客戶端都支持，支持率比較低，但隨著客戶端版本的更新迭代，以后各種客戶端會(huì)都支持。因?yàn)閟ession id客戶端支持率比較高，所以目前這兩種方式都在使用。

這是 session ticket 的復(fù)用，跟 session id 的區(qū)別是 client hello 會(huì)帶上 Session ticket ，將近200個(gè)字節(jié)的加密數(shù)據(jù)，服務(wù)器會(huì)用session ticket 密鑰來解密，解密成功則直接復(fù)用，也簡化了握手流程，提升效率和性能。

這是我們上了分布式 Session id 復(fù)用的效果，session id復(fù)用的比例在沒有開啟分布式緩存時(shí)只占了3%左右，復(fù)用率很低，上了分布式session緩存之后，這個(gè)比例提升到20%多。握手時(shí)間也從75ms左右降低到65ms左右，性能提升效果還是很明顯的。

SSL/TLS握手時(shí)的私鑰用途（RSA、ECDHE）

我們知道私鑰是整個(gè)SSL中最重要的東西，那私鑰在SSL握手里面又是怎么使用的呢？兩種使用方式分別是：使用RSA來做密鑰交換和使用ECDHE來做密鑰交換。對于RSA來說，客戶端生成預(yù)主密鑰，然后用公鑰加密再發(fā)給服務(wù)器，服務(wù)器用私鑰來解密得到預(yù)主密鑰，然后由預(yù)主密鑰生成主密鑰，再由主密鑰生會(huì)話密鑰，最后用會(huì)話密鑰來通信。

對于ECDHE來說，客戶端和服務(wù)器雙方是交換橢圓曲線參數(shù)，私鑰只是用來簽名，這是為了保證這個(gè)消息是持有私鑰的人給我發(fā)的，而不是冒充的。雙方交換完參數(shù)之后生成預(yù)主密鑰，再生成主密鑰和會(huì)話密鑰。這就跟剛才RSA后面的流程一樣了。

可以看出RSA和橢圓曲線密鑰交換算法的私鑰用途是不一樣的，RSA密鑰交換時(shí)是用來做加解密的，橢圓曲線密鑰交換時(shí)是用來做簽名的。

SSL/TLS中的密鑰

預(yù)主密鑰、主密鑰和會(huì)話密鑰，這幾個(gè)密鑰都是有聯(lián)系的。

對于RSA來說，預(yù)主密鑰是客戶端生成，加密之后發(fā)給服務(wù)器，服務(wù)器用私鑰來解密。對于ECDHE來說，預(yù)主密鑰是雙方通過橢圓曲線算法來生成。

主密鑰是由預(yù)主密鑰、客戶端隨機(jī)數(shù)和服務(wù)器隨機(jī)數(shù)通過PRF函數(shù)來生成；會(huì)話密鑰是由主密鑰、客戶端隨機(jī)數(shù)和服務(wù)器隨機(jī)數(shù)通過PRF函數(shù)來生成，會(huì)話密鑰里面包含對稱加密密鑰、消息認(rèn)證和CBC模式的初始化向量，但對于非CBC模式的加密算法來說，就沒有用到這個(gè)初始化向量。

session 緩存和session ticket里面保存的是主密鑰，而不是會(huì)話密鑰，這是為了保證每次會(huì)話都是獨(dú)立的，這樣才安全，即使一個(gè)主密鑰泄漏了也不影響其他會(huì)話。

Keyless

剛才提到RSA和ECDHE的私鑰用途，對于服務(wù)器來說，密鑰交換算法是RSA時(shí)，私鑰是用來做解密的，ECDHE時(shí)，私鑰是用來簽名的。

Keyless就是將私鑰參與運(yùn)算的部分分離遠(yuǎn)程服務(wù)器，這樣可以解決兩個(gè)問題：
1，公私鑰分離，用戶不需要將私鑰給第三方，減少私鑰泄露的風(fēng)險(xiǎn)。
2，將非對稱加密運(yùn)算這種cpu密集型運(yùn)算剝離到keyserver，可以在keyserver中安裝ssl加速卡做硬件加速，提高性能。

HTTP/2

HTTP/2主要有這幾個(gè)特性：
一、二進(jìn)制協(xié)議，可以做更多的優(yōu)化；
二、多路復(fù)用，一定程度上解決了隊(duì)頭阻塞的問題，提高并發(fā)和總的加載時(shí)間
三、頭部壓縮，很多請求頭或者響應(yīng)頭都沒有必要重復(fù)傳輸浪費(fèi)帶寬，比如user-agent、cookie還有其他沒有必要每次都傳的頭部在http2中都做了優(yōu)化
四、安全，雖然RFC規(guī)定HTTP/2可以運(yùn)行在明文之上，但目前所有瀏覽器都只支持https之上的http/2，所以是安全的。

開啟HTTP/2會(huì)有這幾個(gè)收益：

一、加載時(shí)間的提升，我們做了這么一個(gè)測試，一張大圖片分割成幾百個(gè)小圖片，然后用http/1.1和http/2打開，http/1.1加載完所有小圖片用了五六秒，但http/2加載完所有小圖片只需要不到1s的時(shí)間，有5倍左右的提升，效果還是很明顯的，具體提升百分之多少這得具體看具體的業(yè)務(wù)類型。

二、頭部壓縮有95%左右的提升，http/1.1的平均響應(yīng)頭大小有500個(gè)字節(jié)左右，而http/2的平均響應(yīng)頭大小只有20多個(gè)字節(jié)，提升非常大，所以http/2非常適合小圖片小文件的業(yè)務(wù)類型，因?yàn)樾∥募膆ttp頭部比重較大，而http/2對頭部的壓縮做了非常好的優(yōu)化。

三、服務(wù)器QPS的性能有60%多的提升，這是因?yàn)閔ttp/2的連接復(fù)用和多路復(fù)用機(jī)制，可以處理更多的并發(fā)請求。

三、HTTPS實(shí)踐

本章節(jié)會(huì)重點(diǎn)給大家講講 Tengine 如何配置 https、HTTP/2、TLSv1.3，以及如何實(shí)現(xiàn)動(dòng)態(tài)證書。

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參數(shù)就可以了。

server {listen 443 ssl http2;http2 on;server_name a.com;#…… } server {listen 443 ssl;http2 off;server_name b.com;#…… }

但是有一個(gè)場景需要注意，因?yàn)橛行┯蛎⒉幌腴_啟http2，比如上面這個(gè)配置的http://b.com并不想開http2，但是因?yàn)?span id="ze8trgl8bvbq" class="invisible" style="font-size:0px;line-height:0;font-family:a;background-color:transparent;">http://a.com開啟了http2，所以http://b.com也被自動(dòng)開啟了，這是因?yàn)閔ttp2這個(gè)參數(shù)作用在ip和端口上，在ssl握手時(shí)用了http://a.com的配置參數(shù)，所以tengine針對這種情況做了一個(gè)域名級別的開關(guān)來做控制。

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 實(shí)現(xiàn)與配置動(dòng)態(tài)證書

動(dòng)態(tài)證書主要解決的問題是接入域名太多，server塊過多導(dǎo)致tengine reload慢的問題，lua-nginx模塊提供了一個(gè)證書的lua階段，可以在這個(gè)階段來做證書的熱加載，不需要reload tengine，這樣可以提高效率和性能。

配置也比較簡單，在ssl_cert.lua里面做證書的管理，在ssl握手時(shí)拿到sni，去拿這個(gè)域名的證書和私鑰，再調(diào)用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:
調(diào)用 lua ffi 接口設(shè)置證書和私鑰

四、HTTPS調(diào)試

我們知道HTTP是明文傳輸，調(diào)試就很簡單，抓包就可以看得清清楚楚，但HTTPS是加密的，抓包看到的是密文，這一節(jié)我告訴大家怎么去解密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

方法二：
強(qiáng)制使用RSA密鑰交換算法，Wireshark配置私鑰。

抓包解密-wireshark設(shè)置

常用命令及參數(shù)

curl

寫在最后

證書的購買和申請是非常復(fù)雜耗時(shí)的，為了縮短開通周期，為開發(fā)者提供最大化便利，簡化HTTPS加速設(shè)置環(huán)節(jié)，目前阿里云CDN已經(jīng)支持控制臺(tái)可實(shí)現(xiàn)一鍵開通HTTPS，后臺(tái)將完成代理免費(fèi)證書購買、證書節(jié)點(diǎn)部署以及證書到期之前自動(dòng)續(xù)簽，幫助開發(fā)者更便捷的完成全站HTTPS訪問加速。

了解阿里云CDN 快速開啟HTTPS加速

本文作者：樰籬

原文鏈接

總結(jié)

以上是生活随笔為你收集整理的Tengine HTTPS原理解析、实践与调试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。