咱們知道,HTTP請求都是明文傳輸的,所謂的明文指的是沒有通過加密的信息,若是HTTP請求被黑客攔截,而且裏面含有銀行卡密碼等敏感數據的話,會很是危險。爲了解決這個問題,Netscape 公司制定了HTTPS協議,HTTPS能夠將數據加密傳輸,也就是傳輸的是密文,即使黑客在傳輸過程當中攔截到數據也沒法破譯,這就保證了網絡通訊的安全。算法
在正式講解HTTPS協議以前,咱們首先要知道一些密碼學的知識。瀏覽器
明文: 明文指的是未被加密過的原始數據。安全
密文:明文被某種加密算法加密以後,會變成密文,從而確保原始數據的安全。密文也能夠被解密,獲得原始的明文。服務器
密鑰:密鑰是一種參數,它是在明文轉換爲密文或將密文轉換爲明文的算法中輸入的參數。密鑰分爲對稱密鑰與非對稱密鑰,分別應用在對稱加密和非對稱加密上。網絡
對稱加密:對稱加密又叫作私鑰加密,即信息的發送方和接收方使用同一個密鑰去加密和解密數據。對稱加密的特色是算法公開、加密和解密速度快,適合於對大數據量進行加密,常見的對稱加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。 其加密過程以下:明文 + 加密算法 + 私鑰 => 密文 解密過程以下:密文 + 解密算法 + 私鑰 => 明文 對稱加密中用到的密鑰叫作私鑰,私鑰表示我的私有的密鑰,即該密鑰不能被泄露。 其加密過程當中的私鑰與解密過程當中用到的私鑰是同一個密鑰,這也是稱加密之因此稱之爲「對稱」的緣由。因爲對稱加密的算法是公開的,因此一旦私鑰被泄露,那麼密文就很容易被破解,因此對稱加密的缺點是密鑰安全管理困難。session
非對稱加密:非對稱加密也叫作公鑰加密。非對稱加密與對稱加密相比,其安全性更好。對稱加密的通訊雙方使用相同的密鑰,若是一方的密鑰遭泄露,那麼整個通訊就會被破解。而非對稱加密使用一對密鑰,即公鑰和私鑰,且兩者成對出現。私鑰被本身保存,不能對外泄露。公鑰指的是公共的密鑰,任何人均可以得到該密鑰。用公鑰或私鑰中的任何一個進行加密,用另外一個進行解密。 被公鑰加密過的密文只能被私鑰解密,過程以下: 明文 + 加密算法 + 公鑰 => 密文, 密文 + 解密算法 + 私鑰 => 明文 被私鑰加密過的密文只能被公鑰解密,過程以下: 明文 + 加密算法 + 私鑰 => 密文, 密文 + 解密算法 + 公鑰 => 明文 因爲加密和解密使用了兩個不一樣的密鑰,這就是非對稱加密「非對稱」的緣由。 非對稱加密的缺點是加密和解密花費時間長、速度慢,只適合對少許數據進行加密。 在非對稱加密中使用的主要算法有:RSA、Elgamal、Rabin、D-H、ECC(橢圓曲線加密算法)等。tcp
HTTPS協議 = HTTP協議 + SSL/TLS協議,在HTTPS數據傳輸的過程當中,須要用SSL/TLS對數據進行加密和解密,須要用HTTP對加密後的數據進行傳輸,由此能夠看出HTTPS是由HTTP和SSL/TLS一塊兒合做完成的。函數
SSL的全稱是Secure Sockets Layer,即安全套接層協議,是爲網絡通訊提供安全及數據完整性的一種安全協議。SSL協議在1994年被Netscape發明,後來各個瀏覽器均支持SSL,其最新的版本是3.0大數據
TLS的全稱是Transport Layer Security,即安全傳輸層協議,最新版本的TLS(Transport Layer Security,傳輸層安全協議)是IETF(Internet Engineering Task Force,Internet工程任務組)制定的一種新的協議,它創建在SSL 3.0協議規範之上,是SSL 3.0的後續版本。在TLS與SSL3.0之間存在着顯著的差異,主要是它們所支持的加密算法不一樣,因此TLS與SSL3.0不能互操做。雖然TLS與SSL3.0在加密算法上不一樣,可是在咱們理解HTTPS的過程當中,咱們能夠把SSL和TLS看作是同一個協議。加密
HTTPS爲了兼顧安全與效率,同時使用了對稱加密和非對稱加密。數據是被對稱加密傳輸的,對稱加密過程須要客戶端的一個密鑰,爲了確保能把該密鑰安全傳輸到服務器端,採用非對稱加密對該密鑰進行加密傳輸,總的來講,對數據進行對稱加密,對稱加密所要使用的密鑰經過非對稱加密傳輸。
HTTPS在傳輸的過程當中會涉及到三個密鑰:
服務器端的公鑰和私鑰,用來進行非對稱加密
客戶端生成的隨機密鑰,用來進行對稱加密
一個HTTPS請求實際上包含了兩次HTTP傳輸,能夠細分爲8步。
客戶端向服務器發起HTTPS請求,鏈接到服務器的443端口。
服務器端有一個密鑰對,即公鑰和私鑰,是用來進行非對稱加密使用的,服務器端保存着私鑰,不能將其泄露,公鑰能夠發送給任何人。
服務器將本身的公鑰發送給客戶端。
客戶端收到服務器端的公鑰以後,會對公鑰進行檢查,驗證其合法性,若是發現發現公鑰有問題,那麼HTTPS傳輸就沒法繼續。嚴格的說,這裏應該是驗證服務器發送的數字證書的合法性,關於客戶端如何驗證數字證書的合法性,下文會進行說明。若是公鑰合格,那麼客戶端會生成一個隨機值,這個隨機值就是用於進行對稱加密的密鑰,咱們將該密鑰稱之爲client key,即客戶端密鑰,這樣在概念上和服務器端的密鑰容易進行區分。而後用服務器的公鑰對客戶端密鑰進行非對稱加密,這樣客戶端密鑰就變成密文了,至此,HTTPS中的第一次HTTP請求結束。
客戶端會發起HTTPS中的第二個HTTP請求,將加密以後的客戶端密鑰發送給服務器。
服務器接收到客戶端發來的密文以後,會用本身的私鑰對其進行非對稱解密,解密以後的明文就是客戶端密鑰,而後用客戶端密鑰對數據進行對稱加密,這樣數據就變成了密文。
而後服務器將加密後的密文發送給客戶端。
客戶端收到服務器發送來的密文,用客戶端密鑰對其進行對稱解密,獲得服務器發送的數據。這樣HTTPS中的第二個HTTP請求結束,整個HTTPS傳輸完成。
並非。SSL是邏輯上獨立於運輸層的,而且是面向鏈接的,因此無論進行幾回https請求,也無論tcp鏈接有沒有更新,只要客戶和服務器的SSL鏈接沒有終止而且雙方沒有丟失這段SSL鏈接的識別號,客戶和服務器之間就能夠一直使用握手階段生成的對稱密鑰進行應用層通訊。只有從新進行SSL鏈接時纔會再握手。
瀏覽器能夠session ID爲單位臨時保存加密key等安全參數。瀏覽器客戶端訪問同一個https服務器,能夠沒必要每次都進行完整的TLS Handshake,由於完整的TLS Handshake,涉及到認證服務器的身份(數字證書),須要作大量的非對稱加密/解密運算,此外還須要作僞隨機函數PRF,經過「Pre-Master Key」、「Server Nonce」、「Client Nonce」共同推導出session key,非對稱加密算法RSA/DSA很是耗費CPU資源。爲了克服這個困難,服務器維護一個以session ID爲索引的結構體,用於臨時存放session key,並在TLS handshake 階段分享給瀏覽器。當瀏覽器從新鏈接https 服務器時,TLS handshake 階段,出示本身的session ID,服務器得到session ID,以此爲索引,能夠得到和該瀏覽器共同擁有的session key,使用session key能夠直接對用戶流量作加密/解密動做。這樣避免了大量的冪、指數計算。固然,若是服務器沒有查找到session ID,雙方的TLS安全參數協商按照正常流程走。
經過觀察HTTPS的傳輸過程,咱們知道,當服務器接收到客戶端發來的請求時,會向客戶端發送服務器本身的公鑰,可是黑客有可能中途篡改公鑰,將其改爲黑客本身的,因此有個問題,客戶端怎麼信賴這個公鑰是本身想要訪問的服務器的公鑰而不是黑客的呢? 這時候就須要用到數字證書。
在講數字證書以前,先說一個小例子。假設一個鎮裏面有兩我的A和B,A是個富豪,B想向A借錢,可是A和B不熟,怕B借了錢以後不還。這時候B找到了鎮長,鎮長給B做擔保,告訴A說:「B人品不錯,不會欠錢不還的,你就放心借給他吧。」 A聽了這話後,內心想:「鎮長是全鎮最德高望重的了,他說B沒問題的話那就沒事了,我就放心了」。 因而A相信B的爲人,把錢借給了B。
與此類似的,要想讓客戶端信賴公鑰,公鑰也要找一個擔保人,並且這個擔保人的身份必須德高望重,不然沒有說服力。這個擔保人的就是證書認證中心(Certificate Authority),簡稱CA。 也就是說CA是專門對公鑰進行認證,進行擔保的,也就是專門給公鑰作擔保的擔保公司。 全球知名的CA也就100多個,這些CA都是全球都承認的,好比VeriSign、GlobalSign等,國內知名的CA有WoSign。
那CA怎麼對公鑰作擔保認證呢?CA自己也有一對公鑰和私鑰,CA會用CA本身的私鑰對要進行認證的公鑰進行非對稱加密,此處待認證的公鑰就至關因而明文,加密完以後,獲得的密文再加上證書的過時時間、頒發給、頒發者等信息,就組成了數字證書。
不論什麼平臺,設備的操做系統中都會內置100多個全球公認的CA,說具體點就是設備中存儲了這些知名CA的公鑰。當客戶端接收到服務器的數字證書的時候,會進行以下驗證:
首先客戶端會用設備中內置的CA的公鑰嘗試解密數字證書,若是全部內置的CA的公鑰都沒法解密該數字證書,說明該數字證書不是由一個全球知名的CA簽發的,這樣客戶端就沒法信任該服務器的數字證書。
若是有一個CA的公鑰可以成功解密該數字證書,說明該數字證書就是由該CA的私鑰簽發的,由於被私鑰加密的密文只能被與其成對的公鑰解密。
除此以外,還須要檢查客戶端當前訪問的服務器的域名是與數字證書中提供的「頒發給」這一項吻合,還要檢查數字證書是否過時等。
經過瀏覽器直接獲取服務器的公鑰很容易,各個瀏覽器操做大同小異。