SSL通讯原理 （生活版）

SSL通讯原理 （生活版）

 

     工作需要做了一部分Apache配置SSL方面的东东，对SSL的通讯过程作了一些了解。时间过了挺长，包抓了不少，资料看了不少，弯路走了不少。现在做个小小的总结。接受大家考察。

 

    关于SSL数字证书,国际上顶级的认证中心(CA)、、、n等都有销售。国内的 VeriSign()代理机构如，，提供不同需求的SSL证书产品及应用解决方案。

 

SSL即Secure Socket Layer, 是一种在TCP层之上，应用层之下的实现安全信息传输的方式。这里介绍的SSL是嵌入在特定应用程序中实现的。在TCP/IP模型的位置如下：

HTTP	FTP	SMTP
SSL or TLS
TCP
IP

 

安全认证包含三个方面：内容加密，消息完整性和身份认证。

1．  内容加密

最初，据我猜测~~，可能大概也许，人们想到的是内容加密，理由很简单，不希望消息用明文在网络上传输。就好象我们写信一定要加个信封，做好保密工作。所以第一部份就是内容加密。比如我在淘包上买了瓶花水，我要告诉招商银行：

Dear bank, 把105块钱转给支付包。

要是ethereal抓的包里有这些明文的信息，那完了。我的帐户就极其不安全。所以我就要把这个消息加密，把加密后的消息发给银行。就好象把消息装在一个盒子里，把盒子上锁，银行收到盒子打开锁，就OK了。

       有了带锁的盒子，就是钥匙的问题了。有2种方式可供选择，对称密码和不对称密码。对称密码就是我和银行有同一把钥匙。不对称密码就是我和银行的钥匙不一样。现在SSL都选择使用不对称密码。即公钥密钥密码系统。公钥是发给每一个想和银行有业务关系的客户。密钥只有银行有。所以我会用公钥把消息加密上锁，银行收到后用她的密钥解密开锁。

必须注意：用公钥加密的数据只有私钥才能解密，相反的，用私钥加密的数据只有公钥才能解密。

可是假如有个中间人，劫持了我的消息，篡改了消息，改为把钱打到他的帐号上，同样用银行的公钥加密（人人都有），那我的帐户同样存在危险。这就是第二步，消息完整性。

2．  消息完整性

（使用情形仅用于说明消息摘要的原理，仅明白原理就OK了。）

为了保证划转资金的这个消息是完整的，没有被人篡改过的，就和这个消息一起发送一个摘要给银行，银行用这个摘要和原始消息生成的摘要作对比，如果一致，则认为消息是没有被篡改过的，完整的从我这里发出去的。

好了，现在我用消息生成摘要，把这些东东加密给银行发过去。那下一个重要的问题是，我怎么知道那个XX就是我要通讯的银行。所以就目前的技术，我得验证这个XX是银行。通讯初始阶段，流程是这样地：

我 -> 招商银行：hi, 招行？

招商银行 ->我：我就是招商银行+银行公钥。

我 -> 招商银行：给个理由先。

招商银行 -> 我：我就是招商银行+银行私钥加密{“我就是招商银行”+ 消息摘要}

我 -> 招商银行：银行公钥加密{“我要转账给支付宝”+ 消息摘要}

….

我收到公钥在询问一次，因为只有银行的私钥加密的消息，我才能用这个公钥解开。所以第四步我成功解密，我就有理由认为现在这个XX是银行了。

但是，任何一个有公钥密钥的XX都可以仿冒银行。只要他劫持到我的访问请求就可以肆无忌惮的套出我的银行信息。这才是最最糟糕的事。于是进行第三步，身份认证。

1．  身份认证

我要确保，给我发公钥的XX是招商银行那个XX（第一步就不能出现冒牌货）。可是在现在这个混暗的社会，我该相信谁呢？经过这么多年，终于被我找到了，哈哈。答案就是证书！！！

开个玩笑。银行去一个公认的机构（所谓的证书颁发机构）领取一个含有他名称的证书（其中还有公钥）。而我呢，是信任这个机构的因此我信任这个证书，所以我信任给我证书的这个XX就是银行。

关于证书又可以写一篇文章了。这里仅涉及证书的使用和如何能利用它来进行身份认证。其他信息如证书管理和申请可以参考：Apache Document 2.0。

有了证书，我就可以通过验证证书，得到银行公钥，改善过的通讯过程如下：

我 -> 招商银行：hi, 招行？

招商银行 ->我：我就是招商银行+证书。

我 -> 招商银行：给个理由先

招商银行 -> 我：我就是招商银行+银行私钥加密{“我就是招商银行”+ 该消息摘要}

在我这里，是信任几个顶级的证书颁发机构，因此我这里有这些颁发机构的公钥。我用公钥解开这个证书，确认其中这个机构的数字签名，即可以认定证书的是真的。也就确认了这个XX是招商银行，同时从证书中得到银行的公钥，但仅有这步是不够的。我还需要确认和我通讯的这个XX有该公钥对应的私钥。于是后两步依然如前。

至此， SSL通讯中的过程就如此了。为了技术的讲解，把整个通讯过程简化了。实际过程更加复杂。有兴趣的可以继续往下看。

抓包中实际的交互过程：

a. Client -> Server：Client Hello

b. Server -> Client：Server Hello, Certificate, Server Hello Done

c. Client -> Server：Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

d. Server -> Client：Change Cipher Spec, Encrypted Handshake Message

e. Client -> Server：Application data

f. Server -> Client：Application data

a, b, c, d四步是握手阶段，这里要经过，协商密码组，身份验证，数据通讯过程中使用的方式等等。分步讲解：    

a. Client Hello:

客户端向服务器发送客户SSL 版本号、加密算法设置、随机数(32位时间戳和28 字节随机序列)、会话ID、客户支持的密码算法列表(CipherSuite) 和客户支持的压缩算法列表。

   b. Server Hello:

       服务器向客户端发送服务器的SSL 版本号、从客户信息中选择的加密算法和压缩算法、随机产生的数据和其他客户需要用于和服务器通信的数据. 另外, 服务器还要发送自己的证书证明身份。如果服务器需要验证客户端身份，这里还要去请求客户端的证书。

   客户用服务器发送来的数字证书验证服务器身份. 如果认证不成功, 用户将得到一个警告, 加密连接无法建立; 如果成功：

       c. Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

       客户端发送“Client Key Exchange”消息，其中内容是由服务器的公钥加密；同时产生会话密钥，发送“Change Cipher Spec”消息。

       d. Change Cipher Spec, Encrypted Handshake Message

  服务器发送此消息表明，支持更换使用改密码组，后面的握手消息使用服务器的密钥加密。至此握手过程完成。客户端和服务器段建立起一个安全的连接。用此连接传输应用层数据。

 

    总结，文中没有涉及服务器端对客户端的身份验证(即：代理的SSL双证书)，相应的也没有数字签名。有兴趣的朋友可以自己找资料参考。另外最后的通讯过程详解，自我感觉一般，仅读过RFC2246的附录，没对重要内容作研究。欢迎大家指出错误，肉包非常谢谢。最后感谢友情客串：花水，支付包，招商银行和XX。