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

　　/* cert is OK. This is the client side of an SSL connection.

　　* Now check the name field in the cert against the desired hostname.

　　* NB: This is our only defense against Man-In-The-Middle (MITM) attacks! */

　　这样的检查是为了防止中间人攻击：因为我们对整个信任链条上的人都采取了完全信任的态度，认为他们并不会进行黑客行为，就像我们的证书中所声称它是来自Amazon.com，但是假如他的真实来源并非Amazon.com，那我们可能就有被攻击的危险。如果攻击者使用域名污染(DNS cache poisoning)等技术对你的DNS服务器进行篡改，那么你也许会把黑客的网站误认为是一个安全的受信网站(诸如Amazon.com)，因为地址栏显示的信息一切正常。这最后一步对证书颁发机构的检查就是为了防止这样的事情发生。

　　随机密码串(Pre-Master Secret)

　　现在我们已经了解了Amazon.com的各项要求，并且知道了公共解密密钥e和参数n。在通信过程中的任何一方也都知道了这些信息(佐证就是我们通过Wireshark获得了这些信息)。现在我们所需要做的事情就是生成一串窃密者/攻击者都不能知道的随机密码。这并不像听上去的那么简单。早在1996年，研究人员就发现了网景浏览器1.1的伪随机数发生器仅仅利用了三个参数：当天的时间，进程ID和父进程ID。正如研究人员所指出的问题：这些用于生成随机数的参数并不具有随机性，而且他们相对来说比较容易被破jie。

　　因为一切都是来源于这三个随机数参数，所以在1996，利用当时的机器仅需要25秒钟的时间就可以破jie一个SSL通信。找到一种生成真正随机数的方法是非常困难的，如果你不相信这一点，那就去问问Debian OpenSSL的维护工程师吧。如果随机数的生成方式遭到破jie，那么建立在这之上的一系列安全措施都是毫无意义的。

　　在Windows操作系统中，用于加密目的随机数都是利用一个叫做CryptGenRandom的函数生成的。这个函数的哈希表位对超过125个来源的数据进行抽样!火狐浏览器利用CryptGenRandom函数和它自身的函数来构成它自己的伪随机数发生器。(译者注：之所以称之为伪随机数是因为真正意义上的随机数算法并不存在，这些函数还是利用大量的时变、量变参数来通过复杂的运算生成相对意义上的随机数，但是这些数之间还是存在统计学规律的，只是想要找到生成随机数的过程并不那么容易)。

　　我们并不会直接利用生成的这48字节的随机密码串，但是由于很多重要的信息都是由他计算而来的，所以对随机密码串的保密就显得格外重要。正如我之前所预料到的，火狐浏览器对随机密码串的保密十分严格，所以我不得不编译了一个用于debug的版本。为了观察随机密码串，我还特地设置了SSLDEBUGFILE和SSLTRACE两个环境变量。

　　其中，SSLDEBUGFILE显示的就是随机密码串的值：