转载

HTTPS 初解

标签（空格分隔）： https 基础

在进行 HTTP 通信时，信息可能会监听、服务器或客户端身份伪装等安全问题。HTTPS 则能有效解决这些问题。这里就简单了解下 HTTPS。

1、HTTP 存在的问题

HTTP 日常使用极为广泛的协议，它很优秀且方便，但还是存在一些问题，如：

– 明文通信，内容可以直接被窃听

– 无法验证报文的完整性，可能被篡改

– 通信方身份不验证，可能遇到假的客户端或服务器

1.1 明文通信，内容可以直接被窃听

HTTP 不会对请求和响应的内容进行加密，报文直接使用明文发送。报文在服务器与客户端流转中间，会经过若干个结点，这些结点中随时都可能会有窃听行为。

因为通信一定会经过中间很多个结点，所以就算是报文经过了加密，也一样会被窃听到，不过是窃听到加密后的内容。要窃听相同段上的通信还是很简单的，比如可以使用常用的抓包工具 Wireshark。

那如何保护信息的安全呢？最常用的就是加密技术了。加密方式可以根据加密对象分以下几种：

通信加密

HTTP 协议基于 TCP/IP 协议族，它没有加密机制。但可以通过 SSL（Secure Socket Layer，安全套接层）建立安全的通信线路，再进行 HTTP 通信，这种与 SSL 结合使用的称为 HTTPS（HTTP Secure，超文本传安全协议）。

内容加密

还可以对通信内容本身加密。HTTP 协议中没有加密机制，但可以对其传输的内容进行加密，也就是对报文内容进行加密。这种加密方式要求客户端对 HTTP 报文进行加密处理后再发送给服务器端，服务器端拿到加密后的报文再进行解密。这种加密方式不同于 SSL 将整个通信线路进行加密，所以它还是有被篡改的风险的。

1.2 无法验证报文的完整性，可能被篡改

接收到的内容可能被做假

HTTP 协议是无法证明通信报文的完整性的。因此请求或响应在途中随时可能被篡改而不自知，也就是说，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。

比如浏览器从某个网站上下载一个文件，它是无法确定下载的文件和服务器上有些话的文件是同一个文件的。文件在传输过程中被掉包了也是不知道的。

这种请求或响应在传输途中，被拦截、篡改的攻击就是中间人攻击。

某运营商就经常干这种事，打开百度、网易什么的，中间直接来个大大的广告，你懂的…

防止篡改

也有一些 HTTP 协议确定报文完整性的方法，不过这些方法很不方便，也不太可靠。用得最多的就是 MD5 等散列值校验的方法。很多文件下载服务的网站都会提供相应文件的 MD5 散列值，一来得用户亲自去动手校验（中国估计只有 0.1% 不到的用户懂得怎么做吧），二来如果网站提供的 MD5 值也被改写的话呢？所以这种方法不方便也不可靠。

1.3 通信方身份不验证，可能遇到假的客户端或服务器

在进行 HTTP 通信时，请求和响应方都不会对通信方进行身份确认。这也会给人以可乘之机。

任何人都可以发起、响应请求

在 HTTP 通信时，由于服务器不确认请求发起方的身份，所以任何设备都可以发起请求，服务器会对每一个接收到的请求进行响应（当然，服务器可以限制 IP 地址和端口号）。由于服务器会响应所有接收到的请求，所以有人就利用这一点，给服务器发起海量的无意义的请求，造成服务器无法响应正式的请求，这就是 Dos 攻击（Denial Of Service，拒绝服务攻击）。

由于客户端也不会验证服务器是否真实，所以遇到来自假的服务器的响应时，客户端也不知道，只能交由人来判断。钓鱼网站就是利用了这一点。

查明对方的证书

HTTP 协议无法确认通信方，而 SSL 则是可以的。SSL 不仅提供了加密处理，还提供了叫做“证书”的手段，用于确定通信方的身份。

证书是由值得信任的第三方机构颁发（已获得社会认可的企业或组织机构）的，用以证明服务器和客户端的身份。而且伪造证书从目前的技术来看，是一件极为难的事情，所以证书往往可以确定通信方的身份。

以客户端访问网页为例。客户端在开始通信之前，先向第三机机构确认 Web 网站服务器的证书的有效性，再得到其确认后，再开始与服务器进行通信。

HTTPS

2.1 HTTP + 加密 + 认证 + 完整性保护 = HTTPS

