HTTPS 协议

[coconilu]

概述

所谓互联网，是由能连通到全世界的网络组成的。无论世界哪个角落的服务器在和客户端通信时，在此通信线路上的某些网络设备、光缆、计算机等都不可能是个人的私有物，所以不排除某个环节中会遭到恶意窥视行为。

我们知道，财产是神圣不可侵犯的。所以互联网想要发展起来，必须要可以保证使用互联网的人的权益不受到侵犯，安全技术不断发展。

目前，HTTPS（HTTP Secure）是公认较安全的措施。因为第三方（CA）的介入，可以保证通信过程不被窥视和替换。不仅如此，还有很多保障用户隐私的措施，比如一次性Token等待。

http和https的关系

它们之间的关系可以用公式表示：HTTP + SSL\TLS = HTTPS

其中，TLS是以SSL为原型开发的协议。

SSL\TLS保护整个上层应用协议的通信包，Cookie是HTTP包的一部分，可以保护。所有信息中，只有IP和端口不加密，请求报文都会被加密。

HTTPS一般使用的加密与HASH算法如下：

1. 非对称加密算法：RSA，DSA/DSS
2. 对称加密算法：AES，RC4，3DES
3. HASH算法：MD5，SHA1，SHA256

SSL/TLS的通信过程

1. 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
2. 服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
3. 后服务器发送Certificate报文。报文中包含公开密钥证书。
4. 最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
5. SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。
6. 接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。
7. 客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
8. 服务器同样发送Change Cipher Spec报文。
9. 服务器同样发送Finished报文。
10. 服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
11. 应用层协议通信，即发送HTTP响应。
12. 最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。

中间人攻击

借鉴大神的一张图：

通信过程的安全性自下而上就是这样保证的：

1. 双方通信内容的安全性是靠公钥加密、私钥解密来保证的，这一安全性由非对称加密的特性，即由公钥加密的信息只能使用对应的私钥才能解开来保证。由于私钥不会传递，只有拥有者知道，所以安全性就由公钥的正确性来保证。
2. 公钥由对方在通信初始所提供，但是这时很容易被中间人替换掉，为了保证公钥的正确性，所以在发送公钥的时候也会提供对应的数字证书，用于验证这个公钥是对方的而不是中间人的。那么安全性就是由数字证书的正确性来保证了。
3. 数字证书是由上级 CA 签发给个人 / 组织的，上级 CA 用自己的私钥给个人证书进行签名，保证证书中的公钥不被篡改，而接受者需要用上级 CA 证书中的公钥来解密个人数字证书中的数字签名来验证证书中的公钥是否是正确的。那么安全性就是由上级 CA 证书的正确性保证的了。
4. 但是，上级 CA 证书也是由其上级 CA 签发的，这种信任关系一直到根证书。根证书没有上级 CA 为其签名，而是自签名的，也就是说，它自身为自身签名，保证正确性。所以根证书就是这个信任链最重要的部分。如果根证书泄露的话，其签名的所有证书及使用其签名的证书所签名的证书的安全性将不复存在。现在，安全性就是靠系统根证书的私钥不被泄露或者其公钥不被篡改来保证的了。
5. 根证书不应该通过网络分发，因为通过网络分发的话，可能会被中间人攻击。一般根证书都通过操作系统或者浏览器分发，在操作系统中会内置很多根证书，但是最初的操作系统也不能通过网络分发，因为中间人可以修改操作系统中的根证书。所以要保证安全只能靠最原始的方法，当面交流。硬件厂商会和证书签发机构合作，在电脑、手机等设备出厂的时候在其操作系统中内置签发机构的根证书，再将这些设备分发出去，这样，这些设备的用户就可以安全地进行信息交换了。所以，安全性就依赖于这些设备在分发到消费者手中之前不会被恶意修改来保证了。

有一个细节需要注意，数字摘要可以保证不受中间人攻击：

数字摘要中肯定有一段唯一标识目标网站的字段，比如域名。
这个唯一标识会被记录在CA机构，由CA机构保证它的唯一性。
浏览器解开服务器证书，并拿到数字摘要中的这个唯一标识后，就可以验证证书是否来自目标网站。

公钥与私钥的理解

既然是加密，那肯定是不希望别人知道我的消息，所以只有我才能解密，所以可得出公钥负责加密，私钥负责解密；
同理，既然是签名，那肯定是不希望有人冒充我发消息，只有我才能发布这个签名，所以可得出私钥负责签名，公钥负责验证。

证书和服务器公钥的关系

为了提防中间人攻击，需要第三方（数字证书认证机构，CA——Certificate Authority）的介入。

数字证书认证机构处于客户端和服务器双方都可信赖的第三方机构的立场上。一般浏览器在安装的时候会预装一些权威的CA的公钥，用以验证签名。

首先，服务器的运营人员向CA提出公开密钥的申请。CA在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。

然后，当客户端访问服务器的时候，服务器会将这份由CA颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。接到证书的客户端可使用CA的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥是真实有效的CA；二，服务器的公开密钥是值得信赖的。

EV SSL，可以保证服务器是规范的，也可以保证服务器背后运营的企业是真是存在的。

证书还有下面几种分类：

1. 客户端证书，典型例子是银行发给个人的电子证书
2. 自签名证书，使用OpenSSL制作的证书
3. 自认证证书，独立构建的认证机构叫做自认证机构，它们发布的“无用”证书也被成为自签名证书
4. 中级认证机构的证书，可能会变成自签名证书

对称加密方式传输数据

客户端和服务端并不是一直使用非对称加密的方式传输数据。

而是在客户端保证不被中间人攻击拿到服务端的公钥后，使用公钥加密一段随机字符串，然后回传给服务器，以后双方都通过这个随机字符串对称加密解密传输数据。

即使中间人可以获取客户端回传的经过公钥加密的随机字符串，也没有办法获取解密后的随机字符串。中间人就算使用服务器公钥伪造了一份随机字符串也无济于事。

参考

《图解HTTP》
HTTPS 中间人攻击及其防范