HTTPS 通俗简介
為什么需要HTTPS
9個問題搞懂 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進行傳輸。
大致如圖所示。
就是這么回事。將數據加密后再傳輸，而不是任由數據在復雜而又充滿危險的網絡上明文裸奔，在很大程度上確保了數據的安全。
這樣的話，即使數據被中間節點截獲，壞人也看不懂。
?
H
?
TTPS是如何加密數據的
?
對安全或密碼學基礎有了解的同學，應該知道常見的加密手段。
一般來說，加密分為對稱加密、非對稱加密（也叫公開密鑰加密）。
?
對稱加密
?
對稱加密的意思就是，加密數據用的密鑰，跟解密數據用的密鑰是一樣的。
對稱加密的優點在于加密、解密效率通常比較高。缺點在于，數據發送方、數據接收方需要協商、共享同一把密鑰，并確保密鑰不泄露給其他人。
此外，對于多個有數據交換需求的個體，兩兩之間需要分配并維護一把密鑰，這個帶來的成本基本是不可接受的。
?
非對稱加密
?
非對稱加密的意思就是，加密數據用的密鑰（公鑰），跟解密數據用的密鑰（私鑰）是不一樣的。
什么叫做公鑰呢？其實就是字面上的意思——公開的密鑰，誰都可以查到。因此非對稱加密也叫做公開密鑰加密。
相對應的，私鑰就是非公開的密鑰，一般是由網站的管理員持有。
?
公鑰、私鑰兩個有什么聯系呢？
?
簡單的說就是，通過公鑰加密的數據，只能通過私鑰解開。通過私鑰加密的數據，只能通過公鑰解開。
很多同學都知道用私鑰能解開公鑰加密的數據，但忽略了一點，私鑰加密的數據，同樣可以用公鑰解密出來。
而這點對于理解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
如何辨別非法證書
上面提到，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/blo...
轉載于:https://www.cnblogs.com/dhsz/p/7680530.html
總結
以上是生活随笔為你收集整理的HTTPS 通俗简介的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 拖拽功能-jquery
- 下一篇： Linux 服务器注意事项