通俗易懂的HTTPS协议

>>强大,10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程!

        HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer,超文本传输安全协议),是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层。HTTP的端口是80,而HTTPS使用的端口是443。

通俗易懂的HTTPS协议
通俗易懂的HTTPS协议                

加密算法


        在传输敏感的信息的时候,使用HTTP请求可能会导致我们的信息被黑客获取,从而导致信息泄露,造成一定的财产损失。如何解决这个问题呢,一般的思路是加密,加密方式分为两种方式,对称加密和非对称加密

        在对称加密算法中,加密和解密使用的密钥是相同的。如果要保证安全性的话,密钥就要做好保密,不能对外公开,只能使用的人知道。而在非对称加密算法中,加密使用的密钥和解密使用的是不相同的。一把作为公开的公钥,另一把是谁都不能给的私钥。公钥加密的信息,只有私钥才能解密。私钥加密的信息,只有公钥才能解密

因为对称加密算法相比非对称加密算法来说,效率要高的多,性能也好,所以交互场景下多用对称加密。


对称加密和非对称加密


        假设你和团购网站约定了一个密钥,你发送请求的时候用这个密钥进行加密,团购网站使用同样的密钥进行解密。这样就算中间的黑客截获了你的请求,但是它没有密钥,还是破解不了。虽然这一切看起来似乎很完美,

通俗易懂的HTTPS协议
通俗易懂的HTTPS协议                

但是中间还有个问题,你们两个怎么约定这个密钥呢?如果这个密钥在互联网上传输,也是很有可能让黑客截获的。黑客一旦截获这个密钥,它可以佯作不知,静静的获取你们互通的所有消息。在互联网时代的我们不像谍战剧里面通过线下交流把密钥(密码本)给对方,但这种方式太落后了,

通俗易懂的HTTPS协议

在互联网的应用中,客户太多,这样是不行的。

        所以只要是对称加密,就会永远在这个死循环里面出不来,这个时候就需要加入非对称加密。我们可以通过非对称加密传输对称加密的密钥。非对称加密的私钥放在团购网站这里,不随意传输,但是对应私钥的公钥,是可以在互联网上随意传输的,只要团购网站把这个公钥给你,你们就可以愉快的交流了。

        比如你用公钥加密“我要团购十只益妹”,黑客就算在中间截获了这个报文,但是因为他们没有私钥也是解不开的,所以这个报文可以顺利到达团购网站,但是团购网站回复你的时候就出现问题了,回复的这句话是团购网站用私钥加密的,互联网上人人都可以把它打开,包括黑客。那么团购网站可以拿公钥加密吗,当然不能,因为它自己的私钥只有自己知道,谁也解不开。还有一个问题就是黑客可以用获取到的公钥模拟发送“我要团购益妹”这个过程的,毕竟公钥他也有,所以一切似乎陷入了困境。

通俗易懂的HTTPS协议
通俗易懂的HTTPS协议                

        为了解决这个问题,看来光有公钥私钥是不够的,客户端也要有自己的公钥和私钥。并且客户端要把自己的公钥,给团购网站。这样客户端给团购网站发送的时候,用团购网站的公钥加密,而团购网站给客户端发送消息的时候,使用客户端的公钥。这样就算有黑客企图模拟客户端来获取一些信息,或者半路截获恢复信息,但是他没有私钥,这些信息他还是打不开。

数字证书

        不对称加密也会有同样的问题,如何将不对称加密的公钥给对方呢?一种是放在公网的地址上,让对方下载;另一种就是在建立连接的时候,传给对方。这两种方式其实都有一个问题,就是怎么鉴别别人给你的公钥是对的。会不会有人冒充团购网站,给你一个它的公钥。接下来,你和他的所有互通,看起开都是没有任何问题的。毕竟每个人都可以创建自己的公钥和私钥。

        这个时候就需要权威部门的介入了,就像每个人都可以打印自己的简历,但是有公安局盖章的,就只有户口本,才能证明你是你。这个由权威部门颁发的称为证书。

        证书里面有什么呢?当然应该有公钥,这是最重要的;还有证书的所有者,就像户口本上有你的姓名和身份证,说明这个户口本是你的;另外还有证书的发布机构和有效期

        因为也有人冒充权威机构颁发证书,就像有假身份证和假户口本一样的。生成证书需要发起一个证书请求,然后将这个请求发送给一个权威机构去认证,这个权威机构我们称为CA(Certificate Authority)

        将请求发送给权威机构,权威机构会给这个证书卡一个章,我们称为签名算法。问题又来了,那怎么签名才能保证是真的权威机构签名的呢?

通俗易懂的HTTPS协议
通俗易懂的HTTPS协议                

当然只有掌握在权威机构手里的东西签名才行,这就是CA的私钥。

        签名算法大概是这样工作的:一般是对一个信息做一个Hash计算,得到一个Hash值,这个过程是不可逆的,也就是说无法通过Hash值得出原来的信息内容。在把信息发送出去时,把这个Hash值加密后,作为一个签名和信息一起发送出去。

       权威机构给证书签名的命令是这样的:

