「HTTPS」安全在哪裏?

背景

最近基於興趣學學習了下 HTTPS 相關的知識,在此記錄下學習心得。算法

在上網獲取信息的過程當中,咱們接觸最多的信息加密傳輸方式也莫過於 HTTPS 了。每當訪問一個站點,瀏覽器的地址欄中出現綠色圖標時,意味着該站點支持 HTTPS 信息傳輸方式。咱們知道 HTTPS 是咱們常見的 HTTP 協議與某個加密協議的混合體,也就是 HTTP+S。這個 S 能夠是 TLS(安全傳輸層協議)、也能夠是 SSL(安全套接層),不過我更承認另外一個抽象歸納的說法,HTTP+Security。不過要談論 HTTPS 爲什麼安全,還得從 HTTP 爲什麼不安全提及。瀏覽器

假設你如今正坐在教室裏上課,如今你很是想和走道旁的迷人的 TA 說一些話,通常這個時候你會用「傳紙條」的方式來交流。而這個方式和 TCP/IP 協議基本的工做模式十分相像:安全

  1. 經過小動做引發對方注意;微信

  2. 對方以多種可能的方式(注視、肢體語言等)迴應於你;學習

  3. 你確認對方感知到你後,將紙條傳給對方;優化

  4. 對方閱讀紙條;網站

  5. 對方給予你閱讀後的反應;加密

怎麼樣,這個流程是否是很熟悉?spa

若是你要傳遞紙條的 TA 距離你很遠怎麼辦?HTTP 協議就是指你在紙條上寫明你要傳給的 TA 是誰,或者 TA 的座位在哪,接着只須要途徑的同窗拿到紙條後根據紙條上的指示依次將紙條傳過去就 OK 了。操作系統

這個時候問題來了:途徑的同窗徹底能夠觀看並知道你在紙條上寫了什麼。

這就是 HTTP 傳輸所面臨的問題之一:中間人攻擊,指消息傳遞的過程當中,處在傳遞路徑上的攻擊者能夠嗅探或者竊聽傳輸數據的內容。

加密

HTTPS 針對這個問題,採用了「加密」的方式來解決。最著名原始的加密方法就是對稱加密算法了,就是雙方約定一個暗號,用什麼字母替換什麼字母之類的。如今通常採用一種叫 AES(高級加密算法)的對稱算法。

對稱加密算法既指加密和解密須要使用的密鑰 key 是同樣的。

AES 在數學上保證了,只要你使用的 key 足夠長,破解幾乎是不可能的(除非光子計算機造出來了)

咱們先假設在沒有密鑰 key 的狀況下,密文是沒法被破解的,而後再回到這個教室。你將用 AES 加密後的內容噌噌噌地寫在了紙條上,正要傳出去的時候你忽然想到,TA 沒有 key 怎麼解密內容呀,或者說,應該怎麼把 key 給TA?

若是把 key 也寫在紙條上,那麼中間人照樣能夠破解竊聽紙條內容。也許在現實環境中你有其餘辦法能夠把 key 經過某種安全的渠道送到 TA 的手裏,可是互聯網上的實現難度就比較大了,畢竟無論怎樣,數據都要通過那些路由。

因而聰明的人類發明了另外一種加密算法——非對稱加密算法。這種加密算法會生成兩個密鑰(key1 和 key2)。凡是 key1 加密的數據,key1 自身不能解密,須要 key2 才能解密;凡事 key2 加密的數據,key2 自身不能解密,只有 key1 才能解密。

目前這種算法有不少中,最經常使用的是 RSA。其基於的數學原理是:

兩個大素數的乘積很容易算,可是用這個乘積去算出是哪兩個素數相乘就很複雜了。好在以目前的技術,分解大數的素因確實比較困難,尤爲是當這個大數足夠大的時候(一般使用2的10次方個二進制位那麼大),就算是超級計算機,解密也須要很是長的時間。

