数字加密和HTTPS详解笔记
in 代码操作系统 with 0 commentand 203 read

数字加密和HTTPS详解笔记

in 代码操作系统 with 0 commentand 204 read

最近在做Blog迁移的时候,梳理了一些Web有关的技术细节,整理下来,以作备忘。

数字加密

术语

对称加密和非对称加密

对称加密比较简单,就是客户端和服务器共用同一个密钥,该密钥可以用于加密一段内容,同时也可以用于解密这段内容。对称加密的优点是加解密效率高。但是在安全性方面可能存在一些问题,因为保持密钥的机密状态是很重要的。在很多情况下,编 / 解码算法都是众所周知的,因此密钥就是唯一保密的东西了。好的加密算法会迫使攻击者试遍每一个可能的密钥,才能破解代码。用暴力去尝试 所有的密钥值称为 枚举攻击(enumeration attack)。
流行的对称密钥加密算法包括:DES、Triple-DES、RC2 和 RC4。

而非对称加密则要复杂一点,它将密钥分成了两种:公钥和私钥。公钥通常存放在客户端,私钥通常存放在服务器。使用公钥加密的数据只有用私钥才能解密,反过来使用私钥加密的数据也只有用公钥才能解密。非对称加密的优点是安全性更高,因为客户端发送给服务器的加密信息只有用服务器的私钥才能解密,因此不用担心被别人破解,但缺点是加解密的效率相比于对称加密要差很多。非对称加密的代表算法有:RSA、ElGamal等。

数字签名

除了加 / 解密报文之外,还可以用加密系统对报文进行签名(sign),以说明是谁编写的报文,同时证明报文未被篡改过。这种技术被称为数字签名(digital signing)。

数字签名是附加在报文上的特殊加密校验码。数字签名通常是用 非对称公开密钥技术产生的。因为只有所有者才知道其私有密钥, 所以可以将作者的私有密钥当作一种“指纹”使用。
数字签名.png

RSA 加密系统将解码函数 D 作为签名函数使用,是因为 D 已经将私有密钥作为输入使用了。注意, 解码函数只是一个函数,因此,可以将其用于任意的输入。同样,在 RSA 加密系统中,以任意顺序 应用 D 和 E 函数时,两者都会相互抵消。因此 E(D(stuff)) = stuff,就像 D(E(stuff)) = stuff 一样。

数字证书

因特网上的“ID 卡”——数字证书。数字证书(通常被称作“certs”)中包含了由某个受信任组织担保的用户或公司的相关信息。

数字证书中还包含一组信息,所有这些信息都是由一个官方的 证书颁发机构(CA) 以数字方式签发的。

而且,数字证书通常还包括对象的公开密钥,以及对象和所用签名算法的描述性信息。任何人都可以创建一个数字证书,但并不是所有人都能够获得受人尊敬的签发 权,从而为证书信息担保,并用其私有密钥签发证书。典型的证书结构如图所示。
数字证书.png

HTTPS

HTTPS 是最流行的 HTTP 安全形式。它是由网景公司首创的,所有主要的浏览器和 服务器都支持此协议。

使用 HTTPS 时,所有的 HTTP 请求和响应数据在发送到网络之前,都要进行加密。 HTTPS 在 HTTP 下面提供了一个传输级的密码安全层——可以使用 SSL,也可以使用其后继者—— 传输层安全(Transport Layer Security,TLS)
HTTPS.png
传统的HTTP传输方式由于我们在传输数据时信息都是明文的,因此很容易出现数据被监听和窃取的情况,传输的数据还有可能被一些别有用心的人篡改,导致浏览器与网站收发的内容不一致。
HTTP.png
也就是说,使用http传输数据至少存在着数据被监听以及数据被篡改这两大风险,因此http是一种不安全的传输协议。

那么解决方案大家肯定都知道是使用https,但是我们先尝试着自己思考一下该如何保证http传输的安全性,进而也就能一步步地理解https的工作原理了。

既然数据以明文的形式在网络上传输是不安全的,那么我们显然要对数据进行加密才行。刚才提到了,加密方式主要有两种,对称加密和非对称加密。对称加密的优点是加解密效率高,而我们在网络上传输数据是非常讲究效率的,因此这里很明显应该使用对称加密。
HTTP对称加密后.png
可以看到,由于我们在网络上传输的数据都是密文,所以不怕被监听者获取到,因为他们无法得知原文是什么。而浏览器收到密文之后,只需要使用和网站相同的密钥来对数据进行解密就可以了。

这种工作机制看上去好像确实保证了数据传输的安全性,但是却存在一个巨大的漏洞:浏览器和网站怎样商定使用什么密钥呢?

这绝对是一个计算机界的难题,浏览器和网站要使用相同的密钥才能正常对数据进行加解密,但是如何让这个密钥只让它们俩知晓,而不被任何监听者知晓呢?你会发现不管怎么商定,浏览器和网站的首次通信过程必定是明文的。这就意味着,按照上述的工作流程,我们始终无法创建一个安全的对称加密密钥。

