https协议

2020-01-27
本博客所有文章采用的授权方式为 自由转载-非商用-非衍生-保持署名 ，转载请务必注明出处，谢谢。

声明：
本博客欢迎转发，但请保留原作者信息!
博客地址：任志帆的博客;
内容系本人学习、研究和总结，如有雷同，实属荣幸！

https协议

为什么需要https

  • HTTP是明文传输的，也就意味着，介于发送端、接收端中间的任意节点都可以知道你们传输的内容是什么。这些节点可能是路由器、代理等。 举个最常见的例子，用户登陆。用户输入账号，密码，采用HTTP的话，只要在代理服务器上做点手脚就可以拿到你的密码了。 用户登陆 –> 代理服务器（做手脚）–> 实际授权服务器

  • 在发送端对密码进行加密？没用的，虽然别人不知道你原始密码是多少，但能够拿到加密后的账号密码，照样能登陆。(这也是很多人觉得前端加密并没有啥软用)

HTTPS是如何保障安全的

稍微了解网络基础的同学都知道，HTTP是应用层协议，位于HTTP协议之下是传输协议TCP。TCP负责传输，HTTP则定义了数据如何进行包装。

从上面图中我们可以看出：HTTPS相对于HTTP有哪些不同呢？其实就是在HTTP跟TCP中间加多了一层加密层TLS/SSL。

神马是TLS/SSL？

通俗的讲，TLS、SSL其实是类似的东西，SSL中文叫做“安全套接层”，SSL是个加密套件，负责对HTTP的数据进行加密。TLS是SSL的升级版。现在提到HTTPS，加密套件基本指的是TLS。

传输加密的流程

原先是应用层将数据直接给到TCP进行传输，现在改成应用层将数据给到TLS/SSL，将数据加密后，再给到TCP进行传输。

就是这么回事。将数据加密后再传输，而不是任由数据在复杂而又充满危险的网络上明文裸奔，在很大程度上确保了数据的安全。这样的话，即使数据被中间节点截获，坏人也看不懂

HTTPS是如何加密数据的

一般来说，加密分为对称加密、非对称加密（也叫公开密钥加密）。

对称加密

  • 对称加密的意思就是，加密数据用的密钥，跟解密数据用的密钥是一样的。

  • 对称内容加密强度非常高，一般破解不了。但存在一个很大的问题就是无法安全地生成和保管密钥。假如客户端软件和服务器之间每次会话都使用固定的，相同的密钥加密和解密，肯定存在很大的安全隐患。如果有人从客户端端获取到了对称密钥，整个内容就不存在安全性了，而且管理海量的客户端密钥也是一件很复杂的事情

非对称加密

  • 非对称加密的意思就是，加密数据用的密钥（公钥），跟解密数据用的密钥（私钥）是不一样的。

  • 什么叫做公钥呢？其实就是字面上的意思——公开的密钥，谁都可以查到。因此非对称加密也叫做公开密钥加密。

  • 相对应的，私钥就是非公开的密钥，一般是由网站的管理员持有

公钥、私钥两个有什么联系呢？

  • 简单的说就是，通过公钥加密的数据，只能通过私钥解开。通过私钥加密的数据，只能通过公钥解开。

  • 很多同学都知道用私钥能解开公钥加密的数据，但忽略了一点，私钥加密的数据，同样可以用公钥解密出来。而这点对于理解HTTPS的整套加密、授权体系非常关键。

  • 非对称密钥交换很安全，但同时也是 HTTPS 性能和速度降低的“罪魁祸首”

HTTPS 的底层原理如下

  • 当我们访问一个 HTTPS 网站的时候，客户端通过发送 Client Hello 报文开始建立与服务器的 SSL 通信，报文中包含了 SSL 协议版本、加密组件、压缩算法等信息，另外，还有一个随机数，用于后续对称加密密钥的协商

  • 服务器可以进行 SSL 通信时，会以 Server Hello 报文作为应答，和客户端一样，在报文中包含 SSL 协议版本、加密组件、压缩算法等信息，同时还有一个随机数，用于后续对称加密密钥的协商

  • 接下来，服务器会以 Certificate 报文的形式给客户端发送服务端的数字证书，其中包含了非对称加密用到的公钥信息。最后，服务器还会发送 Server Hello Done 报文告知客户端，最初阶段的 SSL 握手协商部分结束

  • 客户端当然不相信这个证书，于是从自己信任的 CA 仓库中，拿 CA 证书里面的公钥去解密 HTTPS 网站的数字证书（证书是通过 CA 私钥加密的，所以要用公钥解密），如果能够成功，则说明 HTTPS 网站是可信的

  • 证书验证完毕之后，觉得这个 HTTPS 网站可信，于是客户端计算产生随机数字 Pre-master，用服务器返回的数字证书中的公钥加密该随机数字，再通过 Client Key Exchange 报文发送给服务器，服务器可以通过对应的私钥解密出 Pre-master。到目前为止，无论是客户端还是服务器，都有了三个随机数，分别是：自己的、对端的，以及刚生成的 Pre-Master 随机数。通过这三个随机数，可以在客户端和服务器生成相同的对称加密密钥

  • 有了对称加密密钥，客户端就可以通过 Change Cipher Spec 报文告知服务器以后都采用该密钥和协商的加密算法进行加密通信了

  • 然后客户端还会发送一个 Encrypted Handshake Message 报文，将已经商定好的参数，采用对称加密密钥进行加密，发送给服务器用于数据与握手验证

  • 同样，服务器也可以发送 Change Cipher Spec 报文，告知客户端以后都采用协商的对称加密密钥和加密算法进行加密通信了，并且也发送 Encrypted Handshake Message 报文进行测试。当双方握手结束之后，就可以通过对称加密密钥进行加密传输了

这个过程除了加密解密之外，其他的过程和 HTTP 是一样的，过程也非常复杂。

上面的过程只包含了 HTTPS 的单向认证，也即客户端验证服务端的证书，大部分场景下使用的都是单向认证，也可以在更加严格安全要求的情况下，启用双向认证，双方互相验证证书，比如银行的网银系统就是这样，需要客户端安装数字证书后才能登录，其实就要服务端要要验证客户端的合法性

SSL 与 TLS

TLS（Transport Layer Security，传输层安全）是 SSL 的升级版（Secure Socket Layer，安全套接层），建立在 SSL 3.0 协议规范之上，由于 SSL 这一术语非常常用，所以通常我们把 SSL 和 TLS 统称为 SSL，从这个角度来说，不管是基于 TLS 还是 SSL 实现的 HTTPS，将其描述为 HTTP over SSL 并没有什么问题


章节列表