近几年，互联网发生着翻天覆地的变化，尤其是我们一直习以为常的 HTTP 协议，在逐渐的被 HTTPS 协议所取代，在浏览器、搜索引擎、CA机构、大型互联网企业的共同促进下，互联网迎来了“HTTPS加密时代”，HTTPS 将在未来的几年内全面取代 HTTP 成为传输协议的主流。希望大家带着下面几个问题思考：
- HTTP 通信存在什么问题；
- HTTPS 如何解决了这些问题；
- CA 证书的认证过程；
HTTPS 是什么？
维基百科：超文本传输安全协议（英语：HyperText Transfer Protocol Secure，缩写：HTTPS）是一种通过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。
从上面的定义我们可以得知：
- HTTPS 并非是应用层的一种新协议，只是在 HTTP 的通信接口部分用 SSL 和 TLS 协议代替了而已；
- HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包；
- HTTPS 还会帮助我们提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
HTTPS 是在 HTTP 上建立 SSL 加密层，并对传输数据进行加密，是 HTTP 协议的安全版。现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。
使用 HTTPS 通信时，不再用 http://，而是改用 https://。另外，当浏览器访问 HTTPS 通信有效的 Web网站时，浏览器的地址栏内会出现一个带锁的标记。对 HTTPS 的显示方式会因浏览器的不同而有所改变。
为什么需要 HTTPS？
HTTPS 是专为解决 HTTP 中的问题而诞生的，了解 HTTPS 前，我们先来盘点 HTTP 中的问题：
1. 通信使用明文（不加密），内容可能会被窃听
HTTP 本身不具备加密功能，所以无法对通信整体（请求和相应的内容）进行加密（其实所有未加密的协议都会存在这类问题）。因为互联网是由连通道世界各地的网络组成，在此通信线路上的某些网络设备、光缆、计算机都不可能是个人的私有物，所以无法保证在某个环节遭到恶意窥视。
及时已经过加密处理的通信，也会被窥视到通信内容，只不过如果信息经过加密，就有可能让人无法破解报文原本内容。窃听并非难事，被广泛使用的那些抓包和嗅探器工具就可以。
2. 不验证通信方的身份就可能遭遇伪装
HTTP协议中的请求和响应不会对通信方进行确认。在HTTP协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的IP地址和端口号没有被Web服务器设定限制访问的前提下）。所以会存在以下各种隐患：
- 无法确定请求发送至目标的 WEB 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的服务器；
- 无法确定响应返回到客户端是否是按真实意图接受响应的那个客户端。有可能是已伪装的客户端；
- 无法确定正在通信的对方是否具备访问权限。因为某些 WEB 服务器上保存着重要信息，只想发给特定用户通信的权限；
- 无法判定请求来自何方、出自谁收；
- 即使是无意义的请求也会照单全收。无法阻止海量强求下的 DoS 攻击（拒接服务攻击）
3. 无法证明报文的完整性，可能已遭篡改
所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。换句话说，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击成为中间人攻击（MIMT）
HTTPS 是如何解决这些问题的？
HTTPS 是披着 SSL 协议这层外衣的 HTTP。通常，HTTP 直接和 TCP 通信；当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信。SSL 是当今世界上应用最为广泛的网络安全技术，有了 SSL 之后，HTTP 就拥有了加密、证书和完整性保护的功能。
HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密：
- 其利用非对称加密实现身份认证和密钥协商；
- 对称加密算法采用协商的密钥对数据加密；
- 基于散列函数验证信息的完整性。
1. 解决内容可能被窃听的问题 – 加密
HTTPS 利用非对称加密实现身份认证和密钥协商；然后采用对称加密算法使用协商的密钥对数据加密。这种方式具体原因如下：
近代的加密方式都是公开的，秘钥都是保密的，通过这种方式得以保持加密方法的安全性。加密和解密都需要秘钥，没有秘钥就无法对秘钥解密；反过来，任何人持有秘钥就能解密了。如果秘钥被攻击者获得，加密也就失去了意义；
对称加密（对称秘钥加密），这种方式加密和解密同用一个密钥。所以加密双方必须拥有同一个秘钥。
非对称加密（公开秘钥加密），这种方式使用一对非对称秘钥，一把叫私有秘钥，一把叫公开秘钥，私有秘钥不能让任何人知道，而公开秘钥可以随意发布。使用公开秘钥加密的内容，只有通过私有秘钥解密，反之亦然。
如果使用对称加密，以对称加密方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落人攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。
如果使用非对称加密，非对称加密就很好地解决了对称加密的困境。使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。
非对称加密的特点是信息传输一对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信。这种方式有以下缺点：
- 使用非对称加密在数据加密解密过程需要消耗一定时间，降低了数据传输效率；
- 公钥是公开的，所以针对私钥加密的信息，黑客截获后可以使用公钥进行解密，获取其中的内容；
- 公钥并不包含服务器的信息，使用非对称加密算法无法确保服务器身份的合法性，存在中间人攻击的风险，服务器发送给客户端的公钥可能在传送过程中被中间人截获并篡改；
因为非对称加密的处理速度要比对称加密的效率要慢，所以 HTTPS 充分采用两者的优势，在交换秘钥环节使用非对称加密（来协商秘钥），之后的建立通信交换报文阶段则使用对称加密方式。
2. 解决通信方身份可能被伪装的问题 —— 数字证书
因为公开秘钥加密方式无法证明公开秘钥本身就是货真价实的公开秘钥。比如，正想和某台服务器建立公开秘钥加密方式下的通信时，如何证明收到的公开秘钥就是原本预想的那台服务器的公开秘钥。或许在公开密钥传输途中，真正的公开秘钥已经被攻击者替换掉了。
为解决上述问题，可以使用数字证书认证机构（CA）和其相关机关颁发的公开秘钥证书。
我们来介绍一下数字证书认证机构的业务流程：
- 服务器的运营人员向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;
- CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
- 如信息审核通过，CA会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA的私钥对信息摘要进行加密，密文即签名;
- 客户端 Client 向服务器 Server 发出请求时，Server 返回证书文件;
- 客户端 Client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即服务器的公开密钥是值得信赖的。
- 客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。
3. 解决报文可能遭篡改问题 —— 数字签名
网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？—-校验数字签名。
数字签名有两种功效：
- 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
- 数字签名能确定消息的完整性,证明数据是否未被篡改过。
数字签名如何生成:
将一段文本先用Hash函数生成消息摘要，然后用发送者的私钥加密生成数字签名，与原文文一起传送给接收者。接下来就是接收者校验数字签名的流程了。
校验数字签名流程：
接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
HTTPS 的整个通信流程
- 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等），以及一个随机数（
RandomA），稍后用于生成”对话密钥”。 - 服务器可进行 SSL 通信时，会以 Server Hello* 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件（服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的，确认加密方式，比如 RSA），一个随机数（
RandomB），稍后用于生成”对话密钥”。 - 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
- 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束，（之后客户端会验证证书的合法性，拿到服务端的公钥）。
- SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的服务端公钥进行加密。
- 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会约定的加密方式和三个随机数（RandomA、RandomB、Pre-master secret）生成的密钥加密。
- 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
- 服务器同样发送 Change Cipher Spec 报文。
- 服务器同样发送 Finished 报文。
- 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
- 应用层协议通信，即发送 HTTP 响应。
- 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。
在以上流程中，应用层发送数据时会附加一种叫做 MAC（Message Authentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。
更详细的过程看下图：
至于为什么一定要用三个随机数？
“不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说，pre-master-key 本身就是一个随机数，再加上 hello 消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre-master 的存在在于 SSL 协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么 pre-master secret 就有可能被猜出来，那么仅适用 pre master secret 作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上 pre master secret 三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”
为何不所有的网站都使用 HTTPS？
既然HTTPS那么安全可靠，那为何不所有的Web网站都使用HTTPS？
首先，很多人还是会觉得HTTPS实施有门槛，这个门槛在于需要权威CA颁发的SSL证书。从证书的选择、购买到部署，传统的模式下都会比较耗时耗力。
其次，HTTPS普遍认为性能消耗要大于HTTP，因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。但事实并非如此，用户可以通过性能优化、把证书部署在SLB或CDN，来解决此问题。举个实际的例子，“双十一”期间，全站HTTPS的淘宝、天猫依然保证了网站和移动端的访问、浏览、交易等操作的顺畅、平滑。通过测试发现，经过优化后的许多页面性能与HTTP持平甚至还有小幅提升，因此HTTPS经过优化之后其实并不慢。
除此之外，想要节约购买证书的开销也是原因之一。要进行HTTPS通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。