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

haishui

現(xiàn)在IOS 都要求了。

c3po

Godbach 發(fā)表于 2016-11-28 18:49
回復(fù) 2# GB_juno

是的。我之前了解的數(shù)據(jù)，也差不多是 1/10 的樣子。

請(qǐng)教大佬，是降了十分之一還是降到十分之一？
我用Nginx也在愁這個(gè)事情，還沒(méi)機(jī)會(huì)大規(guī)模測(cè)試驗(yàn)證。

Godbach

c3po 發(fā)表于 2016-12-07 09:13
請(qǐng)教大佬，是降了十分之一還是降到十分之一？
我用Nginx也在愁這個(gè)事情，還沒(méi)機(jī)會(huì)大規(guī)模測(cè)試驗(yàn)證。

加密這么耗性能的，如果只損失十分之一的性能，那么又安全又好用，誰(shuí)還不用呢。

cjfeii

我們的https改造，就是在原來(lái)的http服務(wù)器上加一個(gè)https的代理  ~~

lnwu

弱弱的問(wèn)下：
前端一個(gè)公網(wǎng)IP，安裝haproxy，haproxy使用的http模式，配置多個(gè)域名分別指向后端不同的服務(wù)器。
啟用HTTPS的話，證書(shū)放在前端服務(wù)器，從haproxy到后端只能走h(yuǎn)ttp，不能走HTTPS對(duì)嗎？
這種情況下怎么實(shí)現(xiàn)從haproxy到后端服務(wù)器這最后一公里實(shí)現(xiàn)全加密走HTTPS？

感覺(jué)要實(shí)現(xiàn)從haproxy到后端服務(wù)器走HTTPS的話就得使用tcp模式，但是tcp模式又不能判斷域名從而
轉(zhuǎn)發(fā)到不同的后端服務(wù)器。

想不明白這個(gè)改如何解決。
看到網(wǎng)上說(shuō)有的網(wǎng)站有兩級(jí)反向代理，Nginx+haproxy+server的，那種環(huán)境多域名一個(gè)的話怎樣實(shí)現(xiàn)全
走h(yuǎn)ttps的呢？

Godbach

回復(fù) 35# lnwu

從haproxy到后端只能走h(yuǎn)ttp，不能走HTTPS對(duì)嗎？

不是的。作為一個(gè)七層 proxy，client->proxy 以及 proxy->server 是可以各自配置各自的 SSL 邏輯。HAProxy 是完全支持的。

Godbach

回復(fù) 35# lnwu

感覺(jué)要實(shí)現(xiàn)從haproxy到后端服務(wù)器走HTTPS的話就得使用tcp模式，但是tcp模式又不能判斷域名從而
轉(zhuǎn)發(fā)到不同的后端服務(wù)器。

HAProxy 到后端是可以配置為 http 模式，并且把 SSL 啟用起來(lái)。其實(shí) HAProxy 作為 client，也就是要加載好 server 端證書(shū)的 CA 就行了，這樣可以驗(yàn)證 server 的證書(shū)。

c3po

Godbach 發(fā)表于 2016-12-07 09:54
加密這么耗性能的，如果只損失十分之一的性能，那么又安全又好用，誰(shuí)還不用呢。

我心里也是這么猜的，被大佬挑明了好桑心啊。魚(yú)和熊掌我都好咋辦

c3po

回復(fù) 35# lnwu

我們?cè)趯?shí)踐中一般不采用軟式多級(jí)反代，只要條件允許，建議客戶在公網(wǎng)入口部署有HA/LB能力的硬件，在四層向后面兩個(gè)nginx分發(fā)，各個(gè)Nginx上再跑七層向后端分發(fā)，Nginx上面可以做很多邏輯控制。當(dāng)然以上前提都是木有跑https，這個(gè)時(shí)候Linux/Freebsd下的Nginx接入能力超級(jí)強(qiáng)大足夠?yàn)楸姸嗟暮蠖藨?yīng)用服務(wù)器做代理。
現(xiàn)在大佬說(shuō)了上https以后縮水90%的接入性能，就不知道咋辦鳥(niǎo)。
以上是我這的經(jīng)驗(yàn)希望對(duì)你有點(diǎn)用

ccjsj1

1.網(wǎng)站改造 HTTPS 過(guò)程中跳過(guò)的坑或者要注意的問(wèn)題
目前的http還沒(méi)改造成https，公司有這個(gè)計(jì)劃了，真的改造起來(lái)不知道會(huì)遇到什末坑呢。

2.影響甚至導(dǎo)致無(wú)法全站 HTTPS 的痛點(diǎn)或者障礙
https是無(wú)法被緩存的覺(jué)得是個(gè)問(wèn)題，干的活多了cpu消耗增大了。

3.證書(shū)申請(qǐng)以及私鑰管理上的一些注意事項(xiàng)
證書(shū)的私鑰文件要保管好，只對(duì)涉及的運(yùn)維和開(kāi)發(fā)人員放開(kāi)。傳輸過(guò)程中要文件和密碼分開(kāi)途徑傳輸，避免泄漏。

4.部署 HTTPS 后，優(yōu)化手段、遇到的問(wèn)題以及解決方法
使用的證書(shū)是等級(jí)較低的，證書(shū)鏈不完整的話，會(huì)被當(dāng)非法站點(diǎn)，需要重新簽。

5.負(fù)載均衡下或者 CDN 中部署 HTTPS 的一些經(jīng)驗(yàn)
使用單獨(dú)的證書(shū)和獨(dú)立域名，避免同域下的瀏覽器加載并發(fā)限制等問(wèn)題。