1990年互联网诞生之初，就已经开始用超文本传输协议HTTP传输数据，这也是为什么现在网页地址都是以http开头的原因。但是HTTP协议传输数据是明文传输，任意的人抓包就能看到传输的数据，这显然不安全。1994年，Netscape公司用加密协议增加了HTTP，开始在HTTP的基础上加入SSL（Secure Socket Layer）。称为"HTTP over SSL"或者"HTTP Secure"，也就是我们现在熟知的HTTPS。
SSL/TLS是位于TCP/IP 7层协议中的会话层，用于认证用户和服务器，加解密数据以及维护数据的完整性，确保数据在传输过程中不会被修改。
TLS（Transport Layer Security，传输层安全协议）是IETF制定的一种新的协议，TLS1.0是建立在SSL3.0协议规范之上，是SSL3.0协议的后续版本，可以理解为SSL3.1。TLS的主要目的是使SSL更加安全，更加完善。TLS记录格式于SSL记录格式相同，但是版本号值不一样，TLS的版本1.0使用的版本号是SSLv3.1。
SSL/TLS分为对称加密和非对称加密两种方式。
对称加密是指加密和解密都用同一份密钥。如下图所示：
常用的对称加密算法有AES-128，AES-192，AES-256。
非对称加密对应于一对密钥，称为私钥和公钥，用私钥加密后需要用公钥解密，用公钥加密后需要用私钥解密。如下图所示：
对称加密的优点是运算速度快，缺点是互联网环境下无法将密钥安全的传送给对方。非对称加密的优点是可以安全的将公钥传递给对方，但是运算速度慢。
那么HTTPS究竟是采用对称加密还是非对称加密呢？答案是两者都有。先采用非对称加密传输协商对称加密的密钥，然后用对称加密通信。
上图是比较粗粒度的讲解了HTTPS的非对称和对称加解密过程：
整个流程可以这样抽象，但是实际上session key的生成是需要多次协商的结果（文章后面会讲到），我们暂且这样简单的理解。整个流程会有一个问题，第2步中WEB服务器发给客户端的公钥，万一被中间人修改了呢，换句话说，客户端怎么验证公钥的正确性呢？那就需要讲到数字签名。
如上图所示，公钥内容的后面是会跟上一个数字签名，该数字签名是将公钥内容的HASH用私钥加密后的密文。客户端拿到公钥后，会用相同的HASH算法重新算一遍，得到一个HASH值hash1。然后用公钥解密数字签名得到HASH值hash2，如果hash1等于hash2就证明这个公钥是没有被中间人修改的。即使中间人修改了公钥的内容，他也没有私钥可以重新生成数字签名，用户拿到修改后的公钥一算发现HASH不对就会报错。
明天再写，累了。
https://tiptopsecurity.com/how-does-https-work-rsa-encryption-explained/
http://www.youdzone.com/signature.html
https://zh.wikipedia.org/wiki/%E4%B8%AD%E9%97%B4%E4%BA%BA%E6%94%BB%E5%87%BB
https://www.tutorialsteacher.com/https/how-ssl-works
http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html
https://www.linuxidc.com/Linux/2016-05/131147.htm
https://hpbn.co/transport-layer-security-tls/
原文：https://www.cnblogs.com/makelu/p/11140824.html