白話說https執行原理

wish發表於2020-11-29
HTTP
系列文章：
技術面試應該問些什麼？應聘者應該如何應對？ 白話說https執行原理

https到底是什麼？是怎麼運作的呢？

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層。

白話說https執行原理

在很久很久以前，那時候還沒有https，大家還都很講武德，自從馬保國退出武林之後，武林開始動盪了起來，一切變得不安全了。
此時，http的傳輸安全成為了當務之急必須處理的一個問題。

那麼，該怎麼解決呢？

聰明如我的你一定會想到，資料加密啊。不錯。這就是https演化的第一步。

白話說https執行原理

此種方式屬於對稱加密，雙方擁有相同的金鑰，資訊得到安全傳輸，但此種方式的缺點是：
（1）不同的客戶端、伺服器數量龐大，所以雙方都需要維護大量的金鑰，維護成本很高
（2）因每個客戶端、伺服器的安全級別不同，金鑰極易洩露

第二步：既然使用對稱加密時，金鑰維護這麼繁瑣，那我們就用非對稱加密試試。

如上圖所示，客戶端用公鑰對請求內容加密，伺服器使用私鑰對內容解密，反之亦然，但上述過程也存在缺點：

（1）公鑰是公開的（也就是黑客也會有公鑰），所以第 ④ 步私鑰加密的資訊，如果被黑客截獲，其可以使用公鑰進行解密，獲取其中的內容。

第三步：非對稱加密既然也有缺陷，那我們就將對稱加密，非對稱加密兩者結合起來，取其精華、去其糟粕，發揮兩者的各自的優勢。

如上圖所示

（1）第 ③ 步時，客戶端說：（我們們後續回話採用對稱加密吧，這是對稱加密的演算法和對稱金鑰）這段話用公鑰進行加密，然後傳給伺服器。

（2）伺服器收到資訊後，用私鑰解密，提取出對稱加密演算法和對稱金鑰後，伺服器說：（好的）對稱金鑰加密。

（3）後續兩者之間資訊的傳輸就可以使用對稱加密的方式了。

遇到的問題：

（1）客戶端如何獲得公鑰

（2）如何確認伺服器是真實的而不是黑客

第四步：獲取公鑰與確認伺服器身份

1、獲取公鑰

（1）提供一個下載公鑰的地址，回話前讓客戶端去下載。（缺點：下載地址有可能是假的；客戶端每次在回話前都先去下載公鑰也很麻煩）

（2）回話開始時，伺服器把公鑰發給客戶端（缺點：黑客冒充伺服器，傳送給客戶端假的公鑰）

2、那有木有一種方式既可以安全的獲取公鑰，又能防止黑客冒充呢？ 那就需要用到終極武器了：SSL證照。

如上圖所示，在第 ② 步時伺服器傳送了一個SSL證照給客戶端，SSL 證照中包含的具體內容有：

（1）證照的釋出機構CA
（2）證照的有效期
（3）公鑰
（4）證照所有者
（5）簽名
………

3、客戶端在接受到服務端發來的SSL證照時，會對證照的真偽進行校驗，以瀏覽器為例說明如下：

（1）首先瀏覽器讀取證照中的證照所有者、有效期等資訊進行一一校驗

（2）瀏覽器開始查詢作業系統中已內建的受信任的證照釋出機構CA，與伺服器發來的證照中的頒發者CA比對，用於校驗證照是否為合法機構頒發

（3）如果找不到，瀏覽器就會報錯，說明伺服器發來的證照是不可信任的。

（4）如果找到，那麼瀏覽器就會從作業系統中取出頒發者CA 的公鑰，然後對伺服器發來的證照裡面的簽名進行解密

（5）瀏覽器使用相同的hash演算法計算出伺服器發來的證照的hash值，將這個計算的hash值與證照中籤名做對比

（6）對比結果一致，則證明伺服器發來的證照合法，沒有被冒充

（7）此時瀏覽器就可以讀取證照中的公鑰，用於後續加密了

4、所以通過傳送SSL證照的形式，既解決了公鑰獲取問題，又解決了黑客冒充問題，一箭雙鵰，HTTPS加密過程也就此形成。

所以相比HTTP，HTTPS 傳輸更加安全

