[每日短篇] 24 - HTTPS 和 SSL 自簽名證書的現代知識

今天因故須要測試 SSL 自簽名證書，在翻閱資料時發現中文社區介紹 HTTPS 和 SSL 證書的網帖不只陳舊並且存在很多同源的錯誤，一旦錯誤內容處處都是就容易被人當成正確的，因此寫一篇帖子更新一下現代知識和更正一些錯誤觀點。如今是 2019-11-06，若是好久之後看到這篇帖子，其中與協議版本、密鑰強度相關的內容已通過時了，請注意識別。

關於 HTTPS

• HTTPS 是 HTTP 的擴展，重點解決傳輸安全的問題，之前是 HTTP over SSL，新的是 HTTP over TLS。須要注意的是 HTTPS 解決的是傳輸安全，防範竊聽、中間人攻擊之類的，不解決兩端的安全問題，見過一些系統中試圖用 HTTPS 解決防客戶端破解的問題，其實是沒有任何用處的。
• 通常場景下只有客戶端驗證服務器的證書，客戶端不向服務器提供證書。對安全性要求特別高又高不到須要額外硬件支持的時候，還能夠雙向驗證證書，好比早期的網銀、支付寶會須要申請數字證書，本身下載安裝以後，登陸時須要向服務器提供證書驗證客戶端身份。

關於 SSL 和 TLS

• SSL 和 TLS 也有多個版本，按照 Google、Mozilla、Cloudflare 等大廠的認識，爲現代客戶端提供的服務應該使用 TLSv1.3，爲遠古客戶端提供的服務應該向下支持到 TLSv1，爲不太古老的客戶端提供的服務可使用 TLSv1.2 TLSv1.3。這跟國內情況差異巨大，國內還在大量使用遠古客戶端都不該該支持的 SSLv3，要是用到 TLSv1.3 也常會被抱怨版本過高。
• 密鑰位數如今推薦 2048 位，1024 位的現代瀏覽器都會吐槽不安全。
• SSL 證書有幾種分類方式，其中一種是根據域名格式分的，*.xxx.yyy.zzz 叫作泛域名證書，不包含 xxx.yyy.zzz 自己。
• SSL 證書支持對 IP 簽發，與對域名簽發同樣，簽發以後任意端口可用。
• Cipher 也分強弱，TLSv1.2 裏也有弱密鑰算法，要用 TLSv1.2 的話 Mozilla 推薦 ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384，TLSv1.3 目前看都還行。
• 在 Nginx 裏若是隻用 TLSv1.3 的話，不要添加 ssl_ciphers 指令，即便指定的是 TLSv1.3 的幾個 cipher 也照樣報錯，不寫就沒錯了。若是是同時用幾個版本，也不須要在 ssl_ciphers 裏面寫 TLSv1.3 的 cipher。
• 簽發一個證書不會讓另一個證書失效，在一個新服務器上使用證書也不會讓老服務器上的同一個證書失效。CA 那裏有讓證書失效的機制，第一須要人爲申請，第二須要客戶端知道要到網上查且能到網上查某個證書的有效性，因此這個機制並不老是可以生效。

關於自簽名

• 不少網帖裏面（包括英文帖子）提到自簽名第一步生成私鑰時須要輸入密碼，而且還要第二步去掉密碼，實際上罪魁禍首是命令裏面的 -des3，這個參數的做用是用 DES3 加密私鑰，那不要密碼就怪了。蠻奇怪第一個這麼寫帖子的人在想啥，後面的人抄的時候在想啥。
• 若是沒加 -des3 也要輸入密碼，試試 -nodes 參數，有些系統缺省參數不同，可能須要顯式禁用加密私鑰。
• 自簽名密鑰也記得改 2048，強度跟是否受信是兩碼事。
• 訪問自簽名網址時注意看瀏覽器的風險提示，是這個證書是自簽名的仍是這個證書跟域名不匹配，提示是自簽名的服務器就配置對了，否則就還得繼續改。