HTTPS-知识点整理

HTTPS

一、SSL/TLS协议运行机制的概述

握手阶段的详细过程

握手阶段所有的通讯都是明文的

（一） 第一阶段 客户端和服务器端安全信息的互相发送

1.1 客户端发出请求（ClientHello）

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。
在这一步，客户端主要向服务器提供以下信息。
（1）客户端可以支持的SSL的最高版本号
（2）一个用于生成密钥的32字节的随机数
（3）一个确定会话的会话ID
（4）一个客户端可以支持的密码套件列表
（5）一个客户端可以支持的压缩算法列表

1.2 服务端回应 （serverHello）

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。
（1）SSL版本号，取客户端支持的最高版本号和服务器端支持的最高版本号中的较低者
（2）一个用于生成密钥的32字节的随机数
（3）会话ID
（4）从客户端的密码套件列表中选择的一个密码套件
（5）从客户端的压缩方法列表中选择的压缩方法

这个阶段之后，客户端服务端知道了下列内容：
（1）SSL版本
（2）密钥交换算法（也就是，非对称加密算法）、信息验证算法（也就是，HASH算法）和加密算法（也就是，对称加密算法）
（3）压缩方法
（4）有关密钥生成的两个随机数

握手阶段所有的通讯都是明文的

（二） 第二阶段 服务器推送证书到客户端进行密钥交换与客户端证书鉴别

（a）证书：服务器将数字证书和到根CA的整个证书链发给客户端，使客户端能够认证服务器
（b）服务器密钥交换（可选）：这里视密钥交换算法而定
（c）证书请求：服务器可能要求客户端发送客户端证书
（d）服务器握手完成：第二阶段结束，第三阶段开始
上图中省略了：客户端利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，通讯将继续。

（三） 第三阶段 客户端推送证书密钥到服务器端

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

与上一步类似，上一步是服务器端向客户端推送证书，客户端已经信任了服务器端，但是服务器端还要验证客户端，这一步的操作完成后，双向的SSL就完成了。

如果证书没有问题，客户端就会从证书中取出服务器的公钥
（a）证书（可选）：为了向服务器证明自身，客户端要发送客户端证书
（b）预备主密钥（Pre-master-secret）：客户端生成预备主密钥，并将其发送给服务端，注意这里会使用服务端的公钥进行加密
（c）证书验证（可选）：对预备主密钥和随机数进行签名，证明客户端拥有（a）证书的公钥
至此，服务器端和客户端各有一把私钥和公钥，私钥都是自己的，公钥都是对方的。
上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。

（四） 第四阶段 服务器确认，SSL通讯建立，定期修改密码规范

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

但是，每一次后期的传输，也可以通过设置实现：不使用同一个密码，而是像上图中最后一步一样，将摘要散列值和密码定期更换。
至此，SSL通道就建立成功了。

二、HTTPS中的密码学

2.1 概念

HTTPS 在证书的数字签名中使用了哈希算法和非对称加密算法，在加密通信的过程中使用了对称加密算法，为了防止传输的数据被篡改和重放还使用了 MAC（消息认证码）等。

• 哈希 --散列算法
• 哈希算法又称散列，它是一种将任意长度的数据转化为固定长度的算法
• 哈希算法是不可逆的
• 常见的哈希算法有 MD5 和 SHA1
• 对称加密 --加密算法
• 对称加密指的是加密和解密使用相同一个密钥
• 对称加密的优点是速度快，缺点是密钥管理不方便，必须共享密钥
• 常见的对称加密算法有 DES、AES、Blowfish 等
• 非对称加密 --秘钥交换
• 非对称加密指的是加密和解密使用不同的密钥，其中一个是公钥，另一个是私钥，公钥是公开的，私钥只有自己知道
• 使用公钥加密的数据必须使用私钥解密，使用私钥加密的数据必须使用公钥解密
• 公钥和私钥之间存在着某种联系，但是从公钥不能（或很难）推导出私钥
• 非对称加密的缺点是速度慢，优点是密钥管理很方便
• 常见的非对称加密算法有 RSA、ECC 等
• **公钥密码体制(public-key cryptography) **
  
  公钥密码体制的公钥和算法都是公开的(这是为什么叫公钥密码体制的原因)，私钥是保密的。大家都以使用公钥进行加密，但是只有私钥的持有者才能解密。在实际的使用中，有需要的人会生成一对公钥和私钥，把公钥发布出去给别人使用，自己保留私钥。
  
  公钥密码体制分为三个部分，公钥、私钥、加密解密算法，它的加密解密过程如下：