openssl x509 -req -in cliu8sitecertificate.req -CA cacertificate.pem -CAkey caprivate.key -out cliu8sitecertificate.pem

这个命令会返回Signature ok,而cliu8sitecertificate.pem就是签过名的证书。CA用自己的私钥给团购网站的公钥签名。就相当于给团购网站背书,形成了团购网站的证书。

        证书里面有个Issuer,也即证书是谁颁发的;Subject,就是证书颁发给谁;Validity是证书期限;Public-key是公钥内容;Signature Algorithm是签名算法。

        这下好了,你不会从团购网站上得到一个公钥,而是会得到一个证书,如果这个证书有个发布机构CA,你只要得到发布机构CA的公钥,去解密团购网站证书的签名,如果解密成功了,Hash也对的上,就说明这个外卖网站的公钥没有啥问题。

        你有没有发现,又有新问题了。要想验证证书,需要CA的公钥,问题是,你怎么确定CA的公钥就是对的?

通俗易懂的HTTPS协议
通俗易懂的HTTPS协议                

        所以,CA的公钥也需要更牛的CA给它签名,然后形成CA的证书。要想知道某个CA的证书是否可靠,要看CA的上级证书的公钥,能不能解开这个CA的签名。这样层层上去,直到全球皆知的几大著名CA,称为root CA,做最后的背书。这样通过层层授信背书的方式,从而保证了非对称加密模式的正常运转。

最最重要的是CA的公钥必须安全的转移给客户端,使用通信方式时,如何安全转交是一件很困难的事,因此,多数浏览器开发商发布版本时,会事先在内部植入常用认证机关的公开密钥。或者在操作系统中已经内置了世界上公认可信的CA证书,该证书中包含了公钥。这样的机构不会很多,所以完全可做到内置。同时我们也应该注意不要随便安装来源不明的操作系统或者随意添加证书,这会让你在互联网世界“裸奔”。

通俗易懂的HTTPS协议
通俗易懂的HTTPS协议                

        除此之外,还有一种自签名证书,就是自己给自己签名。给人一种不管你信不信,反正我信了的感觉。这里就不再赘述。

HTTPS的工作模式

        因为非对称加密在性能上不如对称加密,HTTPS工作思路是将两者结合起来,例如,公钥私钥主要用于传输对称加密的私钥,而真正的双方的大数据量的通信都是通过对称加密进行的。工作过程如下:

通俗易懂的HTTPS协议
通俗易懂的HTTPS协议                

        一开始登录团购网站的时候,客户端会以明文传输TLS版本信息,加密套件候选列表,压缩算法候选列表等信息,再给个随机数用于协商对称密钥的时候使用。然后团购网站告诉客户端自己选择的协议版本,加密套件,压缩算法等等,还有一个随机数用于后续的密钥协商。

        之后团购网站给你给一个服务器端的证书,然后你从自己信任的CA仓库中拿出CA证书去解密团购网站的证书。如果成功说明团购网站是可信的。这个过程你可能会不断追溯CA,CA的CA等,直到一个可以授信的CA就可以了。

        证书验证完毕之后,这个团购网站是可信的,于是客户端计算产生随机数字Pre-master,发送Client Key Exchange,用证书中的公钥加密,再发送给服务器,服务器可以通过私钥解密出来。

        到目前为止无论是客户端还是服务端都有了三个随机数,分别是自己的,对端的,以及刚刚生成的Pre-Master随机数。通过这三个随机数,可以在客户端和服务端产生相同的对称密钥。

        有了对称密钥,客户端就可以说:“Change Cipher Spec,咱们以后都采用商量好的通行密钥和加密算法进行通信了。

        然后发送一个Encrypted Handshake Message,将商定好的参数等,采用协商密钥进行加密,发送给服务器用于数据与握手验证。

       同样服务器也发送Change Cipher Spec,并且也发送Encrypted Handshake Message消息试试,当双方的握手结束之后,就可以通过对称加密进行传输了。之后的其他过程和HTTP一样。

        上面过程只包含了HTTPS的单向认证,也即客户端验证服务端证书,大部分场景就够用了,在安全要求更加严格的情况下,需要启用双向认证,双方互相验证证书。

重放与篡改

        其实还有一些问题依旧没决,WTF,比如重放和篡改的问题。

通俗易懂的HTTPS协议
通俗易懂的HTTPS协议                

虽然有了加密和解密,黑客截获了包也打不开了,但是他可以发送N次。这个通过Timestamp和Nonce随机数联合起来,然后做一个不可逆的签名来保证。Nonce随机数保证唯一,或者Timestamp和Nonce联合起来保证唯一,同样的,请求只接受一次,于是服务器多次收到相同的Timestamp和Nonce,则视为无效即可。如果有人想篡改Timestamp和Nonce,还有签名保证不可篡改性,如果改了用签名算法解出来,就对不上了,可以丢弃了。

通俗易懂的HTTPS协议
通俗易懂的HTTPS协议

原文始发于微信公众号(九局下半大逆转):通俗易懂的HTTPS协议