SSL 是 Netscape 所提出來的資料保密協定,採用了 RC4 , MD5 以及 RSA 等加密演算法再加上 CA (Certification Authority) 來確定身份所組成的.
- RC4 為 Symmetric Algorithms 對稱式加密的一種,而所謂的對稱式加密就是加密以及解密都是使用同一支鑰匙 (Single Key)
- MD5 為 One Way Hashes 的一種.他主要會產生一組固定長度字串 (Fingerprint or message digests),這組字串用來比對原資料是否遭到修改.
- RSA 為 Asymmetric (Public Key) Algorithms (非對稱式) 或稱公鑰密碼演算法的一種.而所謂的非對偁式加密會使用兩把公與私鑰 (Public/Private Key), public key 會當成加密用, Private key 就會當解密用
- CA(Certification Authority) 公正的第三者,主要用來驗證公鑰的真假.
note:以上的加解密方式也可以使用不同的其他演算法來取代.如 MD5 可用 SHA1 來取代…. 其他請參考 PKI (Public Key Infrastructure) – https://benjr.tw/310
SSL 交易方式
所謂的 SSL 就是伺服器端和使用者端的資料都經過加密的方式來傳送,而這之鑰匙就是 RC4 (對稱式加密),而這隻鑰匙是無法透過網路來傳送.因為當別人擷取這把鑰匙時,他也可以用這把鑰匙對你們的資訊加解密.
所以會使用 RSA (公私鑰,非對稱式加解密)方式來傳送這把鑰匙.
伺服器端會給使用者端 RSA 公鑰(用來加密使用者端的對稱式加密鑰匙),使用者端產生一支對稱式加密的鑰匙,並使用伺服器端的公鑰加密並回傳給伺服器端,伺服器端使用自己的私鑰解開還原使用者端給的對稱式加密鑰匙,等到伺服器端使用者端都有對稱式加密的鑰匙後,就使用這對稱式加密的鑰匙來進行接下來的資料傳送與交易.
看到這你或許會覺得奇怪,為何不用非對稱式的公鑰來做全程的加解密.因為非對稱加密的演算法很消耗 CPU 的資源所以不適合大量的資料的加解密,但是對稱式的鑰匙卻很適合大量的資料的加解密,但是他無法直接使用網路上來傳送,因為有可能被擷取,所以對稱式鑰匙被非對稱式的公鑰包在一起,傳送到伺服器端,只有伺服器有非對稱式的私鑰能解開.所以能很安全的傳給伺服器.之後的 SSL 連線中都會使用這對稱式的鑰匙加解密.
這樣看似安全其實不然,因為使用者無法確定伺服器端的真假 (經過假的 DNS Server 使用者可能被導向假的伺服器端),所以使用 CA (Certification Authority) 來進行伺服器端的身份確認.因此伺服器端不只會單給 Public key 還會加上數位簽名的憑證.
完整的 HTPS (SSL) 的交易方式.
- 伺服器端會給使用者端 公鑰(用來加密使用者端的對稱式加密鑰匙) 與 數位簽名的憑證(身份確認).
- 使用者端接到數位簽名的憑證,會先去 Root CA 詢問資料是否真的由該網站所核發.
- 使用者端產生一支對稱式加密的鑰匙,並使用伺服器端的公鑰加密並回傳給伺服器端,伺服器端使用自己的私鑰解開還原使用者端給的對稱式加密鑰匙.
- 等到伺服器端使用者端都有對稱式加密的鑰匙後,就使用這對稱式加密的鑰匙來進行接下來的資料傳送與交易.
憑證的內容如下.
[root@localhost ~]# openssl x509 -noout -text -in /etc/ssl/certs/apache-selfsigned.crt Certificate: Data: Version: 1 (0x0) Serial Number: 8b:a9:05:f5:e5:ee:9d:77 Signature Algorithm: sha256WithRSAEncryption Issuer: C=TW, ST=TAIWAN, L=TAIPEI, O=Benjr, OU=Benjr, CN=benjr.tw/emailAddress=admin@benjr.tw Validity Not Before: Aug 27 15:17:57 2019 GMT Not After : Aug 26 15:17:57 2020 GMT Subject: C=TW, ST=TAIWAN, L=TAIPEI, O=Benjr, OU=Benjr, CN=benjr.tw/emailAddress=admin@benjr.tw Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ca:a5:09:02:cc:36:9d:a9:67:3c:f3:4b:38:9b: 略... Exponent: 65537 (0x10001) Signature Algorithm: sha256WithRSAEncryption 9f:b2:e0:b6:1b:f6:ff:0f:3a:b7:1a:62:92:15:9c:e4:d9:2c: 略...
第一部分是憑證的內容包括一些是誰簽發給誰的到期日等資訊.
第二部分是伺服器端的 Public Key
第三部分是上一層 CA 在簽發憑證時,將剛才的內容(第一二部分)經過 on way hash (如:MD5 , SHA1..) 所到的訊息摘要 (Digest Hash).這可確定在傳送過程資料不會遭到修改.
網頁伺服器與瀏覽器 (Web Browser) 之間的 SSL 實際範例
我們先用瀏覽器來看看網頁伺服器加上 SSL 的用戶端是怎麼運作的,先打開瀏覽器去看中國信託的網站 http://www.chinatrust.com.tw/ 並且登入他的網路銀行 ,你會看到如下圖所示:
首先你會看到 http 變成 https ,表示就是 http 使用了 SSL ,而它使用的 port 為 443
你還會看到瀏覽器的右下方多了一個鑰使形狀的東西,把它點兩下,就會完整看到 SSL 的相關訊息
這邊會看到與 CA (Certification Authority)相關的資料.
至於我們的瀏覽器 (Explorer or Mozilla….) 跟網頁伺服器 (IIS or Apache…) 之間是怎麼運作的說明如下:
當使用者上網時要和網頁伺服器以 SSL 進行溝通時,網頁伺服器會給使用者他的公鑰 (這把鑰匙和私鑰為一對,以公鑰的加密的資料只有私鑰能解開).但是此時使用者卻不能確定中國信託的網站真假.因為網站也有可能被假冒,所以要經過公正的第三者 CA (Certification Authority)來確定這網站的真假.
微軟的瀏覽器 IE 預設上就已經幫我們設定了一些公正的 CA (Certification Authority),我們可以透過 IE 的工具 / 網際網路選項 / 內容 / 憑證/ 信任的根憑證授權,如下圖所示:
你會看到好幾個 CA 其中的一個 VeriSign 就是發給中國信託的 CA ,他只檢查數位簽章,經過一番的確認後使用者就會傳送一把對稱式的鑰匙給網頁伺服器,當然這鑰匙也經過網頁伺服器的公鑰加密才傳送出去的.之後的交易都會透過這一把鑰匙的加解密來傳送.
每個環節都必須正確才能讓 SSL 的交易進行下去.其中的 CA 佔有很大的部分.當瀏覽器遇到不認識的網頁公鑰.這時瀏覽器就會讓使用者來決定是否相信這把公鑰的正確性.你會看到如下圖所示: