Https

1.概念

HTTPS（HyperText Transfer Protocol over Secure Socket Layer）超文本传输安全协议，近两年Google、Baidu、Facebook 等这样的互联网巨头，不谋而合地开始大力推行 HTTPS，国内外的大型互联网公司很多也都已经启用了全站 HTTPS，这也是未来互联网发展的趋势。

为鼓励全球网站的 HTTPS 实现，一些互联网公司都提出了自己的要求：

Google 已调整搜索引擎算法，让采用 HTTPS 的网站在搜索中排名更靠前；

从 2017 年开始，Chrome 浏览器已把采用 HTTP 协议的网站标记为不安全网站；

苹果要求 2017 年 App Store 中的所有应用都必须使用 HTTPS 加密连接；当前国内炒的很火热的微信小程序也要求必须使用 HTTPS 协议；

新一代的 HTTP/2 协议的支持需以 HTTPS 为基础。

作用：

对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全
对网站服务器进行真实身份认证

使用特征：

使用HTTPS通信时，不再用http://，而是改用https://。另外，
当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏内会出现一个带锁的标记。

2.架构图

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

SSL/TLS协议就是为了解决上面提到的HTTP存在的问题而生的:

所有的信息都是加密传输的，第三方无法窃听
配备身份验证（服务端程序），防止身份被冒充
具有校验机制，一旦被篡改，通信双方会立刻发现

3.https工作原理

HTTPS是身披SSL/TLS外壳的HTTP

TLS全称传输层安全协议Transport Layer Security Protocol，TLS/SSL是一种加密通道的规范。

协议版本	描述
SSL1.0	存在严重的安全漏洞,从未公开过
SSL2.0	2.0版本在1995年2月发布，但因为存在数个严重的安全漏洞而被3.0版本替代
SSL3.0	3.0版本在1996年发布
TLS1.0	IETF对SSL3.0进行了标准化，并添加了少数机制（但是几乎和SSL3.0无差异）
TLS1.1	在RFC 4346中定义，于2006年4月发表
TLS1.2	在RFC 5246中定义，于2008年8月发表
TLS1.3	在RFC 8446中定义，于2018年8月发表

TLS协议是由TLS记录协议（TLS record Protocol）和TLS握手协议（TLS handshake Protocol）这两层协议叠加而成的。

记录协议：TLS Record protocol

TLS记录协议位于TLS握手协议的下层，是负责使用对称密码对消息进行加密通信的部分加密使用的密钥是通过握手协议在服务器和客户端之间协商决定的
握手协议：TLS Handshaking Protocols

由TLS Change Ciper Spec Protocol（密码规格变更协议）和TLS Alert Protocol（警告协议）组成

负责在客户端和服务器之间协商决定密码算法和共享密钥。密码规格变更协议负责向通信对象传达变更密码方式的信号，当协议中途发生错误时，就会通过警告协议传达给对方。警告协议是TLS握手协议负责在发送错误时将错误传达给对方。

HTTPS和HTTP协议相比提供了:

数据完整性：内容传输经过完整性校验
数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥
身份认证：第三方无法伪造服务端（客户端）身份

其中，数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。

3.1 对称加密算法

定义：采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密。

要素：原文、秘钥、算法 (秘钥：在密码学中是一个定长的字符串、需要根据加密算法确定其长度)

工作过程：对称加密通常使用的是相对较小的密钥，一般小于256 bit。因为密钥越大，加密越强，但加密与解密的过程越慢。如果你只用1 bit来做这个密钥，那黑客们可以先试着用0来解密，不行的话就再用1解；但如果你的密钥有1 MB大，黑客们可能永远也无法破解，但加密和解密的过程要花费很长的时间。密钥的大小既要照顾到安全性，也要照顾到效率。

加密：明文 + 密钥 -> 密文

解密：密文 + 密钥 -> 明文

算法:

DES（Data Encryption Standard）

数据加密标准（现在用的比较少，因为它的加密强度不够，能够暴力破解）
3DES

原理和DES几乎是一样的，只是使用3个密钥，对相同的数据执行三次加密，增强加密强度。(缺点：要维护3个密钥，大大增加了维护成本)
AES（Advanced Encryption Standard）

高级加密标准，用来替代原先的DES，目前美国国家安全局使用的，苹果的钥匙串访问采用的就AES加密。是现在公认的最安全的加密方式，是对称密钥加密中最流行的算法。

AES128和AES256主要区别是密钥长度不同（分别是128bits,256bits)、加密处理轮数不同（分别是10轮，14轮），后者强度高于前者。

特点：

优点：算法公开、计算量小、加密速度快、加密效率高
缺点：相对来说不算特别安全，只有一把钥匙，密文如果被拦截，且密钥也被劫持，那么，信息很容易被破译

推演：为了防止上述现象的发生，人们想到一个办法：对传输的信息加密（即使黑客截获，也无法破解）

加密公式： f1 ( key（密钥），data ) = X（密文）

