转自:GitHub,ImportNew 作者:Stephanie Tang stephanietang.github.io/2020/04/19/how-https-works/
当你打开浏览器,访问某个网站,如果网址旁有个小锁,代表访问的网址是安全的,反之不安全。当我们没有看到那个小锁的小图标的时候,需要提高警惕,不要随意输入个人重要的资料。所有的银行和支付相关的网站都是100%使用HTTPS的。
主要有三个原因:
需要理解SSL/TLS的工作原理,我们需要掌握加密算法。加密算法有两种:对称加密和非对称加密:
SSL/TLS是利用了对称加密和非对称加密的特点。先来看下整个SSL/TLS的握手过程,之后我们再分步骤详细解读,每一步都干了些什么。
1.当TCP建立连接之后,TLS握手的第一步由客户端发起,发送ClientHello的消息到服务器。
ClientHello消息包含:
延伸阅读:
加密套件名如:“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256”,这么长的名字看着有点晕吧,不用怕,其实它的命名非常规范,格式很固定。基本的形式是“密钥交换算法-服务身份验证算法-对称加密算法-握手校验算法”。
握手过程中,证书签名使用的RSA算法,如果证书验证正确,再使用ECDHE算法进行密钥交换,握手后的通信使用的是AES256的对称算法分组模式是GCM。验证证书签名合法性使用SHA256作哈希算法检验。相关的算法的用处将在后文中详解。
2.然后服务器端在收到这个ClientHello,从中选择服务器支持的版本和套件,发送ServerHello消息:
随后服务器发送服务器的安全证书(含公钥)。
如果需要客户端也提供证书的话,还会发出客户端证书请求(Client Certificate Request),只有少数金融机构才需要客户端也提供客户端证书。
此后客户端发送Server Hello Done消息表示Hello阶段完成。
3.客户端收到ServerHello后,会对收到的证书进行验证。
我们来看一下为什么可以通过CA(Certificate Authority,证书颁发机构)签发的证书来确认网站的身份?
当我们安装操作系统或者浏览器的时候,会安装一组可信任的CA(根证书CA包括GlobalSign、GeoTrust、Verisign等)列表。根CA如GlobalSign就在我们的可信任的CA列表里,你的浏览器或者操作系统含有GlobalSign的公钥。
先来看一下Google的证书,当你访问Google的时候,Google会发给你它的证书。证书中包含颁发机构的签名以及服务器的公钥。
浏览器首先用哈希函数对明文信息的摘要做哈希得到一个哈希值(用到的就是证书中的签名哈希算法SHA256),然后用根CA的公钥对根证书的签名作解密得到另一个哈希值(用到的算法就是RSA非对称算法),如果两个哈希值相等则说明证书没有被篡改过。当然还需校验证书中服务器名称是否合法以及验证证书是否过期。
这样就免受中间人攻击了,因为假如有中间人修改了证书的内容(如将证书中的公钥替换成自己的公钥),那么将获得不同的哈希值,从而两个哈希值不匹配导致验证失败。如果要绕过这个机制,中间人必须要也替换签名,使签名也相匹配。而做到这一点就需要破解到了根证书的密钥(而这是不可能的,中间人必然会失败)。浏览器会出现以下画面,告诉你正在遭受中间人攻击,因为证书被篡改了:
那聪明的你肯定也想到了,如果你开发了一个系统还在测试阶段,还没有正式申请一张证书,那么你可以为服务器自签名一张证书,然后将证书导入客户端的CA信任列表中。
信任链机制
可以看到证书路径是GlobalSign Root CA-R2 -> GTS CA 1O1->*.google.com。因为我们的浏览器信任GlobalSign Root CA,根据信任链机制,你相信了根CA颁发的证书,也要相信它签名的子CA颁发的证书,也要相信子CA签名的子子CA的证书…而我们通过一级级的校验,如果从根证书到最下层的证书都没有被篡改过,我们就相信最下层的这个服务器证书是合法的。所以在这个机制中,你就需要无条件的相信根证书的颁发机构。
如果通过验证,客户端生成一个随机数pre-master,用于密钥交换过程。
4.密钥交换过程:客户端用第三步中服务器的证书中拿到服务器的公钥,用这个公钥加密(算法是加密套件中的密钥交换算法,譬如ECDHE算法)生成密文发送给服务器。
5.客户端用server-random + client-random + pre-master一起计算出对称密钥master secret。
6.服务器收到第四步的信息之后,用服务器的私钥对密文进行解密得到密钥pre-master。
因为只有服务器有私钥,可以针对客户端发出的加密过的信息进行解密得到pre-master,这样就保证了只有服务器和客户端知道pre-master。服务器端也可以用server-random + client-random + pre-master一起计算出对称密钥master secret。
现在客户端和服务器均有密钥master secret了,后面就可以用它来进行加密和解密了。
为什么不能只用一个pre-master作为之后加密的对称密钥?
虽然只有服务器有私钥,能够解密pre-master呀,但仅用它作为master secret是不够安全的,这是因为要以防客户端的pre-master并不是随机数的情况。加上另外两个随机数client-random以及server-random(而这两个随机数和时间有相关性),这样就能保证最后生成的master secret一定是随机数。
7.客户端用master secret加密了一条握手完成的消息发送给服务器。
8.服务器端也回发了一条用master secret加密的握手完成的消息。
9.当两方都收到对方发送的握手消息之后,也成功解密后,就可以用master secret愉快的开始数据加密和解密了。
综上,整个握手过程主要是通过一系列步骤通过非对称加密的算法交换得到了master secret,这个步骤通常需要几百毫秒,但是就是这一顿猛操作之后使得只有服务器和客户端知道master secret。之后的通信又利用了高效的对称算法对所有信息进行加密和解密,虽然加密和解密也需要耗时耗流量,不过信息是完全不可能被别人篡改和破解的,这一点损耗还是值得的。
end