https详解（轻松搞懂HTTPS工作原理）
https详解（轻松搞懂HTTPS工作原理）SSL和TSL是一种安全协议。SSL和TSL位于传输层之上，在数据到达传输层之前都会经过SSL/TSL协议层处理，由SSL/TSL保证数据的机密性和完整性。什么是SSL/TSLHTTPS是在HTTP协议上加了SSL加密层HTTPS与HTTP的区别HTTP直接与TCP层通信，而HTTPS在SSL层通信，然后由SSL层与TCP层通信，可以理解为HTTPS = HTTP SSL
目录- 概述
- 已有HTTP，为何还要HTTPS?
- HTTPS是什么？
- SSL/TSL中的加密技术
- HTTPS如何解决内容可能被窃听的问题
- HTTPS如何解决报文可能遭篡改问题
- HTTPS如何解决通信方身份可能被伪装的问题
- HTTPS工作流程
- php7进阶到架构师相关阅读
这是关于php进阶到架构之后端开发必备学习的系列课程：深入浅出，轻松搞懂HTTPS工作原理
学习目标：
- 了解HTTPS工作原理
- 掌握HTPPS采用对称加密和非对称加密两者并用的混合加密机制的思想，日后工作中涉及安全方面可以运用此机制
HTTP存在哪些问题？
- 信息是通过明文传输（不加密），内容可能被窃听
- 无证确保报文的完整性（信息的准确度），内容可能被篡改
- 不能验证通信方的身份，可以被伪装，存在被“钓鱼欺诈”的可能
为了解决以上问题，于是就有了HTTPS。
HTTPS是什么？HTTPS是在HTTP协议上加了SSL加密层
HTTPS与HTTP的区别
HTTP直接与TCP层通信，而HTTPS在SSL层通信，然后由SSL层与TCP层通信，可以理解为HTTPS = HTTP SSL
什么是SSL/TSL
SSL和TSL是一种安全协议。SSL和TSL位于传输层之上，在数据到达传输层之前都会经过SSL/TSL协议层处理，由SSL/TSL保证数据的机密性和完整性。
SSL/TSL中的加密技术SSL/TSL安全协议保证数据安全的技术基础就是加密算法。
接下来，我们先了解一些跟HTTPS有关的加密算法的知识。
对称密钥加密
对称加密就是加密和解密使用同一个密钥的加密技术
对称加密
在对称加密中，发送端和接收端使用相同的密钥进行通信。
发送端使用共享的密钥发送报文，然后将密文发送到接收端。
接收端使用相同密钥解密密文，恢复原始数据。
非对称密钥加密
非对称加密，加密和解密使用使用不同密钥的加密技术
非对称加密
非对称加密技术使用了不同的密钥进行通信。
在发送端使用公钥对报文进行加密（公钥就是所有人都可以获取到的密钥），
然后在接收端使用私钥对加密的密文进行解密
HTTPS如何解决内容可能被窃听的问题HTTPS采用对称加密和非对称加密两者并用的混合加密机制
对称密钥的好处是解密的效率比较快，但是如何安全告知对方密钥就成了问题。
这个问题可以使用非对称加密算法，因为就算你拦截到了数据和公钥（公钥用来加密数据），但是没有对应的私钥，也是不能破解内容的。
具体做法：
发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，
然后对方用自己的私钥解密拿到“对称的密钥”，
这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信
HTTPS对报文的内容使用对称加密算法，即加密和解密是同一个密钥。
同时对称加密使用的密钥通过非对称加密，确保对称加密的密钥是安全的。
这样既保证了数据的安全性（非对称加密保证了对称密钥传输的安全），又提高了效率（对称加密比非对称加密速度快）。
HTTPS如何解决报文可能遭篡改问题网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？----校验数字签名。
数字签名是附加在报文上的特殊加密校验码。数字签名可以防止报文被篡改，如果有恶意攻击在传输过程在篡改了报文，那么校验的时候校验和就不再匹配，因此可以确认报文被篡改了。
数字签名如何生成？
数字签名生成流程
传输的报文 哈希（对称加密的密钥）=> 消息摘要（即传输的密文，可以通过对称密钥解密）
消息摘要 私钥加密（或公钥加密）=>数字签名
注意：
非对称加密是公钥加密则私钥解密，私钥加密则公钥解密。
私钥和公钥是一对，谁都可以加解密。
HTTPS将【消息摘要（对称加密的报文） 数字签名】一起传送给接收方。那对方如何校验签名呢？
数字签名如何验证？
假设接收方接收到的信息摘要为A，
接收方用公钥将获得的数字签名进行解密，得到解密后的消息摘要，设为B
如果解密后的消息摘要和接收的消息摘要相同（即A=B），则签名验证通过，
否则验证签名不通过。
这样就解决了报文可能遭篡改的问题
HTTPS如何解决通信方身份可能被伪装的问题假设客户端C和服务器端S通信，
服务端S将消息连同数字签名一起发送给客户端C，客户端C接收到消息后，
通过校验数字签名，就可以验证接收到的消息就是服务端S发送的。
当然，客户端C和服务器端S通信的前提是客户端C知道服务端S的公钥。但客户端C拿到的公钥如何证明是服务端S的呢？
此时就需要引入了证书颁发机构（Certificate Authority，简称CA），CA数量并不多，客户端C内置了所有受信任CA的证书。CA对服务器端S的公钥（和其他信息）数字签名后生成证书。
数字证书认证机构的业务流程：
- 服务器的运营人员向第三方机构CA提交公钥、组织信息、域名等信息并申请认证
- CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等
- 如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。 其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名;
- 客户端 Client 向服务器 Server 发出请求时，Server 返回证书文件;
- 客户端 Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
- 客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。
HTTPS工作流程
- Client发起一个HTTPS（比如https://juejin.im/user/5a9a9cdcf265da238b7d771c）的请求
- Server把事先配置好的公钥证书（public key certificate）返回给客户端
- Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面等。如果验证通过则继续，不通过则显示警告信息。
- Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。
- Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。
- Server使用对称密钥加密“明文内容A”，发送给Client
- Client使用对称密钥解密响应的密文，得到“明文内容A”。
- Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”
https://www.kancloud.cn/gofor/gofor
最后，欢迎大家留言补充，讨论~~~
