https协议详解

最新推荐文章于 2023-06-18 17:38:20 发布

遇到困难睡大觉-

最新推荐文章于 2023-06-18 17:38:20 发布

阅读量664

点赞数

分类专栏：网络协议文章标签： https 服务器 ssl

本文链接：https://blog.csdn.net/qq_35337506/article/details/129114951

版权

网络协议专栏收录该内容

12 篇文章 0 订阅

订阅专栏

HTTPS 概述

TTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https: URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。众所周知，WEB服务存在http和https两种通信方式，http默认采用80作为通讯端口，对于传输采用不加密的方式；https默认采用443，对于传输的数据进行加密传输。目前主流的网站基本上开始默认采用HTTPS作为通信方式

HTTP通信的缺点

从上面的图片可以看出，隔壁小王是可以截取到你的账号密码，然后为所欲为的。为了防止出现这种情况，就需要对传输的内容进行加密。

对称加密

对称加密算法的加密和解密都是用同一个密钥，在一定条件下，对称加密可以解决数据传输安全性的问题。比如我在登录某个网站的时候，需要填写账户名和密码进行登录，客户端把登录的表单信息进行对称加密后再传输，这时候就算小王截获数据包，他也无法获取数据的内容，因为数据已经被加密了。但是服务器收到数据后也是一脸懵逼，你发来的加密的数据包服务器也不知道解密的密钥！

那是不是客户端与服务端在通信之前应该先协商密钥呢？客户端可以通知服务器需要开启数据传输了，然后服务器告诉客户端，咱们以后用xxxx这个密钥进行加密解密吧！

这样内容是可以加密传输了，但是上图中第一步协商密钥的过程又同样存在安全的问题！万一小王截获了协商密钥的数据，那后续加密传输的数据对小王来说无异于未加密！所以，对称加密存在密钥协商的问题！

非对称加密

基于对称加密存在的问题，又有了非对称加密。非对称加密算法需要一组密钥对，分别是公钥和私钥，这两个密钥是成对出现的。公钥加密的内容需要用私钥解密，私钥加密的内容需要用公钥解密！私钥由服务器自己保存，公钥发送给客户端。客户端拿到公钥后就可以对请求进行加密后发送给服务端了，这时候就算被小王截获，小王没有私钥也无法解密发送的内容，这样确保了客户端发送到服务端数据的“安全”！但是由于公钥也需要通过网络发送给客户端，同样能被小王截获，这样服务器私钥加密后的内容依然可以被小王截获并解密，并且非对称加密的效率很低。

对称加密和非对称加密都存在密钥传输的问题，但是至少非对称加密可以保证客户端传输给服务端的内容无法被“破解”，而对称加密算法性能又比较好，那我们是不是可以这样子呢。第一次通信的时候服务端发送公钥给客户端，由客户端产生一个对称密钥，通过服务端的公钥加密后发送给服务端，后续的交互中都通过对称密钥进行加密传输。也就是说先通过非对称密钥加密对称密钥，通过对称密钥加密实际请求的内容。

过程：

1. 某网站拥有用于非对称加密的公钥A1、私钥A2。

2. 浏览器向网站服务器请求，服务器把公钥A1明文给传输浏览器。

3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A1加密后传给服务器。

4. 服务器拿到后用私钥A2解密得到密钥X。

5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密即可。

但是这样依旧存在漏洞，中间人可以伪装成服务器欺骗客户端，如下图

过程：

1. 某网站拥有用于非对称加密的公钥A1、私钥A2。

2. 浏览器向网站服务器请求，服务器把公钥A1明文传输给浏览器。

3. 中间人劫持到公钥A1，保存下来，把数据包中的公钥A1替换成自己伪造的公钥B1（它当然也拥有公钥B1对应的私钥B2）。

4. 浏览器随机生成一个用于对称加密的密钥X，用公钥B1（浏览器不知道公钥被替换了）加密后传给服务器。

5. 中间人劫持后用私钥B2解密得到密钥X，再用公钥A1加密后传给服务器。

6. 服务器拿到后用私钥A2解密得到密钥X。

所以这里要解决客户端怎么可以确定对方是真正的目标服务器，怎么可以证明服务器的身份？

数字证书

现实生活中，如果想证明某身份证号一定是小明的，怎么办？看身份证。这里政府机构起到了“公信”的作用，身份证是由它颁发的，它本身的权威可以对一个人的身份信息作出证明。互联网中也有这么一个公信机构，CA 机构。

网站在使用HTTPS前，需要向“CA机构”申请颁发一数字证书，数字证书里有证书持有者、证书持有者的公钥等信息。服务器把证书传输给浏览器，浏览器从证书里取公钥就可以了。然而这里又有一个显而易见的问题：证书本身的传输过程中，如何防止被篡改？即如何证明证书本身的真实性？数字证书怎么防伪呢？

数字签名

我们把证书内容生成一份“签名”，比对证书内容和签名是否一致就能察觉是否被篡改。这种技术就叫数字签名。

数字签名的制作过程：

1. CA拥有非对称加密的私钥和公钥。

2. CA对证书明文信息进行hash。

3. 对hash后的值用私钥加密，得到数字签名。

验证过程：

1. 拿到证书，得到明文T1，数字签名S1。

2. 用CA机构的公钥对S1解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S2。

3. 用证书里说明的hash算法对明文T1进行hash得到T2。

4. 比较S2是否等于T2，等于则表明证书可信。

完整的https流程：

client向server发送请求https://baidu.com，然后连接到server的443端口。
服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。
传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
客户端解析证书

这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值（密钥）。然后用证书对该随机值进行加密。
传送加密信息

这部分传送的是用证书加密后的密钥（随机值），目的就是让服务端得到这个密钥（随机值），以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
服务端加密信息

服务端用私钥解密，得到了客户端传过来的密钥（随机值），然后把内容通过该值进行对称加密。
开始对称加密传输数据