安全是相对的，虽然我们把CA的公钥内置到浏览器里面去了，但还是有办法对内置的进行更改，我们只能够去相对的提高公钥传输的安全性，真到那个时候，我们可以采用吊销证书来解决
HTTPS
◼ HTTPS（HyperText Transfer Protocol Secure），译为：超文本传输安全协议
常称为HTTP over TLS、HTTP over SSL、HTTP Secure
over通过的意思，就是HTTP使用了TLS
由网景公司于1994年首次提出
很早之前只有网景和微软推出了自己的浏览器，有自己的标准。在后面的竞争当中，网景输了，IE（微软）赢了，但是IE还是不好用，所以google推出了google浏览器
在浏览器输网址使用HTTPS，会说我们是安全的
使用HTTP会说我们是不安全的
点击域名，不显示协议的，一般是HTTP
◼ HTTPS的默认端口号是443（HTTP是80）
◼ 现在在浏览器上输入http://www.baidu.com
服务器会返回给浏览器302
浏览器会自动重定向到https://www.baidu.com
是服务器告诉浏览器的
百度直接输域名默认使用HTTPS
SSL/TLS
◼ HTTPS是在HTTP的基础上使用SSL/TLS来加密报文，对窃听和中间人攻击提供合理的防护
使用HTTPS，会让传输通道加密，整个HTTP的报文都是密文
HTTP是不安全的，但是加上SSL/TLS就变得安全了
◼ SSL/TLS也可以用在其他协议上，比如
FTP → FTPS（文件传输）
SMTP → SMTPS（邮件协议）
会让不安全的，变的安全
SSL/TLS
◼ TLS（Transport Layer Security），译为：传输层安全性协议
前身是SSL（Secure Sockets Layer），译为：安全套接层
以前叫SSL ，后面改名字叫TLS
◼ 历史版本信息
SSL 1.0：因存在严重的安全漏洞，从未公开过
SSL 2.0：1995年，已于2011年弃用（RFC 6176）
SSL 3.0：1996年，已于2015年弃用（RFC 7568）
TLS 1.0：1999年（RFC 2246）
TLS 1.1：2006年（RFC 4346）
TLS 1.2：2008年（RFC 5246）
TLS 1.3：2018年（RFC 8446）
✓ 有没有发现：TLS的RFC文档编号都是以46结尾
SSL/TLS—工作在那一层
在应用层和传输层之间，但属于应用层
报文给传输层之前要进行加密，因为传输层不负责加密
OpenSSL
◼ OpenSSL是SSL/TLS协议的开源实现，始于1998年，支持Windows、Mac、Linux等平台
Linux、Mac一般自带OpenSSL
Windows下载安装OpenSSL：https://slproweb.com/products/Win32OpenSSL.html
◼ 常用命令
生成私钥：openssl genrsa -out mj.key
使用RSA非对称算法
生成公钥：openssl rsa -in mj.key -pubout -out mj.pem
-in告诉openssl生成的是谁的公钥
-pubout告诉openssl等会我要生成的是公钥
公钥私钥其实就是一串文本
进入openssl特定的界面，就可以省略掉左边的openssl
◼ 可以使用OpenSSL构建一套属于自己的CA，自己给自己颁发证书，称为“自签名证书”
在互联网上，浏览器和操作系统里面只有靠谱的CA机构的公钥，我们的“自签名证书”它们肯定是辨别不了的，但是你可以在自己搭建的一套HTTPS服务环境里面玩，商用是不用想了
签名证书可以找一些免费的机构，或者是阿里云，付费的那一种
HTTPS的成本
因为HTTPS的成本，所以现在有些网站没有使用HTTPS协议，即使它很安全
◼ 证书的费用
便宜的几十块，贵的可以达到上万（一年的那一种）
◼ 加解密计算
传输的内容是完全加密的
◼ 降低了访问速度
消耗更多的CPU资源，对比HTTP来说，但是也不能这么说，因为HTTPS可以优化，说不定在未来，它会比HTTP访问的更快
◼ 有些企业的做法是：包含敏感数据的请求才使用HTTPS，其他保持使用HTTP
http://www.icbc.com.cn/
https://mybank.icbc.com.cn/
无所谓谁看都可以的数据使用HTTP
在以前没有HTTPS的时候，有些大公司，它们有庞大的网站数据都是用HTTP，现在你要想把全部的HTTP升级为HTTPS的，是不太现实的，它要有一个过度的过程，所以我们就选择升一部分数据敏感的，其它的保留HTTP
HTTPS的通信过程
◼ 总的可以分为3大阶段
① TCP的3次握手
② TLS的连接
前面两步搞定，就可以开始数据传输了
安全连接的过程集中在第二步，我们接下来讨论的也是第二步
③ HTTP请求和响应
与HTTP相比，就是在中间多了一步
TLS 1.2的连接
TLS 1.3在1.2的基础上简化了一下算法，基本上差不多
GCM加密算法的分组模式
有了分组模式，我们就可以去加密很大的东西，反复迭代，反复加密
◼ 大概是有10大步骤
主要是为了协商，协商TLS版本、加密套件、其他信息
◼ 图片中省略了中间产生的一些ACK确认
捕获过滤器
选择一个网络，在最里面输
显示过滤器
TLS 1.2的连接—①
① Client Hello
TLS的版本号
支持的加密组件（Cipher Suite）列表
✓ 加密组件是指所使用的加密算法及密钥长度等
加密组件都是不一样的，我总共支持21总
一个随机数（Client Random）
TLS 1.2的连接—②
② Server Hello
TLS的版本号
选择的加密组件
✓ 是从接收到的客户端加密组件列表中挑选出来的
一个随机数（Server Random）
TLS 1.2的连接—③
③ Certificate
服务器的公钥证书（被CA签名过的）
拆开掉，分开传输
TLS 1.2的连接—④
④ Server Key Exchange
用以实现ECDHE算法的其中一个参数（Server Params）
✓ ECDHE是一种密钥交换算法，用来决定用什么密钥生成什么密文
✓ 为了防止伪造，Server Params经过了服务器私钥签名
TLS 1.2的连接—⑤
⑤ Server Hello Done
告知客户端：协商部分结束
我该给你发的都发了
◼ 目前为止，客户端和服务器之间通过明文共享了
Client Random、Server Random、Server Params
这三个东西双方都有，目前来说，因为它们是共享，发送方和接收方都有
◼ 而且，客户端也已经拿到了服务器的公钥证书，接下来，客户端会验证证书的真实有效性（用浏览器自身存储的CA机构的公钥去认证）
服务器肯定会发这4（Server Hello、Certificate、Server Key Exchange、Server Hello Done）个东西，分开发，还是一起发，不是很重要
TLS 1.2的连接—⑥
⑥ Client Key Exchange
用以实现ECDHE算法的另一个参数（Client Params）
◼ 目前为止，客户端和服务器都拥有了ECDHE算法需要的2个参数：Server Params、Client Params
◼ 客户端、服务器都可以
使用ECDHE算法根据Server Params、Client Params计算出一个新的随机密钥串：Pre-master secret
然后结合Client Random、Server Random、Pre-master secret生成一个主密钥
之所以搞得这么复杂，都是为了提高安全性
最后利用主密钥衍生出其他密钥：客户端发送用的会话密钥、服务器发送用的会话密钥等
用多个密钥可以保证安全，客户端发送的消息，服务器要用客户端发送消息的密钥进行解密，服务器发送的消息也是如此
TLS 1.2的连接—⑦
⑦ Change Cipher Spec
告知服务器：之后的通信会采用计算出来的会话密钥进行加密
TLS 1.2的连接—⑧
⑧ Finished
包含连接至今全部报文的整体校验值（摘要），加密之后发送给服务器
客户端前面发的所有东西提取出来加密成摘要值，利用会话密钥加密摘要值
这次握手协商是否成功，要以服务器是否能够正确解密该报文作为判定标准
TLS 1.2的连接—⑨、⑩
⑨ Change Cipher Spec
⑩ Finished
跟7、8步相对应
到此为止，客户端服务器都验证加密解密没问题，握手正式结束
后面开始传输加密的HTTP请求和响应
用会话密钥进行加密
中间人攻击无法破解，因为会话密钥全是随机生成的，为这次会话做的准备
浏览器有会话密钥，不然谁来加密
要看它用什么密钥交换算法，用不同的密钥交换算法，过程是不一样的，要看是左边的算好了传一个过去呢，还是各自计算呢
我们本次讨论的是用ECDHE密钥算法