所以,只使用对称加密看来是永远无法解决这个问题了,这个时候我们需要将非对称加密引入进来,协助解决无法安全创建对称加密密钥的问题。
HTTP非对称加密后.png
可以看到,如果我们想要安全地创建一个对称加密的密钥,可以让浏览器这边来随机生成,但是生成出来的密钥不能直接在网络上传输,而是要用网站提供的公钥对其进行非对称加密。由于公钥加密后的数据只能使用私钥来解密,因此这段数据在网络上传输是绝对安全的。而网站在收到消息之后,只需要使用私钥对其解密,就获取到浏览器生成的密钥了。

另外,使用这种方式,只有在浏览器和网站首次商定密钥的时候需要使用非对称加密,一旦网站收到了浏览器随机生成的密钥之后,双方就可以都使用对称加密来进行通信了,因此工作效率是非常高的。

那么,上述的工作机制你认为已经非常完善了吗?其实并没有,因为我们还是差了非常关键的一步,浏览器该怎样才能获取到网站的公钥呢?虽然公钥是属于公开的数据,在网络上传输不怕被别人监听,但是如果公钥被别人篡改了怎么办?
HTTP进一步缺陷.png
也就是说,只要我们从网络上去获取任何网站的公钥,就必然存在着公钥被篡改的风险。而一旦你使用了假的公钥来对数据进行加密,那么就可以被别人以假的私钥进行解密,后果不堪设想。

方案设计到这里好像已经进入了死胡同,因为无论如何我们都无法安全地获取到一个网站的公钥,而我们显然也不可能将世界上所有网站的公钥都预置在操作系统当中。

这个时候,就必须引入一个新的概念来打破僵局了:CA机构

CA机构专门用于给各个网站签发数字证书,从而保证浏览器可以安全地获得各个网站的公钥。那么CA机构是如何完成这个艰巨的任务的呢?下面开始一步步解析。

首先,我们作为一个网站的管理员需要向CA机构进行申请,将自己的公钥提交给CA机构。CA机构则会使用我们提交的公钥,再加上一系列其他的信息,如网站域名、有效时长等,来制作证书。

证书制作完成后,CA机构会使用自己的私钥对其加密,并将加密后的数据返回给我们,我们只需要将获得的加密数据配置到网站服务器上即可。

然后,每当有浏览器请求我们的网站时,首先会将这段加密数据返回给浏览器,此时浏览器会用CA机构的公钥来对这段数据解密。

如果能解密成功,就可以得到CA机构给我们网站颁发的证书了,其中当然也包括了我们网站的公钥。你可以在浏览器的地址栏上,点击网址左侧的小锁图标来查看证书的详细信息,如下图所示。
Google.png
得到了公钥之后,接下来的流程就和刚才示意图中所描述的一样了。

而如果无法解密成功,则说明此段加密数据并不是由一个合法的CA机构使用私钥加密而来的,有可能是被篡改了,于是会在浏览器上显示一个著名的异常界面.
那么你可能会问了,有了CA机构之后就真的安全了吗?我们在浏览器端要使用CA机构的公钥来解密数据,那么又该如何安全地获取到CA机构的公钥呢?
这个问题就很好解决了,因为世界上的网站是无限多的,而CA机构总共就那么几家。任何正版操作系统都会将所有主流CA机构的公钥内置到操作系统当中,所以我们不用额外获取,解密时只需遍历系统中所有内置的CA机构的公钥,只要有任何一个公钥能够正常解密出数据,就说明它是合法的。
Windows内置证书.png

查看方式:win+R -> "certmgr.msc"

但是即使使用CA机构的公钥能够正常解密出数据,目前的流程也还是存在问题的。因为每一家CA机构都会给成千上万的网站制作证书,假如攻击者知道abc.com使用的是某家CA机构的证书,那么他也可以同样去这家CA机构申请一个合法的证书,然后在浏览器请求abc.com时对返回的加密证书数据进行替换。
HTTPS证书篡改.png
可以看到,由于攻击者申请的证书也是由正规CA机构制作的,因此这段加密数据当然可以成功被解密。

也正是因为这个原因,所有CA机构在制作的证书时除了网站的公钥外,还要包含许多其他数据,用来辅助进行校验,比如说网站的域名就是其中一项重要的数据。

同样是刚才的例子,如果证书中加入了网站的域名,那么攻击者就只能无功而返了。因为,即使加密数据可以被成功解密,但是最终解密出来的证书中包含的域名和浏览器正在请求的域名对不上,那么此时浏览器仍然会显示异常界面。
HTTPS证书篡改中止请求.png
好了,方案设计到这里,其实我们的网络传输就已经做到足够的安全了。当然,这其实也就是https的工作原理。

笔记纪要

站点证书的有效性验证

SSL 自身不要求用户检查 Web 服务器证书,但大部分现代浏览器都会对证书进行简 单的完整性检查,并为用户提供进行进一步彻查的手段。网景公司提出的一种 Web 服务器证书有效性算法是大部分浏览器有效性验证技术的基础。验证步骤如下所述:

评论