（1） 所有資訊都是加密傳播，黑客無法竊聽。

（2） 具有校驗機制，一旦被篡改，通訊雙方會立刻發現。

（3） 配備身份證照，防止身份被冒充。

也推薦看看下面這兩篇文章：
www.sohu.com/a/320031789_371153
www.kuacg.com/22672.html

問題1: SSL/TLS又是啥？

SSL（Secure Socket Layer，安全套接字層）：1994年為 Netscape 所研發，SSL 協議位於 TCP/IP 協議與各種應用層協議之間，為資料通訊提供安全支援。

TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL，它最初的幾個版本（SSL 1.0、SSL 2.0、SSL 3.0）由網景公司開發，1999年從 3.1 開始被 IETF 標準化並改名，發展至今已經有 TLS 1.0、TLS 1.1、TLS 1.2 三個版本。SSL3.0和TLS1.0由於存在安全漏洞，已經很少被使用到。TLS 1.3 改動會比較大，目前正在推進中，目前使用最廣泛的是TLS 1.1、TLS 1.2。

問題2：加密演算法有哪些？

1、對稱加密

有流式、分組兩種，加密和解密都是使用的同一個金鑰。
例如：DES、AES-GCM、ChaCha20-Poly1305等

2、非對稱加密

加密使用的金鑰和解密使用的金鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和演算法都是公開的，私鑰是保密的。非對稱加密演算法效能較低，但是安全性超強，由於其加密特性，非對稱加密演算法能加密的資料長度也是有限的。
例如：RSA、DSA、ECDSA、 DH、ECDHE

3、雜湊演算法

將任意長度的資訊轉換為較短的固定長度的值，通常其長度要比資訊小得多，且演算法不可逆。
例如：MD5、SHA-1、SHA-2、SHA-256 等

4、數字簽名

簽名就是在資訊的後面再加上一段內容（資訊經過hash後的值），可以證明資訊沒有被修改過。hash值一般都會加密後（也就是簽名）再和資訊一起傳送，以保證這個hash值不被修改。

問題3：中間人能否通過第三方公鑰拿到伺服器公鑰，進而破解對稱祕鑰？

我感覺好像能，但無法篡改。因為中間人也你能拿到證照機構的公鑰，然後解密出伺服器公鑰，最後通過伺服器公鑰解密隨機生成的對稱祕鑰，然後不是檢視到加密資料了嗎？貌似一些抓包工具信任他們的證照後就可以解密出加密資料。但如果這樣的了，就防止不了竊聽了。我哪裡理解錯了嗎？請高手指教一下！

問題4：中間人能否篡改伺服器證照？

不能，因為證照是通過證照機構私鑰加密的，要篡改證照必須要拿到證照機構的私鑰，這是不可能的。

openssl生成證照

在大部分開發除錯過程中，我們需要本地除錯https的頁面時候，我們需要在本地擁有證照，而openssl就是就是這樣一個整合工具；通過使用openssl來完成本地除錯https的請求。

  1. openssl簡介
  2. 自簽名證照
  3. 本地私有CA證照

openssl的簡介

OpenSSL 是一個開源專案，其組成主要包括一下三個元件：

  1. openssl：多用途的命令列工具
  2. libcrypto：加密演算法庫
  3. libssl：加密模組應用庫，實現了ssl及tls

openssl可以實現：祕鑰證照管理、對稱加密和非對稱加密更多簡介和官網和openssl簡介。

自簽名證照

為了能夠把線上的https的請求，走向本地，需要我們本地也有https服務，那麼證照就是不可避免的，然而一般情況我們並不是使用線上的證照，因為走本地需要本地啟用服務，如果證照使用線上的，那麼本地起服務的話就需要線上的私鑰等隱私資訊，這很容易導致私鑰洩露，所以不安全，那麼我們就需要生成一個本地的證照；

前文講過了，一個證照是需要經過CA機構進行認證簽名的，那麼我們本地測試使用的證照然道也要去申請認證嗎？但是否定的，因為這個這是隻是我們本地使用，所以只需要我們有證照，並且手動新增信任就行，那麼自簽名證照就很好的解決了這個問題。

