Dovis's blog

# https的工作原理

HTTPS并非是应用层一个新的协议，通常 HTTP 直接和 TCP 通信，HTTPS则先和安全层（SSL/TLS）通信，然后安全层再和 TCP 层通信。

HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。

SSL/TLS是怎么解决HTTP存在的问题的：

  • HTTP存在的问题

    • 窃听风险：通信使用明文（不加密），内容可能会被窃听（第三方可能获取通信内容）
    • 冒充风险：不验证通信方的身份，因此有可能遭遇伪装
    • 篡改风险：无法证明报文的完整性，所以有可能已经遭遇篡改

  • SSL/TLS解决：

    • 混合加密的⽅式实现信息的机密性，第三方无法窃听
    • 将服务器公钥放⼊到数字证书中，解决了冒充的⻛险。
    • 摘要算法的⽅式来实现完整性，它能够为数据⽣成独⼀⽆⼆的「指纹」，指纹⽤于校验数据的完整性，解决了篡改的⻛险。

    客户端在发送明⽂之前会通过摘要算法算出明⽂的「指纹」，发送的时候把「指纹 + 明⽂」⼀同加密成密⽂后，发送给服务器，服务器解密后，⽤相同的摘要算法算出发送过来的明⽂，通过⽐较客户端携带的「指纹」和当前算出的「指纹」做⽐较，若「指纹」相同，说明数据是完整的。

TIP

运输层安全协议。现在广泛使用两个协议：

  • 安全套接字层SSL
  • 运输层安全TLS

SSL协议作用在端系统应用层的HTTP和运输层之间，在TCP之上建立一个安全通道，为通过TCP传输的应用层数据提供安全保障。TLS是在SSL 3.0的基础上设计的，为所有基于TCP的网络应用提供安全数据传输服务。SSL/TLS处于应用层和传输层之间。使用https时，在发送方SSL接收应用层的数据，对数据进行加密，然后把加了密的数据送往TCP套接字。在接收方，SSL从TCP套接字读取数据，解密后把数据交给应用层。

SSL提供的安全服务可以归纳为三种：

  1. SSL服务器鉴别，允许用户证实服务器的身份。支持SSL的客户端通过验证来自服务器的证书，来鉴别服务器的真实身份并获得服务器的公钥
  2. SSL客户鉴别，SSL的可选安全服务，允许服务器证实客户的身份
  3. 加密的SSL会话
  • SSL/TLS协议基本流程：
    • 客户端向服务器所要并验证服务器的公钥
    • 双方协商生成会话密钥
    • 双方采用会话密钥进行加密通信

前两步是SSL/TLS的建立过程，也就是握手阶段

  • SSL/TLS协议建立的详细流程：
    1. ClientHello

    首先由客户端向服务器发起加密通信请求，也就是ClientHello请求。在这一步，客户端主要向服务器发送以下信息：

    • 客户端支持的SSL/TLS协议版本，如TLS 1.2版本
    • 客户端生产的随机数（Client Random）后面用于生产会话密钥。
    • 客户端支持的密码套件列表，如RSA加密算法。
    1. ServerHello

    服务器收到客户端请求后，向客户端发出响应，也就是ServerHello。服务器回应的内容有如以下内容：

    • 确认SSL/TLS协议版本，如果浏览器不支持就关闭加密通信。
    • 服务器生产的随机数（Server Random）后面用于生产会话密钥
    • 确认的密码套件列表，如RSA加密算法。
    • 服务器的数字证书。
    1. 客户端回应

    客户端收到服务器的回应之后，⾸先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使⽤它加密报⽂，向服务器发送如下信息：

    • 一个随机数（pre-master key）该随机数会被服务器公钥加密。
    • 加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。
    • 客户端握⼿结束通知，表示客户端的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘要，⽤来供服务端校验

    上⾯第⼀项的随机数是整个握⼿阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就⽤双⽅协商的加密算法，各⾃⽣成本次通信的「会话秘钥」。

    1. 服务器的最后回应

    服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发⽣最后的信息：

    • 加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。
    • 服务器握⼿结束通知，表示服务器的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘要，⽤来供客户端校验。

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

# 加密

# 对此加密

在每次数据传输之前，小服会先传输给小客一把密钥，然后小服在之后给小客发消息的过程中，会用这把密钥对这些消息进行加密。小客在收到这些消息后，会用之前小服给的那把密钥对这些消息进行解密，这样，小客就能得到密文里面真正的数据了。如果小客要给小服发消息，也同样用这把密钥来对消息进行加密，小服收到后也用这把密钥进行解密。

