黑閾服務(wù)器，實(shí)際上有兩臺(tái)。國(guó)內(nèi)的 AWS，使用 Amazon Linux 2，基于 CentOS 7；另外一臺(tái)在國(guó)外，直接就是 CentOS 7。
2017 年 4 月發(fā)布的 Nginx 1.13.0 起支持 TLSv1.3，但是，當(dāng)然需要底層 OpenSSL 支持。后期，也支持谷歌的 BoringSSL。
要支持 TLSv1.3 其實(shí)比較簡(jiǎn)單，只需要升級(jí) OpenSSL 即可。在 CentOS 8 中，OpenSSL 已經(jīng)升級(jí)到 1.1.1。如果直接使用 rpmbuild 來構(gòu)建，由于 ABI 兼容性問題，無法直接使用。但是非常友好的是，nginx 可以直接使用參數(shù) --with-openssl 來指定 openssl 路徑。于是，修改 nginx.spec，加上 --with-openssl 參數(shù)，打包，安裝，開啟支持，終于 ssllabs.com 顯示支持 TLSv1.3 了。
但是，問題來了，沒有動(dòng)態(tài)為 Android 設(shè)備優(yōu)化 cipher 啊。比如在沒有 AES-NI 支持的情況下，ChaCha20 會(huì)友好一些；但是如果有 AES-NI 支持，直接使用 AES-128-GCM 就會(huì)快很多。這點(diǎn)，可以找個(gè) Android 低端測(cè)試分別訪問 https://www.google.cn 然后檢查 TLS 屬性即可檢查。
一翻搜索之后，發(fā)現(xiàn) BorringSSL 在 2014 年 6 月起，引入 Equal preference cipher groups 概念。之前的話，Cipher 優(yōu)先級(jí)只能是一個(gè)，現(xiàn)在可以同時(shí)有多個(gè)，就能達(dá)到如果設(shè)備支持 AES-NI，則使用 AES-GCM，如果不支持，使用 ChaCha20。
好的，開干，使用 BoringSSL 編譯。咦，怎么無法鏈接？一看，沒開 -fPIC 選項(xiàng)呢。（中間當(dāng)然還有略微復(fù)雜的，如何跳過 tests 編譯。）好，開干，終于一切都支持了。
咦，怎么不支持 OCSP stapling？呃，BoringSSL 本身就不支持這個(gè)東西。那，還是切回 OpenSSL 好了。
在 OpenSSL 下，怎么才能達(dá)到對(duì)移動(dòng)設(shè)備不支持 AES-NI 的情況下，直接使用 ChaCha20，而如果支持，則使用 AES-GCM 呢？一翻搜索，OpenSSL Issue 541 提到這個(gè)，而在 Issue 4436，則加進(jìn)了這個(gè)支持，使用新的屬性 SSL_OP_PRIORITIZE_CHACHA。但是，Nginx 并不使用這個(gè)值。所以，只需要改動(dòng) Nginx，設(shè)置這個(gè)值即可。
又是一翻編譯，終于達(dá)成目標(biāo)。
咦，怎么 BoringSSL 下，瀏覽器使用 AES-128-GCM，而 OpenSSL 下，瀏覽器使用 AES-256-GCM 呢？又是一翻搜索，發(fā)現(xiàn)無法指定 TLSv1.3 的 Cipher 順棄，而這個(gè)，呃，在 OpenSSL 中是寫死的。所以，繼續(xù)改吧。
最終，子非的改動(dòng)清單如下：
openssl 中，在
include/openssl/ssl.h中，把TLS_DEFAULT_CIPHERSUITES定義中的TLS_AES_256_GCM_SHA384與TLS_AES_128_GCM_SHA256順序?qū)φ{(diào)。nginx.spec中，去掉對(duì) openssl 的依賴（畢竟真的不再依賴系統(tǒng) OpenSSL），同時(shí)，編譯參數(shù)加入--with-openssl路徑，以及設(shè)置SSL_OP_PRIORITIZE_CHACHA屬性（位于src/event/ngx_event_openssl.c中）。
歡迎使用低端設(shè)備上的瀏覽器，高端設(shè)備上的瀏覽器，以及電腦版瀏覽器，當(dāng)然還有 ssllabs.com 測(cè)試黑閾服務(wù)器 jianyv.com。
