说完身份认证的方式/原理，再回到 SSL/TLS 的话题上。 对于 SSL/TLS 的应用场景，由于双方（“浏览器”和“网站服务器”）通常都是互不相识的，显然不可能采用第一种方式（私密的共享信息），而只能采用第二种方式（依赖双方都信任的“公证人”）。 那么，谁来充当这个公证人捏？这时候，CA 就华丽地登场啦。 所谓的 CA，就是“数字证书认证机构”的缩写，洋文全称叫做“Certificate Authority”。关于 CA 以及 CA 颁发的“CA 证书”，俺已经写过一篇教程：《数字证书及CA的扫盲介绍》，介绍其基本概念和功能。所以，此处就不再重复唠叨了。 如果你看完那篇 CA 的扫盲，你自然就明白——CA 完全有资格和能力，充当这个“公证人”的角色。
★方案3——基于 CA 证书进行密钥交换
其实“方案3”跟“方案2”很像的，主要差别在于——“方案3”增加了“CA 数字证书”这个环节。所谓的数字证书，技术上依赖的还是前面提到的“非对称加密”。为了描述“CA 证书”在 SSL/TLS 中的作用，俺大致说一下原理（仅仅是原理，具体的技术实现要略复杂些）： 第1步（这是“一次性”的准备工作） 网站方面首先要花一笔银子，在某个 CA 那里购买一个数字证书。 该证书通常会对应几个文件：其中一个文件包含公钥，还有一个文件包含私钥。 此处的“私钥”，相当于“方案2”里面的 k1；而“公钥”类似于“方案2”里面的 k2。 网站方面必须在 Web 服务器上部署这两个文件。 所谓的“公钥”，顾名思义就是可以公开的 key；而所谓的“私钥”就是私密的 key。 其实前面已经说过了，这里再唠叨一下： “非对称加密算法”从数学上确保了——即使你知道某个公钥，也很难（不是不可能，是很难）根据此公钥推导出对应的私钥。 第2步 当浏览器访问该网站，Web 服务器首先把包含公钥的证书发送给浏览器。 第3步 浏览器验证网站发过来的证书。如果发现其中有诈，浏览器会提示“CA 证书安全警告”。 由于有了这一步，就大大降低了（注意：是“大大降低”，而不是“彻底消除”）前面提到的“中间人攻击”的风险。 为啥浏览器能发现 CA 证书是否有诈？ 因为正经的 CA 证书，都是来自某个权威的 CA。如果某个 CA 足够权威，那么主流的操作系统（或浏览器）会内置该 CA 的“根证书”。 （比如 Windows 中就内置了几十个权威 CA 的根证书） 因此，浏览器就可以利用系统内置的根证书，来判断网站发过来的 CA 证书是不是某个 CA 颁发的。 （关于“根证书”和“证书信任链”的概念，请参见之前的教程《数字证书及CA的扫盲介绍》） 第4步 如果网站发过来的 CA 证书没有问题，那么浏览器就从该 CA 证书中提取出“公钥”。 然后浏览器随机生成一个“对称加密的密钥”（以下称为 k）。用 CA 证书的公钥加密 k，得到密文 k' 浏览器把 k' 发送给网站。 第5步 网站收到浏览器发过来的 k'，用服务器上的私钥进行解密，得到 k。 至此，浏览器和网站都拥有 k，“密钥交换”大功告成啦。 可能有同学会问：那么“方案3”是否就足够严密，无懈可击了捏？ 俺只能说，“方案3”【从理论上讲】没有明显的漏洞。实际上 SSL 的早期版本（SSLv2）使用 RSA 进行身份认知和密钥交换，其原理与这个“方案3”类似。 但是，“理论”一旦落实到“实践”，往往是有差距滴，会引出新的问题。套用某 IT 大牛的名言，就是：In theory, there is no difference between theory and practice. But in practice, there is. 所以在本系列的后续博文，俺还会再来介绍“针对 SSL/TLS 的种种攻击方式”以及“对应的防范措施”。