加密和解密用同一个密钥的方式称为共享密钥加密，也被叫做对称密钥加密。

img

  • 浏览器发送给服务端 client_random 和一系列加密方法
  • 服务端发送给浏览器 server_random 和加密方法

现有浏览器和服务器有了三个相同的凭证：client_random、server_random和加密方法 用加密方法把client_random、server_random 两个随机数混合起来，生成秘钥，这个密钥就是浏览器和服务端通信的暗号。 存在的问题：第三方可以在中间获取到client_random、server_random和加密方法，由于这个加密方法同时可以解密，所以中间人可以成功对暗号进行解密，拿到数据，很容易就将这种加密方式破解了。

# 非对称加密

需要两个密钥，一个是公开密钥，另一个是私有密钥；一个用作加密的时候，另一个则用作解密。使用其中一个密钥把明文加密后所得的密文，只能用相对应的另一个密钥才能解密得到原本的明文；甚至连最初用来加密的密钥也不能用作解密。由于加密和解密需要两个不同的密钥，故被称为非对称加密；

img

  • 浏览器发送给服务器端一系列加密方法
  • 服务端发送给浏览器加密方法和公钥

之后浏览器通过公钥将数据加密传输给服务端，服务端收到数据使用私钥进行解密。服务端给浏览器发送数据，则使用私钥进行加密，浏览器收到服务端发送过来的数据，使用公钥进行解密。

存在的问题：

  1. 非对称加密效率太低：会严重影响解密的速度，进而影响到用户打开页面的速度。
  2. 无法保证服务器发送给浏览器的数据安全，服务器的数据只能用私钥进行加密（因为如果它用公钥那么浏览器也没法解密），中间人一旦拿到公钥，就可以对服务端传来的数据进行解密了，就这样又被破解了。

# HTTPS使用两种加密结合

传输数据阶段依然使用对称加密，但是对称加密的密钥我们采用非对称加密传输。HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实，HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

img

  • 浏览器向服务器发送client_random和加密方法列表
  • 服务器收到，返回server_random，加密方法和公钥
  • 浏览器接收，接着生成另一个随机数pre_master，并且公钥加密，传给服务器。
  • 服务器用私钥解密这个被加密后的pre_master

到此为止，服务器和浏览器就有了相同的 client_random、server_random 和 pre_master, 然后服务器和浏览器会使用这三组随机数生成对称秘钥。有了对称秘钥之后，双方就可以使用对称加密的方式来传输数据了。

TIP

  • 采用混合加密的原因
  1. 对称加密只使⽤⼀个密钥，运算速度快，密钥必须保密，⽆法做到安全的密钥交换。
  2. ⾮对称加密使⽤两个密钥：公钥和私钥，公钥可以任意分发⽽私钥保密，解决了密钥交换问题但速度慢

# CA（数字证书）需要做什么

  • 证书包含的信息
    • 颁发机构信息
    • 公钥
    • 公司信息
    • 域名
    • 有效期
    • 指纹
    • ...

我们在申请一个 https 证书的时候，要在市场上选择一家 CA 来给你签发证书，那么 CA 的工作是什么呢？

CA 要验证这个域名真的是你的：通常就是通过 DNS 记录或者就是你在指定 URI 下放置一个特殊文件，让 CA 可以在外网环境下访问到它。

对于浏览器来说，数字证书有两个作用：

  • 通过数字证书向浏览器证明服务器的身份
  • 数字证书里面包含了服务器公钥

相比于不含数字证书的HTTPS请求流程，主要以下两个改动：

  • 服务器没有直接返回公钥给浏览器，而是返回了数字证书，而公钥正是包含数字证书中的；
  • 在浏览器端多了一个证书验证的操作，验证了证书之后，才继续后序流程。

TIP

  1. 服务端把自己的公钥注册到CA上
  2. CA用自己的私钥将服务器的公钥数字签名并颁发数字证书
  3. 客户端拿到服务器的数字证书后，使用CA的公钥确认服务器的数字证书的真实性。
  4. 从数字证书获取服务器公钥后，使用它对报文加密后发送。
  5. 服务器用私钥对报文进行解密

# HTTPS验证过程

img

  1. 证书验证阶段
  • 浏览器发起HTTPS请求
  • 服务端返回HTTPS证书
  • 客户端验证证书是否合法，如果不合法则提示告警。