如今就把這種非對稱加密的方法應用在咱們教室傳紙條的場景裏。

  • 你在寫紙條內容以前先用 RSA 技術生成了一對密鑰 k1 和 k2。

  • 你把 k1 用明文傳了出去,路經也許有人會截取,可是沒有用,k1 加密的數據須要 k2 才能夠破解,而 k2 在你本身手中。

  • k1 傳到了目的人,目的人會去準備一個接下來準備用於對稱加密(AES)的傳輸密鑰 key,而後用收到的 k1 把 key 加密,傳給你。

  • 你用手上的 k2 解出 key 後,全教室只有你和你的目的人擁有這個對稱加密的 key,大家倆就能夠盡情聊天不怕竊聽啦~

這裏也許你會有問題,爲何不直接用非對稱加密來加密信息,而是加密 AES 的 key 呢?
由於非對稱加密和解密的平均消耗時間比較長,爲了節省時間提升效率,咱們一般只是用它來交換密鑰,而非直接傳輸數據。

然而使用非對稱加密真的能夠防範中間人攻擊嗎?
雖然看上去很安全,可是實際上卻擋不住可惡的中間人攻擊。

假設你是 A,你的目的地是 B,如今要途徑一個惡意同窗M。

中間人的惡意之處在於它會假裝成你的目標。

  • 當你要和 B 完成第一次密鑰交換的時候,M 把紙條扣了下來,僞裝本身是B並僞造了一個 key,而後用你發來的 k1 加密了 key 發還給你。

  • 你覺得你和 B 完成了密鑰交換,實際上你是和 M 完成了密鑰交換。

  • 同事 M 和 B 完成一次密鑰交換,讓 B 覺得和 A 你完成了密鑰交換。

  • 如今總體的加密流程變成了A(加密連接1)->M(明文)->B(加密連接2)的狀況了,這時候 M 依然能夠知道A和B傳輸的所有消息。

這個時候就是體現 HTTPS 和傳紙條的區別了。在教室裏,你是和一位與你身份幾乎對等的的對象來通訊;而在訪問網站時,對方每每是一個比較大(或者知名)的服務者,他們有充沛的資源,或許他們能夠向你證實他們的合法性。

此時咱們須要引入一個很是權威的第三方,一個專門用來認證網站合法性的組織,能夠叫作 CA(Certificate Authority)。各個網站服務商能夠向 CA 申請證書,使得他們在創建安全鏈接時能夠帶上 CA 的簽名。而 CA 得安全性是由操做系統或者瀏覽器來認證的。

你的 Windows、Mac、Linux、Chrome、Safari 等會在安裝的時候帶上一個他們認爲安全的 CA 證書列表,只有和你創建安全鏈接的網站帶有這些CA的簽名,操做系統和瀏覽器纔會認爲這個連接是安全的,不然就有可能遭到中間人攻擊。

一旦某個 CA 頒發的證書被用於的非法途徑,那麼這個 CA 以前頒發過的全部證書都將被視爲不安全的,這讓全部 CA 在頒發證書時都十分當心,因此 CA 證書在一般狀況下是值得信任的。

總結

使 HTTP 後面增長一個S(Security)的技術,正是 對稱加密 + 非對稱加密 + CA 認證 這三種技術的混合體。固然這個主要是 HTTPS 的基本原理,真正實際中的 HTTPS 的協議是比以上的描述更爲複雜一些的,而且其中任何一步稍有閃失,整個流程都將再也不安全。

這也是爲何 HTTPS 協議從 SSL 1.0升級到 SSL 3.0,再被 TLS 1.0 如今被 TLS 1.3取代,其背後都是一個個細節上的優化,以防有任何閃失。

TLS 協議相比 SSL 協議增長了傳輸層的安全保證。


更多精彩內容歡迎關注Bugly的微信公衆帳號:
Bugly

相關文章
相關標籤/搜索