HTTPS
HTTPS 概述与运行机制
在进行 HTTP 通信时，信息可能会监听、服务器或客户端身份伪装等安全问题，HTTPS 则能有效解决这些问题。在使用原始的 HTTP 连接的时候，因为服务器与用户之间是直接进行的明文传输，导致了用户面临着很多的风险与威胁。攻击者可以用中间人攻击来轻易的 截获或者篡改传输的数据。攻击者想要做些什么并没有任何的限制，包括窃取用户的 Session 信息、注入有害的代码等，乃至于修改用户传送至服务器的数据。
我们并不能替用户选择所使用的网络，他们很有可能使用一个开放的，任何人都可以窃听的网络，譬如一个咖啡馆或者机场里面的开放 WiFi 网络。普通的 用户很有可能被欺骗地随便连上一个叫免费热点的网络，或者使用一个可以随便被插入广告的网路当中。如果攻击者会窃听或者篡改网路中的数据，那么用户与服务 器交换的数据就好不可信了，幸好我们还可以使用 HTTPS 来保证传输的安全性。HTTPS 最早主要用于类似于经融这样的安全要求较高的敏感网络，不过现在日渐被各种各样的网站锁使用，譬如我们常用的社交网络或者搜索引擎。HTTPS 协议使用的是 TLS 协议，一个优于 SSL 协议的标准来保障通信安全。只要配置与使用得当，就能有效抵御窃听与篡改，从而有效保护我们将要去访问 的网站。用更加技术化的方式说，HTTPS 能够有效保障数据机密性与完整性，并且能够完成用户端与客户端的双重验证。
随着面临的风险日渐增多，我们应该将所有的网络数据当做敏感数据并且进行加密传输。已经有很多的浏览器厂商宣称要废弃所有的非 HTTPS 的请求，乃 至于当用户访问非 HTTPS 的网站的时候给出明确的提示。很多基于 HTTP/2 的实现都只支持基于 TLS 的通信，所以我们现在更应当在全部地方使用 HTTPS。目前如果要大范围推广使用 HTTPS 还是有一些障碍的，在一个很长的时间范围内使用 HTTPS 会被认为造成很多的计算资源的浪费，不过随着现代硬件 与浏览器的发展，这点计算资源已经不足为道。早期的 SSL 协议与 TLS 协议只支持一个 IP 地址分配一个整数，不过现在这种限制所谓的 SNI 的协议扩展来解 决。另外，从一个证书认证机构获取证书也会打消一些用户使用 HTTPS 的念头，不过下面我们介绍的像 Let’s Encrypt 这样的免费的服务就可以打破这种障碍。
Definition
HTTPS = HTTP + 加密 + 认证 + 完整性保护，HTTPS 也就是 HTTP 加上加密处理、认证以及完整性保护。使用 HTTPS 通信时，用的是 https://，而不是 http://。另外，当浏览器访问 HTTPS 的 Web 网站时，浏览器地址栏会出现一个带锁的标记。要注意，HTTPS 并非是应用层的新协议，而是 HTTP 通信接口部分用 SSL 协议代替而已。本来，HTTP 是直接基于 TCP 通信。在 HTTPS 中，它先和 SSL 通信，SSL 再和 TCP 通信。所以说 HTTPS 是披了层 SSL 外壳的 HTTP。SSL 是独立于 HTTP 的协议，所以其他类似于 HTTP 的应用层 SMTP 等协议都可以配合 SSL 协议使用，也可以给它们增强安全性。整个架构如下图所示:
Performance
HTTPS 使用 SSL 通信，所以它的处理速度会比 HTTP 要慢。一是通信慢。它和 HTTP 相比，网络负载会变慢 2 到 100 倍。除去和 TCP 连接、发送 HTTP 请求及响应外，还必须进行 SSL 通信，因此整体上处理通信量会不可避免的增加。二是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的去处处理。所以它比 HTTP 会更多地消耗服务器和客户端的硬件资源。
SSL/TLS Protocol
SSL 协议，是一种安全传输协议，最初是由 Netscape 在 1996 年发布，由于一些安全的原因 SSL v1.0 和 SSL v2.0 都没有公开，直到 1996 年的 SSL v3.0。TLS 是 SSL v3.0 的升级版，目前市面上所有的 Https 都是用的是 TLS，而不是 SSL。本文中很多地方混用了 SSL 与 TLS 这个名词，大家能够理解就好。
下图描述了在 TCP/IP 协议栈中 TLS( 各子协议)和 HTTP 的关系:
TLS Handshake Protocol 和 Change Ciper Spec Protocol 会导致 Record Protocol 状态切换。
empty state -------------------> pending state ------------------> current state
Handshake Protocol Change Cipher Spec
初始当前状态(Current State )没有指定加密，压缩和 MAC 算法，因而在完成 TLS Handshaking Protocols 一系列动作之前，客户端和服务端的数据都是明文传输的；当 TLS 完成握手过程后，客户端和服务端确定了加密，压缩和 MAC 算法及其参数，数据(Record )会通过指定算法处理。
Why HTTPS?
HTTP 日常使用极为广泛的协议，它很优秀且方便，但还是存在一些问题，如: – 明文通信，内容可以直接被窃听 – 无法验证报文的完整性，可能被篡改 – 通信方身份不验证，可能遇到假的客户端或服务器
中间人攻击与内容窃听
HTTP 不会对请求和响应的内容进行加密，报文直接使用明文发送。报文在服务器与客户端流转中间，会经过若干个结点，这些结点中随时都可能会有窃听行为。因为通信一定会经过中间很多个结点，所以就算是报文经过了加密，也一样会被窃听到，不过是窃听到加密后的内容。要窃听相同段上的通信还是很简单的，比如可以使用常用的抓包工具 Wireshark。这种情况下，保护信息安全最常用的方式就是采取加密了，加密方式可以根据加密对象分以下几种：( 1)通信加密 HTTP 协议基于 TCP/IP 协议族，它没有加密机制。但可以通过 SSL(Secure Socket Layer，安全套接层)建立安全的通信线路，再进行 HTTP 通信，这种与 SSL 结合使用的称为 HTTPS(HTTP Secure，超文本传安全协议)。(2 )内容加密还可以对通信内容本身加密。HTTP 协议中没有加密机制，但可以对其传输的内容进行加密，也就是对报文内容进行加密。这种加密方式要求客户端对 HTTP 报文进行加密处理后再发送给服务器端，服务器端拿到加密后的报文再进行解密。这种加密方式不同于 SSL 将整个通信线路进行加密，所以它还是有被篡改的风险的。
报文篡改
接收到的内容可能被做假
HTTP 协议是无法证明通信报文的完整性的。因此请求或响应在途中随时可能被篡改而不自知，也就是说，没有任何办法确认，发出的请求 / 响应和接收到的请求 / 响应是前后相同的。比如浏览器从某个网站上下载一个文件，它是无法确定下载的文件和服务器上有些话的文件是同一个文件的。文件在传输过程中被掉包了也是不知道的。这种请求或响应在传输途中，被拦截、篡改的攻击就是中间人攻击。比如某运营商或者某些 DNS 提供商会偷偷地在你的网页中插入广告脚本，就是典型的例子。
防篡改
也有一些 HTTP 协议确定报文完整性的方法，不过这些方法很不方便，也不太可靠。用得最多的就是 MD5 等哈希值校验的方法。很多文件下载服务的网站都会提供相应文件的 MD5 哈希值，一来得用户亲自去动手校验(中国估计只有 0.1% 不到的用户懂得怎么做吧)，二来如果网站提供的 MD5 值也被改写的话呢？所以这种方法不方便也不可靠。
仿冒服务器 / 客户端
DDOS 攻击与钓鱼网站
在 HTTP 通信时，由于服务器不确认请求发起方的身份，所以任何设备都可以发起请求，服务器会对每一个接收到的请求进行响应(当然，服务器可以限制 IP 地址和端口号)。由于服务器会响应所有接收到的请求，所以有人就利用这一点，给服务器发起海量的无意义的请求，造成服务器无法响应正式的请求，这就是 Dos 攻击(Denial Of Service，拒绝服务攻击)。由于客户端也不会验证服务器是否真实，所以遇到来自假的服务器的响应时，客户端也不知道，只能交由人来判断。钓鱼网站就是利用了这一点。
身份认证
HTTP 协议无法确认通信方，而 SSL 则是可以的。SSL 不仅提供了加密处理，还提供了叫做 “ 证书 ” 的手段，用于确定通信方的身份。证书是由值得信任的第三方机构颁发(已获得社会认可的企业或组织机构)的，用以证明服务器和客户端的身份。而且伪造证书从目前的技术来看，是一件极为难的事情，所以证书往往可以确定通信方的身份。以客户端访问网页为例。客户端在开始通信之前，先向第三机机构确认 Web 网站服务器的证书的有效性，再得到其确认后，再开始与服务器进行通信。