在先前的文章中，我們通過一些列分析，在一個LNMP架構(gòu)下的站群系統(tǒng)中挖掘出了基于host字段進(jìn)行注入的SQL注入漏洞。在解決HOST繞過問題時，我們給出了三種解決方案。冒號分割、雙寫host字段、利用SNI機(jī)制。

經(jīng)過測試，冒號分割是可行的，雙寫host字段被高版本的nginx返回了400，無法使用。最后一個則是SNI機(jī)制。

SNI（Server Name Indication）定義在RFC 4366，是一項用于改善SSL/TLS的技術(shù)，在SSLv3/TLSv1中被啟用。它允許客戶端在發(fā)起SSL握手請求時（具體說來，是客戶端發(fā)出SSL請求中的ClientHello階段），就提交請求的Host信息，使得服務(wù)器能夠切換到正確的域并返回相應(yīng)的證書。

我們知道證書機(jī)制是為了加密通信流量，防止第三方竊聽而存在的。而同一臺主機(jī)配置多個網(wǎng)站時，會用到虛擬主機(jī)技術(shù)，每一個網(wǎng)站對應(yīng)的證書也是不一樣的。那么在用戶與服務(wù)器第一次建立連接時，將使用哪一個證書進(jìn)行通信呢？最初就是用的默認(rèn)證書，而之后為了適應(yīng)這樣的需求，RFC推出了SNI機(jī)制，在TLS協(xié)議初期，即客戶端發(fā)送自己的client hello報文時，就將host字段加入進(jìn)去，以供服務(wù)器區(qū)分目的網(wǎng)站。選到對應(yīng)的證書。

隨后，證書就為客戶端和服務(wù)器加密了通信內(nèi)容，也就是說。后續(xù)的通信一旦發(fā)現(xiàn)是用某一個證書解密的。不需要再做判斷，可以直接將數(shù)據(jù)報文交給對應(yīng)的網(wǎng)站即可。也就是在建立了穩(wěn)定的https通信之后，服務(wù)器中間件將不需要對host頭進(jìn)行解析，直接通過證書實現(xiàn)定向解析。

那么，我們會產(chǎn)生一系列思考。

第一：SNI機(jī)制會一直觸發(fā)嗎？ 單https虛擬主機(jī) —>多https虛擬主機(jī)

第二：控制證書為變量，測試證書對于流量解析的影響？—>證明是用證書私鑰做流量區(qū)分的

第三：控制端口號為變量，測試端口號對于流量解析的影響？

1.前置環(huán)境搭建

既然如此我們就需要準(zhǔn)備兩套完整的nginx解析https虛擬主機(jī)進(jìn)行測試。以及個服務(wù)器證書與私鑰。

#1.雙證書準(zhǔn)備
#1.創(chuàng)建證書目錄
[root@blackstone nginx]# mkdir certificate
[root@blackstone nginx]# cd certificate/#2.生成私鑰 - 要求你輸入這個key文件的密碼。給nginx使用。每次reload nginx配置時候都要驗證這個PAM密碼。
openssl genrsa -des3 -out ssl.key 4096
openssl genrsa -des3 -out sslb.key 4096
#3.生成CA證書文件 -- 此處為了區(qū)分證書，我們只好開兩份CA證書相當(dāng)于兩個機(jī)構(gòu)的認(rèn)證
openssl req -new -key ssl.key -out aaa.csr
openssl req -new -key sslb.key -out bbb.csr#4.利用CA證書簽名生成服務(wù)器身份證書 - 證書簽發(fā)有效期365天
openssl x509 -req -days 365 -in aaa.csr -signkey ssl.key -out aaa.crt
openssl x509 -req -days 365 -in bbb.csr -signkey sslb.key -out bbb.crt
#5.檢查生成情況 - 此時包含我們自己的私鑰，自己的證書.crt文件，以及csrCA證書
[root@blackstone certificate]# ll
total 32
-rw-r--r-- 1 root root 1895 Feb 10 23:34 aaa.crt
-rw-r--r-- 1 root root 1724 Feb 10 23:32 aaa.csr
-rw-r--r-- 1 root root 1907 Feb 11 00:52 bbb.crt
-rw-r--r-- 1 root root 1728 Feb 11 00:51 bbb.csr
-rw-r--r-- 1 root root 3311 Feb 11 00:50 sslb.key
-rw-r--r-- 1 root root 3311 Jan 11 21:24 ssl.key

網(wǎng)頁部署

[root@blackstone www]# mkdir -p /var/www/aaa
[root@blackstone www]# mkdir -p /var/www/bbb
[root@blackstone www]# echo 'this is aaa.com' > /var/www/aaa/index.html
[root@blackstone www]# echo 'this is bbb.com' > /var/www/bbb/index.html

記得修改本機(jī)的host文件：C:\Windows\System32\drivers\etc

192.168.2.169 www.bbb.com 
192.168.2.169 www.aaa.com

2.測試SNI生效條件(時間)

