随着网络安全形势越来越严峻,整个互联网界似乎已经达成了共识:那就是尽一切可能提高网站的安全性。安全技术有很多,其中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 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 -connectwww.yahoo.com:443 也可以看到,此次SSL握手协商好的cipher算法是ECDHE-RSA-AES128-GCM-SHA256。好长的名字,一看就安全感倍增啊。 搞清楚了这些,在当前签名算法从SHA1向SHA2升级的日子里,看到浏览器信息里显示证书的“指纹算法为SHA1”也不用感到疑惑了! 另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
本文名称:有关SSL证书的一些事儿-创新互联
浏览路径:http://bjjierui.cn/article/phssd.html