一文读懂HTTPS⭐揭秘加密传输背后的原理与Nginx配置攻略
HTTP协议使用明文传输，不能保证安全性，而使用HTTPS却能够保证传输安全
为什么HTTPS能够保证传输安全呢？
HTTPS在HTTP的基础上除了要进行TCP三次握手，还会进行TLS的四次握手
（本文不对HTTP进行说明）
在进行TLS四次握手时会使用对称加密、非对称加密、数字证书的验证等多种方式一起来保证连接的安全
对称加密
在对称加密模型中，加密和解密使用的是同一个密钥
客户端使用密钥将明文转化为密文，服务端再使用相同的密钥将密文转化为明文
对称加密非常高效适合加密大量数据，但如果第三方恶意机构也拥有密钥就会变得不安全
非对称加密
在非对称加密模型中分为公钥和私钥，公钥（可以暴露给外界），私钥（自己留着）
客户端先向服务端申请公钥，客户端使用公钥将明文转换为密文，服务端再使用私钥将密文转换为明文
非对称加密加密效率不如对称加密，开销会更大
但非对称加密相对安全，即使公钥暴露，也不能拦截客户端请求进行解密
但第三方恶意机构可以伪装成服务端，对数据进行篡改并发送给真正的服务端，同时向客户端发访伪造公钥
为了解决这种问题，客户端、服务端要信任第三方权威机构并申请证书
申请证书
申请证书指的是服务端向第三方权威机构（CA）申请数字证书，有了数字证书后，客户端能够判断数据是否被篡改和公钥是否可信任
-
服务端生成公钥、私钥
-
服务端向CA申请证书
-
CA机构先使用hash得到数据摘要，再用自己的私钥加密生成数字签名，配合服务端公钥、申请信息等其他信息生成数字证书再返回
验证证书
客户端收到证书后，该如何验证数据是否被篡改？公钥是否可信呢？
由于证书中数字签名是由CA私钥加密的，那么解密就需要CA公钥
客户端首先要信任CA机构，必须有CA机构的根证书（主流OS或浏览器已内置）
客户端拿到服务端的证书后，使用CA公钥解密数字签名得到数据摘要，再使用生成证书时相同的hash加密数据获得数据摘要，再进行比较
（CA 公钥和hash 都是来自根证书）
如果不相等说明数据被篡改，让浏览器提示警告：证书不可信任
如果数据被篡改、公钥被替换，它们生成的数据摘要都会不相等，从而发出警告
HTTPS流程
HTTPS建立连接的流程会进行TCP三次握手+TSL四次握手
-
TCP三次握手
-
客户端请求服务端证书
-
服务端返回证书
-
客户端将证书中的数字签名使用CA公钥解密得到数据摘要，再使用CA相同的hash加密信息得到数据摘要，两个数据摘要相同说明数据未被篡改/公钥可信任
-
验证成功，根据服务端公钥生成对称密钥发送服务端
-
服务端使用私钥解密获取对称密钥，后续使用对称密钥加密/解密
在HTTPS中先请求证书、再校验证书、最后生成对称密钥，基于对称密钥高效的特点，即使后续通信数据量大，性能也不会太差
请求证书和校验证书可以看成非对称加密，因此HTTPS是通过第三方可信任机构、数字证书、非对称加密、对称加密一起实现的
nginx配置HTTPS
如果要使用HTTPS，可以在nginx中进行相关配置
其中 ssl_certificate 为数字证书的路径、ssl_certificate_key为服务端私钥的路径 (这两个文件可以由云服务器或OpenSSL生成)
shell
# ----------HTTPS配置-----------
server {
# 监听HTTPS默认的443端口
listen 443;
# 配置自己项目的域名
server_name www.xxx.com;
# 打开SSL加密传输
ssl on;
# 输入域名后，首页文件所在的目录
root html;
# 配置首页的文件名
index index.html index.htm index.jsp index.ftl;
# 配置 数字证书
ssl_certificate certificate/xxx.pem;
# 配置 服务器私钥
ssl_certificate_key certificate/xxx.key;
# 停止通信时，加密会话的有效期，在该时间段内不需要重新交换密钥
ssl_session_timeout 5m;
# TLS握手时，服务器采用的密码套件
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;
# 服务器支持的TLS版本
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# 开启由服务器决定采用的密码套件
ssl_prefer_server_ciphers on;
location / {
try_files $uri $uri/ /html/index.html;
}
}
# ---------HTTP请求转HTTPS-------------
server {
# 监听HTTP默认的80端口
listen 80;
# 如果80端口出现访问该域名的请求
server_name www.xxx.com;
# 将请求改写为HTTPS（这里写你配置了HTTPS的域名）
rewrite ^(.*)$ https://www.xxx.com;
}总结
对称加密模型只有一种密钥，加密/解密都使用这种密钥，高效但不安全
非对称加密模型分为公钥与私钥，公钥可以暴露给外界，而私钥自己保存，加密/解密开销大，但只是相对安全，遇到恶意第三方结构伪造成服务端篡改数据/伪造公钥还是不安全的
为了让客户端判断数据是否被篡改/公钥是否可信任，引入第三方权威可信机构
申请证书时，CA根据hash对数据进行加密得到数据摘要，再使用密钥对数据摘要进行加密得到数字签名，数字签名与其他信息形成数字证书
验证数字证书时，根据CA hash加密数据得到的数据摘要和使用CA公钥对证书中签名解密得到的数据摘要进行对比，不相同说明数据被篡改或公钥不可信，从而发出警告
客户端、服务端请求前都依赖第三方可信机构，客户端依赖CA根证书（CA hash、公钥），服务端依赖数据证书
HTTPS通过可信任的第三方结构、数字证书、非对称加密、对称加密等多种方式实现
最后（不要白嫖，一键三连求求拉~）
本篇文章被收入专栏 后端的网络基石，感兴趣的同学可以持续关注喔
本篇文章笔记以及案例被收入 Gitee-CaiCaiJava、 Github-CaiCaiJava，除此之外还有更多Java进阶相关知识，感兴趣的同学可以starred持续关注喔~
有什么问题可以在评论区交流，如果觉得菜菜写的不错，可以点赞、关注、收藏支持一下~
关注菜菜，分享更多技术干货，公众号：菜菜的后端私房菜