准确的说，HTTPS 不是一种协议，而是 HTTP 和 SSL 两种技术的组合，HTTP 本身所有的数据都是不加密的。
SSL ( Secure Socket Layer ) ，有时也称为 TLS ( Transport Layer Security ) ，是介于传输层和应用层的拓展层，可以将应用层数据加密后送入传输层。因此，使用了 SSL 传输的 HTTP 报文整体都是被加密的。
真的安全吗？
为什么 HTTPS 比 HTTP 安全？下面来逐步分析其加密过程。
对称加密算法
对称加密算法：又称单钥加密，是指加密和解密使用相同的密钥。
因为 HTTP 所有数据都没有被加密，一旦中间人拦截到客户端请求，就可以看到具体的报文内容。如果客户端和服务端约定好同一密钥进行通信，则中间人无法破解。
但是服务端在通信之前不知道客户端的密钥，如何安全地进行密钥传递就是接下来要解决的问题。
非对称加密算法
非对称加密算法：又称双钥加密，包括公钥和私钥。公钥/私钥一一对应，有一把公钥就必然有一把与之对应的、独一无二的私钥，反之亦成立。公钥可以解开私钥加密的信息，反之亦成立；
借助非对称加密算法，服务端生成自己的密钥对，私钥自己保存，公钥对外公开。
这样的话，客户端就可以使用服务端返回的公钥来加密自己的密钥 ( 对称加密算法 ) 发送给服务端。即使中间人拦截，由于能解密公钥的私钥只有服务端才有，所以不能解密，保证了数据传输的安全。
那么问题来了，任何人都可以生成一对公钥/私钥，如果中间人在拦截请求时，把自己的公钥返回给客户端，客户端不能分辨出公钥的拥有者，只会按照之前的逻辑，使用接收到的公钥去加密自己的密钥来和服务端通信。
由于客户端使用中间人的公钥进行加密，所以中间人可以使用自己的私钥对客户端的请求进行解密，拿到请求的所有内容，然后再用服务端的公钥对请求进行加密并转发给服务端。整个过程“天衣无缝”，你几乎觉察不到中间人的存在，但是你的信息已经实实在在地被盗取了。
如果客户端能辨别服务端公钥真伪，那么我们的信息又安全了。
数字证书
CA ( Certification Authority ) 是认证机构的国际通称，它是对数字证书的申请者发放、管理、取消数字证书的机构。CA的作用是检查证书持有者身份的合法性，并签发证书，以防证书被伪造或篡改。
服务端将自己的公钥以及相关注册信息发送给 CA 申请认证，来获得数字证书，其中就包含了服务端的公钥。这样服务端就可以返回数字证书给客户端，因为通过了国际权威机构的认证，数字证书将持有者的公钥和持有者的身份绑定起来，我们这次可以放心地使用公钥去和服务端进行通信了。
这时候中间人又出来搞事情了，我能伪造公钥，我难道不能伪造证书吗？证书没有加密，那我把证书中的公钥换成我自己 ( 中间人 ) 的不就得了？
可以，没毛病。不过中间者还是 SOMETIME NAIVE，CA 比他们不知道高到哪里去了，自然有应对证书被篡改的办法。
数字签名
CA 首先对证书进行 HASH，拿到摘要后使用 CA 的私钥对其加密，并把加密后的结果 ( 签名 ) 附在证书后面，这个过程就叫数字签名。客户端拿到证书后，会使用 CA 的公钥对签名解密，然后把证书 HASH 后跟解密后的结果进行对比，一致的话说明确实是原厂出品，不一致的话说明被纂改过，直接丢掉。
这次中间人发现没招了，即使修改了证书，由于没有 CA 的私钥，就不能对证书的 HASH 结果进行加密，这个数字签名改不了是不会有客户端认的。正打算放弃时，他忽然想到，CA 的公钥这里貌似可以做文章，如果能伪造 CA 的公钥，那么就可以伪造证书，从而摧毁这套信任链体系。
那客户端怎么保证 CA 的公钥 ( 或者说用于验证证书签名的公钥 ) 的可靠性？
证书链
其实，一个证书的公钥是放在他上一级证书，只要能保证他上一级证书可靠，我们就能保证本级证书可靠。
以此类推，每级证书都是使用上一级证书的非对称密钥进行签名和验证的，我们称这一系列证书的关系为证书链。而在证书链的最顶层的是根证书，那根证书的可靠性是由谁保证的？
根证书是由他自己进行签名和验证的，我们又称他为自签名根证书。他的可靠性是不需要被证明的，或者说需要使用者去证明。
所以，只要我们系统中安装了一个机构的自签名根证书，就代表信任该证书下的所有证书。一旦根证书出了问题，我们的整个证书体系的安全就不再可信。
证书撤销
证书吊销列表 ( Certificate Revocation List，CRL ) ，一个被签署的列表，它指定了一套证书发布者认为无效的证书。
当我们从服务端拿到数字证书时，会根据证书上的CRL分发点从指定的 URL 下载 CRL 来检查证书的有效性，CRL 包含了其下一次的更新日期。
Q&A
客户端通过证书拿到服务端的公钥后，为什么不采用双钥加密，而转用单钥加密？
这是个好问题。确实，如果客户端拿到服务端公钥的时候，生成自己的公钥/私钥，然后把自己的公钥发给服务端，采用两对密钥进行通信也是可以的。
但是，非对称算法在性能上比对称算法要慢太多。
采用对称算法已经能确保整个通信的安全，其加密/解密带来的消耗可以忽略不计，而且理论上来说对称算法比非对称算法甚至更难破解。
CA 为什么不使用自己的私钥直接对证书加密，而采用数字签名的方式？
其实这个问题跟上一个类似，因为非对称加密的方式效率低下，比起加密原信息，不如去加密他的 HASH 来得划算，其实这两种给我们带来的作用是等效的，都能防止证书被篡改。
为什么不可以直接用根证书去给其他所有证书签名，而要设计证书链的概念？
这个问题一开始也困扰我很久，我就不阐述我错误的思路了，只提醒大家一点：两个父子证书间的映射关系是放在子证书，而不是父证书。
如果直接使用根证书去给各服务端签署证书，那根证书的密钥就不是足够安全的，毕竟签署的过程不是手动进行，而是放在服务端进行的。一旦有人攻破 CA 的服务器，拿到根证书的密钥，那他就可以伪造根证书，该 CA 下的所有证书都不可信了。
所以，为了保证根证书的绝对安全，根证书的私钥都被保存在离线的金库中。他一般被定期拿出来确保相关密码设备的正常工作，签署证书吊销列表，以及签署新的二级证书。
那么二级证书就可以用来做在线签名，即使二级证书的私钥被盗 ( 可能性很小 ) ，只要根证书是安全的，那么我就可以去更新证书的吊销列表，来让被盗的二级证书失效。
为什么要有多个二级证书？我们可以使用不同的证书去做不同的事情，例如 A 来签署保证邮件安全的证书，B 来签署 SSL 证书。毕竟多线程更高效，各自负责自己的业务场景，一定程度上也能分散风险 ( 我是这么想的，不一定对 ) 。
缺点
HTTPS 相比于 HTTP 更加安全自不必说，那他都有哪些缺点呢？
建立连接
HTTP 使用 TCP 三次握手建立连接，客户端和服务端需要交换 3 个包。 HTTPS 除了 TCP 的三个包，还需要加上 SSL 握手需要的 9 个包，一共是 12 个包。
这样的话，HTTPS 在建立连接阶段比 HTTP 多花费的时间包括了多出的网络延时和 SSL 本身加密/解密的开销。
为了避免重新握手而造成的访问效率低下，这时候引入了Session ID的概念。出于某种原因，如果对话中断且在短时间内重连，只要客户端给出之前的Session ID，且服务器有这个Session ID的记录，双方就可以重新使用已有的对称密钥，而不必重新生成一把。
上述方式可以缓解单个连接的性能问题，但对于并发访问用户数极多的大型网站，如果频繁的重建 SSL 的Session ID，对于服务器性能的影响将会是致命的。这时可以考虑在 Web 服务前配置 [SSL Termination Proxy] ( https://en.wikipedia.org/wiki/TLS_termination_proxy ) ，来将 SSL 处理转移到另一起机器以减少主服务器的负载。
通信阶段
当 SSL 建立连接后，之后的加密方式会使用客户端传输的对称加密算法。相对前面 SSL 建立连接时的非对称加密方式，对称加密方式对 CPU 的负荷基本可以忽略不记。
总而言之
HTTPS 相比 HTTP 在建立连接阶段确实会有性能的影响，但建立连接之后的通信速度跟 HTTP 差别不大。
好在 HTTPS 提供了Session ID这种优化的方式，再加上服务端如果能够进行恰当的配置和优化，相对于 HTTPS 带来的安全性，给客户端以及服务端造成体验上和性能上微小的损失都是值得的。
参考
- 密码学笔记
- HTTPS 要比 HTTP 多用多少服务器资源？
- 深入揭秘HTTPS安全问题&连接建立全过程
- 怎么保证「CA 的公钥」是真实的？
- TLS 过程中，为何不用证书提供的公钥加密数据或者加密私钥，而要设计秘钥交换流程呢？
- 证书链-Digital Certificates
- What’s in a certificate chain and why?
- SSL certificate chain verification
