有關SSL證書的一些事兒

    隨著網絡安全形勢越來越嚴峻，整個互聯網界似乎已經達成了共識：那就是盡一切可能提高網站的安全性。安全技術有很多，其中SSL/TLS非對稱加密技術及對應的PKI公鑰架構體系又是最重要的技術之一。由于其技術分支較為復雜，這里僅就幾個知識點做一下展開，以期幫助讀者更好的理解SSL。

    術語：SSL、TLS、HTTPS三者，盡管確切含義各不相同，但它們作為非對稱加密技術的代表術語，很多語境下都可以互相替換。

    給網站申請https證書的過程是怎樣的？

    在展開這個題目之前，先回顧一下PKI架構。user, server, CA，這三者是PKI中的三個角色。user方接收到server發出的證書，并通過user自身客戶端（瀏覽器或者其他APP等程序）內含的已信任CA（根證書）列表來做校驗，只有證實該server提供的https證書是已信任CA簽發的，https通信才可以繼續。

    所以我們的https證書必須是主流CA簽發的才行。為什么強調“主流”？因為不同瀏覽器使用的已信任CA列表可能是不盡相同的。IE，firefox，chrome，都帶有自己的根證書集合。大型電子商務網站必然使用最為知名的CA機構，例如verisign (已被symantec收購）、enTrust等等。

    申請證書時候，需要給CA機構提供證書簽發申請CSR文件(certificate sigining request)。大部分支持https的web服務程序都可以生成CSR文件。步驟如下：

    1. 根據RSA算法生成公鑰私鑰對。私鑰即需要機密保管的以.key為后綴名的文件，公鑰則在.csr文件中。csr文件中還包括生成CSR過程中輸入的組織名、域名、聯系人郵箱等信息。

    2. 發送CSR文件給證書供應商，比如verisign。供應商對CSR文件做處理，設置有效期限等，并做最為關鍵的動作：用供應商自己的私鑰對證書進行簽名。這樣就生成了一張有效的SSL證書。

    3. 用戶收到證書后，在web服務器（或負載均衡等設備）上，以此前的私鑰文件和收到的公鑰證書為密鑰對，生成SSL配置文件，并綁定到對應的web站點上。

    客戶端是怎么驗證https證書并確保加密通信是安全的呢？

    以web訪問為例：

    1. 客戶啟動瀏覽器程序，訪問某個https加密站點。

    2. 瀏覽器嘗試SSL握手，發送自身支持的各類加密算法的列表，同時從站點獲得對方的支持算法列表及該站點的證書。

    3. 瀏覽器讀取證書的數字簽名部分，用自身根證書列表中對應的公鑰證書對其進行解密。如果解密成功，并且證書哈希值與簽名內的哈希值匹配一致，可證明站點提供的證書確實是該CA根證書簽發的。此所謂“不可抵賴性”（non-repudiation)。

    由于瀏覽器自身的根證書是隨著瀏覽器程序安裝而默認獲得的，所以其安全性就取決于瀏覽器提供商的安全監管機制。難怪google等公司會嚴格監控internet上可能出現的CA舞弊行為。具體案例請見下一小節。

    中級(intermediate)證書是怎么回事？

    SSL支持證書鏈，所以可以從一張根證書簽發一張中級證書（可能繼續簽發第二、第三級中級證書），最后到終端證書。這主要有以下幾個方面的考慮：

    1. 擴展性：根據不同的服務級別，使用不同的中級證書的私鑰簽發終端證書。

    2. 風險隔離：任一張中級證書的私鑰被盜，可以立即吊銷(revoke)這張中級證書，而其他中級證書可以保持安全性不受影響。

    3. 商業授權：根證書廠商簽發中級證書給二級證書廠商（即授權），二級廠商可以簽發終端證書給自己的客戶。這里面存在安全監管的問題。去年和今年陸續出現了法國信息系統安全局（ANSSI）和中國CNNIC授權的中級證書廠商惡意（自稱“無意”）簽發了google域名的證書的重大安全事件。 

    ANSSI的事件，據其自稱是“使用不當，用自己運營的公網CA根證書對內部私網環境簽發了google域名的證書給內部測試使用”。但顯然這種辯解是站不住腳的。這張證書是否能用在公網上，完全只取決于用哪張CA根證書簽發。用了公網CA根證書（即屬于瀏覽器默認配置的根證書集）做簽發，則必定可以在公網上使用。只要建立一個釣魚站點綁定這張舞弊證書，再加上DNS劫持（這個很容易做到），用戶的google加密信息全部可以被盜取。真的很怕怕。怪不得微軟、谷歌等公司迅速通過各種途徑吊銷（revoke）了這張舞弊證書。

    CNNIC事件也是類似。其簽發了一張中級證書給埃及一家公司，后者違規簽發了google.com域名的證書。由于SSL證書鏈的設計，只要信任了CNNIC根證書的用戶，也隨之會信任這張埃及公司的舞弊證書。當然了，CNNIC也隨之被chrome等瀏覽器開除了。

    小伙伴們，中級證書的重要性不亞于根證書啊。

    中級證書示例：

    此外，還要提一下EV(extended validation)證書。這也是一種中級證書，并且從瀏覽器表現上顯得更”安全“一些。以chrome瀏覽器為例，使用EV證書的站點，它的站點名左側的安全圖標是綠色帶框的，跟普通的中級證書簽發的站點（綠色不帶框）略有不同。算法上EV跟其他中級證書完全一致。能否體現“更安全”的圖標，也取決于瀏覽器的支持。可以理解為網站購買了CA供應商的VIP服務，并不表示證書一定在算法上更安全。算法安全性方面的問題，客官請往下看。

    為什么我升級了SSL證書到SHA256算法，但瀏覽器里還是顯示SHA1？

    -- 證書算法安全性與站點的SSL/TLS算法安全性的區別

    加密算法流派眾多，確實很容易混淆。即使有一定經驗的IT工程師依然會分不清哪些算法是證書提供的，哪些是站點本身提供的。

    RSA：證書提供。非對稱加密算法。SSL證書大部分使用此算法生成公鑰私鑰對。用于對SSL/TLS會話中的對稱秘鑰進行加密/解密。RSA2048bit算法很安全，目前不需要升級或替換。

    MD5/SHA1/SHA2：證書提供。散列/哈希/摘要算法。用于驗證簽名真實性。按安全性來排序，MD5<SHA1<SHA2。由于SHA1可能近年內就被破解（或者已經破解但未有公開報告），各大瀏覽器廠商已經要求CA機構和互聯網公司盡快升級到SHA2簽名證書。此外還有一個很接近的fingerprint指紋算法（一般使用SHA1），這個是客戶端瀏覽器對證書整體做的摘要算法，用于瀏覽器內部證書管理，跟簽名算法無關。

    DES/AES：站點提供。對稱加密算法。用于實際的數據加密傳輸。對稱算法的秘鑰一般稱為cipher，以顯示跟口令(password)、私鑰(private key)的區別。展開來說，對稱加密算法在SSL/TLS里實現的時候還是很復雜的，一般可能的cipher算法有（僅舉幾例）：

    SSL3-DES-CBC3-SHA    #SSL3協議，DES對稱加密使用CBC3塊加密模式（另一種是流加密），SHA摘要算法

    TLS1-AES-128-CBC-SHA   #TLS1協議，AES對稱加密使用CBC塊加密模式，SHA摘要算法

    具體使用何種對稱加密算法，取決于SSL握手時候的協商結果。

    SSL加密傳輸過程中，非對稱秘鑰用于對“對稱秘鑰”的加密，而信息本身用對稱秘鑰進行加密。這是因為：

    對稱加密：計算資源消耗低，但秘鑰無法安全傳輸

    非對稱加密：計算資源消耗高，但秘鑰可以安全傳輸

    所以為了折中這對矛盾，SSL/TLS采用了現在的方案：用非對稱加密來傳輸對稱秘鑰，用對稱秘鑰對數據進行加密。這就平衡了安全性和計算資源消耗性的這對蹺蹺板。

    怎樣查看SSL證書的詳細信息？

    除了用瀏覽器本身的圖形化界面方式查看信息，還可以用openssl命令工具查看更多內容。以雅虎網站為例。查看其證書信息的命令：

    openssl s_client -connect www.yahoo.com:443 | openssl x509 -text

    在上面的輸出中，我們看到其簽名算法是SHA1，公鑰加密算法是RSA。公鑰長度是2048位，這個也是目前推薦的秘鑰長度。托摩爾定律的福，計算機性能不斷飛速發展，以前（當然也包括現在）在用的1024位的RSA秘鑰已經不×××全了。各大瀏覽器即將在2015年停止支持1024位RSA證書。而CA廠商方面，這兩年已經停止簽發RSA1024位的證書。

    查看SSL握手信息（比如cipher協商結果），可以直接運行：

    openssl s_client -connect www.yahoo.com:443  

    也可以看到，此次SSL握手協商好的cipher算法是ECDHE-RSA-AES128-GCM-SHA256。好長的名字，一看就安全感倍增啊。

   搞清楚了這些，在當前簽名算法從SHA1向SHA2升級的日子里，看到瀏覽器信息里顯示證書的“指紋算法為SHA1”也不用感到疑惑了！