2.2 HTTPS
[TOC]
概念
HyperText Transfer Protocol over Secure Socket Layer。在 HTTPS 中，使用传输层安全性(TLS)或安全套接字层(SSL)对通信协议进行加密。也就是 HTTP + SSL(TLS) = HTTPS。
默认端口号443
SSL、TSL
1994年，NetScape公司设计了SSL协议1.0版，但是未发布
1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞
1996年，SSL 3.0版问世，得到大规模应用，目前已被发现有安全漏洞
1999年，互联网标准化组织接替NetScape公司，在SSL3.0的基础上发布了TLS 1.0版
2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2018年TLS 1.3正式版发布
为什么会出现，能够解决什么问题
主要为了解决HTTP不能解决的问题
HTTPS 协议提供了三个关键的指标
- 防窃听：数据加密(Encryption)
HTTPS 通过对数据加密来使其免受窃听者对数据的监听，这就意味着当用户在浏览网站时，没有人能够监听他和网站之间的信息交换，或者跟踪用户的活动，访问记录等，从而窃取用户信息。
- 防篡改：数据一致性(Data integrity)
数据在传输的过程中不会被窃听者所修改，用户发送的数据会完整的传输到服务端，保证用户发的是什么，服务器接收的就是什么。
- 防冒充：身份认证(Authentication)
是指确认对方的真实身份，也就是证明你是你（可以比作人脸识别），它可以防止中间人攻击并建立用户信任。
加密算法
HTTPS发展过程
1.内容为什么不使用对称加密？
不同的客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本很高
因每个客户端、服务器的安全级别不同，密钥极易泄露
2.内容为什么不使用非对称加密？
公钥是公开的（也就是黑客也会有公钥），如果被黑客截获，其可以使用公钥进行解密，获取其中的内容
3.非对称加密和对称机密结合
通过非对称加密 交换 对称加密的秘钥
回话内容通过对称加密进行加密解密
问题：
- 客户端如何获得公钥 (SSL证书)
- 如何确认服务器是真实的而不是黑客(CA证书)
以浏览器为例说明如下：
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
（4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充
（7）此时浏览器就可以读取证书中的公钥，用于后续加密了
此处也可以参考即时通讯安全篇（八）：你知道，HTTPS用的是对称加密还是非对称加密？
HTTPS实现原理
证书验证阶段：
- 1）浏览器发起 HTTPS 请求；
- 2）服务端返回 HTTPS 证书；
- 3）客户端验证证书是否合法，如果不合法则提示告警。
数据传输阶段：
- 1）当证书验证合法后，在本地生成随机数；
- 2）通过公钥加密随机数，并把加密后的随机数传输到服务端；
- 3）服务端通过私钥对随机数进行解密；
- 4）服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输。
SSL/TSL握手过程
Client Hello
- 支持的协议版本，比如TLS 1.0版
- 一个客户端生成的随机数，稍后用于生成"对话密钥"
- 支持的加密方法
- 支持的压缩方法，一般为 null
- SNI(Server Name Indication)支持
Server Hello
- 确认使用的TLS协议版本，如果两端支持的版本不一致，服务器关闭加密通信
- 一个服务器生成的随机数，稍后用于生成"对话密钥"
- 确认使用的加密方法，比如RSA公钥加密
- 服务器数字证书
- 请求客户端发送证书[可选]
服务证书验证
- 证书的签发机构是否权威(内置CA证书链)
- 证书对应的域名是否正确
- 证书是否过期
回应 Server Hello
- 服务端证书通过验证，从中取得公钥
- 一个随机数，又称"pre-master key”，该随机数用服务器公钥加密，防止被窃听
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验
SSL/TLS 握手总结
- Server 端决定使用 TLS 版本及加密套件
- 整个握手过程，client 端生成2个随机数，server 端生成1个随机数，一共3个随机数。前两个未加密，第三个使用服务端公钥加密。最终的会话密钥来自这3个随机数
- 整个 SSL/TLS 握手过程几乎都是明文
可参考
重要的问题
- Q: HTTPS用的是对称加密还是非对称加密？
HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。
- Q: 为什么需要证书？
防止”中间人“攻击，同时可以为网站提供身份证明。
- Q: 使用 HTTPS 会被抓包吗？
HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。
但是，正如前文所说，浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？
HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。
- Q: HTTPS 的传输过程是怎样的？
A: 客户端发起 HTTPS 请求，服务端返回证书，客户端对证书进行验证，验证通过后本地生成用于改造对称加密算法的随机数，通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数，之后的数据交互通过对称加密算法进行加解密。