解密公式： f2 ( key（密钥），X（密文） ) = data

缺陷：加密和解密同用一个密钥，加密和解密都会用到密钥，没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密。改进：比如服务器为每一个客户端请求的TCP连接生成一个唯一的key (但由于不同客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本高，每个客户端服务端的安全级别不同，密钥也极易泄露)

3.2 非对称加密算法

简介：非对称加密是计算机通信安全的基石，保证了加密数据不会被破解。非对称加密算法需要两个密钥：公开密钥(public key) 和私有密钥(private key) ，公开密钥和私有密钥是一对

特点：

如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密。
如果用私有密钥对数据进行加密，只有用对应的公开密钥才能解密。
由于其算法复杂，而使得加密、解密速度没有对称加密解密的速度快。有两种密钥，其中一个是公开的，这样就可以不需要像对称密码那样传输对方的密钥了，这样安全性就大了很多。
私钥保存在服务端，公钥保存在客户端，私钥永远不对外暴露

常用算法：RSA, DSA, ECDSA

缺陷：公钥是公开的，则用私钥加密的信息，则可能被窃取用公钥进行解密

组合使用：非对称加密既然也有缺陷，那我们就将对称加密，非对称加密两者结合起来，取其精华、去其糟粕，发挥两者的各自的优势。

通过对称加密和非对称加密的组合使用，解决内容可能被窃听的问题,但是仍存在以下缺陷：

报文可能遭篡改—-使用数字签名解决
通信方身份可能被伪装—–使用数字证书解决

3.3 数字签名

功能：

能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
数字签名能确定消息的完整性,证明数据是否未被篡改过。

数字签名生成：

将要发送的数据先用Hash算法（摘要算法、散列算法）生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文一起传送给接收者。

MD(Message Digest)：消息摘要算法

SHA(Secure Hash Algorithm)：安全散列算法

MAC(Message Authentication Code)：消息认证码

数字签名校验流程：

接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

假设消息传递在客户端、服务器之间发生。服务器将消息连同数字签名一起发送给客户端，客户端接收到消息后，通过校验数字签名，就可以验证接收到的消息就是服务器发送的。

这个过程的前提是客户端知道服务器的公钥。问题的关键的是，和消息本身一样，公钥不能在不安全的网络中直接发送给客户端，或者说拿到的公钥如何证明是服务器的。此时就需要引入了证书颁发机构（Certificate Authority，简称CA），CA数量并不多，客户端内置了所有受信任CA的证书。

3.4 证书

数字证书：是一个经证书认证结构数字签名的包含公开密钥、拥有者信息的文件，有点像生活中的身份证、护照等，是由一个官方的证书颁发机构签发的一组数据。这种证书很难伪造，用于使用者的身份证明。

实际上，我们使用的证书分很多种类型，SSL证书只是其中的一种，SSL证书负责传输公钥。 我们常见的证书根据用途不同大致有以下几种：

SSL证书，用于加密HTTP协议，也就是HTTPS，TLS。如果一个web应用想要升级为https，需要购买证书。
代码签名证书，用于签名二进制文件，比如Windows内核驱动，Firefox插件，Java代码签名等等
客户端证书，用于加密邮件
双因素证书，网银专业版使用的USB Key里面用的就是这种类型的证书

证书中包含：组织信息、域名信息、公钥（比如拉勾教育的公钥）、证书有效期等信息。

CA - 数字证书认证机构：

CA是证书的签发机构，它是公钥基础设施（Public Key Infrastructure， PKI）的核心。CA是负责签发证书、认证证书、管理已颁发证书的机关。

认证过程(升级https):

服务器的运营人员（拉勾网站的运营）向第三方机构CA（或者其代理机构）提交公钥、组织信息、域名等信息并申请认证;
CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
如信息审核通过，CA会向申请者签发认证文件-证书。

证书包含以下信息：申请者公钥（如拉勾教育的公钥）、申请者的组织信息和个人信息、签发机构的信息、有效时间、证书序列号等信息的明文，同时包含一个CA机构的数字签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名；

用户向web服务器发起一个安全连接的请求服务器返回经过CA认证的数字证书，证书里面包含了服务器的public key。

用户拿到数字证书，怎么确保CA证书不被劫持，黑客完全可以把一个假的CA证书发给Client，进而欺骗Client，用户如何编写证书真伪？

CA的大杀器就是，CA把自己的CA证书集成在了浏览器和操作系统里面。 Client拿到浏览器或者操作系统的时候，已经有了CA证书，没有必要通过网络获取，那自然也不存在劫持的问题。

查看浏览器CA证书：设置–>安全检查–>安全–>管理证书查看操作系统CA证书：certmgr.msc

Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。

客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。

ssl证书分类：

DV（域名型SSL）：个人站点
OV（企业型SSL）：企业官网
EV（增强型SSL）：对安全需求更强的企业官网、电商、互联网金融网站

3.5 完整的https通信

