HTTPS分析-簡單易懂

一、簡單總結

1、HTTPS概念總結

HTTPS 就是對HTTP進行了TLS或SSL加密。

應用層的HTTP協議通過傳輸層的TCP協議來傳輸，HTTPS 在 HTTP和 TCP中間加了一層TLS/SSL加密層。

HTTP是明文傳輸，而現在HTTPS把明文加密后 再給TCP傳輸。

2、HTTPS實現的簡化版

2.1、HTTPS在三次握手的時候用非對稱加密生成 一個密鑰，后面的數據通信就用這個密鑰進行對稱加密通信。這樣既做到了安全性，又避免了非對稱加密的效率問題。

2.2、有的時候我們需要做接口的安全性，如果用非對稱加密是最安全的，但是效率比較低，如果用對稱加密 安全性又不是很好。所以 也可以自己 簡單模擬HTTPS來進行通信。

比如APP接口設計，我們用對稱加密進行通信，如果對稱加密的密鑰放到APP中，是不安全的，可以用逆向工程拿到，如果用HTTPS的接口獲取密鑰，其實HTTPS里的內容也可以被解密，這個和客戶端的代碼也有關系（比如iOS最常用的AFNetWorking就存在過漏洞），所以我們可以這么做：

• APP請求接口，第一次先用非對稱加密 請求接口 XXX/getAESSecretKey 來獲取密鑰（字符串）。

• 剩下的請求都根據這個密鑰來進行對稱加密 通信。

上面兩步就是簡化版的HTTPS通信。

2.3、真正的HTTPS通信要比這個麻煩，我們剛才舉例的密鑰是事先定好的，而HTTPS是通過 三次握手 中每次都生成一次隨機數，也就是客戶端生成2次隨機數，服務端生成1次隨機數，並且服務端確定加密方法，然后客戶端和服務端根據定好的加密規則，各自把這三個隨機數生成同樣的“對話密鑰”，這個“對話密鑰”就是后面數據通信用的 對稱加密的 密鑰。

這樣每個客戶端也 都有不同的 對稱加密密鑰。

二、HTTPS簡介

HTTPS（Hypertext Transfer Protocol Secure）：超文本傳輸安全協議。

HTTP的URL由“http://”起始，默認端口為80，HTTPS的URL由“https://”起始，默認端口為443。

HTTPS報文中的任何東西都被加密，包括所有報頭和荷載。這樣攻擊者就獲取不到有用的信息。

三、對稱加密和非對稱加密

1、概念

對稱加密：文件加密和解密使用相同的密鑰

非對稱加密：需要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey）。

用公鑰對數據進行加密，只有用對應的私鑰才能解密；如果用私鑰對數據進行加密，那么只有用對應的公鑰才能解密。

公鑰 :用於向外發布，任何人都能獲取。

私鑰 :要自己保存，切勿給別人，一般只有運維的人才知道。

2、算法

對稱加密常用的算法：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等。

非對稱加密常用的算法： RSA，ECDHE，DH，DHE、Elgamal、背包算法、Rabin、等。

3、能否被破解

RSA加密：還沒人聲稱以破解。世紀金融體系就是靠着1RSA加密建立的，破解了這個，就可以偽造整個金融體系。

AES加密：標准的128位AES是10輪的。現在針對7輪的AES已經破解了，家用機幾分鍾就能搞定。破解標准的10輪，家用電腦，還不足以短時間內破解。。大型機已經可以算是破解了128位的，所以現在最低也要求256位的AES。

四、TLS

1、TLS歷程：

• 1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，但是未發布。

• 1995年，NetScape公司發布SSL 2.0版，很快發現有嚴重漏洞。

• 1996年，SSL 3.0版問世，得到大規模應用。

• 1999年，互聯網標准化組織ISOC接替NetScape公司，發布了SSL的升級版TLS 1.0版。

• 2006年，升級到TLS 1.1版

• 2008年，升級到TLS 1.2版

• 2011年，TLS 1.2的修訂版

目前，應用最廣泛的是TLS 1.0，然后是SSL 3.0。但是，主流瀏覽器都已經實現了TLS 1.2的支持。

TLS 1.0也可以標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

前一段時間蘋果對HTTPS支持的要求里面就要求為TLS1.2版本。