HTTPS 也就是 HTTP 加上加密处理、认证以及完整性保护。HTTP 协议在通信过程如果没有使用加密的明文，比如在 Web 页面输入手机号，如果这条通信线路再窃听，那么手机号就被别人知道了。

另外，在 HTTP 中，服务器和客户端都无法确认通信方，说不定就是正在和某个骗子通信呢。还得考虑报文在通信过程中有没有被篡改。

为了解决上面这些问题，可以在 HTTP 上加入加密处理和认证机制。这种添加了加密及认证机制的 HTTP 就叫做 HTTPS（HTTP Secure）。

使用 HTTPS 通信时，用的是 https://，而不是 http://。另外，当浏览器访问 HTTPS 的 Web 网站时，浏览器地址栏会出现一个带锁的标记。如下面就是 Chrome 的样式：

2.2 HTTPS 是 HTTP 披了层 SSL 的外壳

HTTPS 并非是应用层的新协议，而是 HTTP 通信接口部分用 SSL 协议代替而已。

本来，HTTP 是直接和 TCP 通信。在 HTTPS 中，它先和 SSL 通信，SSL 再和 TCP 通信。所以说 HTTPS 是披了层 SSL 外壳的 HTTP。

SSL 是独立于 HTTP 的协议，所以其他类似于 HTTP 的应用层 SMTP 等协议都可以配合 SSL 协议使用，也可以给它们增强安全性。

2.3 SSL 密钥

加密

数据在传输过程中，很容易被窃听。加密就是保护数据安全的措施。一般是利用技术手段把数据变成乱码（加密）传送，到达目的地后，再利用对应的技术手段还原数据（解密）。

加密包含算法和密钥两个元素。算法将要加密的数据与密钥（一窜数字）相结合，产生不可理解的密文。由此可见，密钥与算法同样重要。

对数据加密技术可以分为两类：私人密钥加密（对称密钥加密）和公开密钥加密（非对称密钥加密）。

SSL 采用了公开密钥加密（Public-key cryptography）的加密处理方式。

现在的加密方法中，加密算法都是公开的，网上都有各种算法原理解析的内容。加密算法虽然是公开的，算法用到的密钥却是保密的，以此来保持加密方法的安全性。

加密和解密都会用到密钥。有了密钥就可以解密了，如果密钥被攻击者获得，加密也就没有意义了。

私人密钥

私人密钥加密就是加密和解密用的是同一个密钥，这也称为对称密钥加密。

私人密钥加密存在这样一个问题，必须要将密钥发送给对方。但如何才能安全地转交密钥呢？如果在互联网上转交密钥时，被监听了，那加密也就没有意义了。也就是说，只要在互联网上发送密钥，就有被窃听的风险，但如果不发送，对方怎么解密呢？再说，如果密钥能够安全发送，那数据不也应该能安全送达么！

公开密钥加密

公开密钥加密方式能很好地解决私人密钥加密的困难。

公开密钥加密方式有两把密钥。一把叫做私有密钥（private key），另一把叫做公开密钥（public key）。私有密钥是一方保管，而公开密钥则谁都可以获得。

这种方式是需要发送密文的一方先获得对方的公开密钥，使用已知的算法进行加密处理。对方收到被加密的信息后，再使用自己的私有密钥进行解密。

这种加密方式有意思是的加密算法的神奇，经过这个公开的算法加密后的密文，即使知道公开密钥，也是无法对密文还原的。要想对密文进行解决，必须要有私钥才行。所以公开密钥加密是非常安全的，即使窃听到密文和公开密钥，却还是无法进行解密。

公开密钥加密算法用的一般是 RSA 算法（这可能是目前最重要的算法了）。这个算法由3个小伙子在1977年提出，它的主要原理是：将两个大素数相乘很简单，但想要这个乘积进行因式分解极其困难，因此可以将乘积公开作为公开密钥。不过随着目前的分布式计算和量子计算机的快速发展，说不定在将来也许能破解这个算法了。

混合加密

公开密钥加密很安全，但与私人密钥加密相比，由于公开密钥加密的算法复杂性，导致它的加密和解密处理速度都比私人密钥加密慢很多，效率很低。所以可以充分利用它们各自的优势，结合起来。

先用公开密钥加密，交换私人密钥加密会用的密钥，之后的通信交换则使用私人密钥方式。这就是混合加密。

1) 使用公开密钥加密方式安全地交换在稍后的私人密钥加密中要使用的密钥2）确保交换的密钥是安全的前提下，使用私人密钥加密方式进行通信

