确保Web安全的 HTTPS

写下前面

阅读这篇文章可能须要20分钟，但能帮你了解关于HTTPS的SSL、CA、密钥加密之间的关系。

HTTP的缺点

HTTP主要有这些不足，列举以下：

• 通讯使用明文（不加密），内容可能会被窃听
• 不验证通讯方的身份，所以有可能遭遇假装
• 没法证实报文的完整性，因此有可能已遭篡改

通讯使用明文可能会被窃听

因为HTTP自己不具有加密的功能，因此也没法作到对通讯总体（使用HTTP协议通讯的请求和响应内容）进行加密。即，HTTP报文使用明文（指未通过加密的报文）方式发送。

TCP/IP是可能被窃听的网络

按TCP/IP协议簇的工做机制，通讯内容在全部的通讯线路上都有可能遭到窥视。

即便已经加密处理过的通讯，也会被窥视到通讯内容，这点和未加密过得通讯是相同的。只是说若是通讯通过加密，就有可能让人没法破解报文信息的含义，但加密处理过的报文信息自己仍是会被看到的。可使用Wireshark或Fiddler进行抓包。

加密处理防止被窃听

在目前你们正在研究的如何防止窃听保护信息的几种对策中，最为普及的就是加密技术。加密的对象能够有这么几个：

通讯的加密

HTTP协议中没有加密机制，但能够经过和SSL（Secure Socket Layer，安全套接[ip+port]层）或TLS（Transport Layer Security，安全传输协议）的组合使用，加密HTTP的通讯内容。

用SSL创建安全通讯线路以后，就能够在这条线路上进行HTTP通讯了。与SSL组合使用的HTTP被称为HTTPS（HTTP Secure，超文本传输安全协议）或HTTP over SSL。

内容的加密

诚然，为了作到有效的内容加密，前提是要求客户端和服务器同时具有加密和解密机制。因为该方式不一样于SSL或TLS将整个通讯线路加密处理，因此内容仍然有被篡改的风险。

不验证通讯方的身份就可能遭到假装

HTTP协议中的请求和响应不会对通讯方进行确认。也就是说存在“服务器是否就是发送请求中URL真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端手中”等相似问题。

任何人均可以发起请求

服务器只要接收到请求，无论对方是谁都会返回一个响应（但也仅限于发送端的IP地址和端口号没有被Web服务器设定限制访问的前提下）。由于不确认通讯方，会存在如下隐患：

• 没法肯定请求发送至目标的Web服务器是不是按真实意图返回响应的那台服务器。有多是假装的Web服务器。
• 没法肯定响应返回到的客户端是不是按真实意图接收响应的那个客户端。有多是已假装的客户端。
• 没法肯定正在通讯的对方是否具有访问权限。由于某些Web服务器上保存着重要的信息，只想发给特定用户通讯的权限。
• 没法判断请求是来自何方、出自谁手。
• 即便是无心义的请求也会照单全收。没法阻止海量请求下的DOS（Denial of Service，拒绝服务攻击）。

查明对手的证书

虽然使用HTTP协议没法确认通讯方，但若是使用SSL则能够。SSL不只提供加密处理，并且还使用了一种被称为证书的手段，可用于确认方。

证书由值得信任的第三方机构颁发，用以证实服务器和客户端是实际存在的。另外，伪造证书从技术角度来讲是异常困难的一件事。因此，只要可以确认通讯方（服务器或客户端）持有的证书，便可判断通讯方的真实意图。

经过使用证书，以证实通讯方就是意料中的服务器。这对使用者我的来说，也减小了信息泄露的危险性。

在掘金主页点开浏览器地址栏的小锁以后，再点击证书，即可以看到第三方机构颁发给 *.juejin.im 的证书。

另外，客户端持有证书便可完成我的身份的确认，也可用于对Web网站的认证环节。例如在配置Git的时候，在本地持有的证书。

没法证实报文完整性，可能已遭篡改

接受到的内容可能有误

因为HTTP协议没法证实通讯的报文完整性，所以，在请求或响应发出去以后直到对方接收以前的这段时间内，即便请求或响应的内容遭到篡改，也没办法获悉。像这样，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）。

如何防止篡改

虽然有使用HTTP协议肯定报文完整性的方法，但事实上并不便捷、可靠。其中经常使用的是MD5和SHA-1等散列值校验的方法，以及用来确认文件的数字签名方法。

提供文件下载服务的Web网站也会提供相应的以PGP（Pretty Good Privacy，完美隐私）建立的数字签名及MD5算法生成的散列值。PGP是用来证实建立文件的数字签名，MD5是由单向函数生成的散列值。

不论使用哪种方法，都须要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器没法自动帮用户检查。

惋惜的是，用这些方法也依然没法百分百保证确认结果正确。由于PGP和MD5自己被改写的话，用户是没有办法意识到的。

为了有效防止这些弊端，有必要使用 HTTPS。SSL 提供认证和加密处理及摘要功能。仅靠 HTTP 确保完整性是很是困难的，所以经过和其余协议组合使用来实现这个目标。

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

HTTP加上加密处理和认证以及完整性保护后既是HTTPS

