什么是 HTTPS ?

回到首页

DXY Tech&Product Division


准确的说,HTTPS 不是一种协议,而是 HTTP 和 SSL 两种技术的组合,HTTP 本身所有的数据都是不加密的。

SSL ( Secure Socket Layer ) ,有时也称为 TLS ( Transport Layer Security ) ,是介于传输层和应用层的拓展层,可以将应用层数据加密后送入传输层。因此,使用了 SSL 传输的 HTTP 报文整体都是被加密的。

真的安全吗?

为什么 HTTPS 比 HTTP 安全?下面来逐步分析其加密过程。

对称加密算法

对称加密算法:又称单钥加密,是指加密和解密使用相同的密钥。

因为 HTTP 所有数据都没有被加密,一旦中间人拦截到客户端请求,就可以看到具体的报文内容。如果客户端和服务端约定好同一密钥进行通信,则中间人无法破解。

但是服务端在通信之前不知道客户端的密钥,如何安全地进行密钥传递就是接下来要解决的问题。

非对称加密算法

非对称加密算法:又称双钥加密,包括公钥和私钥。公钥/私钥一一对应,有一把公钥就必然有一把与之对应的、独一无二的私钥,反之亦成立。公钥可以解开私钥加密的信息,反之亦成立;

借助非对称加密算法,服务端生成自己的密钥对,私钥自己保存,公钥对外公开。

这样的话,客户端就可以使用服务端返回的公钥来加密自己的密钥 ( 对称加密算法 ) 发送给服务端。即使中间人拦截,由于能解密公钥的私钥只有服务端才有,所以不能解密,保证了数据传输的安全。

那么问题来了,任何人都可以生成一对公钥/私钥,如果中间人在拦截请求时,把自己的公钥返回给客户端,客户端不能分辨出公钥的拥有者,只会按照之前的逻辑,使用接收到的公钥去加密自己的密钥来和服务端通信。

由于客户端使用中间人的公钥进行加密,所以中间人可以使用自己的私钥对客户端的请求进行解密,拿到请求的所有内容,然后再用服务端的公钥对请求进行加密并转发给服务端。整个过程“天衣无缝”,你几乎觉察不到中间人的存在,但是你的信息已经实实在在地被盗取了。

如果客户端能辨别服务端公钥真伪,那么我们的信息又安全了。

数字证书

CA ( Certification Authority ) 是认证机构的国际通称,它是对数字证书的申请者发放、管理、取消数字证书的机构。CA的作用是检查证书持有者身份的合法性,并签发证书,以防证书被伪造或篡改。

服务端将自己的公钥以及相关注册信息发送给 CA 申请认证,来获得数字证书,其中就包含了服务端的公钥。这样服务端就可以返回数字证书给客户端,因为通过了国际权威机构的认证,数字证书将持有者的公钥和持有者的身份绑定起来,我们这次可以放心地使用公钥去和服务端进行通信了。

这时候中间人又出来搞事情了,我能伪造公钥,我难道不能伪造证书吗?证书没有加密,那我把证书中的公钥换成我自己 ( 中间人 ) 的不就得了?

可以,没毛病。不过中间者还是 SOMETIME NAIVE,CA 比他们不知道高到哪里去了,自然有应对证书被篡改的办法。

数字签名

CA 首先对证书进行 HASH,拿到摘要后使用 CA 的私钥对其加密,并把加密后的结果 ( 签名 ) 附在证书后面,这个过程就叫数字签名。客户端拿到证书后,会使用 CA 的公钥对签名解密,然后把证书 HASH 后跟解密后的结果进行对比,一致的话说明确实是原厂出品,不一致的话说明被纂改过,直接丢掉。

这次中间人发现没招了,即使修改了证书,由于没有 CA 的私钥,就不能对证书的 HASH 结果进行加密,这个数字签名改不了是不会有客户端认的。正打算放弃时,他忽然想到,CA 的公钥这里貌似可以做文章,如果能替换客户端手里 CA 的公钥,那么就可以伪造证书,从而摧毁这套信任链体系。

那客户端怎么保证 CA 的公钥 ( 或者说用于验证证书签名的公钥 ) 的可靠性?

证书链

其实,一个证书的公钥是放在他上一级证书,只要能保证他上一级证书可靠,我们就能保证本级证书可靠。

以此类推,每级证书都是使用上一级证书的非对称密钥进行签名和验证的,我们称这一系列证书的关系为证书链。而在证书链的最顶层的是根证书,那根证书的可靠性是由谁保证的?

