HTTPS

HTTPS ： Hypertext Transfer Protocol Secure
因为HTTP明文传输数据不安全。所以HTTPS通过使用TLS协议对数据进行对称加密来保证数据传输的安全性。
HTTPS更安全，相应的效率比http低一点
HTTPS 协议规定了新的协议名https和端口号(443)
至于其他的请求-应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP。

TLS协议
SSL：Secure Socket Layer 安全套接字层
TLS：Transport Layer Security 传输安全层
TLS在 OSI 七层网络模型中处于第五层(会话层)，是一个独立的协议，不只有 HTTP 可以使用，其他应用层协议也可以使用。用于加密数据进行安全的数据传输
HTTPS中，HTTP 会先和 TLS 进行通信，然后再由 TLS 和 TCP 进行通信。

HTTPS原理

• 采用非对称加密进行握手
• 采用对称加密进行数据传输

为什么HTTPS采用混合加密呢？

对称加密比非对称加密块。
非对称加密比对称加密安全。
所以应充分利用两者各自的优势，将多种方法组合起来用于通信。

数字证书： 解决公钥传输问题

为什么要用数字证书？ 解决公钥传输问题
server 可以向 CA 申请证书，在证书中附上公钥，然后将证书传给 client。用第三方权威机构保证公钥的正确性。
当 client 拿到证书后，就可以获得证书上的公钥，再用此公钥加密 对称加密密钥传给 server 即可。

证书内容如下：

看起来确实很完美，不过在这里大家要考虑两个问题

问题一、 如何验证证书是否被篡改？——数字签名

想象一下上文中我们提到的学历，企业如何认定你提供的学历证书是真是假呢，答案是用学历编号，企业拿到证书后用学历编号在学信网上一查就知道证书真伪了，学历编号就是数字签名，可以防止证书造假。

回到 HTTPS 上，证书的数字签名如何产生的呢？

步骤如下

步骤一、 首先使用一些摘要算法为证书明文生成摘要，然后再用第三方权威机构的私钥对生成的摘要进行加密生成数字签名

怎么生成摘要的？
生成摘要是把任意长度的输入揉和而产生长度固定的伪随机输出的算法，无论输入的消息有多长，计算出来的消息摘要的长度总是固定的，一般来说，只要内容不同，产生的摘要必然不同（相同的概率可以认为接近于 0），所以可以验证内容是否被篡改了。

为啥要先生成摘要再加密呢，不能直接加密？——节约时间

因为使用非对称加密是非常耗时的，如果把整个证书内容都加密生成签名的话，客户端验签也需要把签名解密，证书明文较长，客户端验签就需要很长的时间，而用摘要的话，会把内容很长的明文压缩成小得多的定长字符串，客户端验签的话就会快得多。

步骤二、
客户端拿到证书后也用同样的摘要算法对证书明文计算摘要，两者一笔对就可以发现报文是否被篡改了，验签过程如下：

如果客户端收到一个假的数字签名，使用 CA 的公钥是无法解密的
如果客户端收到了真的数字签名，但证书上的内容被篡改了，摘要比对也不会成功的，客户端还是会认定此证书非法。
所以可以解决安全问题了。

那CA 公钥如何安全地传输到 client ？
预先内置在操作系统上的，无需传输。

完整图示：

问题二、 如何验证证书是否被调包？——验证域名

实际上任何站点都可以向第三方权威机构申请证书，中间人也不例外。
正常站点和中间人都可以向 CA 申请证书，获得认证的证书由于都是 CA 颁发的，所以都是合法的，那么此时中间人是否可以在传输过程中将正常站点发给 client 的证书替换成自己的证书呢，如下所示

如果client只验证签名的话，确实无法发现被掉包，但是client除了通过验签的方式验证证书是否合法之外，还会验证证书上的域名与自己的请求域名是否一致，中间人中途虽然可以替换自己向 CA 申请的合法证书，但此证书中的域名与 client 请求的域名不一致，client 会认定为不通过！

HTTPS七次握手

HTTPS七次握手=TCP三次握手+TLS四次握手

TLS四次握手：
握手的目标是安全地交换对称密钥，对称密钥用于数据传输阶段对数据进行加密

TLS四次握手核心流程

TLS 第一次握手
客户端发给服务器Client Random

TLS 第二次握手
服务器发给客户端Server Random和证书

TLS 第三次握手
客户端校验证书合法性
生成pre_master，并利用三个随机数生成对称密钥。
利用从证书中得到的服务器公钥将对称秘钥和pre_master加密之后传给服务器。

TLS 第四次握手
服务器用自己的私钥解密得到对称秘钥，同样利用三个随机数计算生成对称密钥。
二者生成的对称密钥如果相同则握手成功。

用Client Random、Server Random、Pre-Master这三个参数生成对称密钥，前面两个参数明文传输。但是Pre-Master是加密的，黑客拿不到Pre-Master，所以不用担心最终的密钥不安全

TLS四次握手详述

TLS 第一次握手

客户端首先会发一个「Client Hello」消息，消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random）。

TLS 第二次握手