HTTPS是身披SSL外壳的HTTP

HTTPS并不是是应用层的一种新协议。只是HTTP通讯接口部分用SSL（Secure Socket Layer）和TLS（Transport layer Security）协议代替而已。

一般HTTP直接和TCP通讯。当使用SSL时，则演变成先和SSL通讯，再由SSL和TCP通讯了。

SSL是独立于HTTP的协议，因此不光是HTTP协议，其余运行在应用层的SMTP和Telnet等协议都可配合SSL协议使用。能够说SSL是当今世界上应用最普遍的网络安全技术。

相互交换密钥的公开密钥加密技术

在对SSL讲解以前，咱们先来了解一下加密方法。SSL采用一种叫作公开密钥加密（Public-key cryptography）的加密方式。

近代的加密方法中加密算法是公开的，而密钥确实保密的。经过这种方式得以保持加密方法的安全性。

共享密钥加密的困境

加密和解密用同一个密钥的方式称为共享密钥加密（Common key crypto system），也被称为对称密钥加密。

以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能

安全地转交

？在互联网上转发密钥时，若是通讯被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

使用两把密钥的公开密钥加密

公开密钥加密方式很好地解决了共享密钥加密的困境。

公开密钥加密使用一对非对称的密钥。一把叫作私钥（private key），另外一把叫作公开密钥（public key）。顾名思义，私有密钥不能让其余任何人知道，而公开密钥则能够随意发布，任何人均可以得到。

使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方接收到被加密的信息后，再使用本身的私有密钥进行解密。利用这种方式，不须要发送用来解密的私有密钥，也没必要担忧密钥被攻击者窃听而盗走。

HTTPS采用混合加密机制

HTTPS采用共享密钥加密和公开密钥加密二者并用的混合加密机制。若密钥可以实现安全交换，那么有可能会考虑仅使用公开密钥加密来通讯。可是公开密钥加密和共享密钥加密相比，其处理速度要慢。

因此充分利用二者各自的优点，在交换密钥环节使用公开密钥加密方式，以后的创建通讯交换报文阶段则使用共享密钥加密方式。

证实公开密钥正确性的证书

遗憾的是，公开密钥加密方式仍是存在一些问题。那就是没法证实公开密钥自己就是货真价实的公开密钥。好比，正准备和某台服务器创建公开密钥加密方式下的通讯时，如何证实收到的公开密钥就是本来预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。

为了解决上述问题，可使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

数字证书认证机构处于客户端与服务器双方都信赖的第三方机构的立场上。咱们先来介绍下数字证书认证机构的业务流程。首先，服务器的运营人员先数字证书认证机构提出公开密钥的申请。数字证书认证机构在判别提出申请者的身份以后，会对已申请的公开密钥作数字签名，而后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一块儿。

服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通讯。公钥证书也可叫作数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证经过，客户端即可明确两件事：一，认证服务器的公开密钥是真实有效的数字证书认证机构所颁发。二，服务器的公开密钥是值得信赖的。

此处认证机关的公开密钥必须安全地转交给客户端。使用通讯方式时，如何转交是一件很困难的事，所以，多数浏览器开发商发布版本时，会事先在内部植入经常使用认证机关的公开密钥。

HTTPS的安全通讯机制

为了更好的理解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响应。

最后由客户端断开链接。断开链接时，发送client_notify报文。上图作了一些省略，这步以后再发送TCP-FIN报文来关闭与TCP的通讯。

在上述；流程中，应用层发送数据时会附加一种叫作MAC（Massage Authentication Code）的报文摘要。MAC可以查知报文是否找到篡改，从而保护报文的完整性。

下面是对整个流程的图解。图中说明了从仅使用服务器端的公开密钥证书（服务器证书）创建HTTPS通讯的整个过程。

SSL与TSL

HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport LayerSecurity）这两个协议。

SSL技术最初是由浏览器开发商网景通讯公司率先倡导的，开发过SSL3.0以前的版本。目前主导权已转移到IETF（Internet Engineering Task Force，Internet工程任务组）的手中。

IETF以SSL3.0为基准，后又指定了TSL1.0、TSL1.1和TSL1.2.TSL是以SSL为原型开发的协议，有时会统一称该协议为SSL。当前主流的版本是SSL3.0和TSL1.0。

SSL速度慢吗

HTTPS也存在一些问题，那就是当使用SSL时，他的处理速度会变慢。

SSL的慢分两种。一种是指通讯慢。另外一种是指因为大量消耗CPU及内存等资源，致使处理速度变慢。

和使用HTTP相比，网络负载可能会变慢2到100倍。除去和TCP链接，发送HTTP请求-响应之外，还必须进行SSL通讯，所以总体上处理通讯量不可避免会增长。

另外一点是SSL必须进行加密处理。在服务器和客户端都须要进行加密和解密的运算操做。所以从结果上将，比起HTTP会更多地消耗服务器和客户端的硬件资源，致使负载加强。

针对速度变慢这一问题，并无根本性的解决方案，咱们可使用SSL加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL通讯专用硬件，相对软件来讲，可以提升数倍SSL的计算速度。

参考：《图解HTTP》

百度百科-公开密钥

HTTPS的故事