Picker Ready Go

# http 和 https

# 介绍

HTTP 是超文本传输协议，被用于在Web浏览器和网站服务器之间传递信息，HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议 HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

HTTPS协议的主要作用可以分为两种：

  • 加密数据，建立一个信息安全通道，来保证数据传输的安全；
  • 身份认证，就是确认网站的真实性。

https

HTTPS 默认工作在 TCP 协议443端口，它的工作流程一般如以下方式：

  • 1、TCP 三次同步握手;
  • 2、客户端验证服务器数字证书;
  • 3、DH 算法协商对称加密算法的密钥、hash 算法的密钥;
  • 4、SSL 安全加密隧道协商完成;
  • 5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。

# 区别

  • 1、http是超文本传输协议，信息是明文传输，https 协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全；
  • 2、https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用；
  • 3、http的连接很简单，是无状态的；https 握手阶段比较费时，会使页面加载时间延长 50%，增加 10%~20%的耗电；
  • 4、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443；
  • 5、https 缓存不如 http 高效，会增加数据开销；？
  • 6、SSL 证书需要绑定 IP，不能再同一个 IP 上绑定多个域名，IPV4 资源支持不了这种消耗。

http

无状态:

HTTP协议 自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理。

使用HTTP协议每当有新的请求发送时，就会有对应的新响应产生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成 如此简单的。

可是，随着Web的不断发展，因无状态而导致业务处理变得棘手 的情况增多了。

比如，用户登录到一家购物网站，即使他跳转到该站的其他页面后，也需要能继续保持登录状态。针对这个实例，网站为了能够掌握是谁送出的请求，需要保存用户的状态。HTTP/1.1虽然是无状态协议，但为了实现期望的保持状态功能， 于是引入了Cookie技术。有了Cookie再用HTTP协议通信，就可以管理状态了。

无连接：

无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间，并且可以提高并发性能，不能和每个用户建立长久的连接，请求一次响应一次，服务端和客户端就中断了。

无连接有两种方式

  • 早期的http协议是一个请求一个响应之后，直接就断开了；
  • 现在的http协议1.1版本不是直接就断开了，而是等几秒钟，这几秒钟是等什么呢，等着用户有后续的操作，如果用户在这几秒钟之内有新的请求，那么还是通过之前的连接通道来收发消息，如果过了这几秒钟用户没有发送新的请求，那么就会断开连接，这样可以提高效率，减少短时间内建立连接的次数，因为建立连接也是耗时的，默认是3秒，但是这个时间是可以通过咱们后端的代码来调整的，自己网站根据自己网站用户的行为来分析统计出一个最优的等待时间。

# HTTPS协议通讯方式的建立

  • 1、客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接；
  • 2、Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端；
  • 3、客户端的浏览器与Web服务器开始协商SSL/TLS连接的安全等级，也就是信息加密的等级；？
  • 4、客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站；
  • 5、Web服务器利用自己的私钥解密出会话密钥；
  • 6、Web服务器利用会话密钥加密与客户端之间的通信。

# CA证书的申请及其使用过程

# 非对称加密优点

  • 非对称加密采用公有密匙和私有密匙的方式，解决了http中消息保密性问题，而且使得私有密匙泄露的风险降低;
  • 因为公匙加密的消息只有对应的私匙才能解开，所以较大程度上保证了消息的来源性以及消息的准确性和完整性。

# 非对称加密的缺点

  • 非对称加密时需要使用到接收方的公匙对消息进行加密，但是公匙不是保密的，任何人都可以拿到，中间人也可以。那么中间人可以做两件事，第一件是中间人可以在客户端与服务器交换公匙的时候，将客户端的公匙替换成自己的。这样服务器拿到的公匙将不是客户端的，而是中间人的。服务器也无法判断公匙来源的正确性。第二件是中间人可以不替换公匙，但是他可以截获客户端发来的消息，然后篡改，然后用服务器的公匙加密再发往服务器，服务器将收到错误的消息。?
  • 非对称加密的性能相对对称加密来说会慢上几倍甚至几百倍，比较消耗系统资源。正是因为如此，https将两种加密结合了起来。

