TLS协议扫盲（握手，非对称加密，证书，电子签名等）

想学习TLS协议最好的方法应该是去看RFC，但如果对安全传输协议没有一些基本认识的人很难一上来就读懂RFC里面的种种细节和设计原则，所以这里为了能够进一步去弄懂TLS协议，把一些基本的知识放在这里，算是扫下盲。

1. TLS与SSL的区别：SSL是TLS的前身，TLS做出了一些使其更安全的改进。事实上，在客户端向服务器发起连接请求时，会附上的所支持的协议版本；这里的协议版本标识了是SSL或TLS（3.1为TLS）

2. TLS在真正传输过程中使用对称加密，因为对称加密效率更高。而对称加密所使用的key是在握手过程中使用特定的算法协商出来的。老版本的SSL使用RSA协商算法，需要使用服务器的公钥来加密传输客户端随机生成的对称key。这种方法有一些安全隐患（一个隐患就是攻击者可以先存储下来双方的加密包。如果攻击者后来获取了服务器的私钥，进而就能获取对称key，从而破解密文）。最新的Diffie-Hellman算法可以在协商过程中不传递任何关于对称key的信息，因而更加安全。

3. 客户端使用证书对服务器进行身份验证。证书一般由其他机构发放，证书会包含证书的公钥，并会在结尾处对证书内容做哈希并用发放机构自己的私钥对哈希值做加密（电子签名）。客户端可以用证书中发放机构的公钥对证书结尾的电子签名做解密，并验证解密出的哈希值与证书正文的哈希值是否一致，以验证证书是否确实为所宣称的发放机构发放。这个验证发放者的过程可以不断递归直到验证到的一个可信的发放者，或者电子签名验证失败。现在一般证书的格式都采用X509这个标准。

上面所述的过程只能验证证书本身的可信性，而不能验证提供这个证书的服务器实际上持有相关证书。关于如何验证服务器确实是证书的持有者，可能有两种方法：

1）. 让服务器用证书中公钥对应的私钥加密一段文字，客户端用证书的公钥解密这段密文并验证服务器的私钥是否对应证书的公钥（如何防范人在回路？）

2）. 验证证书中的CN与服务器的CN（基本上可以理解为域名）。因为客户端在发起向的某个服务器的连接过程中，客户端是知道自己想要连接到的服务器的域名的。而服务器传回的证书中包含证书被颁发者的信息，这里面就包含了被颁发者的域名。由于证书是由颁发者的私钥进行签名加密的，证书的内容被颁发者无法随意篡改，所以可以通过比对证书中的域名信息来验证对方是否是某个域名的服务器。

大体就是这几个关键点，以后有时间再补充细节。

参考资料：

https://developer.mozilla.org/en-US/docs/Archive/Security/Introduction_to_Public-Key_Cryptography#How_CA_Certificates_Are_Used_to_Establish_Trust

https://developer.mozilla.org/en-US/docs/Archive/Security/Introduction_to_SSL

http://chimera.labs.oreilly.com/books/1230000000545/ch04.html#TLS_FORWARD_SECRECY

http://blog.fourthbit.com/2014/12/23/traffic-analysis-of-an-ssl-slash-tls-session (非常详细解析协议每种message的格式，重点推荐！！)

关于openssl编程：

http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html

http://www.linuxjournal.com/node/5487/print

http://www.ibm.com/developerworks/library/l-openssl/

https://www.cs.utah.edu/~swalton/Documents/Articles/Programming-OpenSSL.pdf

关于session resumption：

http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html