【專家坐堂】全站 HTTPS——如何規(guī)劃、部署、優(yōu)化？（獲獎名單已公布）

InfoHunter

forgaoqiang 發(fā)表于 2016-12-05 14:14
回復(fù) 27# Godbach
好吧 ( ⊙ o ⊙ )

移动端不提示证书非法也是一个问题

forgaoqiang

InfoHunter 發(fā)表于 2016-12-15 22:03
移動端不提示證書非法也是&# ...

基本上都會提示吧

至少很多應(yīng)用會提醒 比如UC、淘寶、微信等 用戶很少看明白怎么回事

Fl_wolf

回復(fù) 30# Godbach

那些開發(fā)的事情啦

撒加

1.    網(wǎng)站改造 HTTPS 過程中跳過的坑或者要注意的問題
1.1 近期我們公司也在逐步來上https，雖然我們在上之前做了一定的準備工作，但是上之后也遇上一些問題，我們指定的步驟是先上HTTPS，再上HTTP/2，測試我們的官網(wǎng)后，就像樓上說的那樣，出現(xiàn)HTTP的資源無法訪問，必須讓頁面加載的第三方資源也支持HTTPS。出現(xiàn)這個問題后，我找研發(fā)、測試、前端、APP各部門負責人開會討論各自團隊在上線HTTPS后的支持以及問題應(yīng)對，例如將https:\\ http:\\ 都只保留\\來做自適應(yīng)。
1.2 在部署HTTPS的時候，還是建議服務(wù)器的CPU使用E5 V3 V4的，主要原因是這兩個系列的CPU支持AESNI，當然能夠使用CPU AESNI引擎的openssl版本是1.0.2以上版本，1.0.1是不支持的，所以不管是Nginx還是Haproxy來做都需要重新編譯（可以順道帶上chacha20的patch）。編譯Nginx和Haproxy時建議使用cflags設(shè)置-mtune=native（我是這么用的）
1.3 編譯openssl的話，默認最好帶上

no-ssl3 no-ssl3-method編譯，從OPENSSL就關(guān)閉SSLV3的支持，免得一些SA大意在Nginx和haproxy中忘記關(guān)閉SSL V3
1.4 AES-NI默認內(nèi)核是沒加載的，所以需要手動加載AESNI模塊，modprobe aesni-intel,當然可以在內(nèi)核里把這個功能默認就編譯到kernel中，而不是以模塊形式啟用，當然openssl engine查看的時候是看不到AESNI引擎的。
1.5 SNI問題，openssl 1.0.2默認就支持SNI了，openssl 1.0.1默認不開啟，在Nginx和Haproxy配置的時候必須注意OPENSSL版本，如果不得不用1.0.1的openssl在編譯的時候需要加上enable-tlsext，另外判斷nginx是否支持了SNI，可以用nginx -V,如果有TLS SNI support enabled ，那SNI就是開啟的

1.6 Nginx使用SNI問題不大，Haproxy還是有點差別的，比如普通的HTTPS和HTTP/2，用到的參數(shù)貌似還不一樣，比如req.ssl_sni和ssl_fc_sni（還請Godbach簡單聊聊啊）
2.    影響甚至導(dǎo)致無法全站 HTTPS 的痛點或者障礙
我認為還是影響HTTPS部署的因素有如下幾個：
從APP來說，比如一些算法JDK 1.8支持的JDK 1.7就不支持，那高效的算法要使用，估計還得升級JDK，這個升級回來帶來不確定性
從手機端系統(tǒng)來說，安卓不同的版本支持的算法也不一樣，做兼容性測試，工作量也不小
從PC端來說，瀏覽器的兼容性、證書的類型啥的也都多少影響一些
代碼來說，如果調(diào)用第三方的URL，第三方URL如果不是HTTPS還真是個頭疼的事情

3.    證書申請以及私鑰管理上的一些注意事項
用商業(yè)的證書我覺得問題不大
免費證書我覺得還是做好自動更新相關(guān)的東東吧

4.    部署 HTTPS 后，優(yōu)化手段、遇到的問題以及解決方法
正常的業(yè)務(wù)部署HTTPS后，我認為還是算法的優(yōu)化上，需要多做測試，我們目前正在進行中
我們業(yè)務(wù)里有Varnish,直接Varnish部署HTTPS感覺還是不靠譜，所以打算用其提供的hitch來做ssl proxy，將解密后的數(shù)據(jù)發(fā)送到Varnish

5.    負載均衡下或者 CDN 中部署 HTTPS 的一些經(jīng)驗
負載均衡下，怎么說呢，要是硬件負載均衡本身就帶了SSL加速卡，沒的說
軟件負載均衡，除了上面說的SNI，還有AESNI外，性能還有更高要求那就得上專門的硬件加速卡了。
為了使用HTTPS，我們自己對Haproxy和OpenResty所用的系統(tǒng)又重新做了定制化，主要就是AESNI的支持，讓其變成默認支持，而不是模塊化支持

Godbach

回復(fù) 54# 撒加

灰常給力。贊一個！

撒加

回復(fù) 55# Godbach

目前的研究成果也就這些了，后續(xù)再補充HTTP/2的，哈哈

Godbach

回復(fù) 56# 撒加
分析的內(nèi)容很豐富啊。

Godbach

回復(fù) 56# 撒加

1.6 Nginx使用SNI問題不大，Haproxy還是有點差別的，比如普通的HTTPS和HTTP/2，用到的參數(shù)貌似還不一樣，比如req.ssl_sni和ssl_fc_sni（還請Godbach簡單聊聊�。�

這個地方你的問題再具體一點？ 你是說 HAProxy 對 SNI 的支持問題嗎？

撒加

回復(fù) 58# Godbach

在查閱相關(guān)資料的時候，發(fā)現(xiàn)個現(xiàn)象就是如果僅僅是Haproxy啟用HTTPS，要使用SNI的話，用的指令是req.ssl_sni，如果是啟用HTTPS且私用ALPN支持HTTP/2，看到使用的指令是ssl_fc_sni

Godbach

回復(fù) 59# 撒加

ssl_fc_sni 和 req.ssl_sni （HAProxy v1.7 不推薦使用 req_ssl_sni）最根本的區(qū)別：

• ssl_fc_sni 是在 SSL offload 開啟的情況下匹配 SNI 的。也就是，你配置 bind 的時候，還需要明確開啟了 SSL，配置了證書和私鑰。這個情況下，OpenSSL 庫本身就幫你獲取了這些信息的。
• req.ssl_sni 是在沒有 SSL offload 時使用的。也就是你只配置了 TCP 模式，并且沒有配置 SSL。其實就是一個 DPI（深度報文檢測） 的過程，從 client 端的 TCP 請求數(shù)據(jù)中識別出來是 SSL 的傳輸，然后再此基礎(chǔ)上提取 SNI。
  

這個應(yīng)該是在 HAProxy 引入 SSL 之后，就是這么個區(qū)別的。當時我搞 SSL 的時候，特意看了一下這個區(qū)別。