HTTP: http://xx.yy.com
HTTPS: https://xx.yy.com
这两个网址 https 比 http 多了一个s , 差别在哪里?
HTTP协议
HTTP协议全称Hyper Text Transfer Protocol,即超文本传输协议,位于 TCP/IP 四层模型当中的应用层。
HTTP协议通过请求/响应的方式,在客户端和服务端之间进行通信。
但是,HTTP协议有一个致命的缺点:不够安全
HTTP协议的信息传输完全以明文方式,不做任何加密,相当于是在网络上“裸奔”。
会存在这样的问题:
假如A要给B发送消息
但是,由于传输信息是明文,信息可能被某个中间人恶意截获甚至篡改。这种行为叫做中间人攻击。
如果对明文信息进行加密,就会相对减少这样的错误 。
A和B可以事先约定一种对称加密方式,并且约定一个随机生成的密钥。后续的通信中,信息发送方都使用密钥对信息加密,而信息接收方通过同样的密钥对信息解密。但是第一次约定加密方式和密钥的通信仍然是明文,如果第一次通信就已经被拦截了,那么密钥就会泄露给中间人,中间人仍然可以解密后续所有的通信内容。
所以,可以使用非对称加密,为密钥的传输做一层额外的保护。
非对称加密的一组秘钥对中,包含一个公钥和一个私钥。明文既可用公钥加密,用私钥解密;也可用私钥加密,用公钥解密。
过程如下:
在A和B建立通信的时候,B首先把自己的公钥Key1发给A:
A收到B的公钥以后,A自己生成一个用于对称加密的密钥Key2,并且用刚才接收的公钥Key1对Key2进行加密,发送给B:
B利用自己非对称加密的私钥,解开了公钥Key1的加密,获得了Key2的内容。A、B 就可以利用Key2进行对称加密的通信了。
在通信过程中,即使中间人在一开始就截获了公钥Key1,由于不知道私钥是什么,也无从解密。
但这样,也不能保证绝对安全。
虽然中间人不知道B的私钥是什么,但在截获了B的公钥Key1之后,却可以偷天换日,自己另外生成一对公钥私钥,把自己的公钥Key3发送给A。
A不知公钥被偷偷换过,以为Key3就是B的公钥。按照先前的流程,用Key3加密了自己生成的对称加密密钥Key2,发送给A。
这次通信再次被中间人截获,中间人先用自己的私钥解开了Key3的加密,获得Key2,再用当初B发来的Key1重新加密,发给B。
这样一来,两个人后续的通信尽管用Key2做了对称加密,但是中间人已经掌握了Key2,所以可以轻松进行解密。
那怎样保证更为安全呢?
引入第三方,一个权威的证书颁发机构(CA)来解决。
流程:
1.作为服务端的B,首先把自己的公钥发给证书颁发机构,向证书颁发机构申请证书。
2.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1,并且通过服务端网址等信息生成一个证书签名,证书签名同样经过机构的私钥加密。证书制作完成后,机构把证书发送给了服务端B。
3.当A向B请求通信的时候,B不再直接返回自己的公钥,而是把自己申请的证书返回给A。
4.A收到证书以后,要做的第一件事情是验证证书的真伪。(各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥)
所以A只需要知道是哪个机构颁布的证书,就可以从本地找到对应的机构公钥,解密出证书签名。接下来,A按照同样的签名规则,自己也生成一个证书签名,如果两个签名一致,说明证书是有效的。验证成功后,A就可以放心地再次利用机构公钥,解密出服务端B的公钥Key1。
5.像之前一样,A生成自己的对称加密密钥Key2,并且用服务端公钥Key1加密Key2,发送给B。
6.最后,B用自己的私钥解开加密,得到对称加密密钥Key2。于是两人开始用Key2进行对称加密的通信。
想一想,中间人是否还具有使坏的空间呢?
不会,因为证书的签名是由服务端网址等信息生成的,并且经过机构私钥加密,中间人也无法篡改。所以,假证书是无法通过验证的。这个就是相对于http更安全的地方,这也是HTTPS的主体思想。
HTTPS在HTTP协议的基础上增加了SSL安全层,上述流程就是在SSL层中完成的。
PS: TLS协议,是SSL 3.0协议的升级版,和SSL协议的大体原理是相同的。