服务端收到客户端的打招呼，会返回四条数据：
1、「Server Hello」
包括：

• 服务器确认的 TLS 版本号，
• 随机数（Server Random），
• 从客户端的密码套件列表选择的一个合适的密码套件。密码套件解析：

「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」

• 对称密钥协商算法使用 ECDHE；

• 签名算法使用 RSA；

• 握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM；

• 摘要算法使用 SHA384；

2、「Certificate」消息：服务端为了证明自己的身份，会把证书也发给客户端。

3、「Server Key Exchange」消息
这是一个关键的操作，因为服务器选择了ECDHE算法，所以它会在证书后发送Server Key Exchange消息，里面是椭圆曲线的的公钥（Server Parma），用来实现密钥交换算法，再加上自己的私钥签名认证。

3、「Server Hello Done」消息
服务端跟客户端表明：“这些就是我提供的信息，打招呼完毕”。

至此，TLS 两次握手就已经完成了，目前客户端和服务端通过明文共享了以下信息：
Client Random、Server Random 、Server Parma

这几个信息很重要，是后续生成会话密钥的材料。

TLS 第三次握手

客户端收到了服务端的证书后，自然要校验证书是否合法，如果证书合法，那么服务端的身份就是没问题的。校验证书的过程，会走证书链逐级验证，确认证书的真实性，再用证书的公钥验证签名，这样就能确认服务端的身份了，确认无误后，就可以继续往下走。

第三次握手Client发送三条数据给Server

1、客户端按照密码套件的要求，也生成一个椭圆曲线的公钥(Client Param)，然后用「Client 、Key Exchange」消息发给服务端。

现在客户端和服务器手里都拿到了密钥交换算法的两个参数（Client Params、Server Params），就用ECDHE算法一阵算，算出了一个新的东西，叫“Pre-Master——用于计算对称加密秘钥的第三个随机数。

现在客户端和服务器手里有了三个随机数：（Client Random、Server Random、Pre-Master）。用这三个作为原始材料，就可以生成用于加密会话的主密钥——Master-Secrect。
而黑客因为拿不到“Pre-Master”，所以也就得不到主密钥。
计算公式：

master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)

主密钥有48字节，但它也不是最终用于通信的会话密钥，还会再用PRF扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）等等，避免只用一个密钥带来的安全隐患。

2、有了主密钥和派生的会话密钥，客户端发一个「Change Cipher Spec」，
3、然后再发一个“Finished”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证。
意思就是告诉服务器：“后面都改用对称算法加密通信了啊，用的就是打招呼时说的AES，加密对不对还得你测一下。”

此时Client就可以抢跑的给Server发数据了

为什么要三个随机数？
之所以这么麻烦，是因为 TLS 设计者不信任客户端或服务器「伪随机数」的可靠性，为了保证真正的完全随机，把三个不可靠的随机数混合起来，那么「随机」的程度就非常高了。

TLS 第四次握手

服务端也会有一个同样的操作，发「Change Cipher Spec」和「Finished」消息，如果双方都验证加密和解密没问题，那么握手正式完成。于是，就可以正常收发加密的 HTTP 请求和响应了。

HTTPS优化

既然要对 HTTPS 优化，那得清楚哪些步骤会产生性能消耗，再对症下药。

产生性能消耗的两个环节：

• TLS 协议握手过程；

• 握手后的对称加密报文传输。

第二个环节的性能消耗可以说非常地小

第一个环节，TLS 协议握手过程不仅增加了网络延时（最长可以花费掉 2 RTT），而且握手过程中的一些步骤也会产生性能损耗
所以主要针对 TLS 协议握手过程进行优化。主要包括以下几方面：

加密算法

• 对称加密: 加密和解密的秘钥使用的是同一个.
• 非对称加密: 公开密钥和私有密钥

对称加密

优点:
算法公开、计算量小、加密速度快、加密效率高

缺点:
安全性稍低，秘钥容易在传输过程中泄露

有人说对这个密钥加密不就完了，但对方如果要解密这个密钥还是要传加密密钥给对方，依然还是会被中间人截获的，这么看来直接传输密钥无论怎样都无法摆脱俄罗斯套娃的难题，是不可行的。

非对称加密

解决单向对称密钥的传输问题

公开密钥与私有密钥是一对，
如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；
如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。
因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

非对称加密算法实现机密信息交换的基本过程是：
甲方生成一对密钥并将其中的一把作为公用密钥向大家公开；乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用私钥对加密后的信息进行解密。

优点:安全

缺点:

• 速度较慢
• server 怎么把公钥安全地传输给 client 呢?
  如果直接传公钥，也会存在被中间人调包的风险。

常见的非对称加密算法有: RSA、Diffie-Hellman

CA 机构

全世界具有认证的 CA 就几家，分别颁布了 DV、OV、EV 三种，区别在于可信程度。DV 是最低的，只是域名级别的可信，EV 是最高的，经过了法律和审计的严格核查，可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字，例如 Apple、GitHub 的网站）。不同的信任等级的机构一起形成了层级关系。