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 协议使用，也可以给它们增强安全性。整个架构如下图所示:
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 的关系:
其中
Handshake protocol ，
Change Ciper Spec protocol 和
Alert protocol 组成了
SSL Handshaking Protocols 。
Record Protocol 有三个连接状态
(Connection State) ，连接状态定义了压缩，加密和
MAC 算法。所有的
Record 都是被当前状态
(Current State ) 确定的算法处理的。
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 网站服务器的证书的有效性，再得到其确认后，再开始与服务器进行通信。
