HTTP
概念
++HTTP 默认工作在 TCP 协议 80 端口。++
HTTP 协议以明文方式发送内容，不提供任何方式的数据加密。
超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。
http由于不加密，所以账号密码都能通过抓包获取到。
不使用HTTPS可能导致中间人攻击：
- 不安全的Wi-Fi网络： 在咖啡店、机场或其他公共场所的免费Wi-Fi网络中，攻击者可以轻松地设置一个名为“Free Wi-Fi”的网络，诱使用户连接。一旦用户连接，攻击者就可以拦截并读取他们的网络流量，包括登录凭证。
- 家庭/办公室网络被入侵： 如果家庭或办公室网络的安全措施不足，攻击者可以通过社会工程学或其他手段获取访问权限，然后设置中间人攻击，拦截网络流量。
- 移动网络中的攻击： 在移动网络中，攻击者可能会攻击基站或网关，从而拦截移动设备的数据流量。
- 通过软件漏洞进行攻击： 如果用户的操作系统或浏览器存在已知的安全漏洞，攻击者可以利用这些漏洞来安装恶意软件，从而实现中间人攻击。
- 通过社交工程学进行攻击： 攻击者可能会通过电子邮件或电话与用户联系，假装是可信的实体，并诱使用户点击链接或下载文件，从而在用户的设备上安装中间人攻击的软件。
- 通过物理手段进行攻击： 在极端情况下，攻击者可能会直接物理接触用户的设备，例如通过USB攻击或安装恶意软件。
HTTPS
概念
HTTPS为Hypertext Transfer Protocol Secure，即超文本传输安全协议。
它是一种透过计算机网络进行安全通信的传输协议。
HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。
++HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。++
++HTTPS 默认工作在 TCP 协议443端口。++
原理
1、客户端发起 HTTPS 请求
即类似浏览器输入https地址，然后回车访问。
2、服务端的配置
采用 HTTPS 协议的服务器必须要有一套数字证书，此证书可以服务器自己生成，也可以向CA组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问（自己生成的，在浏览器会弹出您的连接不是私密连接，这是由于浏览器即客户端会去向CA组织验证此证书的安全性，如果不是在CA组织申请的就会提示不安全，这个过程就是下面的第四步），而使用受信任的公司申请的证书则不会弹出提示页面。
3、传送证书
这个数字证书里面主要的就是包含了公钥，还包含了很多信息，如证书的颁发机构，过期时间等等。
++如果没有传送证书这个过程，我们在客户端手动安装证书，证书也有很多种格式。++
4、客户端解析证书
这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会警告，提示证书存在问题。
在浏览器，比如证书过期，那么在左上角会有不安全的字样，和https红色中间划线。
如果证书没有问题，那么就生成一个随机值，然后用证书（里面携带的公钥）对该随机值进行加密（对称算法加密）。
5、传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了（对称算法加解密）。
6、服务端解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(密钥)。
后面进行数据的通信就可以通过该值进行对称加密。
7、传输加密后的信息
这部分信息是服务端用私钥加密后的信息，可以在客户端被还原。
8、客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。
问题
通过原理我们可以知道https加解密过程中出现了两次加密（对称加密和非对称加密），为什么要两次而不是只需一次就行了？或者说为什么不用两次对称加密，而是一次对称加密和和一次非对称加密？这是因为对称加密速度快，安全性不高，而非对称加密速度慢，安全性高的性质决定，所以我们用非对称算法加密密钥，对称算法加密内容。我们知道在对称加解密的过程中，产生的随机值(密钥)是很重要的，绝不能泄露，所以客户端把此密钥告诉服务端的一定要确保安全的（用非对称算法加密）。
SSL/TLS
https://segmentfault.com/a/1190000002554673
数字证书
什么是数字证书
我们知道https过程中存在数字证书，这个数字证书包括了服务端的公钥、权威机构的信息、服务端域名，签名算法，签名哈希算法以及证书对应的域名，证书的到期时间，还有经过CA私钥签名之后的额外内容（先通过Hash函数计算之前的内容得到证书的所谓的数字摘要，然后用权威机构私钥加密数字摘要，这样就得到了所谓的数字签名/数字指纹)，
为什么要对内容进行Hash？这是提供了防止内容被篡改的验证手段。
为什么还要利用CA私钥对数字摘要进行签名？这是假如内容篡改了，然后用篡改后的内容计算数字摘要，接收证书方就无法确认是否内容被篡改过，所以需要利用CA私钥再签名。
客户端收到服务端发来的证书后，就会利用根据证书里的机构信息，去本地的电脑的权威证书库中寻到对应的机构的公钥，使用公钥对数字签名进行解密，拿到数字摘要，然后再根据证书里一样的hash算法信息，去计算证书的内容，得到数字摘要，跟之前解密拿到的数字摘要对应比较，如果一样则说明证书没有被篡改，后面就可以拿证书内容里的公钥去干事情了。
数字证书的格式
- jks是JAVA的keytools证书工具支持的证书私钥格式。
可利用java的keytool工具来生成jks证书请求文件：
keytool -genkey -alias zhy_server -keyalg RSA -keystore zhy_server.jks -validity 3600 -storepass 123456
您的名字与姓氏是什么?
[Unknown]: zhang
您的组织单位名称是什么?
[Unknown]: zhang
您的组织名称是什么?
[Unknown]: zhang
您所在的城市或区域名称是什么?
[Unknown]: xian
您所在的省/市/自治区名称是什么?
[Unknown]: shanxi
该单位的双字母国家/地区代码是什么?
[Unknown]: cn
CN=zhang, OU=zhang, O=zhang, L=xian, ST=shanxi, C=cn是否正确?
[否]: y
输入 <zhy_server> 的密钥口令
(如果和密钥库口令相同, 按回车):123456
zhy_server.jks来签发证书，即可生成包含公钥的证书zhy_server.cer：
keytool -export -alias zhy_server
-file zhy_server.cer
-keystore zhy_server.jks
-storepass 123456
- pfx是微软支持的私钥格式。
- cer是证书的公钥格式。
双向认证
首先对于双向证书验证，也就是说，客户端也会有个“jks文件”，服务器那边会同时有个“cer文件”与之对应。
我们已经生成了zhy_server.kjs和zhy_server.cer文件。
接下来按照生成证书的方式，再生成一对这样的文件，我们命名为:zhy_client.jks,zhy_client.cer.
然后在服务端开始客户端的认证和客户端的证书即可，此时再拿浏览器已经无法访问到我们的服务了，会显示基于证书的身份验证失败。
项目
netty实现https服务器
http://me.heawill.top/upload/2022/08/netty_https_server.zip
攻击
中间人攻击
假设有一个攻击者处于“浏览器”和“网站服务器”的通讯线路之间(比如公共WIFI)，它的攻击过程如下：
服务器向客户端发送公钥。
攻击者截获公钥，保留在自己手上。
然后攻击者自己生成一个伪造的公钥，发给客户端。
客户端收到伪造的公钥后，生成加密hash值发给服务器。
攻击者获得加密hash值，用自己的私钥解密获得真秘钥。
同时生成假的加密hash值，发给服务器。
服务器用私钥解密获得假秘钥。
服务器用假秘钥给客户端发送信息，攻击者就可以截获解码消息了。
FIddler就是通过这种方式截获HTTPS信息。
FIddler是一个可以抓包https的工具。
上面问题的根源是因为“缺乏身份认证机制”，需要验证伪造的公钥是否是网站服务器的，我们客户端可以通过验证公钥中的host，防止被中间人攻击。
具体样例就是我们使用okhttp这个库的时候，OkHttpClient.Builder有个hostnameVerifier方法可以用来设置，默认是开启验证，我们可以使用下面代码创建一个不开启验证的配置类：
public static HostnameVerifier DO_NOT_VERIFY = (hostname, session) -> true;
参考
HTTP 与 HTTPS 的区别
https://www.runoob.com/w3cnote/http-vs-https.html
数字签名、数字证书与HTTPS是什么关系？
https://www.zhihu.com/question/52493697
HTTP和HTTPS协议，看一篇就够了
https://blog.csdn.net/xiaoming100001/article/details/81109617
Android Https相关完全解析 当OkHttp遇到Https
http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0831/3393.html
java hostnameverifier_关于HostnameVerifier接口的解读
https://blog.csdn.net/weixin_31315007/article/details/114725172