有关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”也不用感到疑惑了！