HTTPS连接的前几毫秒发生了什么

　　这里应该是软件的用词不当，因为这一段实际上是指那些即将被签名的信息，而不是指那些已经包含了签名的信息。

　　实际上经过签名的信息S，在Wireshark中被称之为“encrypted”(密文)。我们将S的e次幂除以n取余数(即公式： )就能计算出被加密的原文，其十六进制如下：

　　0001FFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFF00302130 0906052B0E03021A05000414C19F8786 871775C60EFE0542 E4C2167C830539DB

　　根据PKCS#1 v1.5标准(译者注：The Public-Key Cryptography Standards (PKCS)是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准)规定：“第一个字节是00，这样就可以保证加密块在被转换为整数的时候比其加密参数要小。”第二个字节为01，表示了这是一个私有密钥操作(数字签名就是私有密钥操作的一种)。后面紧接着的一连串的FF字节是为了填充数据，使得这一串数字变得足够大(加大黑客恶意破jie的难度)。填充数字以一个00字节结束。紧接着的30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14这些字节是PKCS#1 v2.1标准中用于说明这段哈希值是通过SHA-1算法计算而出的。最后的20字节是SHA-1算法所计算出来的哈希值，即对未加密信息的摘要描述。(译者注：原文中这里使用了带引号的signedCertificate，根据作者前文描述，这应该是Wireshark软件的bug，实际上应指的是未被加密的信息。)

　　因为这段信息的格式正确，且最后的哈希值与我们独立计算出来的校验一致，所以我们可以断定，这一定是知道“VeriSign Class 3 Secure Server CA”的解密密钥d的人对它进行了签名。而世界上只有VeriSign公司才知道这串密钥。

　　当然了，我们也可以重复验证这个“VeriSign Class 3 Secure Server CA”的证书的确是通过VeriSign公司的“第三类公私证书认证(Class 3 Public Primary Certification Authority)”进行签名的。

　　但是，即便是这样，我们为什么要信任VeriSign公司?整个的信任链条就此断掉了。

　　由图可以看到，“VeriSign Class 3 Secure Server CA”对Amazon.com进行了签名，而“VeriSign Class 3 Public Primary Certification Authority”对“VeriSign Class 3 Secure Server CA”进行了签名，但是最顶部的“VeriSign Class 3 Public Primary Certification Authority”则对自己进行了签名。这是因为，这个证书自从NSS(网络安全服务)库中的certdata.txt 升级到1.4版之后就作为“受信任的根证书颁发机构”(译者注：参照微软官方翻译)被编译到了Mozilla产品中(火狐浏览器)。这段信息是由网景公司的Robert Relyea于2000年9月6日提交的，并随附以下注释：

　　“由仅存的NSS编译了框架。包含一个在线的certdata.txt文档，其中包含了我们受信的跟证书颁发机构(一旦我们获得了其他受信机构的许可会陆续将他们添加进去)”。

　　这个举动有着相当长远的影响，因为这些证书的有效日期是从1996年1月28日到2028年1月1日。

　　肯·汤普逊(Ken Thompson)在他的《对深信不疑的信任》(译者注：Reflections on Trusting Trust是肯汤普逊1983年获得图灵奖时的演说)的演说中解释的很好：你最终还是要绝对信任某一人，在这个问题上没有第二条路可走。在本文的例子中，我们就毫无保留的信任Robert Relyea做了一个正确的决定。我们同样希望Mozilla在自己软件中加入“受信任根证书颁发机构”这种行为也是合理的吧。

　　这里需要注意的是：这一系列的证书和签名只是用来形成一个信任链。在公共互联网上，VeriSign的根证书被火狐浏览器完全信任的时间远早于你接触互联网。在一个公司中，你可以创建自己的受信任的根证书颁发机构并把它安装到任何人的计算机中。

　　相对的，你也可以购买VeriSign公司的业务，降低整个证书信任链的信任风险。通过第三方的认证机构(在这个例子里是VeriSign公司)我们能利用证书建立起信任关系。如果你有类似于“悄悄话”的安全途径来传递一个秘密的key，那你也可以使用一个预共享密钥(PSK)来建立起信任关系。诸如TLS-PSK、或者带有安全远程密码(SRP)的TLS扩展包都能让我们使用预共享密钥。不行的是，这些扩展包在应用和支持方面远远比不上TLS，所以他们有的时候并不实用。另外，这些替代选项需要额外德尔安全途径进行保密信息的传输，这一部分的开销远比我们现在正在应用的TLS庞大。换句话说，这也就是我们为什么不应用那些其他途径构建信任关系的原因。

　　言归正传，我们所需要的最后确认的信息就是在证书上的主机名跟我们预想的是一样的。Nelson Bolyard在SSL_AuthCertificate 函数中的注释为我们解释其中的原因：

　　“SSL连接的客户端确认证书正确，并检查证书中所对应的主机名是否正确，因为这是我们应对中间人攻击的唯一方式!” (译者注：中间人攻击是一种“间接”的入qin攻击，这种攻击模式是通过各种技术手段将受入qin者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间，这台计算机就称为“中间人”。)

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]  下一页