为了应对上面非对称加密带来的问题，我们就引入了数字证书与数字签名。

CA认证介入我们的HTTPS连接的过程如下：

  • 1、服务器拥有自己的私钥与公钥；
  • 2、服务器将公钥交给CA认证机构，请求给予一份数字证书；
  • 3、CA认证机构生成数字证书，并颁发给服务器；
  • 4、服务器将带有公钥信息的数字证书发给客户端；
  • 5、进入客户端生成对称密钥再进行对接的过程。

CA证书原理

CA机构有一套自己的公钥和私钥。

CA证书结构如下：内容和签名

  • 第一部分：服务端的公钥，服务器名称、授权中心名称、有效期、序列号等。
  • 第二部分：数字签名，数字签名即第一部分使用hash 压缩的，CA 机构使用 自己的私钥进行加密的。

CA证书也包括指纹算法（签字哈希算法）

然后构成了CA证书。CA证书签发给服务端。CA根证书CA根公钥内置在浏览器，CA根证书内置在客户端的操作系统。

# https CA 证书验证过程

  • 首先是先进行TCP连接（三次握手）。紧接着服务端向客户端发送证书。
  • 客户端收到证书，将证书上的CA根证书与操作系统内置的CA根证书匹配。
  • 如果匹配失败，说明证书不合法。
  • 客户端进行哈希压缩证书的第一部分得到一段字符。
  • 客户端使用浏览器内置的 CA公钥 解密第二部分，获得一段字符。
  • 两段字符对比，如果相同没有问题。
  • 如果不同，可能证书被修改过或者不是使用CA公钥加密的。以上一套流程是保护CA证书本身的。
  • 客户端生成随机对称密钥，使用服务端的公钥给这个密钥加密，发送给服务端。
  • 然后通过客户端生成的对称密钥进行http通信。
  • 所以在https中CA证书的作用是确认网站合法性。

# HTTPS的缺点

  • 1、HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
  • 2、HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；？
  • 3、SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用；
  • 4、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗；
  • 5、HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

TIP

实践中建议保留http。所以我们在切换的时候可以做http和https的兼容，具体实现方式是，去掉页面链接中的http头部，这样可以自动匹配http头和https头。例如：将http://www.baidu.com改为//www.baidu.com。然后当用户从http的入口进入访问页面时，页面就是http，如果用户是从https的入口进入访问页面，页面即使https的

# SSL与TLS的区别

SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。

# SSL/TLS协议的基本过程

  • （1） 客户端向服务器端索要并验证公钥。
  • （2） 双方协商生成”对话密钥”。
  • （3） 双方采用”对话密钥”进行加密通信。

上面过程的前两步，又称为”握手阶段”（handshake）。

  • 1、客户端发出请求（ClientHello）
    • （1） 支持的协议版本，比如TLS 1.0版；
    • （2） 一个客户端生成的随机数，稍后用于生成”对话密钥”；
    • （3） 支持的加密方法，比如RSA公钥加密；
    • （4） 支持的压缩方法。
  • 2、服务器回应（SeverHello）
    • （1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信；
    • （2） 一个服务器生成的随机数，稍后用于生成”对话密钥”；
    • （3） 确认使用的加密方法，比如RSA公钥加密，此时带有公钥信息；
    • （4） 服务器证书。
  • 3、客户端回应
    • （1） 一个随机数pre-master key。该随机数用服务器公钥加密，防止被窃听。
    • （2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
    • （3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

上面客户端回应中第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。

那么为什么一定要用三个随机数，来生成”会话密钥”呢？

"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机数，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

  • 4、服务器的最后回应
    • （1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
    • （2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。（客户端在第三阶段也生成这个“会话秘钥”）。然后，向客户端最后发送下面信息。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

参考 (opens new window)

← HTTP/1 、HTTP/2 及 HTTP/3 →