• 加密：通过加密算法和公钥对内容(或者说明文)进行加密，得到密文。加密过程需要用到公钥。
• 解密：通过解密算法和私钥对密文进行解密，得到明文。解密过程需要用到解密算法和私钥。注意，由公钥加密的内容，只能由私钥进行解密，也就是说，由公钥加密的内容，如果不知道私钥，是无法解密的。
  
• 签名和加密
• 加密：某个内容加密，加密后的内容还可以通过解密进行还原
• 签名：签名就是在信息的后面再加上一段内容，可以证明信息没有被修改过。
  一般是对信息做一个hash计算得到一个hash值，注意，这个过程是不可逆的，在把信息发送出去时，把这个hash值加密后做为一个签名和信息一起发出去。 接收方在收到信息后，会重新计算信息的hash值，并和信息所附带的hash值(解密后)进行对比，如果一致，就说明信息的内容没有被修改过，因为这里hash计算可以保证不同的内容一定会得到不同的hash值
  为了防止攻击者修改信息内容的同时也修改hash值，从而让他们匹配，hash值一般都会加密后(也就是签名)再和信息一起发送，以保证这个hash值不被修改

• 数字证书
  是用于公开密钥基础建设的电子文件，用来证明公开密钥拥有者的身份。此文件包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对这份文件的数字签名，以保证这个文件的整体内容正确无误

名称	密钥交换	验证算法	加密算法	位	散列算法
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	ECDH	RSA	AES_256_GCM	256	SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256	DH	RSA	AES_256_CBC	256	SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384	RSA	RSA	AES_256_GCM	256	SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA	ECDH	ECDSA	AES_256_CBC	256	SHA

• 术语
  ECDH - 椭圆曲线 Diffie-Hellman
  DH - Diffie-Hellman
  RSA - Rivest, Shamir, Adleman
  ECDSA - 椭圆曲线数字签名算法
  AES - 高级加密标准
  GCM - Galois/计数器模式 - 密码区块加密的操作模式
  CBC - 密码块链接
  3DES - 三重数据加密算法
  SHA - 安全散列算法

2.2 关于证书

• 什么是证书
  证书 （digital certificate / public key certificate）：数字证书就好比介绍信上的公章，有了它，就可以证明这份介绍信确实是由某个公司发出的，而证书可以用来证明任何一个东西的身份，只要这个东西能出示一份证明自己身份的证书即可，譬如可以用来验证某个网站的身份，可以验证某个文件是否可信等等;
• 数字证书
  是用于公开密钥基础建设的电子文件，用来证明公开密钥拥有者的身份。此文件包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对这份文件的数字签名，以保证这个文件的整体内容正确无误
  证书之间的信任关系，是可以嵌套的，叫做证书信任链
• 什么是CA
  CA 是“Certificate Authority”的缩写，也叫“证书授权中心”。是负责管理和签发证书的第三方机构
• 什么是根证书
  根证书（root certificate）是属于根证书颁发机构（CA）的公钥证书，是在公开密钥基础建设中，信任链的起点

三、Keyless服务

• 即你把网站放到它们的CDN上，不用提供自己的私钥，也能使用SSL加密链接。

1.SSL协议的握手过程

SSL协议握手过程

• （一）、客户端给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
• （二）、服务端确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
• （三）、客户端确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给服务端。
• （四）、服务端使用自己的私钥，获取客户端发来的随机数（即Premaster secret）。

• （五）、客户端和服务端根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。

  
  
  

  without keyless

2.私钥的作用

握手阶段有三点需要注意。
（1）生成对话密钥一共需要三个随机数。
（2）握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用。
（3）服务器公钥放在服务器的数字证书之中。
从上面第二点可知，整个对话过程中（握手阶段和其后的对话），服务器的公钥和私钥只需要用到一次。这就是CloudFlare能够提供Keyless服务的根本原因。
某些客户（比如银行）想要使用外部CDN，加快自家网站的访问速度，但是出于安全考虑，不能把私钥交给CDN服务商。这时，完全可以把私钥留在自家服务器，只用来解密对话密钥，其他步骤都让CDN服务商去完成。

with keyless

3.session恢复

握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。
这时有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。
session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。

session ID

上图中，客户端给出session ID，服务器确认该编号存在，双方就不再进行握手阶段剩余的步骤，而直接用已有的对话密钥进行加密通信。
session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。

session ticket

上图中，客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。

四 参考链接

图解SSL/TLS协议
HTTPS和Nginx的HTTPS配置