HTTP是什么
超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是互联网上应用最为广泛的一种网络协议。是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。
为了方便通信就必须统一约定好双方的数据协议，如果每个人都搞一套自己的规则，这玩起来就很麻烦了。因此IETF (互联网工程任务组) 推动了HTTP的统一和发展。现在大家用得最多的还是1999年收录于RFC 2616的1.1版本，2015年发布的2.0版本在推广道路上任重道远。
HTTP[S]报文
最直观上的差异，HTTP协议用明文传输报文，HTTPS用密文。
HTTP的缺陷
- 窃听风险（eavesdropping）：明文传输，第三方可以获知通信内容。
- 篡改风险（tampering）：第三方可以修改通信内容。
- 冒充风险（pretending）：第三方可以冒充他人身份参与通信。
HTTPS是什么
超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）
是一种透过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用SSL/TLS协议来加解密数据包。
HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性；
HTTPS并不是一个单独的协议，而是对工作在一加密连接（TLS/SSL）上的常规HTTP协议的称呼。因此HTTPS被称之为身披SSL外壳的HTTP。
SSL/TLS协议
传输层安全性协议（Transport Layer Security，缩写作 TLS），及其前身安全套接层（Secure Sockets Layer，缩写作 SSL）是一种安全协议，目的是为互联网通信，提供安全及数据完整性保障
发展历史
网景公司（Netscape）在1994年推出首版网页浏览器，网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。后面，IETF将SSL进行标准化，称为TLS。在浏览器、电子邮件、即时通信、VoIP、网络传真等应用程序中，广泛支持这个协议
| 协议 | 年份 | 描述 |
|---|---|---|
| SSL 1.0 | N/A | 从未公开过，因为存在严重的安全漏洞 |
| SSL 2.0 | 1995 | 因为存在数个严重的安全漏洞而被3.0版本替代 |
| SSL 3.0 | 1996 | 2014年10月Google发现该版本的严重漏洞，建议全面禁用SSL版本 |
| TLS 1.0 | 1999 | IETF标准化后的第一个版本。包括可以降级到SSL 3.0的实现，这削弱了连接的安全性 |
| TLS 1.1 | 2006 | - |
| TLS 1.2 | 2008 | 删除了对SSL的兼容。目前使用最广泛的版本 |
| TLS 1.3 | 2018 | 截至本文撰写，为建议标准的互联网草案 |
在TCP/IP模型的位置：介于传输层与应用层之间
TLS内部协议划分
- 记录协议：位于TLS握手协议的下面，在可靠的传输协议(如TCP/IP)上面。其负责识别不同的消息类型，以及每条消息的完整性、安全性验证
- 握手协议：服务端与客户端在应用程序协议传输之前进行相互认证，协商加密算法和加密密钥
另外还有3个辅助协议：
- 改变加密方式协议，用来通知对方要切换加解密方案了(有点冗余，在TLS1.3里面已经被删掉了)
- 警告协议，定义了校验及其他出错类型，
- 应用数据协议， 把http，smtp等数据流传入记录层做处理并传输。
SSL/TLS解决了什么问题
【内容加密】所有信息都是加密传播，第三方无法窃听。（密钥协商机制）
【数据完整性】具有校验机制，一旦被篡改，通信双方会立刻发现。（MAC（Message authentication code）校验机制）
【身份认证】配备身份证书，防止身份被冒充（证书认证机制）
SSL的握手过程
以下是使用curl请求https://baidu.com的详情
foam@cee: ~ » curl "https://baidu.com" -v
* Rebuilt URL to: https://baidu.com/
* Trying 123.125.115.110...
* TCP_NODELAY set
* Connected to baidu.com (123.125.115.110) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=CN; L=Beijing; O=BeiJing Baidu Netcom Science Technology Co., Ltd; OU=service operation department; CN=www.baidu.cn
* start date: Apr 3 00:00:00 2018 GMT
* expire date: Apr 3 12:00:00 2019 GMT
* subjectAltName: host "baidu.com" matched cert's "baidu.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
* SSL certificate verify ok.
> GET / HTTP/1.1
...
< HTTP/1.1 302 Moved Temporarily
...
我们分析下其中TLS1.2握手的过程：
TLS handshake, Client Hello【客户端向服务端问好】
客户端通过发送Client Hello报文开始建立SSL通信，报文包含客户端支持的SSL版本，加密套件列表，随机数。上面例子中，ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH就是客户端支持的加密套件的表达式。TLS handshake, Server Hello【服务端回礼】
服务端回复Server Hello作为应答，报文包含服务端选择好的SSL版本，加密套件，随机数。上面例子中，服务端选择了TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256。TLS handshake, Certificate【服务端亮出身份】
服务端发送证书链（从根证书到自身的证书）。证书包含证书所有者、颁发机构以及公钥、数字签名等信息。
客户端收到证书后，会校验域名；判断有效时间；判断颁发机构是否可信任；用颁发机构的公钥解开加密后的数字签名（解开后得到证书摘要和摘要算法），计算并判断证书摘要是否一致。
如果校验过程中出现问题，客户端将报Alert警告，并终止SSL握手。当然，如果警告级别只是warning（还有一种是fatal），那么客户端也可以选择忽略警告并继续完成握手过程。TLS handshake, Server key exchange【服务端将密钥生成参数及方法告知客户端】
对于使用DHE/ECDHE非对称密钥协商算法的，会有该次握手（RSA、DH、ECDH则没有）。
以ECDHE为例，服务端随机生成随机值Rb，计算Pb(x,y) = Rb * Q(x, y)。然后将Pb(x, y)发送给客户端，用来在后续步骤中计算出PreMasterSecret。ps：该条消息包含一个用服务端私钥作的签名。TLS handshake, Server finished【服务端提醒：关于密钥生成，该说的我都说完了】
服务器发送这条消息表明，服务器部分的密钥交换信息已经发送完了，等待客户端的消息以继续接下来的步骤。这条消息只用作提醒，不包含数据域。TLS handshake, Client key exchange【客户端将密钥生成参数及方法告知服务端】
这条消息会把PreMasterSecret或者生成PreMasterSecret的数据发给服务端。
具体是哪种数据与所选用的密钥交换算法有关：
- RSA：数据为用服务器RSA公钥加密过的PreMasterSecret
- ECDHE：客户端随机生成随机值Ra，计算Pa(x, y) = Ra * Q(x, y)。然后将Pa(x, y)发给服务端。客户端计算Sa(x, y) = Ra * Pb(x, y)；服务器计算Sb(x, y) = Rb *Pa(x, y)；算法保证了Sa = Sb = S，提取其中的S的x向量作为PreMasterSecret
ps: 此次握手过后，双方都拿到了可以计算出MasterSecret的PreMasterSecret。
PRF( secret , label , seed )
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
TLS change cipher, Client hello【客户端：接下来我要用新的加密方式与你交流啦】
客户端发送更改加密方式信号。本流程不携带任何数据，也不参与最后的哈希完整性计算。只是一个宣告信道开始的流程。TLS1.3将其移除。TLS handshake, Finished【客户端：我对握手全过程计算了哈希，你验证下】
客户端发送，用协商好的对称加密密钥（MasterSecret）加密过的握手数据包。该数据包完整地计算了从握手开始到结束的所有内容的哈希值，保证了整个握手过程中，数据没有被篡改。服务端会去做校验。
ps: 这条是整个SSL握手过程中，首次使用对称性加密的数据。TLS change cipher, Client hello【服务端：接下来我也要用新的加密方式与你交流啦】
服务端发送更改加密方式信号。TLS1.3将其移除。TLS handshake, Finished【服务端：我也对握手全过程计算了哈希，你也验证下】
服务端发送，用协商好的对称加密密钥加密过的握手数据包。客户端也会去做校验。
握手终于结束啦，接下来的http数据传输将全部用辛辛苦苦协商好的MasterSecret进行对称加密。
TLS1.3减少了握手期间的RTT（来回通信延迟）
扩展
密码学套件的标准名字
以TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256为例：
- TLS代表的是TLS协议
- WITH是一个分隔单词，前面的
ECDHE_RSA是握手过程所使用的非对称加密方法，后面的AES_128_GCM_SHA256是加密信道的对称加密方法和用于数据完整性检查的哈希方法 - ECDHE_RSA，客户端与服务端之间在握手期间，密钥交换信息使用的非对称加密算法是第一个算法，证书认证时使用的非对称加密算法是第二个。有的证书套件，例如TLS_RSA_WITH_AES_256_CBC_SHA，WITH单词前面只有一个RSA单词，这时就表示密钥交换算法和证书算法都是使用的RSA，所以只指定一次即可。可选的主要的密钥交换算法包括: RSA, DH, ECDH, ECDHE。可选的主要的证书算法包括：RSA, DSA, ECDSA。两者可以独立选择，并不冲突。
- AES_128_GCM，指的是AES这种对称加密算法的128位算法的GCM模式
- SHA256，计算消息完整性的哈希算法。
Charles等代理程序是怎么实现解析https的
本质是中间人。代理程序处在客户端与服务端之间，服务端下发证书的时候，代理程序copy一份数据，并将公钥信息换成自己的，最后用自己的根证书签名。
最最重要的一步是，将自己的根证书加入到系统信任证书列表里边。没有内鬼是破解不了HTTPS的。
参考资料
HTTPS的二三事
图解HTTP之HTTPS详解
HTTPS协议详解(四)：TLS/SSL握手过程
沃通
维基百科
阮一峰博客
TLS的密码学套件
深度解读SSL/TLS实现
Master secret的生成
ECC证书和RSA证书
TLS1.3/QUIC 是怎样做到 0-RTT 的
- 本文固定链接: http://zoufeng.net/2018/08/23/about-https/
- 转载请注明: foam 2018年08月23日于 foam 发表
