本文主要介绍 https 到底 s 在哪里了，以及 s 的运行机制和加密过程，不涉及实现细节；
关键词：TLS/SSL HTTP 双证书 单证书 数字签名 数字证书
HTTPS 并不是新的协议，而是披上了 SSL/TSL 外衣的 HTTP 协议，HTTP (HyperText Transfer Protocol) 是超文本传输协议的缩写，作为我们最常能见到的互联网协议，其实 HTTP 是存在安全隐患的：
1、通信内容是明文，可能被第三方窃听。 2、无法确定通信方的身份，理论上服务器可以被任何客户端发起 http 请求，而 HTTP 自身是没法验证来访者身份的，可能是中间者伪装发来的请求。 3、无法确定报文的完整性，报文的内容可能已经被修改。
针对上述问题，HTTP 自身没有提供很好的解决方案，所以需要结合 SSL 协议来建立安全通信管道。SSL 是独立于 HTTP 协议的，所以不光是 HTTP 协议，包括应用层的其他协议 SMTP Telnet 等协议都可以结合使用 SSL，SSL 是现在世界上最广泛的网络安全技术；所以 HTTPS 也常被称为 HTTP over TLS，HTTP over SSL 。
TLS 与 SSL
TLS (Transport Layer Security) 传输层安全性协议 前身是 SSL 安全套接层 (Secure Sockets Layer ) ，安全协议的发展大致如下：
1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。1996年，SSL 3.0版问世，得到大规模应用。1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。2018年，发表了 TLS 1.3 版本。
所以 TLS 和 SSL 其实指代的是一种安全协议，只不过是版本不同后，命名不同的问题。
传统的 HTTP 协议是直接和 TCP 协议交互的，而 HTTPS 则在中间加了一层：
HTTPS
并没有资料明确的说明，在 TCP/IP 四层网络模型中，TLS 工作在 TCP 层还是应用层。但在 OSI 七层模型中，有观点认为 TLS 是工作在会话层的协议 (如有错误，欢迎指正)。SSL 协议中主要用到了一种公开密钥加密，也叫非对称加密的加密手段，所以先了解一些加密相关的技术。
对称加密和非对称加密
1：对称加密(共享密钥加密)
也称为单密钥加密或者共享密钥加密，用同一个密钥对信息进行加密和解密。和门锁与钥匙比较类似，一把锁只能用一种模型的钥匙打开。常见算法 DES 、AES 等。算法特征：
1、加密方和解密方使用同一个密钥； 2、加密解密的速度比较快，适合数据比较长时的使用； 3、密钥传输的过程不安全，且容易被破解，密钥管理也比较麻烦；
2：非对称加密(公开密钥加密)
非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。工作过程大致如下：
1、乙方生成一对密钥（公钥和私钥）并将公钥向其它方公开。 2、得到该公钥的甲方使用该密钥对机密信息进行加密后再发送给乙方。 3、乙方再用自己保存的另一把专用密钥（私钥）对加密后的信息进行解密。乙方只能用其专用密钥（私钥）解密由对应的公钥加密后的信息。
相较对称加密，非对称加密比较安全，但是效率没有对称加密高，适合少量对少量数据的加密。非对称加密的常见算法：RSA、背包算法等。
HTTPS 采用了混合加密的机制
HTTPS 建立联系的过程中 (实际都是 TLS 协议在干活)，即用到了非对称加密，同时也用了对称加密。结合两种加密的优点，设计的很巧妙。大致过程可简单总结为以下三步：
1、客户端向服务器端索要公钥证书并验证公钥证书。(非对称加密) 2、双方协商生成“对话密钥”。(用三个随机数生成) 3、双方采用“对话密钥”进行加密通信。(通信用的对话密钥是一种对称加密)
建立安全连接的详细过程
1、客户端发出请求 ClientHello
首先，客户端发起请求，一般携带以下信息(除去 http 默认携带的常用信息外)：
支持的 TLS 版本一个随机数 (稍后用于生成对话密钥)支持的加密算法
2、服务器回应（SeverHello)
服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容:
1、服务器证书 (一般是 CA 颁发的认证证书，后文详细介绍) 2、一个随机数 (稍后用于生成对话密钥) 3、和客户端确认 TLS 版本 (如果版本与服务器不对应，服务器会关闭加密通信)，确认使用客户端支持的加密算法等。 4、向客户端索证书 (可选，网上好多说双证书认证，大概就是这步吧)
其中，最后一项，服务器向客户端索要证书不是必须的，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供“客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
3、客户端回应
客户端收到服务器信息后，首先验证服务器的证书，证书有问题，就会向受访者发出一个警告，选择是否继续访问。如果证书没有问题，就会向服务器发送以下信息：
1、 一个随机数。该随机数用服务器公钥加密 (公钥在证书中)，防止被窃听。(非对称加密) 2、编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。也就是开始用对称加密的方式进行通信，密钥就是用以上的 3 个随机数生成的。 3、客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。 4、客户端证书 (如果服务器索要证书的话)
4、服务器最后的回应
服务器收到客户端信息后，先用自己私钥解密第三个随机数(上一步客户端用服务器公钥加密的随机数)，到这一步服务器和客户端同时有 3 个随机数，其中最后一个随机数的传输用的是非对称加密。客户端和服务器会用 3 个随机数生成会话密钥，接下来客户端和服务器的同学就靠这个会话密钥加密来进行，而这种加密是对称加密。
如果需要客户端证书，还会验证客户端的证书。如果都没有问题，就会向客户端发送最后的信息：
1、编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。 2、服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
随后，客户端和服务端都开始走普通的 http 请求，只不过对回话内容使用 “会话秘钥” 进行加密。注意是一种对称加密，客户端和服务器有相同的秘钥，效率会高很多。
证明公开密钥正确性的证书 (CA 证书，也叫数字证书或者证书)
在使用非对称加密的过程，涉及一个问题，就是公钥如何正确的传给另一端，例如上文中服务器需要把自己的公钥传给客户端，那么客户端如何验证这个公钥是自己预想的服务器的公钥呢？
为了解决上述问题，便有了数字证书认证机构 (CA, Certificate Authority) 和其相关机构颁发的公开密钥证书；CA 机构是一种互联网公认的可信赖的第三方机构，例如威瑞信 VeriSign就是其中一家比较有名的数字证书认证机构。CA 认证的过程大致如下：
1、某服务器运营人员向 CA 机构提供公开密钥认证申请，此时会给 CA 机构提供一个自己服务器生成的公钥(私钥自己保存)； 2、CA 机构在查明申请者的身份后，会用自己的公开密钥(注意是 CA 自己的公钥) 对申请者的公钥进行数字签名，然后将数字签名和公钥(稍后用于客户端验证服务器的可靠性) 一起绑定在颁发给该服务器的证书里。
数字签名：又称公钥数字签名，是一种类似写在纸上的普通的物理签名，但是使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。
3、服务器申请到公钥证书(也叫数字证书或者直接叫证书)后，发送给客户端，注意证书里已经包含了服务器的公钥。 4、客户端拿到证书后，用 CA 机构的公钥(客户端为什么能持有 CA 的公钥稍后说)对证书里的数字签名进行验证，验证过程大致也是用 CA 机构的公钥对服务器公钥进行数字签名，将签名结果与证书里的结果进行比对，来检查服务器公钥的可靠性。一旦验证通过，客户端就可以确定两件事： a> 证书是受信任的证书机构颁发的。 b> 服务器的公钥是可信的。
这里边有个问题，就是 CA 机构的证书是如何安全的传给客户端的？为此，多数浏览器开发商在发布浏览器版本时，会在内部植入常用认证机构的公钥证书。但是，正所谓没有绝对的安全，我们如何保证下载的浏览器是可信的、安全的呢？所以下载软件，最好去官网下载正版软件。
客户端证书
上述 HTTPS 建立安全连接的流程中，我们注意到，有些服务器也会要求客户端证书；来保证只能有指定的客户端才能发起请求。例如早期很多银行的网站，都会给持卡用户发一个 U盾，通过 USB 的形式连接到电脑，猜测可能就是客户端认证的一种机制。或者要求客户端在使用网站时，下载其官网提供的某些软件，猜测就是安装客户端证书的过程。
但是这样也不能 100% 保证坐在电脑前的操作者就是持卡用户本人，所以现在有了指纹识别、面部解锁、虹膜识别等生物技术手段。
(完)