SSL基础

SSL 的工作方式可以通过一个典型方案得到最好的说明，在本示例中，该方案为银行的网站。该网站允许客户使用用户名和密码登录。在经过身份验证之后，用户可以执行事务，例如查看帐户余额、支付帐单以及将钱从一个帐户转到其他帐户。

当用户第一次访问该网站时，SSL 机制启动一系列与用户客户端（在此情况下为 Internet Explorer）的协商，称为“握手”。SSL 首先向客户证明银行网站的身份。这一步骤是必需的，因为客户首先必须知道他们正在与真实网站进行通信，而不是与一个试图引诱他们键入自己的用户名和密码的诈骗网站进行通信。SSL 通过使用由受信任的颁发机构（例如 VeriSign）提供的 SSL 证书来执行此身份验证。其逻辑如下：VeriSign 担保该银行网站的身份是真实的。由于 Internet Explorer 信任 VeriSign，因此也信任该网站。如果您希望向 VeriSign 进行核实，可以通过单击 VeriSign 徽标执行此操作。这将显示一份含有到期日期以及接受方（银行网站）的真实性声明。

若要启动一个安全会话，客户端向服务器发送一个等效于“你好”的项，连同一个它可以用来签名、生成哈希以及进行加密和解密的加密算法列表。作为响应，该网站发送回一个确认以及它对算法组之一的选择。在该初次握手期间，双方都发送和接收 Nonce。“Nonce”是一段随机生成的数据，该数据与网站的公钥一起使用以创建哈希。“哈希”是使用某种标准算法（例如 SHA1）从两个数得到的一个新数。 （客户端和网站还交换消息以协商要使用的哈希算法。）哈希是唯一的，并且仅在客户端和网站之间的会话中使用以便对消息进行加密和解密。客户端和服务都具有原始 Nonce 和证书的公钥，所以通信两端可以生成同一个哈希。因此，客户端可以通过以下方式验证服务所发送的哈希：(a) 使用商定的算法根据数据计算哈希；并 (b) 将计算出的哈希与服务所发送的哈希进行比较。如果二者匹配，则客户端可以确信该哈希未遭篡改。客户端随后可以将此哈希用作密钥，以便对同时包含另一个新哈希的消息进行加密。服务可以使用此哈希对消息进行解密，并重新获得倒数第二个哈希。 这样，通信双方就都获知累积的信息（Nonce、公钥和其他数据），并且可以创建最后一个哈希（也称主密钥）。这个最终的密钥使用倒数第二个哈希加密后发送。然后，使用主密钥对用来重置会话的消息进行加密和解密。由于客户端和服务都使用同一密钥，因此该密钥又称为“会话密钥”。

会话密钥还被描述为对称密钥，或“共享秘密”。具有对称密钥很重要，因为它减少了事务双方所需执行的计算量。如果每个消息都要求对 Nonce 和哈希进行新的交换，那么性能将会下降。因此，SSL 的最终目标是使用允许消息在通信双方之间自由流动的对称密钥，同时具有更高程度的安全和效率。

因为协议可能因网站而异，所以前面的描述只是所发生过程的简化版本。还有一种可能，就是客户端和网站都在握手期间生成在算法上相结合的 Nonce，以增加数据交换过程的复杂性，从而为该过程提供更多的保护。

证书和公钥基础结构

在握手期间，服务还将其 SSL 证书发送到客户端。该证书包含一些信息，例如证书的到期日期、颁发机构以及网站的统一资源标识符 (URI)。客户端将该 URI 与它原来联系的 URI 进行比较，以确保二者匹配，并且对日期和颁发机构进行检查。

每个证书都具有两个密钥：一个私钥和一个公钥，并且这两个密钥称为一个“交换密钥对”。简言之，只有证书的所有者知道私钥，而公钥则可以从证书中读取。这两个密钥都可用来加密和解密摘要、哈希或其他密钥，但它们只能用于相反的操作。例如，如果客户端使用公钥加密，则只有网站可以使用私钥对消息进行解密。同样，如果网站使用私钥加密，则客户端可以使用公钥解密。 这可以使客户端确信只与私钥的拥有者交换消息，因为只有使用私钥加密的消息才可以使用公钥进行解密。而网站可以确信它正在与已经使用公钥加密的客户端交换消息。然而，这种交换仅对初次握手是安全的，因此在创建实际的对称密钥时要复杂得多。尽管如此，所有通信都依赖于服务具有有效的 SSL 证书。

双向认证 SSL 协议的具体过程
　　① 浏览器发送一个连接请求给安全服务器。 

　　② 服务器将自己的证书，以及同证书相关的信息发送给客户浏览器。 

　　③ 客户浏览器检查服务器送过来的证书是否是由自己信赖的 CA 中心所签发的。如果是，就继续执行协议；如果不是，客户浏览器就给客户一个警告消息：警告客户这个证书不是可以信赖的，询问客户是否需要继续。

　　④ 接着客户浏览器比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户浏览器认可这个服务器的合法身份。 

　　⑤ 服务器要求客户发送客户自己的证书。收到后，服务器验证客户的证书，如果没有通过验证，拒绝连接；如果通过验证，服务器获得用户的公钥。 

　　⑥ 客户浏览器告诉服务器自己所能够支持的通讯对称密码方案。

　　⑦ 服务器从客户发送过来的密码方案中，选择一种加密程度最高的密码方案，用客户的公钥加过密后通知浏览器。

　　⑧ 浏览器针对这个密码方案，选择一个通话密钥，接着用服务器的公钥加过密后发送给服务器。

　　⑨ 服务器接收到浏览器送过来的消息，用自己的私钥解密，获得通话密钥。 

　　⑩ 服务器、浏览器接下来的通讯都是用对称密码方案，对称密钥是加过密的。 

　　上面所述的是双向认证 SSL 协议的具体通讯过程，这种情况要求服务器和用户双方都有证书。单向认证 SSL 协议不需要客户拥有 CA 证书，具体的过程相对于上面的步骤，只需将服务器端验证客户证书的过程去掉，以及在协商对称密码方案，对称通话密钥时，服务器发送给客户的是没有加过密的（这并不影响 SSL 过程的安全性）密码方案。这样，双方具体的通讯内容，就是加过密的数据，如果有第三方攻击，获得的只是加密的数据，第三方要获得有用的信息，就需要对加密的数据进行解密，这时候的安全就依赖于密码方案的安全。而幸运的是，目前所用的密码方案，只要通讯密钥长度足够的长，就足够的安全。这也是我们强调要求使用 128 位加密通讯的原因。

转自：https://msdn.microsoft.com/zh-cn/library/ms734679.aspx