自簽名證照：跟多詳細介紹，自簽名證照的核心就是自己對自己的申請進行簽名【CA根證照就是這樣產生的】；使用自己的私鑰對自身生成的證照申請CSR進行簽名得出的證照。

通過自簽名證照我們獲得了https服務需要的證照，根據本地不同的環境，都需要對該證照進行一個信任，這樣我們本地起的https服務才會被瀏覽器正確的識別。整個過程如下：

  1. 生成祕鑰

    openssl genrsa -des3 -out cwj.key 2048

    使用以上命令，來生成一個我們本地需要的私鑰，後面需要使用私鑰來生成證照申請CSR以及對證照申請CSR使用私鑰進行自簽名

  2. 生成證照申請CSR

    openssl req -new -key cwj.key -out cwj.csr

    需要填寫一系列資訊，包括地點、單位、域名、email之類的，這裡會自動使生產與服務端私鑰匹配的公鑰，CSR中包含了公鑰；

  3. 使用私鑰完成自簽名，生成完整的證照

    openssl x509 -req -sha256 -days 3650 -in cwj.csr -signkey cwj.key -out cwj.crt

    使用前生產的祕鑰對證照申請CSR進行信任簽名，得到完整的證照；

這樣的確滿足了部分需求，只需要使用該證照和私鑰來啟動https服務，同時本地信任這個證照就大功告成了，其中優點如下：

  1. 本地自簽名，無須CA根證照；
  2. 過程簡單

不過也存在一些弊端：

  1. 該證照無法被吊銷，私鑰需要儲存好，不過對於僅用於本地除錯來說就無傷大雅；
  2. 多域名需要多個證照，需要根據域名生成多個證照，客服端需要分別信任這些證照。【不過openssl也可以生成多域名證照，一個證照可以供多個域名使用，一般使用openssl.cnf配置檔案來生成】

所以還存在其他的方法：為了模擬完整的真是的https服務，我們可以在本地生成一個類似CA根證照，通過CA的私鑰來對其他的所有的本地證照進行簽名，只有信任了本地的CA根證照，那麼他簽名的證照都會被信任，這樣就是下面文提到的進化方法本地私有CA根證照。

本地私有CA根證照偽CA根證照

這個方法的整體流程就是本地生成一個CA證照，就類似CA機構的存在，【暫且稱為偽CA根證照】通過偽CA根證照的私鑰來對其他的所有的本地證照進行簽名，我們本地信任了這個偽CA根證照，那麼通過偽CA根證照簽名的證照都會被信任。避免了多個域名需要生成多個自簽名證照以及要進行分別信任的複雜行為。

  1. 偽CA根證照生成並新增信任

    openssl genrsa -des3 -out ca.key 2048
openssl req -new -key ca.key -out ca.csr
openssl x509 -req -sha256 -days 3650 -in ca.csr -signkey ca.key -out ca.crt

    可以看到，其實ca根證照就是一個自簽名證照的例子；

  2. 本地單一域名證照祕鑰、申請CSR

    openssl genrsa -des3 -out cwj.key 2048
openssl req -new -key cwj.key -out cwj.csr

    生成一個證照請求；

  3. 偽CA根證照的私鑰簽名其他的申請CSR

    openssl x509 -req -sha256 -days 3650 -in cwj.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out cwj.crt

更多內容openssl;這樣證照的問題就解決了，視情況來看使用者是採用哪種方案來生成證照。

信任證照需要一些操作，不同系統有不同的過程，MAC是在鑰匙串中信任，windows是需要匯入證照；

nginx部署https實踐

本地啟動https服務的方式很多，這裡就說一說nginx；nginx官網https模組，主要用到的就是私鑰和證照；根據之前提到的使用不同方法生成的證照以及伺服器私鑰【本地CA根證照也需要本地進行信任】。

server {
        listen       443 ssl;
        server_name  cwj.cc;

        ssl_certificate      /cwjhttps/cwj.crt;
        ssl_certificate_key  /cwjhttps/cwj.key;

        ssl_session_cache    shared:SSL:1m;
        ssl_session_timeout  5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        location / {
            root   /cwjhttps;
            index  home.html index.htm test.html;
        }
    }

以上內容整理自網路，如有侵權請告知刪除。

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章