标签：消息发送 合法性 假设 bubuko 发布 protoc 获取 缓存 为什么
传统Http协议弊端是明文的，如果别人采用抓包分析可以获取到明文数据。
HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer），简单来讲就是加了安全的HTTP，即HTTP+SSL；我们知道HTTP通讯时，如果客户端C请求服务器S，那么可以通过网络抓包的形式来获取信息，甚至可以模拟服务器S端，来骗取与C端的通讯信息；这对互联网应用在安全领域的推广非常不利；HTTPS解决了这个问题。
安全套接字（Secure Socket Layer，SSL）协议是Web浏览器与Web服务器之间安全交换信息的协议，提供两个基本的安全服务：鉴别与保密。
SSL是Netscape于1994年开发的，后来成为了世界上最著名的web安全机制，所有主要的浏览器都支持SSL协议
目前有三个版本：2、3、3.1，最常用的是第3版，是1995年发布的。
SSL协议的三个特性
① 保密：在握手协议中定义了会话密钥后，所有的消息都被加密。
② 鉴别：可选的客户端认证，和强制的服务器端认证。
③ 完整性：传送的消息包括消息完整性检查（使用MAC）。
1）HTTPS的服务器需要到CA申请证书，以证明自己服务器的用途；
2）HTTP信息是明文传输，HTTPS信息是密文传输；
3）HTTP与HTTPS的端口不同，一个是80端口，一个是443端口；
可以说HTTP与HTTPS是完全不同的连接方式，HTTPS集合了加密传输，身份认证，更加的安全。HTTPS效率慢，HTTP效率高。
在微信小程序里面都限制只能有https协议、搜索引擎排名都对https优先收录
1.握手的时候使用的非对称加密算法 ，用来加密握手之后的请求和应答
2.传输信息的时候使用的对称加密，
3.保证数据的完整性用的是hash算法(数字签名)
证书的作用： 返回一些加密信息 颁发机构 加密算法 验证 有效期
非对称加密和对称加密：
非对称加密的目的： 确保对称加密的安全。 确保安全后才会采用对称加密进行传输。
先采用非对称加密： 确保对称加密的密钥安全
然后采用对称加密 ： 确保安全之后 才会使用对称加密传输
抓包工具抓不到 客户端
公钥在证书了里面。 客户单获取到证书后先验证有效期，再生成随机数。
注意： 生成公钥和证书只会搞一次 第一次的时候。 然后缓存到浏览器。 后面也就是不停的生成随机数了，给服务器验证。 公钥私钥每次都是新生成的话 效率太慢了！
证书过期了 情况下缓存就好了 重新请求访问之
后面的传输采用的 对称加密 进行传输 这样效率高
随机数每次生成！
小结： 客户端生成一个随机数 给服务器端 如果服务器端能够解密出来 就用这随机数作为密钥进行对称加密
1）客户端请求服务器，发送握手消息
2）服务器返回客户端自己的加密算法、数字证书和公钥；
3）客户端验证服务器端发送来的数字证书是否与本地受信任的证书相关信息一致；如果不一致则客户端浏览器提示证书不安全如下图所示
如果验证通过，则浏览器会采用自身的随机数算法产生一个随机数，并用服务器发送来的公钥加密；发送给服务器；这里如果有人通过攻击获取了这个消息，那也没用，因为他没有解密此段消息所需要私钥；验证通过的网站在浏览器地址栏的右边会有一安全锁的标识；
3）服务器解密得到此随机数，并用此随机数作为密钥采用对称加密算法加密一段握手消息发送给浏览器；
4）浏览器收到消息后解密成功，则握手结束，后续的信息都通过此随机密钥加密传输。
以上是服务端认证的情况，如果服务端对访问的客户端也有认证需求，则客户端也需要将自己的证书发送给服务器，服务器认证不通过，通讯结束；原理同上；
另外，一般在传输过程中为了防止消息窜改，还会采用消息摘要后再加密的方式，以此保证消息传递的正确性
1.客户端发送自己支持的加密规则给服务器，代表告诉服务器要进行连接了
2.服务器从中选出一套加密算法和hash算法以及自己的身份信息(地址等)以证书的形式发送给浏览器，证书中包含服务器信息，加密公钥，证书的办法机构
3.客户端收到网站的证书之后要做下面的事情：
4.验证证书的合法性
5.如果验证通过证书，浏览器会生成一串随机数，并用证书中的公钥进行加密
6.用约定好的hash算法计算握手消息，然后用生成的密钥进行加密，然后一起发送给服务器
服务器接收到客户端传送来的信息，要求下面的事情：
用私钥解析出密码，，用密码解析握手消息，验证hash值是否和浏览器发来的一致
使用密钥加密消息，回送如果计算法hash值一致，握手成功
证书信息：过期时间和序列号
所有者信息：姓名等
所有者公钥
假设几个场景：
微信小程序是必须的，然后后搜索引擎对HTTPS优先收录。
A(浏览器)和B(服务器)发送隐私的信息 ( http是明文传输怎么搞？
就算加密了，攻击者C获得了双方加密的密钥，也能获得双方的信息呀 ( 密钥丢失了怎么办呀？
就算攻击者C没有办法获得密钥，那么C向B(服务器)发送一些数据，那么B也不知道是不是A发送的呀 ( A是不是A？
HTTPS 混合加密 （对称加密和非对称加密）
公钥存放客户端 使用公钥加密 私钥在服务器端 采用私钥解密
破解出公钥也没用 私钥在服务器端 很难获取
HTTPS底层协议就是使用的SSL协议 也是使用对称加密传输（不需要自己生成密钥，浏览器自己生成）
如果对每个接口生成自己生成对称加密进行加密的话 会很麻烦的 如果几万个接口咋办
HTTPS协议 他的传出效率比传统的HTTP协议低很多
HTTP协议 底层端口默认443
阿里云配置HTTPS整数，购买一年的。
下载证书 配置到Nginx就OK了
注意要监听的端口号是 443
证书放到Nginx的相应的目录
标签：消息发送 合法性 假设 bubuko 发布 protoc 获取 缓存 为什么
原文地址：https://www.cnblogs.com/toov5/p/10323133.html
