阅读 182

【深入浅出HTTPS】TLS/SSL握手过程

HTTPS简介

HTTPS基于SSL/TLS协议,SSL最初由NetScape在1994年设计,经过了三个版本的更新,在1999年由IETF标准化成为TLS,其在TCP的基础上实现了一层安全的协议,包括握手、证书下发、秘钥协商等。它是互联网安全的基础,也是解决http请求被重放、篡改、传输泄露的基本手段。

image.png

TLS1.2握手过程

未命名文件.png

TLS1.2握手过程如下:

  1. 客户端发送“Client Hello”报文发起握手,该报文包括了客户端支持的TLS版本、客户端支持的加密算法、随机字符串“client random”。其中,加密算法包括密钥交换算法、加密算法和散列算法,一般的HTTP客户端实现会将这三种算法组合成一个密码套件(一种密钥交换算法+一种加密算法+一种散列算法)供服务端选择。
  2. 服务端发送"Server Hello"报文,该报文包括了服务端的数字证书、服务端选择的加密套件和随机字符串"Server Random",数字证书中包含了用于密钥交换的公钥A。
  3. 客户端校验并解析证书,获得公钥A,生成随机字符串"premaster secret",使用公钥A加密随机字符串。
  4. 客户端向服务端发送随机字符串"premaster secret"。
  5. 客户端和服务端利用“client random”,"Server Random"和"premaster secret"生成共享密钥C,该密钥C用于加密后续HTTP的通讯明文。
  6. 客户端发送使用密钥C加密的finished报文。
  7. 服务端发送使用密钥C加密的finished报文。
  8. 握手完成,随后的HTTP通讯内容都使用密钥C加密。

密码规范和密码套件

通信双方在安全连接中所使用的算法必须符合密码安全协议的规定。

CipherSpecs 用于认证加密算法和信息摘要算法的组合,通信双方必须同意这个密码规范才能进行通信。而 CipherSuites 则定义了 SSL / TLS 安全连接中所使用的加密算法的组合(密码套件)。

一个密码组合包含三种不同的算法:

  1. 握手期间所使用的的密钥交换和认证算法 (最常用的是 RSA 算法)
  2. 加密算法 (用于握手完成后的对称加密,常用的有 AES、3DES等)
  3. 信息摘要算法 (常用的有 SHA-256、SHA-1 和 MD5 等)

下面是一些常用的加密套件

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
 
复制代码

数字证书

数字证书用于认证公钥持有者的身份,防止第三方进行冒充,常用的证书格式是X.509标准。CA(Certificate Authority,证书授权中心)是数字证书发放和管理的机构,目前比较流行的CA机构有DigiCert,Globalsign,Thawte,GoDaddy等。

CA组织为树形结构,有两种类型的CA:root CA 和 intermediates CA。一个root CA下可以包含多个intermediates CA,而intermediates又可以包含多个intermediates CA,root CAs 和 intermediates CAs都可以颁发证书给用户。

image.png

我们以百度的证书为例,来看一看数字证书的构成。

百度数字证书(有注释).png

数字证书的主要内容包括证书所有者的相关信息(主题信息),证书签发机构的信息(签发者名称),公钥以及这个证书的数字签名等信息。

观察百度的数字证书,该证书向上还有两级证书,下一级的证书由上一级证书签发,我们将这样的结构称为证书链。证书分为三类:

  1. end-user证书:baidu.com证书包含了我们上文所说的密钥A,这也是HTTPS协议中,服务端向客户端传递的证书。
  2. intermediates证书:"GlobalSign Organization Validastion CA"是CA用来认证公钥持有者身份的证书,即确认HTTPS使用的end-user证书是属于baidu.com的证书。
  3. root证书:"GlobalSign Root CA"是根证书,用来认证intermediates证书是合法证书的证书。

客户端对证书的校验

客户端主要对证书做以下校验:

  1. 验证证书链,确保服务端证书是由客户端信任的CA机构签发。
  2. 检查数字签名,确保证书在传输过程中没有被篡改。
  3. 检查证书有效期。
  4. 检查证书的回撤状态。

证书链的验证

image.png

对证书链的验证其实就是逐级而上,判断CA证书是否能信任的过程。在浏览器或操作系统中,会内置一些Root Certifaicates,也称为trusted root certificates。客户端会获取自己所能信任的证书列表(一般是系统根证书或用户证书),判断服务端的CA证书是否在自己的授信列表内:

  1. 如果在授信列表内,则说明该证书是可以信任的,继续其他验证;
  2. 如果不在授信列表内,则说明该证书不被信任,对于不被信任证书的处理,取决于具体客户端的实现。

签名的验证

image.png 上面这张图片简要说明了证书的签发和验证过程,我们可以通过这个过程来观察数字签名的产生以及如何校验:

数字签名的产生:

  1. Signing阶段,首先撰写证书的元信息:签发人(Issuer)、地址、签发时间、过期失效等;当然,这些信息中还包含证书持有者(owner)的基本信息,例如owner的DN(DNS Name,即证书生效的域名),owner的公钥等基本信息。
  2. 通过通用的Hash算法将信息摘要提取出来;
  3. Hash摘要通过Issuer(CA)私钥进行非对称加密,生成一个签名密文;
  4. 将签名密文attach到文件证书上,使之变成一个签名过的证书。

数字签名的验证:

  1. Verification阶段,客户端获得之前签发的证书;
  2. 将其解压后分别获得“元数据”和“签名密文”;
  3. 将同样的Hash算法应用到“元数据”获取摘要;
  4. 将密文通过Issuer(CA)的公钥(非对称算法,私钥加密,公钥解密)解密获得同样的摘要值。
  5. 比对两个摘要,如果匹配,则说明这个证书是被CA验证过的合法证书,里面的公钥等信息是可信的。

总结

  1. 简单理解,HTTPS就是在HTTP的基础上套了一层SSL/TSL。
  2. TLS握手的最终目的是为了确定用于加密HTTP通讯内容的密钥,RSA是HTTPS常用的密钥交换算法。
  3. 数字证书通过数字签名实现对公钥的保护,通过证书链实现对公钥持有者身份的验证。

参考

HTTPS详解二:SSL / TLS 工作原理和详细握手过程

Public key certificate

证书链-Digital Certificates

浅谈SSL握手、证书、证书校验

文章分类
后端
文章标签