1.單個https虛擬主機(jī)

 server {listen       443 ssl;server_name  www.aaa.com;ssl_certificate      /usr/local/nginx/certificate/aaa.crt;ssl_certificate_key  /usr/local/nginx/certificate/ssl.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/aaa;index  index.html index.htm;}}

重啟nginx，使用瀏覽器訪問，進(jìn)行抓包分析。

#后面的所有重啟都建議直接把nginx關(guān)閉，徹底重啟
[root@blackstone www]# /usr/local/nginx/sbin/nginx -s quit
Enter PEM pass phrase:
[root@blackstone www]# /usr/local/nginx/sbin/nginx
Enter PEM pass phrase:

可以看到，確實在client hello報文內(nèi)部，有這個主機(jī)名被發(fā)送給服務(wù)器了。

故，發(fā)送主機(jī)名是高版本瀏覽器的自發(fā)行為，不需要任何激發(fā)條件。瀏覽器會主動發(fā)送server name 以支持SNI機(jī)制。即SNI機(jī)制無需配置，只要服務(wù)器支持，就可以使用。

3. 證書對SNI的影響

3.1 雙方使用同一個證書：

    server {listen       443 ssl;server_name  www.aaa.com;ssl_certificate      /usr/local/nginx/certificate/aaa.crt;ssl_certificate_key  /usr/local/nginx/certificate/ssl.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/aaa;index  index.html index.htm;}}server {listen       443 ssl;server_name  www.bbb.com;ssl_certificate      /usr/local/nginx/certificate/aaa.crt;ssl_certificate_key  /usr/local/nginx/certificate/ssl.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/bbb;index  index.html index.htm;}}

測試訪問情況：

可以實現(xiàn)分流。

3.2 雙方使用不同的證書與私鑰

這時，我們嘗試進(jìn)行證書與私鑰的區(qū)分配置：

server {listen       443 ssl;server_name  www.aaa.com;ssl_certificate      /usr/local/nginx/certificate/aaa.crt;ssl_certificate_key  /usr/local/nginx/certificate/ssl.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/aaa;index  index.html index.htm;}}server {listen       443 ssl;server_name  www.bbb.com;ssl_certificate      /usr/local/nginx/certificate/bbb.crt;ssl_certificate_key  /usr/local/nginx/certificate/sslb.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/bbb;index  index.html index.htm;}}

再次測試訪問效果：

[root@blackstone certificate]# /usr/local/nginx/sbin/nginx -s reload
Enter PEM pass phrase:
Enter PEM pass phrase:

各自可以收到各自的證書，建立各自的通信。

4. 端口號區(qū)分測試

4.1 端口號區(qū)分，證書區(qū)分：

server {listen       8443 ssl;server_name  www.bbb.com;ssl_certificate      /usr/local/nginx/certificate/bbb.crt;ssl_certificate_key  /usr/local/nginx/certificate/sslb.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/bbb;index  index.html index.htm;}}server {listen       8444 ssl;server_name  www.aaa.com;ssl_certificate      /usr/local/nginx/certificate/aaa.crt;ssl_certificate_key  /usr/local/nginx/certificate/ssl.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/aaa;index  index.html index.htm;}

測試效果：

[root@blackstone certificate]# vim ../conf/nginx.conf
[root@blackstone certificate]# /usr/local/nginx/sbin/nginx -s reload
Enter PEM pass phrase:
Enter PEM pass phrase:

可以看到，證書已經(jīng)分別發(fā)送給了兩個虛擬主機(jī)客戶端。實現(xiàn)流量區(qū)分

4.2 端口號區(qū)分,證書不區(qū)分：

server {listen       8443 ssl;server_name  www.bbb.com;ssl_certificate      /usr/local/nginx/certificate/aaa.crt;ssl_certificate_key  /usr/local/nginx/certificate/ssl.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/bbb;index  index.html index.htm;}}server {listen       8444 ssl;server_name  www.aaa.com;ssl_certificate      /usr/local/nginx/certificate/aaa.crt;ssl_certificate_key  /usr/local/nginx/certificate/ssl.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/aaa;index  index.html index.htm;}

中途效果不明顯大家可以重啟nginx服務(wù)，因為服務(wù)一直開著可能會有緩存文件。

[root@blackstone nginx]# /usr/local/nginx/sbin/nginx -s quit
Enter PEM pass phrase:
Enter PEM pass phrase:
[root@blackstone nginx]# /usr/local/nginx/sbin/nginx
Enter PEM pass phrase:
Enter PEM pass phrase:

再次測試查看效果：

服務(wù)端兩次傳遞同一個證書，實現(xiàn)通信。實現(xiàn)完整的虛擬主機(jī)分流訪問。

5.總結(jié)SNI運行機(jī)制

通過以上種種測試，我們發(fā)現(xiàn)，無論使相同端口號，證書不同。達(dá)到證書區(qū)分傳遞的效果。還是證書不同，端口號也不同實現(xiàn)測試環(huán)境下的虛擬主機(jī)配置。SNI始終都可以準(zhǔn)確的找到目標(biāo)主機(jī)，即使是在我們的證書相同的情況下。

