爲什麼需要https
HTTP是明文傳輸的,也就意味着,介於發送端、接收端中間的任意節點都可以知道你們傳輸的內容是什麼。這些節點可能是路由器、代理等。
舉個最常見的例子,用戶登陸。用戶輸入賬號,密碼,採用HTTP的話,只要在代理服務器上做點手腳就可以拿到你的密碼了。
用戶登陸 --> 代理服務器(做手腳)--> 實際授權服務器
在發送端對密碼進行加密?沒用的,雖然別人不知道你原始密碼是多少,但能夠拿到加密後的賬號密碼,照樣能登陸。
HTTPS是如何保障安全的
HTTPS其實就是secure http的意思啦,也就是HTTP的安全升級版。稍微瞭解網絡基礎的同學都知道,HTTP是應用層協議,位於HTTP協議之下是傳輸協議TCP。TCP負責傳輸,HTTP則定義了數據如何進行包裝。
HTTP --> TCP (明文傳輸)
HTTPS相對於HTTP有哪些不同呢?其實就是在HTTP跟TCP中間加多了一層加密層TLS/SSL。
神馬是TLS/SSL?
通俗的講,TLS、SSL其實是類似的東西,SSL是個加密套件,負責對HTTP的數據進行加密。TLS是SSL的升級版。現在提到HTTPS,加密套件基本指的是TLS。
傳輸加密的流程
原先是應用層將數據直接給到TCP進行傳輸,現在改成應用層將數據給到TLS/SSL,將數據加密後,再給到TCP進行傳輸。
大致如圖所示。
就是這麼回事。將數據加密後再傳輸,而不是任由數據在複雜而又充滿危險的網絡上明文裸奔,在很大程度上確保了數據的安全。這樣的話,即使數據被中間節點截獲,壞人也看不懂。
HTTPS是如何加密數據的
對安全或密碼學基礎有了解的同學,應該知道常見的加密手段。一般來說,加密分爲對稱加密、非對稱加密(也叫公開密鑰加密)。
對稱加密:
對稱加密的意思就是,加密數據用的密鑰,跟解密數據用的密鑰是一樣的。
對稱加密的優點在於加密、解密效率通常比較高。缺點在於,數據發送方、數據接收方需要協商、共享同一把密鑰,並確保密鑰不泄露給其他人。此外,對於多個有數據交換需求的個體,兩兩之間需要分配並維護一把密鑰,這個帶來的成本基本是不可接受的。
非對稱加密:
非對稱加密的意思就是,加密數據用的密鑰(公鑰),跟解密數據用的密鑰(私鑰)是不一樣的。
什麼叫做公鑰呢?其實就是字面上的意思——公開的密鑰,誰都可以查到。因此非對稱加密也叫做公開密鑰加密。
相對應的,私鑰就是非公開的密鑰,一般是由網站的管理員持有。
公鑰、私鑰兩個有什麼聯繫呢?
簡單的說就是,通過公鑰加密的數據,只能通過私鑰解開。通過私鑰加密的數據,只能通過公鑰解開。
很多同學都知道用私鑰能解開公鑰加密的數據,但忽略了一點,私鑰加密的數據,同樣可以用公鑰解密出來。而這點對於理解HTTPS的整套加密、授權體系非常關鍵。
舉個非對稱加密的例子
-
登陸用戶:小明
-
授權網站:某知名社交網站(以下簡稱XX)
小明都是某知名社交網站XX的用戶,XX出於安全考慮在登陸的地方用了非對稱加密。小明在登陸界面敲入賬號、密碼,點擊“登陸”。於是,瀏覽器利用公鑰對小明的賬號密碼進行了加密,並向XX發送登陸請求。XX的登陸授權程序通過私鑰,將賬號、密碼解密,並驗證通過。之後,將小明的個人信息(含隱私),通過私鑰加密後,傳輸回瀏覽器。瀏覽器通過公鑰解密數據,並展示給小明。
-
步驟一: 小明輸入賬號密碼 --> 瀏覽器用公鑰加密 --> 請求發送給XX
-
步驟二: XX用私鑰解密,驗證通過 --> 獲取小明社交數據,用私鑰加密 --> 瀏覽器用公鑰解密數據,並展示。
用非對稱加密,就能解決數據傳輸安全的問題了嗎?前面特意強調了一下,私鑰加密的數據,公鑰是可以解開的,而公鑰又是加密的。也就是說,非對稱加密只能保證單向數據傳輸的安全性。
此外,還有公鑰如何分發/獲取的問題。下面會對這兩個問題進行進一步的探討。
公開密鑰加密:兩個明顯的問題
前面舉了小明登陸社交網站XX的例子,並提到,單純使用公開密鑰加密存在兩個比較明顯的問題。
-
公鑰如何獲取
-
數據傳輸僅單向安全
問題一:公鑰如何獲取
瀏覽器是怎麼獲得XX的公鑰的?當然,小明可以自己去網上查,XX也可以將公鑰貼在自己的主頁。然而,對於一個動不動就成敗上千萬的社交網站來說,會給用戶造成極大的不便利,畢竟大部分用戶都不知道“公鑰”是什麼東西。
問題二:數據傳輸僅單向安全
前面提到,公鑰加密的數據,只有私鑰能解開,於是小明的賬號、密碼是安全了,半路不怕被攔截。
然後有個很大的問題:私鑰加密的數據,公鑰也能解開。加上公鑰是公開的,小明的隱私數據相當於在網上換了種方式裸奔。(中間代理服務器拿到了公鑰後,毫不猶豫的就可以解密小明的數據)
下面就分別針對這兩個問題進行解答。
問題一:公鑰如何獲取
這裏要涉及兩個非常重要的概念:證書、CA(證書頒發機構)。
證書
可以暫時把它理解爲網站的身份證。這個身份證裏包含了很多信息,其中就包含了上面提到的公鑰。
也就是說,當小明、小王、小光等用戶訪問XX的時候,再也不用滿世界的找XX的公鑰了。當他們訪問XX的時候,XX就會把證書發給瀏覽器,告訴他們說,乖,用這個裏面的公鑰加密數據。
這裏有個問題,所謂的“證書”是哪來的?這就是下面要提到的CA負責的活了。
CA(證書頒發機構)
強調兩點:
-
可以頒發證書的CA有很多(國內外都有)。
-
只有少數CA被認爲是權威、公正的,這些CA頒發的證書,瀏覽器才認爲是信得過的。比如VeriSign。(CA自己僞造證書的事情也不是沒發生過。。。)
證書頒發的細節這裏先不展開,可以先簡單理解爲,網站向CA提交了申請,CA審覈通過後,將證書頒發給網站,用戶訪問網站的時候,網站將證書給到用戶。
至於證書的細節,同樣在後面講到。
問題二:數據傳輸僅單向安全
上面提到,通過私鑰加密的數據,可以用公鑰解密還原。那麼,這是不是就意味着,網站傳給用戶的數據是不安全的?
答案是:是!!!(三個歎號表示強調的三次方)
看到這裏,可能你心裏會有這樣想:用了HTTPS,數據還是裸奔,這麼不靠譜,還不如直接用HTTP來的省事。
但是,爲什麼業界對網站HTTPS化的呼聲越來越高呢?這明顯跟我們的感性認識相違背啊。
因爲:HTTPS雖然用到了公開密鑰加密,但同時也結合了其他手段,如對稱加密,來確保授權、加密傳輸的效率、安全性。
概括來說,整個簡化的加密通信的流程就是:
-
小明訪問XX,XX將自己的證書給到小明(其實是給到瀏覽器,小明不會有感知)
-
瀏覽器從證書中拿到XX的公鑰A
-
瀏覽器生成一個只有自己知道的對稱密鑰B,用公鑰A加密,並傳給XX(其實是有協商的過程,這裏爲了便於理解先簡化)
-
XX通過私鑰解密,拿到對稱密鑰B
-
瀏覽器、XX 之後的數據通信,都用密鑰B進行加密
注意:對於每個訪問XX的用戶,生成的對稱密鑰B理論上來說都是不一樣的。比如小明、小王、小光,可能生成的就是B1、B2、B3.
參考下圖:(附上原圖出處)
證書可能存在哪些問題
瞭解了HTTPS加密通信的流程後,對於數據裸奔的疑慮應該基本打消了。然而,細心的觀衆可能又有疑問了:怎麼樣確保證書有合法有效的?
證書非法可能有兩種情況:
-
證書是僞造的:壓根不是CA頒發的
-
證書被篡改過:比如將XX網站的公鑰給替換了
舉個例子:
我們知道,這個世界上存在一種東西叫做代理,於是,上面小明登陸XX網站有可能是這樣的,小明的登陸請求先到了代理服務器,代理服務器再將請求轉發到的授權服務器。
小明 --> 邪惡的代理服務器 --> 登陸授權服務器
小明 <-- 邪惡的代理服務器 <-- 登陸授權服務器
然後,這個世界壞人太多了,某一天,代理服務器動了壞心思(也有可能是被入侵),將小明的請求攔截了。同時,返回了一個非法的證書。
小明 --> 邪惡的代理服務器 --x--> 登陸授權服務器
小明 <-- 邪惡的代理服務器 --x--> 登陸授權服務器
如果善良的小明相信了這個證書,那他就再次裸奔了。當然不能這樣,那麼,是通過什麼機制來防止這種事情的放生的呢。
下面,我們先來看看”證書”有哪些內容,然後就可以大致猜到是如何進行預防的了。
證書簡介
在正式介紹證書的格式前,先插播個小廣告,科普下數字簽名和摘要,然後再對證書進行非深入的介紹。
爲什麼呢?因爲數字簽名、摘要是證書防僞非常關鍵的武器。
數字簽名與摘要
簡單的來說,“摘要”就是對傳輸的內容,通過hash算法計算出一段固定長度的串(是不是聯想到了文章摘要)。然後,在通過CA的私鑰對這段摘要進行加密,加密後得到的結果就是“數字簽名”。(這裏提到CA的私鑰,後面再進行介紹)
明文 --> hash運算 --> 摘要 --> 私鑰加密 --> 數字簽名
結合上面內容,我們知道,這段數字簽名只有CA的公鑰才能夠解密。
接下來,我們再來看看神祕的“證書”究竟包含了什麼內容,然後就大致猜到是如何對非法證書進行預防的了。
數字簽名、摘要進一步瞭解可參考 這篇文章。
證書格式
先無恥的貼上一大段內容,證書格式來自這篇不錯的文章《OpenSSL 與 SSL 數字證書概念貼》
內容非常多,這裏我們需要關注的有幾個點:
-
證書包含了頒發證書的機構的名字 -- CA
-
證書內容本身的數字簽名(用CA私鑰加密)
-
證書持有者的公鑰
-
證書籤名用到的hash算法
此外,有一點需要補充下,就是:
-
CA本身有自己的證書,江湖人稱“根證書”。這個“根證書”是用來證明CA的身份的,本質是一份普通的數字證書。
-
瀏覽器通常會內置大多數主流權威CA的根證書。
證書格式-詳細
1. 證書版本號(Version) 版本號指明X.509證書的格式版本,現在的值可以爲:
1) 0: v1
2) 1: v2
3) 2: v3也爲將來的版本進行了預定義
2. 證書序列號(Serial Number) 序列號指定由CA分配給證書的唯一的"數字型標識符"。當證書被取消時,實際上是將此證書的序列號放入由CA簽發的CRL中, 這也是序列號唯一的原因。
3. 簽名算法標識符(Signature Algorithm) 簽名算法標識用來指定由CA簽發證書時所使用的"簽名算法"。算法標識符用來指定CA簽發證書時所使用的:
1) 公開密鑰算法
2) hash算法example: sha256WithRSAEncryption 須向國際知名標準組織(如ISO)註冊
4. 簽發機構名(Issuer) 此域用來標識簽發證書的CA的X.500 DN(DN-Distinguished Name)名字。包括:
1) 國家(C)
2) 省市(ST)
3) 地區(L)
4) 組織機構(O)
5) 單位部門(OU)
6) 通用名(CN)
7) 郵箱地址
5. 有效期(Validity) 指定證書的有效期,包括:
1) 證書開始生效的日期時間
2) 證書失效的日期和時間每次使用證書時,需要檢查證書是否在有效期內。
6. 證書用戶名(Subject) 指定證書持有者的X.500唯一名字。包括:
1) 國家(C)
2) 省市(ST)
3) 地區(L)
4) 組織機構(O)
5) 單位部門(OU)
6) 通用名(CN)
7) 郵箱地址
7. 證書持有者公開密鑰信息(Subject Public Key Info) 證書持有者公開密鑰信息域包含兩個重要信息:
1) 證書持有者的公開密鑰的值
2) 公開密鑰使用的算法標識符。此標識符包含公開密鑰算法和hash算法。
8. 擴展項(extension) X.509 V3證書是在v2的基礎上一標準形式或普通形式增加了擴展項,以使證書能夠附帶額外信息。標準擴展是指 由X.509 V3版本定義的對V2版本增加的具有廣泛應用前景的擴展項,任何人都可以向一些權威機構,如ISO,來 註冊一些其他擴展,如果這些擴展項應用廣泛,也許以後會成爲標準擴展項。
9. 簽發者唯一標識符(Issuer Unique Identifier) 簽發者唯一標識符在第2版加入證書定義中。此域用在當同一個X.500名字用於多個認證機構時,用一比特字符串 來唯一標識簽發者的X.500名字。可選。
10. 證書持有者唯一標識符(Subject Unique Identifier) 持有證書者唯一標識符在第2版的標準中加入X.509證書定義。此域用在當同一個X.500名字用於多個證書持有者時, 用一比特字符串來唯一標識證書持有者的X.500名字。可選。
11. 簽名算法(Signature Algorithm) 證書籤發機構對證書上述內容的簽名算法 example: sha256WithRSAEncryption
12. 簽名值(Issuer's Signature) 證書籤發機構對證書上述內容的簽名值
如何辨別非法證書
上面提到,XX證書包含了如下內容:
-
證書包含了頒發證書的機構的名字 -- CA
-
證書內容本身的數字簽名(用CA私鑰加密)
-
證書持有者的公鑰
-
證書籤名用到的hash算法
瀏覽器內置的CA的根證書包含了如下關鍵內容:
-
CA的公鑰(非常重要!!!)
好了,接下來針對之前提到的兩種非法證書的場景,講解下怎麼識別
完全僞造的證書
這種情況比較簡單,對證書進行檢查:
-
證書頒發的機構是僞造的:瀏覽器不認識,直接認爲是危險證書
-
證書頒發的機構是確實存在的,於是根據CA名,找到對應內置的CA根證書、CA的公鑰。
-
用CA的公鑰,對僞造的證書的摘要進行解密,發現解不了。認爲是危險證書
篡改過的證書
假設代理通過某種途徑,拿到XX的證書,然後將證書的公鑰偷偷修改成自己的,然後喜滋滋的認爲用戶要上鉤了。然而太單純了:
-
檢查證書,根據CA名,找到對應的CA根證書,以及CA的公鑰。
-
用CA的公鑰,對證書的數字簽名進行解密,得到對應的證書摘要AA
-
根據證書籤名使用的hash算法,計算出當前證書的摘要BB
-
對比AA跟BB,發現不一致--> 判定是危險證書
HTTPS握手流程
上面囉囉嗦嗦講了一大通,HTTPS如何確保數據加密傳輸的安全的機制基本都覆蓋到了,太過技術細節的就直接跳過了。
最後還有最後兩個問題:
-
網站是怎麼把證書給到用戶(瀏覽器)的
-
上面提到的對稱密鑰是怎麼協商出來的
上面兩個問題,其實就是HTTPS握手階段要乾的事情。HTTPS的數據傳輸流程整體上跟HTTP是類似的,同樣包含兩個階段:握手、數據傳輸。
-
握手:證書下發,密鑰協商(這個階段都是明文的)
-
數據傳輸:這個階段纔是加密的,用的就是握手階段協商出來的對稱密鑰
附:《SSL/TLS協議運行機制的概述》:http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
本文轉自:APP架構師