TIP

  • 浏览器如何验证证书的合法性？

浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：

  1. 验证域名，有效期等信息是否正确。证书上都包含这些信息，比较容易完成验证。
  2. 判断证书是否合法。每份签发证书都可以根据验证链查找到对应的根证书，操作系统，浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书来完成源验证；
  3. 判断证书是否被篡改。需要和CA服务器进行校验。
  4. 判断证书是否已吊销。通过CRL和OCSP实现，其中OCSP可以用于第三步以减少和CA服务器的交互，提高验证效率。
  • 证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？

其实这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但私钥是无法获取的，一份公钥是不可能推算出其对应的私钥，中间人即使拿到证书也无法伪装成合法服务端，因为无法对客户端传入的加密数据进行解密。

  1. 数据传输阶段
  • 当证书验证合法后，在本地生成用于改造对称加密算法的随机数
  • 通过公钥加密随机数，并把加密后的随机数传输到服务端
  • 服务端通过私钥对随机数进行解密
  • 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输。

验证通过后本地生成用于改造对称加密算法的随机数，通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数，之后的数据交互通过对称加密算法进行加解密。

TIP

  • 为什么数据传输是用对称加密

首先，非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。

  • 为什么需要CA认证机构颁发证书

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的 “中间人攻击” 问题。

TIP

  • 引入证书之后的一个流程
    • 服务端把自己的公钥key1发给证书颁发机构，向证书颁发机构申请证书。
    • 证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密key1，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构来私钥加密。证书制作完成后，机构把证书发送给服务端。
    • 当客户端向服务端请求通信的时候，服务端不再直接返回自己的公钥，而是把自己申请的证书返回给客户端
    • 客户端收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以客户端只需要知道是哪个机构颁发的证书，就可以从本地找到对应的机构公钥，解密出证书签名。接下来客户端按照同样的签名规则，自己也生成一个证书签名，如果两个签名一致，说明证书是有效的。验证成功后，客户端就可以放心地再次利用机构公钥，解密出服务端的公钥key1
    • 客户端生成自己的对称加密密钥key2，并且用服务端公钥加密然后发送给服务端。
    • 最后服务器端用自己的私钥解开加密，得到对称加密密钥key2。于是两端用key2进行对称加密通信。

中间人通过发一个伪造的证书也是没用的，因为证书的签名是由服务端等信息生成的，并且经过机构私钥加密，中间人也无法篡改。所以，发给客户端的假证书也是无法验证通过的

# HTTPS连接建立过程

HTTPS 连接建立过程和 HTTP 差不多，区别在于 HTTP（默认端口 80） 请求只要在 TCP 连接建立后就可以发起，而 HTTPS（默认端口 443） 在 TCP 连接建立后，还需要经历 SSL 协议握手，成功后才能发起请求。

简化版SSL握手

# https协议的工作原理

  • 客户使用https url访问服务器，则要求web 服务器建立ssl链接。
  • web服务器接收到客户端的请求之后，会将网站的证书（证书中包含了公钥），返回或者说传输给客户端。
  • 客户端和web服务器端开始协商SSL链接的安全等级，也就是加密等级。
  • 客户端浏览器通过双方协商一致的安全等级，建立会话密钥，然后通过网站的公钥来加密会话密钥，并传送给网站。
  • web服务器通过自己的私钥解密出会话密钥。
  • web服务器通过会话密钥加密与客户端之间的通信。

# https优缺点

  • 优点：

    • 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
    • HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
    • HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
    • 谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

  • 缺点：

    • https握手阶段比较费时，会使页面加载时间延长50%，增加10%~20%的耗电。
    • https缓存不如http高效，会增加数据开销。
    • SSL证书也需要钱，功能越强大的证书费用越高。
    • SSL证书需要绑定IP，不能再同一个ip上绑定多个域名，ipv4资源支持不了这种消耗。

# http和https的区别

https：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。https协议的主要作用是：建立一个信息安全通道，来确保数据的传输，确保网站的真实性。

http传输的数据都是未加密的，也就是明文的，网景公司设置了SSL协议来对http协议传输的数据进行加密处理，简单来说https协议是由http和ssl协议构建的可进行加密传输和身份认证的网络协议，比http协议的安全性更高。

  • 主要的区别如下：
    • Https协议需要ca证书，费用较高。
    • http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
    • 使用不同的链接方式，端口也不同，一般而言，http协议的端口为80，https的端口为443
    • http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

← 慕课HTTP协议原理课程 →