ssl 协议

SSL协议
SSL协议采用数字证书进行双端实体认证，用非对称加密算法进行密钥协商，用对称算法将数据加密后进行传输以保证数据的保密性，并且通过计算数字摘要来验证数据在传输过程中是否被篡改和伪造，从而为敏感数据在Internet上的传输提供了一种安全保障手段。

双向认证理论过程如下：
（1）客户端的浏览器向服务器传送客户端SSL协议的版本号，加密算法的种类（加密算法、密钥传输算法和单向散列函数），产生的随机数以及其他服务器和客户端之间通讯所需要的各种信息；
（2）服务器向客户端传送SSL协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书；
（3）客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA是否可靠，发行者证书的公钥是否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步；
（4）用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤（2）中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器；
（5）如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密钥”一起传给服务器；
（6）如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA是否可靠，发行CA的公钥能否正确解开客户证书的发行CA的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）；
（7）服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于SSL协议的安全数据通讯的加解密通讯。同时在SSL通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。
（8）客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤（7）中的主密码为对称密钥，同时通知服务器客户端的握手过程结束；
（9）服务器端向客户端发出信息，指明后面的数据通讯将使用的步骤（7）中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束；
（10）SSL的握手部分结束，SSL安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

双向认证SSL协议的具体过程：
（1）浏览器发送一个连接请求给安全服务器；
（2）服务器将自己的证书，以及同证书相关的信息发送给客户浏览器；
（3）客户浏览器检查服务器送过来的证书是否是自己信赖的CA中心所签发的。如果是，就继续执行协议；如果不是，客户浏览器就给客户一个警告消息：警告客户这个证书不是可以信赖的，询问客户是否需要继续；
（4）接着客户浏览器比较证书里的消息，例如域名和公钥，与服务器刚刚发送的相关消息是否一致，如果是一致的，客户浏览器认可这个服务器的合法身份。
（5）服务器要求客户发送客户自己的证书，收到后，服务器验证客户的证书，如果没有通过验证，拒绝连接；如果通过验证，服务器获得用户的公钥；
（6）客户浏览器告诉服务器自己所能够支持的通讯对称密码方案；
（7）服务器从客户发送过来的密码方案中，选择一种加密程度最高的密码方案，用客户的公钥加过密后通知浏览器；
（8）浏览器针对这个密码方案，选择一个通话密钥，接着用服务器的公钥加过密后发送给服务器。
（9）服务器接收到浏览器送过来的消息，用自己的私钥解密，获得通话密钥；
（10）服务器、浏览器接下来的通讯都是用对称密码方案，对称密钥是加过密的；

双向认证SSL要求服务器和用户双方都有证书。单向认证SSL协议不需要客户拥有CA证书，具体的过程相对于上面的步骤，只需将服务器端验证客户证书的过程去掉，以及在协商对称密码方案，对称通话密钥时，服务器发送给客户的是没有加过密的密码方案。

加密一般分三类：对称加密、非对称加密和单向散列函数；
对称加密：分组密码（DES,RC5,IDEA）和序列密码（RC4），其中CBC（cipher block chaining）是分组密码的一类，是指一个明文分组在被加密之前要与前一个的密文分组进行异或运算，当加密算法用于此模式的时候除密钥外，还需协商一个初始化向量（IV），这个IV没有实际意义，只是在第一次计算的时候需要用到而已，采用这种模式的话安全性会有所提高；
单向散列函数：由于信道的破坏，一个通用的方法就是加入校验码。单向散列函数可用于此用途，一个典型的例子是MD5，它产生128位的摘要，在现实中用的更多的是安全散列算法（SHA），SHA的早期版本存在问题，目前用的实际是SHA-1，它可以产生160位的摘要，因此比128位散列更能有效抵抗穷举攻击。由于单向散列的算法是公开的，所以其它人可以先改动原文，再生成另外一份摘要，解决这个问题的方法可以通过HMAC，它包含了一个密钥，只有拥有相同密钥的人才能鉴别这个散列。

密钥协商的形象化比喻：
假设A和B通信，A是SSL客户端，B是SSL服务器端，加密后的消息放在方括号[]内，以突出明文消息的区别，双方的处理动作的说明用圆括号（）括起。
A：我想和你安全的通话，我这里的对称加密算法有DES,RC5，密钥交换算法有RSA和DH，摘要算法有MD5和SHA。
B：我们用DES-RSA-SHA这对组合好了。这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）；
A：查看证书上B的名字是否有误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性。
（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量和HMAC的密钥。将这份秘密消息-协议中称为per_master_secret用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意：下面我将要用加密办法给你发消息了！
（将秘密消息进行处理，生成加密密钥，加密初始化向量和HMAC的密钥）
B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和HMAC的密钥，这时双方已经安全的协商出一套加密办法了）
注意，我也要用加密的办法给你发消息了！

加密的计算：
（1）借助HMAC的密钥，对明文的消息做安全的摘要处理，然后和明文放在一起；
（2）借助加密密钥，加密初始化向量加密上面的消息；

 

一个连接的例子
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using AES256-SHA
* Server certificate:
*        subject: /C=CN/ST=Beijing/L=city/O=IHEP-CC/OU=System
*        start date: 2011-11-20 04:11:20 GMT
*        expire date: 2011-12-20 04:11:20 GMT
*        common name: WARNING couldn't obtain
*        issuer: /C=CN/ST=Beijing/L=city/O=IHEP-CC/OU=System
* SSL certificate verify result: self signed certificate (18), continuing anyway.