|
1、HTTPS 協(xié)議簡介 Https 協(xié)議是由SSL HTTP 協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，相比 Http 更加安全。相比Http 有如下特點： （1）Https 需要到CA 申請證書，一般是收費的； （2）Http 是超文本傳輸協(xié)議，信息是明文傳輸，Https 則是具有安全性的SSL 加密傳 （3）Http 一般使用的端口是80 端口，Https 一般使用443 端口。 Https 的核心作用： （1）數(shù)據(jù)保密性：保證內(nèi)容在傳輸過程不會被第三方看到； （2）數(shù)據(jù)完整性：保證內(nèi)容在傳輸過程中不會被篡改； （3）身份校驗：保證數(shù)據(jù)到達用戶期望的目的地； 2、HTTPS 協(xié)議流程 與 HTTP 相比，HTTPS 增加了SSL（Secure Sockets Layer）安全套接層，如圖1 所示。
在真正的數(shù)據(jù)交互之前通過 SSL Handshake（SSL 握手）協(xié)商一個對稱秘鑰，通過這個 對稱秘鑰對以后的通信內(nèi)容進行加密。如圖2 所示，HTTPS 的通信過程如下： （1）、客戶端發(fā)起HTTPS 請求
3、SSL 證書及其驗證過程 3.1 數(shù)字證書 數(shù)字證書在 SSL 握手過程中扮演身份認證和密鑰分發(fā)的功能，究竟什么是數(shù)字證書呢？ 簡單來說數(shù)字證書就是一種網(wǎng)絡上證明持有者身份的文件，同時證書中還含有公鑰。證書是由國際上公認的證書機構(gòu)頒發(fā)，一些驗證證書的客戶端應用程序比如瀏覽器對于這些機構(gòu)頒發(fā)的證書完全信任。通常windows 部署系統(tǒng)的時候會讓客戶端安裝“根受信任機構(gòu)列表”，當客戶端收到一個證書時會查看證書是否是該列表中的機構(gòu)頒發(fā)的，如果是則信任這個證書。 如圖3 就是一個受信任的證書樣式，而圖4 是一個不受信任的非法證書。
在服務器證書不在受信任的范圍內(nèi)的時候，瀏覽器會給出安全提示：
3.2 數(shù)字證書的驗證 由此可以看出 https 的站點需要一份數(shù)字證書，證書需要一個機構(gòu)頒發(fā)，這個機構(gòu)可以使一個國際上公認的證書機構(gòu)，也可以是任何一臺安裝有證書服務的計算機。客戶端是否信任這個證書取決于客戶端上是否安裝了這個證書頒發(fā)者的根證書。證書的頒發(fā)和驗證過程如 圖7 所示。
以 IE 瀏覽器為例，會從如下三個方面驗證證書的有效性，不滿足情況下會報警提示： （1） 證書頒發(fā)者是否在“根受信任的證書頒發(fā)機構(gòu)列表”中； （2） 證書是否過期； （3） 證書的持有者是否和訪問的網(wǎng)站一致； 實際上除此之外瀏覽器還會定期證書頒發(fā)者的“證書吊銷列表”，如果某個證書雖然符合上述條件，但是被它的頒發(fā)者在“證書吊銷列表”中列出，那么也將給出警告。每個證書的CRLDistribution Point 字段顯示了查看這個列表的url。盡管如此，windows 對于這個列表是“不 4、HTTPS 性能消耗及其優(yōu)化 4.1 HTTPS 性能消耗
如圖 8 所示，Https 與Http 的通信過程相比存在如下幾點差異： （ 1 ） 302 重定向： 302 跳轉(zhuǎn)不是每次都需要的， 當用戶在地址欄直接輸入https://www.baidu.com（當然可以是其他https 站點，只要帶上前綴https://）進行訪問的時候就不會有這個重定向過程； （2）SSL 握手（SSL handshake）過程增加的網(wǎng)絡傳輸RTT，及數(shù)字簽名的校驗過程，特別是一些移動終端的計算性能本身不是很強，耗時就更加明顯； （3）證書驗證和狀態(tài)檢驗，檢查證書是否過期等。瀏覽器一般會通過ocsp 來檢查證書的撤銷狀態(tài)，在拿到服務器發(fā)送過來的證書之后會請求ocsp 站點獲取證書的狀態(tài)，如果ocsp站點位于國外或者出現(xiàn)故障的話會影響這個正常用戶的訪問速度。好在ocsp 檢查周期一般比較長（7 天），不是很頻繁。并且有些瀏覽器直接關閉了ocsp 功能。 4.2 HTTPS 性能優(yōu)化 既然 HTTPS 相比HTTP 存在很多耗時的地方，實際測試表明沒有經(jīng)過任何優(yōu)化的情況下，HTTPS 要比HTTP 耗時多達200ms 以上，因此針對HTTPS 的性能優(yōu)化非常必要。手段都有哪些呢，下面我們來一一分析： 1、首先是減少302 跳轉(zhuǎn)，通過服務器配置HSTS（HTTP Strict Transport Security，HTTP 嚴格傳輸協(xié)議，RFC 6797）。他的作用是強制客戶端（如瀏覽器）使用HTTPS 與服務器之間連接。同時HSTS 還能夠抵御SSL 剝離攻擊，SSL 剝離攻擊屬于中間人劫持的一種，是由Moxie Marlinspike 于2009 年發(fā)明的一種攻擊方式，它的前提是用戶很少直接在地址欄中輸入https://，更多是通過點擊連接、3xx 重定向從HTTP 頁面進入HTTPS。攻擊者在中間將所有的https://替換成http://以達到阻止HTTPS 的目的。 HSTS 的實現(xiàn)方式是當客戶端通過https 發(fā)出請求時，在服務器返回的超文本傳輸協(xié)議響應頭中包含Strict-Transport-Security 字段。非加密傳輸時設置的HSTS 字段無效，比如https://www.baidu.com/ 的響應頭含有Strict-Transport-Security: max-age=31536000;includeSubDomains，表示在接下來的一年時間里，瀏覽器只要向www.baidu.com 發(fā)送請求必須采用HTTPS 方式發(fā)送。用戶在地址欄中輸入http://www.baidu.com，瀏覽器會自動將http:替換成https://。 2、設置ocsp stapling file，使得ocsp 的請求不再發(fā)往ca 提供的ocsp 站點，改為發(fā)往網(wǎng)站的webserver。 3、啟用SPDY，SPDY（讀作“SPeeDY”）是Google 開發(fā)的基于TCP 的應用層協(xié)議，用以最小化網(wǎng)絡延遲，提升網(wǎng)絡速度，優(yōu)化用戶的網(wǎng)絡使用體驗。SPDY 并不是一種用于替代HTTP 的協(xié)議，而是對HTTP 協(xié)議的增強。包括數(shù)據(jù)流的多路復用、請求優(yōu)先級以及HTTP 報頭壓縮。協(xié)議層次如圖9 所示：
SPDY 協(xié)議比較復雜，這里就不再詳細展開。使用SPDY 不僅能夠提高HTTPS 的訪問速度，甚至比HTTP 還要快。谷歌表示，引入SPDY 協(xié)議后，在實驗室測試中頁面加載速度比原先快64%。SPDY 的缺點是支持的瀏覽器不夠多，Google 也表示2016 年將從Chrome中去除SPDY，改用HTTP/2（IETF 努力打造的全新協(xié)議，前身就是大名鼎鼎的HTTP，采用了SPDY 很多的特點）。 4、有限ECDHE 密鑰交換算法，支持PFS（完全正向保密Perfect forward secrecy），能夠?qū)崿F(xiàn)false start； 5、啟用TFO（TCP Fast Open），TFO 能夠優(yōu)化TCP 鏈接的RTT 次數(shù)從而提高效率，不僅能夠優(yōu)化HTTPS，同時也能夠優(yōu)化HTTP，但是支持TFO 的客戶端不多； 6、設置ssl session 的共享內(nèi)存cache. 以nginx 為例，它目前只支持session cache的單機多進程共享。 7、配置相同的session ticket key，部署在多個服務器上，這樣多個不同的服務器也能產(chǎn)生相同的 session ticket。session ticket 的缺點是支持率不廣，大概只有40%。而session id 是client hello 的標準內(nèi)容，從SSL2.0 開始就被全部客戶支持。 8、設置tls record size，最好是能動態(tài)調(diào)整record size，即連接剛建立時record size設置成msg，連接穩(wěn)定之后可以將record size 動態(tài)增加。 5、 HTTPS 的安全分析 從上面對 HTTPS 通信過程的分析，大家可以看出HTTPS 通過客戶端和服務器之間協(xié)商出來的對稱密鑰對數(shù)據(jù)進行加密來實現(xiàn)隱私保護。有兩個地方比較重要： （1）加密算法以及對稱密鑰的安全性，如AES、RC4 和DES 等，本文我們不詳細展開分析對稱加密的安全性； （2）密鑰交換的過程，也就是如何通過非對稱加密的方式協(xié)商出一個對稱密鑰，如RSA、DHE、ECDHE，本文我們以簡單的RSA 為例來介紹非對稱加密的過程，幫助大家理解這個過程，而不去介紹ECDHE 等基于橢圓曲線的更復雜的算法。 5.1 非對稱加密及密鑰交換 在 1976 年以前，所有加密都是對稱加密方式，這種加密方式最大的問題是保存和傳遞密鑰的過程非常不安全。1976 年兩位計算機學家Whitfield Diffie 和 Martin Hellman，提出了一種嶄新構(gòu)思，可以在不直接傳遞密鑰的情況下，完成解密。這被稱為“Diffie-Hellman密鑰交換算法”。1977 年，三位數(shù)學家Rivest、Shamir 和 Adleman 設計了一種算法，可以實現(xiàn)非對稱加密。這種算法用他們?nèi)齻€人的名字命名，叫做RSA 算法。從那時直到現(xiàn)在，RSA 算法一直是最廣為使用的”非對稱加密算法”。毫不夸張地說，只要有計算機網(wǎng)絡的地方，就有RSA 算法。這種算法非常可靠，密鑰越長越安全。到目前為止被公開破解的密鑰長度 RSA 的安全基于大數(shù)分解的難度。其公鑰和私鑰是一對大素數(shù)（100 到200 位十進制數(shù)或更大）的函數(shù)。從一個公鑰和密文恢復出明文的難度，等價于分解兩個大素數(shù)之積。 公鑰 Ku：（e，n） （1） n 是兩個素數(shù)p 和q 的乘積（其中p 和q 保密） 私鑰 Kr：（d，n） 加密過程：C ? Me (mod n)，其中 M 是被加密內(nèi)容，C 是產(chǎn)生的密文； 解密過程：M ? Cd (mod n) 【Example】下面我們演示一個例子：
明文： 從上面例子中我們可以看出，明文（5,8,16）通過公鑰加密得到密文，最后通過私鑰進行解密。當然也可以通過私鑰進行加密，然后通過公鑰進行解密，在對稱密鑰協(xié)商的過程中就是這樣用的。上面的例子選取的素數(shù)都比較小，實際運用要比這復雜得多，由于RSA 算法的公鑰私鑰的長度要到1024 位甚至2048 位才能保證安全，因此，p、q、e 的選取、公鑰私鑰的生成，加密解密模指數(shù)運算都有一定的計算程序，需要仰仗計算機完成。 5.2 HTTPS 依然面臨的安全問題 雖然HTTPS 通過SSL 確實能夠為保護用戶隱私，防止流量劫持起到很大作用，但是依然存在許多威脅，比如服務器私鑰的泄露、協(xié)商過程產(chǎn)生出的對稱泄露、對稱加密算法被破解以及中間人攻擊等等。下面我們主要針對中間人攻擊舉幾個例子來說明： 【SSLSniff 攻擊】：
SSLSniff 屬于中間人攻擊（Man-in-the-MiddleAttack，MITM 攻擊）的一種，過程如下： 1、攻擊者介于用戶和服務器之間，偽造證書，當用戶發(fā)送https 請求是攻擊者劫持這個請求，并返回自己的證書（非法證書），同時它會繼續(xù)請求服務器； 2、由于證書不合法，通常瀏覽器上會有警示，如果用戶稍加注意能夠避免這種攻擊； 3、攻擊者和服務器之間是一個合法的https 連接，服務器無法區(qū)分用戶和攻擊者，攻擊者能夠取到服務器結(jié)果并進行篡改，然后以他和用戶之間協(xié)商出來的密鑰進行通信。 【SSLStrip 攻擊】：
SSLStrip 攻擊的本質(zhì)是利用一般用戶在瀏覽器地址欄中輸入地址時一般不會帶https://的特點，將用戶劫持并對于后續(xù)服務器返回結(jié)果中所有帶有https://的地方都替換成http://使得用戶和服務器之間不會建立https 連接來達到劫持攻擊的目的。過程如下： 1、一般用戶在瀏覽器地址欄輸入時不會選擇https，SSLStrip 利用這個特點進行攻擊 2、正常情況下對于HTTPS 服務器，當遇到http 請求時會做一個重定向到https 3、攻擊者和用戶之間始終保持http 鏈接，而與服務器之間保持https 連接。 【降級攻擊】：
圖12、SSL 降級攻擊 SSL 3.0 是一個比較老的協(xié)議，大多數(shù)瀏覽器為了兼容性都會支持這個協(xié)議，但是SSL3.0 存在一些安全漏洞。攻擊者就是利用這個特性，首先讓用戶使用的協(xié)議降級到SSL 3.0然后利用SSL 3.0 的漏洞進行攻擊。 過程如圖 12 所示： 1、一般情況下用戶發(fā)起請求會采用更加安全的TLS 1.2/1.1/1.0 協(xié)議，TLS（TransportLayer Security，傳輸層安全協(xié)議）是IETF（Internet Engineering Task Force，Internet 工程任務組）制定的一種新的協(xié)議，它建立在SSL 3.0 協(xié)議規(guī)范之上，是SSL 3.0 的后續(xù)版本。在TLS 與SSL3.0 之間存在著顯著的差別，主要是它們所支持的加密算法不同，所以TLS 與SSL3.0 不能互操作； 2、中間人（攻擊者）駁回這個請求，告訴用戶瀏覽器說不支持這幾個協(xié)議，建議其采用SSL 3.0； 3、用戶客戶端降級采用SSL 3.0，中間人就利用SSL 3.0 進行攻擊； 4、攻擊者和服務器之間依然使用https 建立正常的鏈接，服務器無法區(qū)分攻擊者和用戶。 4、參考鏈接 （1） HSTS（RFC 6797）：http://tools./html/rfc6797 （2） TFO 論文：http://conferences./co-next/2011/papers/1569470463.pdf （3） 完全前向安全Perfect Forward Secrecy：http://de./wiki/Perfect_Forward_Secrecy （4） SSL: https://www./ssl.htm （5） SPDY 協(xié)議簡介及如何編譯含有SPDY 的nginx：http://network.51cto.com/art/201401/426957.htm |
|
|