其實這一點也不費解，我們回顧一下之前學(xué)過的TSL通信過程：

第一次握手：客戶端發(fā)送協(xié)議版本號，隨機(jī)數(shù)，支持套件
第二次握手：服務(wù)端發(fā)送隨機(jī)數(shù)，版本號，確認(rèn)支持套件。同時發(fā)送服務(wù)端證書表明自己的身份(相當(dāng)于發(fā)了個身份證過去)。
第三次握手：客戶端收到證書，進(jìn)行身份驗證，驗證完畢后利用從證書內(nèi)部取出的公鑰加密傳輸一串新的隨機(jī)數(shù)pre_master給服務(wù)端。此時，客戶端，服務(wù)端都共享了三個隨機(jī)數(shù),客戶端隨機(jī)數(shù)、服務(wù)端隨機(jī)數(shù)、pre_master。于是根據(jù)三個隨機(jī)數(shù)雙方可以計算出共同的加密對稱密鑰進(jìn)行通信。生成完會話密鑰后，客戶端發(fā)一個「Change Cipher Spec」，告訴服務(wù)端開始使用加密方式發(fā)送消息。再發(fā)一個「Encrypted Handshake Message（Finishd）」消息，把之前所有發(fā)送的數(shù)據(jù)做個摘要，再用會話密鑰（master secret）加密一下，讓服務(wù)器做個驗證，驗證加密通信是否可用和之前握手信息是否有被中途篡改過。
第四次握手：服務(wù)器也是同樣的操作，發(fā)「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果雙方都驗證加密和解密沒問題，那么握手正式完成。
最后就是用會話密鑰進(jìn)行雙方的通信

也就是說，客戶端服務(wù)器通信過程中的密鑰是新協(xié)商出來的。具有唯一標(biāo)識性的這樣一個密鑰。那么通過SNI機(jī)制在第一次客戶端發(fā)送client hello包時就發(fā)送的server name 確定到底訪問的哪一個虛擬主機(jī)。后面的通信，自然可以通過解密密鑰尋找到對應(yīng)的虛擬主機(jī)。以此完成完整的SNI機(jī)制。

實現(xiàn)了可以為不同的虛擬主機(jī)配置這個不同的服務(wù)器證書。

6. SNI機(jī)制繞過host頭探究

這樣一個繞過出現(xiàn)的環(huán)境就很明顯了，必須是配置了SSL的nginx服務(wù)器。

之前有同學(xué)提出過疑問，認(rèn)為僅僅配置一個443端口的虛擬SSL主機(jī)。難以區(qū)分到底是由于我們的請求被轉(zhuǎn)移到了默認(rèn)的443端口處理虛擬主機(jī)上，還是說我們成功繞過了這樣一個檢測機(jī)制呢？接著3.2的環(huán)境，我們對其進(jìn)行進(jìn)一步的測試：

6.1 端口相同的SSL虛擬主機(jī)

#注意那個server在上面，在配置文件里就默認(rèn)的是默認(rèn)虛擬主機(jī)server {listen       443 ssl;server_name  www.bbb.com;ssl_certificate      /usr/local/nginx/certificate/aaa.crt;ssl_certificate_key  /usr/local/nginx/certificate/ssl.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/bbb;index  index.html index.htm;}}server {listen       443 ssl;server_name  www.aaa.com;ssl_certificate      /usr/local/nginx/certificate/aaa.crt;ssl_certificate_key  /usr/local/nginx/certificate/ssl.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/aaa;index  index.html index.htm;}}

相同端口號，不同的證書條件下，修改了host文件后跳轉(zhuǎn)到了默認(rèn)的bbb.com虛擬主機(jī)上。繞過失效

6.2 端口不同的SSL虛擬主機(jī)

 server {listen       443 ssl;server_name  www.bbb.com;ssl_certificate      /usr/local/nginx/certificate/bbb.crt;ssl_certificate_key  /usr/local/nginx/certificate/sslb.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/bbb;index  index.html index.htm;}}server {listen       8443 ssl;server_name  www.aaa.com;ssl_certificate      /usr/local/nginx/certificate/aaa.crt;ssl_certificate_key  /usr/local/nginx/certificate/ssl.key;ssl_session_cache    shared:SSL:1m;ssl_session_timeout  5m;ssl_ciphers  HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers  on;location / {root   /var/www/aaa;index  index.html index.htm;}}

訪問效果：


再次進(jìn)行測試：

這次沒有在跳默認(rèn)了，說明可行。

6.3 小結(jié)

SNI繞過host生效的條件其實就是單一端口下僅僅綁定一臺SSL虛擬主機(jī)。因為我們在6.1中看到，端口相同時同一服務(wù)器綁定多臺SSL主機(jī)時，所有的請求會交給默認(rèn)頁面。如果漏洞點在默認(rèn)頁面就好說，如果不在。就無法使用SNI進(jìn)行繞過了。

但同時，如果服務(wù)器是單一的配置了一個443端口的ssl虛擬主機(jī)，那么將可以進(jìn)行SNI機(jī)制的HOST頭繞過。