HTTPS#
扫盲贴，以尽可能简单的方式说明白HTTPS。
什么是SSL/TLS#
SSL(Secure Sockets Layer)即"安全套接层"，由网景公司在上世纪90年代中期设计。
TLS(Transport Layer Security)即"传输层安全协议"，是SSL应用广泛后，标准化的产物。该协议由两层组成：TLS记录协议和TLS握手协议。
两者的关系是并列关系，都是为了保障在Internet上数据传输的安全。
什么是HTTPS#
HTTPS 即"HTTP over SSL"或"HTTP over TLS"。
HTTP并非是应用层的一种新协议，只是 HTTP 通信接口部分用 SSL和 TLS协议代替而已。通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通 信，再由 SSL 和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。
什么是对称加密#
对称加密即加密与解密都使用相同的密钥。例如文件压缩设置密码就是一个很好的例子，使用密码加密压缩文件，使用相同的密码解压缩文件。
什么是非对称加密#
与对称加密相对，非对称加密即加密与解密使用不同的密钥对。密钥对包含公钥和私钥，通常公钥是公开的，而私钥是私人持有的，一般公钥用于加密，而私钥用于解密。相比于对称加密而言，非对称加密的性能会差很多。
HTTPS的特点#
- 兼容性(兼容HTTP)
- 可扩展性(SSL/TLS可以与其他应用层协议使用，如ftp，smtp，telnet协议等)
- 保密性(防嗅探/偷窥)
- 完整性(防纂改)
- 真实性(防假冒，如dns污染等)
密钥密钥协商#
从上面的介绍可以看到，HTTPS是为了保障在Internet上数据传输的安全。而在整个HTTPS通信中，最重要的事情就是密钥协商。如何实现一个可靠的密钥交换是整个HTTPS的关键。接下来介绍几个方案，同时会说明方案中的可行性。
方案1. 使用"对称加密"#
单纯使用对称加密很明显是行不通的，因为在使用对称加密之前必须先协商"对称加密"用到的密钥，如果将这个密钥直接通过明文传输，那就失去HTTPS的意义了。
方案2.使用"非对称加密"#
假如使用非对称加密，通信流程大致如下:
1. 客户端连接服务端
2. 服务端生成私钥s与公钥S，将公钥S发送给客户端
3. 客户端拿到公钥S后，生成通信秘钥k，使用公钥S加密后发送给服务端
4. 服务端使用私钥s解密得到通信秘钥k
使用非对称加密实现了HTTPS的保密性，即在秘钥协商期间嗅探者无法拿到双方的通信秘钥k。但实际上使用非对称加密也存在着问题，即中间人攻击(MITM，Man-In-The-Middle attack)。
设想一个攻击者处于客户端与服务端之间，且其能够修改通信的双方传输数据，那么一个中间人攻击的步骤大致如下:
1. 客户端连接服务端
2. 服务端生成私钥s与公钥S，将公钥S发送给客户端
3. 此时攻击者先拿到公钥S，自己再生成私钥pk与公钥PK，将自己的公钥PK发送给客户端;
4. 客户端拿到公钥PK，以为是服务端发来的公钥S，生成通信秘钥k，使用公钥PK加密后发送给服务端
5. 此时攻击者先拿到客户端加密的数据，使用自己的私钥pk解密数据，即得到了通信秘钥k。随后攻击者便可以通过通信秘钥k纂改两者的通信。
方案2不可行的原因#
根据上图，我们发现方案2不可行的原因在于步骤4时，客户端没办法确信收到的信息来自于服务端，也就是缺乏一个可靠的身份认证问题。所以我们需要找到一个可靠的身份认证方法。以下是两种身份认证的方法。
认证方法#
基于双方预先知道的信息#
这个方法很好理解，也就是说假如双方预先交换过只有彼此知道的消息，那么就可以通过这个信息来对对方身份进行认证。
基于双方信任的"公证人"#
这个方法就是利用双方都信任的公证人，由公证人担保身份。现在流行的网络购物实际上就是基于这种形式，由电商平台作为公证人，让买家与卖家建立某种程度的信任关系。
数字证书与CA#
什么是数字证书#
数字证书（或简称证书）是在 Internet 上唯一地标识人员和资源的电子文件。证书使两个实体之间能够进行安全、保密的通信。
什么是CA#
CA 是"Certificate Authority"的缩写，也叫证书授权中心。它是负责管理和签发证书的第三方机构。一般来说，CA 必须是所有行业和所有公众都信任的、认可的。因此它必须具有足够的权威性。
什么是CA证书#
CA 证书，顾名思义，就是CA颁发的证书。后文提到的证书都是CA证书。
什么是证书的信任关系#
即用一个证书证明另外一个证书是可信任的。
什么是证书的信任链#
即信任关系的嵌套，例如C信任A1,A1信任A2，A2信任A3......，一直到信任的源头即根证书。
什么是根证书#
假如以一棵树组成证书的信任链，那么处于树顶的就是根证书，根证书是默认可靠的。从中我们也可以看出根证书是整个证书体系安全的根本，假如根证书出了问题，那么所有被根证书所信任的其它证书，也就不再可信了。
证书的作用#
即用于验证某个事物的身份。这个事物可以是网站(即上面提到的HTTPS)，或者文件(是否被纂改)。
方案3:方案2的改进，引入CA证书#
通过上面的叙述，我们知道如果我们引入CA证书来解决身份验证的问题，我们就可以使用方案2来实现安全通信了。
服务器引入CA证书的步骤如下:
1. 从某个CA中引入数字证书，其中包含一个私钥文件s和一个公钥文件S
2. 在网站上部署这两个文件
之后，整个通信流程大致如下:
1. 客户端连接服务端
2. 服务端发送包含公钥S的证书给客户端
3. 客户端(一般是浏览器)验证证书是否可信任，浏览器/操作系统一般内置几十个权威的CA根证书，利用上文提到的信任链向上回溯判断该证书是否可信任
4. 在客户端确认了证书可信任后，生成通信秘钥k，从证书中提取公钥S，使用S加密k后发送到服务端
6. 服务端使用证书中的私钥s解密得到通信秘钥k
从理论上来说，这个方案是没有问题的。但实践中其实还存在一定的问题，后续再填坑。这个方案大概是 SSL 最古老的密钥协商方式 ，早期的 SSLv2 只支持这种密钥协商机制。
方案4:基于 DH 的密钥协商#
DH 算法即Diffie–Hellman 算法，以两位创始人作为名字。这个算法可以在通讯双方在完全没有对方任何预先信息的条件下通过不安全信道创建起一个密钥。但是单纯使用这个算法也存在方案2一样的问题，即缺乏身份认证，会遭到中间人攻击。所以一般DH秘钥协商会与其他签名算法配合，例如RSA/DSA等。
DH算法的原理是利用了求解“离散对数问题”的复杂性。其具体的算法如下：
1. XY双方约定一个大素数p(至少300位)作为模数，和一个小素数g作为基数（也称为生成元），这两个数是可以公开的。
2. X随机生成一个大自然数a(至少100位)，计算出A = (g**a) mod p作为自己的公钥
3. Y随机生成一个大自然数b(至少100位)，计算出B = (g**b) mod p作为自己的公钥
4. X和Y互相交换公钥
5. X通过公钥B计算得通信秘钥k=(B**a) mod p
6. Y通过公钥A计算得通信秘钥k=(A**b) mod p
7. 双方计算出的k是一致的，原因是
在HTTPS中，其通信步骤大致如下:
1. 客户端连接服务端
2. 服务端生成私钥b，根据dh算法计算出公钥B，使用某种签名算法把(p,g,B)作为整体签名，发送给客户端
3. 客户端验证签名是否有效，生成私钥a，计算出公钥A，发送给客户端
4. 服务端和客户端各自计算出相同的通信秘钥k