HTTPS协议
目录
1.HTTPS概述
1.1什么是HTTPS
1.2HTTPS的好处
2.HTTP跟HTTPS对比
3.加密算法
1）对称加密
2）非对称加密
3）如果使用对称加密进行http通信会发生什么？
4.数字证书
1) 如何验证证书的真实性，如何防止证书被篡改？——数字签名
2)如何防止证书被调包？——验证域名
5.HTTPS通信的大致流程
6.TLS协议和SSL协议的区别
7.TLS协议
1)命名规范
2)组成部分
8.ECDHE四次握手
1)概述
2)TLS第一次握手
3)TLS第二次握手
4)TLS第三次握手
5)TLS第四次握手
9.参考资料
HTTPS_kk阿彬-CSDN博客
《码 出 高 效：Java开发手册》1.6.5HTTPS
1.HTTPS概述
1.1什么是HTTPS
HTTPS： Hypertext Transfer Protocol Secure 是基于HTTP协议的一种拓展 HTTP本身并不保证传输的安全性 使用TLS/SSL协议进行加密
1.2HTTPS的好处
HTTP在传输的过程当中是明文传输 在传输的过程中会有如下风险：
1.窃听风险
内容是明文 被获取之后会有窃听风险
2.篡改风险
中间人可以截取报文篡改之后再发送给对方
3.冒充风险
比如你以为是在和某宝通信，但实际上是在和一个钓鱼网站通信。
HTTPS 是如何解决上面的三个风险的？
-
混合加密的方式实现信息的机密性，解决了窃听的风险。 -
摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。 -
将服务器公钥放入到
数字证书中，解决了冒充的风险。
2.HTTP跟HTTPS对比
HTTPS协议在端口方面新开了个443端口号 定义了新的协议名 除此之外 都沿用HTTP协议
在安全性方面
由于HTTP协议使用的是明文传输 而HTTPS在传输过程中加入了SSL/TLS安全协议 使得报文能更加安全
在性能方面
HTTPS由于增加了SSL层 在客户端与服务器端都进行了加密解密的运算处理
因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。
针对速度变慢这一问题，并没有根本性的解决方法
因此
如果是非敏感信息建议使用HTTP通信
如果是敏感信息使用HTTPS通信
3.加密算法
分为两种
1.对称加密 不分公钥私钥 加密解密使用同一个密钥
2.非对称加密 分公钥私钥 加密解密不适用同一个公钥
1）对称加密
在数据传送之前 发送方与接收方商定一个密钥进行加密通信
而商定密钥的过程中如果密钥泄露 那么密钥也就变得不安全了
2）非对称加密
非对称加密有一对密钥
分为公钥和私钥
如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；
如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。
因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
非对称加密算法实现机密信息交换的基本过程是：
甲方生成一对密钥并将其中的一把作为公用密钥向大家公开；乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用私钥对加密后的信息进行解密。
倘若直接传输公钥 公钥也有被截取篡改的风险
3）如果使用对称加密进行http通信会发生什么？
是通过这样一种方式来建立安全的SSL连接的。按照上述逻辑，用户甲与用户乙进行非对称加密传输的过程如下:
（1）甲告诉乙，使用RSA算法进行加密。乙说，好的。
（2）甲和乙分别根据RSA生成一对密钥，互相发送公钥。
（3）甲使用乙的公钥给乙加密报文信息。
（4）乙收到信息，并用自己的密钥进行解密。
（5）乙使用同样方式给甲发送信息，甲使用相同方式进行解密。
这个过程，看起来似于无懈可击 但是如果在公钥运输过程中公钥被中间人截取了 并传输了假的公钥给接收者 接收者运用假的公钥将自己的敏感信息全部告诉了中间人 那么信息的传输就会陷入不安全
那么怎么解决这个问题呢？
使用数字证书
4.数字证书
1)为什么用数字证书？ 解决公钥传输问题
server 可以向 CA 申请证书，在证书中附上公钥，然后将证书传给 client。用第三方权威机构保证公钥的正确性。
当 client 拿到证书后，就可以获得证书上的公钥，再用此公钥加密 对称加密密钥传给 server 即可。
证书内容如下：
如何验证证书的真实性，如何防止证书被篡改？——数字签名
步骤一、 使用摘要算法为证书明文生成摘要
使用第三方权威机构的私钥对摘要进行加密生成数字签名
如何生成摘要？
生成摘要是把任意长度的输入揉和而产生长度固定的伪随机输出的算法，无论输入的消息有多长，计算出来的消息摘要的长度总是固定的，一般来说，只要内容不同，产生的摘要必然不同（相同的概率可以认为接近于 0），所以可以验证内容是否被篡改了。
步骤二
客户端拿到证书用同样的摘要算法对证书明文计算摘要 对比证书是否被更改
用第三方权威机构的私钥对摘要进行加密之后 如果摘要运用公钥无法解密 或者证书内容被篡改 也无法解密 都会被认定该证书无效
那CA 公钥如何安全地传输到 client ？
如果还是从 server 传输到 client，依然无法解决公钥被调包的风险，实际上此公钥是存在于 CA 证书上，而此证书（也称 Root CA 证书）被操作系统信任，内置在操作系统上的，无需传输。
当server 传输 CA 颁发的证书，客户中收到证书后使用内置 的CA 证书中的公钥来解密签名，验签即可，这样的话就解决了公钥传输过程中被调包的风险（因为压根不用传输）。
如何防止证书被调包？——验证域名
任何站点都可以向权威机构申请证书 包括中间人
那么可以将正常站点发给客户端证书可以替换成自己的证书吗？
如果client只验证签名的话，确实无法发现被掉包，但是client除了通过验签的方式验证证书是否合法之外，还会验证证书上的域名与自己的请求域名是否一致，中间人中途虽然可以替换自己向 CA 申请的合法证书，但此证书中的域名与 client 请求的域名不一致，client 会认定为不通过！
5.HTTPS通信的大致流程
(1）浏览器向服务器发送请求，请求中包括浏览器支持的协议，并附带一个随机数。
(2）服务器收到请求后，选择某种非对称加密算法，把数字证书签名公钥、身份信息发送给浏览器，同时也附带一个随机数。
(3）浏览器收到后,验证证书的真实性,用服务器的公钥发送握手信息给服务器。(4）服务器解密后，使用之前的随机数计算出一个对称加密的密钥，以此作为加密信息并发送。
( 5）后续所有的信息发送都是以对称加密方式进行的。
6.TLS协议和SSL协议的区别
7.TLS协议
1)命名规范
基本格式就是密钥交换算法 - 签名算法 - 对称加密算法 - 摘要算法 组成的一个密码串，有时候还有分组模式
2)组成部分
记录协议（Record Protocol）
规定了TLS收发数据的基本单位：记录（record）。它有点像是TCP里的segment，所有的其他子协议都需要通过记录协议发出。但多个记录数据可以在一个TCP包里一次性发出，也并不需要像TCP那样返回ACK。
警报协议（Alert Protocol）
职责是向对方发出警报信息，有点像是HTTP协议里的状态码。
比如， protocol_version就是不支持旧版本，bad_certificate就是证书有问题，收到警报后另一方可以选择继续，也可以立即终止连接。
握手协议（Handshake Protocol）
TLS里最复杂的子协议，要比TCP的SYN/ACK复杂的多，浏览器和服务器会在握手过程中协商TLS版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统。
变更密码规范协议（Change Cipher Spec Protocol）
它就是一个“通知”，告诉对方，后续的数据都将使用加密保护。那么反过来，在它之前，数据都是明文的。
8.ECDHE四次握手
1)概述
2)TLS第一次握手
客户端首先会发一个「Client Hello」消息，消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random）。
3)TLS第二次握手
服务端收到客户端的打招呼，会返回四条数据：
1、「Server Hello」
包括：
服器确认的 TLS 版本号，
随机数（Server Random），
从客户端的密码套件列表选择的一个合适的密码套件。密码套件解析：
「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」
1
对称密钥协商算法使用 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
4)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)
1
主密钥有48字节，但它也不是最终用于通信的会话密钥，还会再用PRF扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）等等，避免只用一个密钥带来的安全隐患。
2、有了主密钥和派生的会话密钥，客户端发一个「Change Cipher Spec」，
3、然后再发一个“Finished”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证。
意思就是告诉服务器：“后面都改用对称算法加密通信了啊，用的就是打招呼时说的AES，加密对不对还得你测一下。”
此时Client就可以抢跑的给Server发数据了
5)TLS第四次握手
服务端也会有一个同样的操作，发「Change Cipher Spec」和「Finished」消息，如果双方都验证加密和解密没问题，那么握手正式完成。于是，就可以正常收发加密的 HTTP 请求和响应了。