openssl的四个验证证书模式分别是：
SSL_VERIFY_NONE:完全忽略验证证书的结果。当你觉得握手必须完成的话，就选用这个选项。其实真正有证书的人很少,尤其在中国。那么如果SSL运用于一些免费的服务，比如email的时候，我觉得server端最好采用这个模式。
SSL_VERIFY_PEER:希望验证对方的证书。不用说这个是最一般的模式了.对client来说，如果设置了这样的模式，验证server的证书出了任何错误，SSL握手都告吹.对server来说,如果设置了这样的模式,client倒不一定要把自己的证书交出去。如果client没有交出证书，server自己决定下一步怎么做。
SSL_VERIFY_FAIL_IF_NO_PEER_CERT:这是server使用的一种模式，在这种模式下，server会向client要证书。如果client不给，SSL握手告吹。
SSL_VERIFY_CLIENT_ONCE：这是仅能使用在sslsessionrenegotiation阶段的一种方式。什么是SSLsessionrenegotiation?以后的章节再解释。我英文差点，觉得这个词组也很难翻译成相应的中文。以后的文章里，我觉得很难直接翻译的单词或词组，都会直接用英文写出来。如果不是用这个模式的话,那么在regegotiation的时候，client都要把自己的证书送给server,然后做一番分析。这个过程很消耗cpu时间的，而这个模式则不需要client在regotiation的时候重复送自己的证书了。
SSL_VERIFY_NONE:完全忽略验证证书的结果。当你觉得握手必须完成的话，就选用这个选项。其实真正有证书的人很少,尤其在中国。那么如果SSL运用于一些免费的服务，比如email的时候，我觉得server端最好采用这个模式。
SSL_VERIFY_PEER:希望验证对方的证书。不用说这个是最一般的模式了.对client来说，如果设置了这样的模式，验证server的证书出了任何错误，SSL握手都告吹.对server来说,如果设置了这样的模式,client倒不一定要把自己的证书交出去。如果client没有交出证书，server自己决定下一步怎么做。
SSL_VERIFY_FAIL_IF_NO_PEER_CERT:这是server使用的一种模式，在这种模式下，server会向client要证书。如果client不给，SSL握手告吹。
SSL_VERIFY_CLIENT_ONCE：这是仅能使用在sslsessionrenegotiation阶段的一种方式。什么是SSLsessionrenegotiation?以后的章节再解释。我英文差点，觉得这个词组也很难翻译成相应的中文。以后的文章里，我觉得很难直接翻译的单词或词组，都会直接用英文写出来。如果不是用这个模式的话,那么在regegotiation的时候，client都要把自己的证书送给server,然后做一番分析。这个过程很消耗cpu时间的，而这个模式则不需要client在regotiation的时候重复送自己的证书了。
握手一般都是由client发起的，SSL也不例外。
1client送给server它自己本身使用的ssl的version(ssl一共有三个version),加密算法的一些配置，和一些随机产生的数据，以及其他在SSL协议中需要用到的信息。
2server送给client它自己的SSL的version,加密算法的配置，随机产生的数据，还会用自己的私有密钥加密SERVER-HELLO信息。Server还同时把自己的证书文件给送过去。同时有个可选的项目，就是server可以要求需要客户的certificate。
3client就用server送过来的certificate来验证server的身份。如果server身份验证没通过，本次通信结束。通过证书验证之后，得到server的公共密钥，解开server送来的被其用私有密钥加密过的SERVER-HELLO信息，看看对头与否。如果不对，说明对方只有该server的公共密钥而没有私有密钥，必是假的。通信告吹。
4client使用到目前为止所有产生了的随机数据(sharedsecret),client产生本次握手中的premastersecret(这个步骤是有可能有server的参与的，由他们使用的加密算法决定),并且把这个用server的公共密钥加密，送回给server.如果server要求需要验证client,那么client也需要自己把自己的证书送过去，同时送一些自己签过名的数据过去。
SSL协议有俩种技术来产生sharedsecret(真不好意思，又是一个很难意译的词组),
一种是RSA,一种是EDH.
RSA就是我们上一章说过的一种不对称加密算法。首先server把自己的RSA公共密钥送给client,client于是用这个key加密一个随机产生的值(这个随机产生的值就是sharedsecret)，再把结果送给server.
EDH也是一种不对称加密算法，但它与RSA不同的是，它好象没有自己固定的公共密钥和私有密钥，都是在程序跑起来的时候产生的，用完就K掉。其他的步骤俩者就差不多了。
RSA,DSA,DH三种不对称加密算法的区别也就在这里。RSA的密钥固定，后俩个需要一个参数来临时生成key.DH甚至要求双方使用同样的参数，这个参数要事先指定。如果SSL库没有load进这个参数，DH算法就没办法用。DSA没研究过。
5Server验证完client的身份之后，然后用自己的私有密钥解密得到premastersecret然后双方利用这个premastersecret来共同协商，得到mastersecret.
6双方用master一起产生真正的sessionkey,着就是他们在剩下的过程中的对称加密的key了。这个key还可以用来验证数据完整性。双方再交换结束信息。握手结束。
接下来双方就可以用协商好的算法和key来用对称加密算法继续下面的过程了。
很简单吧？其实要复杂一些的，我简化了很多来说。
不过还是有个问题，喜欢捣蛋的人虽然看不懂他们在交流些什么，但篡改总可以吧？
记得我们在加密算法里面介绍过的哈希算法吗？就是为了对付这种捣蛋者的。在每次送信息的时候，附带把整条信息的哈希值也送过去，接收方收到信息的时候，也把收到的内容哈希一把，然后和对方送来的哈希值对比一下，看看是否正确。捣蛋者如果乱改通信内容，哈希出来的值是不同的，那么就很容易被发现了。
但这样子，捣蛋者至少可以学舌。他可以把之前监听到的内容重复发给某一方，而这些内容肯定是正确的,无法验证出有问题的。哎，SSL是怎么对付这种人的我还没看出来。有篇文章说：多放点随机数在信息里可以对付，我也没去研究这句话是什么意思。
1client送给server它自己本身使用的ssl的version(ssl一共有三个version),加密算法的一些配置，和一些随机产生的数据，以及其他在SSL协议中需要用到的信息。
2server送给client它自己的SSL的version,加密算法的配置，随机产生的数据，还会用自己的私有密钥加密SERVER-HELLO信息。Server还同时把自己的证书文件给送过去。同时有个可选的项目，就是server可以要求需要客户的certificate。
3client就用server送过来的certificate来验证server的身份。如果server身份验证没通过，本次通信结束。通过证书验证之后，得到server的公共密钥，解开server送来的被其用私有密钥加密过的SERVER-HELLO信息，看看对头与否。如果不对，说明对方只有该server的公共密钥而没有私有密钥，必是假的。通信告吹。
4client使用到目前为止所有产生了的随机数据(sharedsecret),client产生本次握手中的premastersecret(这个步骤是有可能有server的参与的，由他们使用的加密算法决定),并且把这个用server的公共密钥加密，送回给server.如果server要求需要验证client,那么client也需要自己把自己的证书送过去，同时送一些自己签过名的数据过去。
SSL协议有俩种技术来产生sharedsecret(真不好意思，又是一个很难意译的词组),
一种是RSA,一种是EDH.
RSA就是我们上一章说过的一种不对称加密算法。首先server把自己的RSA公共密钥送给client,client于是用这个key加密一个随机产生的值(这个随机产生的值就是sharedsecret)，再把结果送给server.
EDH也是一种不对称加密算法，但它与RSA不同的是，它好象没有自己固定的公共密钥和私有密钥，都是在程序跑起来的时候产生的，用完就K掉。其他的步骤俩者就差不多了。
RSA,DSA,DH三种不对称加密算法的区别也就在这里。RSA的密钥固定，后俩个需要一个参数来临时生成key.DH甚至要求双方使用同样的参数，这个参数要事先指定。如果SSL库没有load进这个参数，DH算法就没办法用。DSA没研究过。
5Server验证完client的身份之后，然后用自己的私有密钥解密得到premastersecret然后双方利用这个premastersecret来共同协商，得到mastersecret.
6双方用master一起产生真正的sessionkey,着就是他们在剩下的过程中的对称加密的key了。这个key还可以用来验证数据完整性。双方再交换结束信息。握手结束。
接下来双方就可以用协商好的算法和key来用对称加密算法继续下面的过程了。
很简单吧？其实要复杂一些的，我简化了很多来说。
不过还是有个问题，喜欢捣蛋的人虽然看不懂他们在交流些什么，但篡改总可以吧？
记得我们在加密算法里面介绍过的哈希算法吗？就是为了对付这种捣蛋者的。在每次送信息的时候，附带把整条信息的哈希值也送过去，接收方收到信息的时候，也把收到的内容哈希一把，然后和对方送来的哈希值对比一下，看看是否正确。捣蛋者如果乱改通信内容，哈希出来的值是不同的，那么就很容易被发现了。
但这样子，捣蛋者至少可以学舌。他可以把之前监听到的内容重复发给某一方，而这些内容肯定是正确的,无法验证出有问题的。哎，SSL是怎么对付这种人的我还没看出来。有篇文章说：多放点随机数在信息里可以对付，我也没去研究这句话是什么意思。
在SSL部分提到了一些secret，在这里做一下进一步的解释：
合法验证通过以后，客户端随即产生一个用于后面通信的对称密钥key，然后用服务器的公钥加密，加密后的密钥我们称其为mkey，将mkey传送给服务器。服务器收到用自己的私钥进行解密，得到了“对称密钥”key，服务器用客户端的公钥将key加密，形成mkey传送给客户端，客户端用自己的私钥对其解密，将得到的密钥与自己原来存储的key比较，如果一致，则可用key进行对以后的通信进行加密，否则退出共享信道的建立。
而上述的重放攻击SSL是通过在MAC中添加系列号来防止的。
