HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。
HTTP的特点:
灵活配置；
无状态协议；
持久化连接（长连接、管线化）
HTTP不足： 这些也是https的特点
通信明文，易被窃听；
无法验证身份，易遭伪装；
无法验证完整性，易被篡改；
HTTPS 端口号 443
HTTPS = HTTP + 加密 + 认证 + 完整性保护
HTTPS并非时应用层的一种新协议，只是 HTTP 通信接口部分 用 SSL(Secure Socket Layer)和 TLS(Transport Layer Security)协议代替而已。 所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP.
采用 SSL 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。
（零）HTTPS的安全通信机制
**第一次握手**：
步骤 1: 【加密协商】客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包 含客户端支持的 SSL 的指定版本、加密组件(Cipher Suite)列表(所 使用的加密算法及密钥长度等)；
步骤 2: 【加密协商】服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的 加密组件内容是从接收到的客户端加密组件内筛选出来的。
步骤 3: 【公钥证书】之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
步骤 4: 【握手完成】最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
**第二次握手**：
步骤 5: 【客户端发送共享密钥给服务端】SSL 第一次握手结束之后，客户端以 Client Key Exchange 报 文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
步骤 6: 【客户端指定共享加密】接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
步骤 7: 【握手完成】客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确 解密该报文作为判定标准。
**第三次握手**：
步骤 8:【服务端指定共享加密】 服务器同样发送 Change Cipher Spec 报文。
步骤 9:【握手完成】服务器同样发送 Finished 报文。
**通信**：
步骤 10: 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接 就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用 层协议的通信，即发送 HTTP 请求。
步骤 11: 应用层协议通信，即发送 HTTP 响应。
步骤 12: 最后由客户端断开连接。断开连接时，发送 close_notify 报 文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。
（一）加密
通信加密
通过和 SSL(Secure Socket Layer，安全套接层)或 TLS(Transport Layer Security，安全层传输协议)的组合使用， 加密 HTTP 的通信内容。
SSL是独立于HTTP协议的，所以，其他运行在应用层的SMTP&Telnet等协议均可配合SSL协议使用，是当今应用最广泛的网络安全技术。
共享密钥加密（对称密钥加密）Common key crypto system：
加密和解密同用一个密钥。
存在一个问题，怎么样安全的发送密钥？ 发送密钥存在被窃听的风险，不发送的话对方不能解密。公开密钥加密解决该问题。
问题：不安全
TLS/SSL 中什么一定要用三个随机数，来生成"共享密钥"?
客户端和服务器都需要生成随机数，以此来保证每次生成的秘钥都不相同。
使用三个随机数，是因为 SSL 的协议默认不信任每个主机都能产生完全随机的数，如果只使用一个伪随机的数来生成秘钥，就很容易被破解。通过使用三个随机数的方式，增加了自由度， 三个伪随机就很接近于随机了，因此可以使用这种方法来保持生成秘钥的随机性和安全性。
第一个随机数，来自ClientHello，Client Random
第二个随机数，来自ServerHello，Server Random
第三个随机数，客户端和服务端手里拿到了密钥交换算法的两个参数（client params、 server params），用ECDHE算法一阵算，算出一个新的随机数Pre-Master。
公开密钥加密：Public-key cryptography
SSL采用该加密处理方式。
一对儿 非对称的密钥，公开密钥、私有密钥；公开密钥可转交给其他方。
具体加密行为解释：发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥。
问题：加密、解密速度慢。
HTTPS采用混合加密:
在交换密钥环节使用公开密钥加密方式传递共享密钥，之后的建立通信交换报文阶段则使用共享密钥加密方.
问题：无法证明公开密钥本身就是货真价实的公开密钥。公开密钥要包裹携带共享密钥的，没法验证公开密钥的可信度，是存在暴露共享密钥风险的。
解决：为了解决上述问题，可以使用由数字证书认证机构(CA，Certificate Authority)和其相关机关颁发的公开密钥证书。
数字证书认证：
接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事: 一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。
如何验证证书的非法性？
SSL连接断开后如何恢复？
一共有两种方法来恢复断开的 SSL 连接，一种是使用 session ID，一种是 session ticket。使用 session ID 的方式，每一次的会话都有一个编号，当对话中断后，下一次重新连接时，只要客户端给出这个编号，服务器 如果有这个编号的记录，那么双方就可以继续使用以前的秘钥，而不用重新生成一把。目前所有的浏览器都 支持这一种方法。但是这种方法有一个缺点是，session ID 只能够存在一台服务器上，如果我们的请求通过负载平衡被转移到 了其他的服务器上，那么就无法恢复对话。
session ticket 是服务器在上一次对话中发送给客户的， 这个 ticket 是加密的 ，只有服务器能够解密，里面包含了
本次会话的信息，比如对话秘钥和加密方法等。这样不管我们的请求是 否转移到其他的服务器上，当服务器将 ticket 解密以后，就能够获取上次对话的信息，就不用重新生成对话秘钥了。
内容加密（实体内容）
要求客户端和服务器同时具备加密和解密机制。
内容仍有被篡改的风险
（二）验证通信方身份（网站认证）
不是任何人都具备访问权限。
通过CA证书可以解决这个问题。
（三）验证报文完整性
接收到的内容可能有误（中间人攻击）
验证是不是一模一样，最好的办法就是发送一个测试报文。用什么报文来测试呢？
秋后算总账: 就是通信双方把此前所有本地发出的、以及从对方收到的所有字节，按照时间的先后次序，放在一起。比如客户端一共发出5000个字节、服务器发出8000字节，那么双方只要将这13000个字节生成一个Hash，然后用Session Key加密发给对方。对方用Session Key解密，得到的明文，其实就是对方计算的Hash值。如果与本地计算的Hash值相同，那么说明两件事：
- 双方的Session Key是一样的，间接说明双方的Master Key是一样的，因为Session Key是由Master Key推导出来的。
- 此前双方的所有交互报文，没有被篡改、删除、添加，否则双方计算的Hash值不可能相等。
双方Hash值相同，那么一次成功的TLS安全协商就宣告结束了。双方就可以使用Session Key、HMAC Key对数据进行加密/解密操作，以及完整性校验了。由于Session Key、HMAC Key只有通信双方知晓，任何第三方单位或个人都无从解密报文，这就满足了数据的机密性要求。
摘要算法 实现完整性的主要手段。个人理解，这是一种特殊的压缩算法，能够把任意长度的数据压缩成固定长度、且独一无二的摘要字符串，就好像给这段数据生成一个数字指纹。存在冲突的可能性，毕竟是压缩，摘要算法具有“单向性”和“ 雪崩效应“。常见的有MD5。
HTTPS优势与不足
HTTPS的优势及不足:
安全、可靠；
通信慢，握手比http费时50%；
缓存不如http高效；
服务端资源占用高：处理速度慢，加密过程大量消耗CPU及内存资源；
SSL要钱，且配置复杂；
HTTPS优化
硬件加速
为接入服务器安装专用的SSL硬件加速卡，作用类似 GPU，释放 CPU，能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供35k的解密能力，相当于175核 CPU，至少相当于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡可以实现接近10台服务器的接入能力。
CDN接入
HTTPS 增加的延时主要是传输延时 RTT，RTT 的特点是节点越近延时越小，CDN 天然离用户最近，因此选择使用 CDN 作为 HTTPS 接入的入口，将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少 HTTPS 带来的延时。 远程解密
本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。
会话缓存
虽然前文提到 HTTPS 即使采用会话缓存也要至少1*RTT的延时，但是至少延时已经减少为原来的一半，明显的延时优化;同时，基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息，可以省去CPU 的消耗。如果业务访问连接集中，缓存命中率高，则HTTPS的接入能力讲明显提升。当前TRP平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际可以承载13k/的接入，收效非常可观。
SPDY/HTTP2 会话复用
前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能，但是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优势，通过修改协议的方法来提升 HTTPS 的性能，提高下载速度等。
配置HTTPS
1） 申请证书；
2） 配置HTTPS：
配置web服务器，在443端口上配置HTTPS服务。
Nginx 配置：
-
listen指令后面加上ssl，再配上刚刚申请的证书即可实现简单的https -
ssl_protocals提升安全系数和性能，指定TLS1.2以上协议； -
ssl_session_tickets打开会话复用； -
ssl_prefer_server_chiphers密码套件，以服务器的套件优先，避免恶意客户端选择较弱的套件，想TSL1.3看齐，只是用ECDHE、AES、ChaCha20.