根证书是由他自己进行签名和验证的,我们又称他为自签名根证书。他的可靠性是不需要被证明的,或者说需要使用者去证明。

所以,只要我们系统中安装了一个机构的自签名根证书,就代表信任该证书下的所有证书。一旦根证书出了问题,我们的整个证书体系的安全就不再可信。

证书撤销

证书吊销列表 ( Certificate Revocation List,CRL ) ,一个被签署的列表,它指定了一套证书发布者认为无效的证书。

当我们从服务端拿到数字证书时,会根据证书上的CRL分发点从指定的 URL 下载 CRL 来检查证书的有效性,CRL 包含了其下一次的更新日期。

Q&A

客户端通过证书拿到服务端的公钥后,为什么不采用双钥加密,而转用单钥加密

这是个好问题。确实,如果客户端拿到服务端公钥的时候,生成自己的公钥/私钥,然后把自己的公钥发给服务端,采用两对密钥进行通信也是可以的。

但是非对称算法在性能上比对称算法要慢太多。

采用对称算法已经能确保整个通信的安全,其加密/解密带来的消耗可以忽略不计,而且理论上来说对称算法非对称算法甚至更难破解。

CA 为什么不使用自己的私钥直接对证书加密,而采用数字签名的方式?

其实这个问题跟上一个类似,因为非对称加密的方式效率低下,比起加密原信息,不如去加密他的 HASH 来得划算,其实这两种给我们带来的作用是等效的,都能防止证书被篡改。

为什么不可以直接用根证书去给其他所有证书签名,而要设计证书链的概念?

这个问题一开始也困扰我很久,我就不阐述我错误的思路了,只提醒大家一点:两个父子证书间的映射关系是放在子证书,而不是父证书

如果直接使用根证书去给各服务端签署证书,那根证书的密钥就不是足够安全的,毕竟签署的过程不是手动进行,而是放在服务端进行的。一旦有人攻破 CA 的服务器,拿到根证书的密钥,那他就可以伪造根证书,该 CA 下的所有证书都不可信了。

所以,为了保证根证书的绝对安全,根证书的私钥都被保存在离线的金库中。他一般被定期拿出来确保相关密码设备的正常工作,签署证书吊销列表,以及签署新的二级证书。

那么二级证书就可以用来做在线签名,即使二级证书的私钥被盗 ( 可能性很小 ) ,只要根证书是安全的,那么我就可以去更新证书的吊销列表,来让被盗的二级证书失效。

为什么要有多个二级证书?我们可以使用不同的证书去做不同的事情,例如 A 来签署保证邮件安全的证书,B 来签署 SSL 证书。毕竟多线程更高效,各自负责自己的业务场景,一定程度上也能分散风险 ( 我是这么想的,不一定对 ) 。

缺点

HTTPS 相比于 HTTP 更加安全自不必说,那他都有哪些缺点呢?

建立连接

HTTP 使用 TCP 三次握手建立连接,客户端和服务端需要交换 3 个包。 HTTPS 除了 TCP 的三个包,还需要加上 SSL 握手需要的 9 个包,一共是 12 个包。

这样的话,HTTPS 在建立连接阶段比 HTTP 多花费的时间包括了多出的网络延时和 SSL 本身加密/解密的开销。

为了避免重新握手而造成的访问效率低下,这时候引入了Session ID的概念。出于某种原因,如果对话中断且在短时间内重连,只要客户端给出之前的Session ID,且服务器有这个Session ID的记录,双方就可以重新使用已有的对称密钥,而不必重新生成一把。

上述方式可以缓解单个连接的性能问题,但对于并发访问用户数极多的大型网站,如果频繁的重建 SSL 的Session ID,对于服务器性能的影响将会是致命的。这时可以考虑在 Web 服务前配置 SSL Termination Proxy ,来将 SSL 处理转移到另一起机器以减少主服务器的负载。

通信阶段

当 SSL 建立连接后,之后的加密方式会使用客户端传输的对称加密算法。相对前面 SSL 建立连接时的非对称加密方式,对称加密方式对 CPU 的负荷基本可以忽略不记。

总而言之

HTTPS 相比 HTTP 在建立连接阶段确实会有性能的影响,但建立连接之后的通信速度跟 HTTP 差别不大。

好在 HTTPS 提供了Session ID这种优化的方式,再加上服务端如果能够进行恰当的配置和优化,相对于 HTTPS 带来的安全性,给客户端以及服务端造成体验上和性能上微小的损失都是值得的。

参考

扩展

分类

TOP