2、SSL/TLS協議的基本過程概要

• 客戶端發送請求給服務器，請求包含客戶端生成的一個隨機數和客戶端版本信息。

• 服務端回復給客戶端，包括服務器證書、服務端生成的一個隨機數、確定加密密算法。

• 客戶端驗證服務器證書，生成一個隨機數並用公鑰加密，編碼信息等。

客戶端和服務端通過上面三個隨機數，按照第二步確定的加密方法，生成各自的"會話密鑰"，"會話密鑰"就是對稱加密的密鑰。

• 服務端發送給客戶端之前商定的編碼信息

• 雙方采用"對話密鑰"進行對稱加密通信。

因為公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。這樣就能保證公鑰不被篡改。

雙方協商生成"對話密鑰"。"對話密鑰"是對稱加密，所以運算速度非常快，而服務器公鑰只用於加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。

前兩個都在握手（明文通信）階段完成的。

五、證書

剛才我們提到通信中要用到證書，公鑰就在證書里面。證書還包括域名、公司信息、序列號和簽名信息等。

證書分為自簽名證書 和 CA 證書。

1、自簽名證書，可以自己生成，但是 容易被假冒和偽造、容易受到SSL中間人攻擊、證書有效期太長、法被吊銷(如果你的私鑰被黑客獲取，證書不能被吊銷，則黑客可以偽裝成你與用戶進行通信)。

2、CA：數字證書認證機構 Certificate Authority

任何個體/組織都可以扮演 CA 的角色，只不過難以得到客戶端的信任，能夠受瀏覽器默認信任的 CA 大廠商有很多，其中 TOP5 是 Symantec、Comodo、Godaddy、GolbalSign 和 Digicert。

需要花錢購買，比如淘寶用的是GlobalSign 的。

六、SSL單向認證和雙向認證

雙向認證：需要服務端與客戶端都提供證書，只能是服務端允許的客戶能去訪問，安全性相對於要高一些。客戶端需要安裝證書。

單向認證：只要求站點部署了ssl證書就行，任何用戶都可以去訪問(IP被限制除外等)，只是服務端提供了身份認證。一般的網站都是單向認證。

七、其他

1、因為前段時間蘋果要求HTTPS的規則里 要求用ECDH_RSA和ECDHE_ECDSA算法，所以這里簡單說下。

上面說過ECDHE 是非對稱加密算法的一種。

• RSA：算法實現簡單，誕生於 1977 年，安全性高。缺點就是需要比較大的素數(目前常用的是 2048 位)來保證安全強度，很消耗 CPU 運算資源。RSA 是目前唯一一個既能用於密鑰交換又能用於證書簽名的算法。

• DH：diffie-hellman 密鑰交換算法，誕生於1977 年，但是 1999 年才公開。缺點是比較消耗 CPU 性能。

• ECDHE：使用橢圓曲線(ECC)的 DH 算法，優點是能用較小的素數(256 位)實現 RSA 相同的安全等級。缺點是算法實現復雜，用於密鑰交換的歷史不長，有的客戶端不支持。

• ECDH：不支持 PFS，安全性低，同時無法實現 false start。

• DHE：不支持 ECC。非常消耗 CPU 資源。

建議優先支持 RSA 和 ECDH_RSA 密鑰交換算法。原因是：

• ECDHE 支持 ECC 加速，計算速度更快。支持 PFS，更加安全。支持 false start，用戶訪問速度更快。

• 目前還有至少 20% 以上的客戶端不支持 ECDHE，我們推薦使用 RSA 而不是 DH 或者 DHE，因為 DH 系列算法非常消耗 CPU(相當於要做兩次 RSA 計算)。

另外，DSA和ECDSA（橢圓曲線簽名算法）都只是簽名算法，它用來確保信息發布人的身份和信息的完整性，不能用來做加密傳輸

2、因為HTTPS連接所用的公鑰以明文傳輸，因此中國的防火長城可以對特定網站按照匹配的黑名單證書，通過偽裝成對方向連接兩端的計算機發送RST包干擾兩台計算機間正常的TCP通訊，以打斷與特定IP地址之間的443端口握手，或者直接使握手的數據包丟棄，導致握手失敗，從而導致TLS連接失敗。這也是一種互聯網信息審查和屏蔽的技術手段。