TLS握手过程：明文—–>非对称加密—–>对称加密

第一步: 浏览器给出TLS协议版本号、一个客户端生成的随机数1（Client random），以及客户端支持的加密方法。（明文通讯）

第二步: 服务器确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数2（Server random）。（明文通讯）

第三步: 浏览器确认数字证书有效，然后生成一个新的随机数3（Pre-master secret），并使用数字证书中的公钥加密这个随机数，发给服务器。（使用非对称加密算法）

浏览器确认数字证书有效：浏览器和操作系统内部内置了很多CA机构的证书，是否篡改、是否在有效期内、域名和访问的网站是否匹配。

第四步: 服务端使用自己的私钥，获取客户端发来的随机数（即Premaster secret）。

双方就都有三个一模一样的随机数，前两个是明文发送的，最后客户端生成的这个是使用证书中的公钥密文发送的。

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

对话密钥，又叫做会话密钥，其实就是讲之前通讯中的三个随机数生成一个密钥（对称加密）

三个随机数—–>第三个是使用非对称加密—->相同的算法——->会话密钥

第六步：客户端和服务器都会第一次使用会话密钥加密一个消息发送给对方。

客户端收到服务端发送的Certificate 报文后首先会校验证书的合法性：

证书路径信任链逐级校验通过（证书确由可信 CA 认证签发）；

签名解密成功（确系证书持有者亲笔）；

从签名解析出的摘要和证书公开内容的摘要一致（证书内容完整，未被篡改）；

主题子域与 URL 中的 HOST 一致，综上确保访问的网站是来自预期目标服务器且非劫持或钓鱼。

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以后，解密后就不必重新生成对话密钥了。

4.ca证书制作实战

使用自签名证书来构建安全网络，所谓自签名证书，就是自己扮演 CA 机构，自己给自己的服务器颁发证书。

4.1 OpenSSL

OpenSSL是一个以C语言编写现了SSL与TLS协议的开源的软件库包，应用程序可以使用这个包来进行安全通信，避免窃听，同时确认另一端连线者的身份。这个包广泛被应用在互联网的网页服务器上。OpenSSL支持Linux、 Windows、BSD（Unix的衍生系统）、Mac等平台，这使得OpenSSL具有广泛的适用性。

OpenSSL整个软件包大概可以分成三个主要的功能部分：

加密算法库
- 对称加密算法
- 非对称加密算法
- 信息摘要算法
ssl协议库
- OpenSSL实现了SSL协议的SSLv2和SSLv3，支持了其中绝大部分算法协议
- OpenSSL也实现了TLSv1.0+
应用程序

多功能的命令行工具，可以实现加密解密、密钥生成、密钥和证书管理、自建CA和签名等功能

4.2 过程

CA生成根密钥
CA生成根证书
Nginx生成私钥
Nginx申请证书
CA签发
Nginx安装证书，配置

4.3 颁发证书

默认情况下Linux操作系统已经内置安装了OpenSSL，可以通过version查看版本号

修改配置

在CA目录下创建两个初始文件，维护序列号。通过CA机构签发的每个证书都有一个唯一的序列号 touch index.txt serial
生成根密钥

表示的CA机构的私钥，CA结构签发的每一个证书都要通过自己的私钥进行签名

进入index.txt目录，生成一个2048位密钥openssl genrsa -out private/cakey.pem 2048
生成根证书

使用req命令生成自签证书
- new：表示新的申请
- x509：表示生成自签证书
- key：指定私钥文件
- out：保存证书的位置
- days：指定证书期限
openssl req -new -x509 -key private/cakey.pem -out cacert.pem

会提示输入一些内容，因为是私有的，所以可以随便输入（之前修改的openssl.cnf会在这里呈现），最好记住能与后面保持一致。
为nginx服务器生成ssl密钥申请SSL证书本质上就是服务器升级支持HTTPS，非对称加密（公钥和私钥）。安装nginx，为nginx生成ssl密钥
```
cd /etc/nginx/ssl
#为nginx web服务器生成ssl密钥
openssl genrsa -out nginx.key 2048
```
为nginx生成证书签署请求

该过程会生成一个文件，包含了证书相关的信息，但是该文件不是证书，生成证书的请求文件。

该文件需要发送给CA机构，由CA签名后生成一个证书文件。

openssl req -new -key nginx.key -out nginx.csr

注意与前面输入的信息保持一致
私有CA根据请求来签署证书

接下来要把上一步生成的证书请求csr文件，发到CA服务器上， openssl ca -in nginx.csr -out nginx.crt

上面签发过程其实默认使用了-cert cacert.pem -keyfile cakey.pem，这两个文件就是前两步生成的位于前面/etc/pki/CA下的根密钥和根证书。将生成的crt证书发回nginx服务器使用。

到此我们已经拥有了建立SSL安全连接所需要的所有文件，并且服务器的crt和key都位于配置的目录下，剩下的是如何使用证书的问题。