2.4 公开密钥证书

其实，公开密钥加密方式还存在一个很大的问题：它无法证明公开密钥本身是真实的公开密钥。比如，打算跟银行的服务器建立公开密钥加密方式的通信时，怎么证明收到的公开密钥就是该服务器的密钥呢？毕竟，要调包公开密钥是极为简单的。

这时，数字证书认证机构（CA，Certificated Authority）就出场了。

数字证书认证机构是具有权威性、公正性的机构。它的业务流程是：首先，服务器的开发者向数字证书认证机构提出公开密钥（ 服务器公开密钥 ）的申请。数字证书认证机构在核实申请者的身份之后，会用自己的公开密钥（ 数字签名公开密钥 ）对申请的公开密钥做数字签名，再将 服务器公开密钥 、数字签名以及申请者身份等信息放入公钥证书。

服务器则将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可做数字证书或简称为为证书。证书就相当于是服务器的身份证。

客户端接到证书后，使用 数字签名公开密钥 对数字签名进行验证，当验证通过时，也就证明了：1、真实有效的数字证书认证机构。2、真实有效的 服务器公开密钥 。然后就可能与服务器安全通信了。

其实这里还是有一个问题的。那就是如何将 数字签名公开密钥 安全地转给客户端？难道再去另一个认证机制那确认（现在是真有的）？无疑，安全转交是一件困难的事。因此，常用的认证机关的公开密钥会被很多浏览器内置在里面。

EV SSL（增强型）证书

证书作用这一是证明服务器是否规范，另一个作用是可以确认服务器背后的企业是否真实。具有这种特性的证书就是 EV SSL （Extended Validation SSL Certificate）证书。

EV SSL 证书是基于国际标准的严格身份验证颁发的证书。通过认证的网站能获得更高的认可度。

EV SSL 证书在视觉上最大的特色在于激活浏览器的地址栏的背景色是绿色。而且在地址栏中显示了 SSL 证书中记录的组织名称。

这个机制原本是为了防止用户被钓鱼攻击的，但效果如何还真不知道，目前来看，很多用户根本不清楚这是啥玩意儿。

HTTPS 初解

客户端证书

客户端也是可以有证书的，让服务器知道，正在通信的客户端是可信任的。

相比之下，客户端证书存在几个问题。第一是证书的获取和安装。想要获取证书时，还得用户自行安装，关键是客户端证书还是要花钱买的。另外，安装这件事本身就有很多年长的人不太会。

所以，客户端证书只在安全性要求级高的特殊情况下都会用。比如网上专业银行，在登录时，不仅要用户名和密码，还要用个U盾。

客户端的另一个问题是，客户端证书只能证明客户端的存在，却不能证明是用户本人在操作。也许是还证书都被盗了呢？

认证机构被黑

SSL 的安全建立在认证机构绝对可靠这一前提之下。但认证机构也有成功被黑的时候。在 2011年7月10号，荷兰的一家名叫 DigiNotar （同年9月20号宣布破产）的认证机构被黑窝入侵，还颁布了 google.com、twitter.com 等网站的伪造证书，走到8月28号才被伊朗发现。这一事件从根本上撼动了 SSL 的可信度。

因为伪造证书上有正规认证机构的数字签名，所以浏览器会判定该证书是正常的。当伪造的证书被用于服务器伪装时，用户根本无法察觉。

虽然微软、苹果、Opera 等浏览器厂商积极采取了措施，不过生效却是要一段时间的，这段时间内造成的用户的损失有多大就不知道了。

OpenSSL

OpenSSL 是用 C 写的一套 SSL 和 TLS 开源实现。这也就意味着人人都可以基于这个构建属于自己的认证机构，然后给自己的颁发服务器证书。不过然并卵，其证书不可在互联网上作为证书使用。

这种自认证机构给自己颁发的证书，叫做自签名证书。自己给自己作证，自然是算不得数的。所以浏览器在访问这种服务器时，会显示“无法确认连接安全性”等警告消息。

OpenSSL 在2014年4月，被爆出一个内存溢出引出的 BUG，骇客利用这点能拿到服务器很多信息，其中就包括私钥，也就使得 HTTPS 形同虚设。当时全世界大概有一百万左右的服务器有受到此漏洞的影响。由于 OpenSSL 举足轻重的作用，再加上足够致命的问题，使得这个 BUG 被形容为“互联网心脏出血”。这是近年来互联网最严重的安全事件。