目录
引言
HTTPS是什么?是一个应用层协议,在HTTP协议的基础上引入了一层加密层。为什么需要HTTPS?答案是显而易见的,要加密,当然就是为了安全。因为HTTP协议是明文传输的,明文数据会经过路由器、WiFi热点、通信服务运营商、代理服务器等多个物理节点,如果信息在传输过程中被劫持,传输的内容就完全暴露了,进而导致隐私泄漏,而且劫持者还可以篡改传输的信息而不被双方察觉,这就是中间人攻击,所以为了避免上述情况发生,HTTPS也就应运而生了。
简单介绍一下TLS。
TLS(传输层安全协议)是现代网络通信中应用最广泛的安全协议,主要用于实现以下目标:
- 数据加密:建立安全通道保护传输数据
- 身份验证:通过数字证书验证通信方身份
- 数据完整性:防止传输过程被篡改
HTTPS和HTTP的区别
HTTPS和HTTP的区别就在于——HTTPS有加密层,而HTTP没有。如果还要说一点区别的话,HTTP的默认端口号是80,HTTPS的默认端口号是443。至于其他的,比如报文结构等就是完全继承HTTP那套了。
常见加密方式
在继续深入HTTPS的加密机制前,我们首先需要了解一些必备的知识,以便于更好的理解加密的机制。
常见的加密方式有两种,一种是对称加密,另一种是非对称加密。
1)对称加密:一个密钥,加密和解密的密钥是相同的。特点是,计算量小,加密解密速度快,效率高。
2)非对称加密:一对密钥,公钥(public key)和私钥(private key)。
● 公钥加密,私钥解密,也可以反过来,私钥加密,公钥解密。
● 公钥任何人都可以持有,但是私钥坚决不能泄漏。
● 特点是,算法强度复杂,加密解密速度很慢。
似乎对称加密就足以满足我们所需的安全性了,而且效率高,为什么还要有非对称加密?对称加密,通信双方持有相同的密钥,不仅可以通过密钥加密数据后发送给对方, 还可以用同一个密钥来对方发来的数据进行解密,似乎已经很完美了,其实不然!要使用对称加密,首先要解决的问题是如何将密钥安全的传递给对方。在不加密的情况下,直接以明文的方式将密钥传给对方,这是很危险的,因为如果被中间人劫持,中间人也有同一份密钥后,接下来双方的通信对他来说将是透明的,因为中间人劫持数据后,通过手中持有的密钥可以对数据进行解密,就知道双方都在聊些什么了,敏感信息的泄露几乎是必然的。
好巧不巧,非对称加密可以做到安全的交换密钥。
服务器有公钥S与对应的私钥S',客户端有对称密钥C。
客户端向服务器发送请求获取公钥S ---> 对称密钥C通过S加密发送给服务器,因为只有服务器持有对应的密钥S',所以只有服务器能解密 ---> 服务器通过密钥S'解密,获取对称密钥C ---> 由于对称密钥C只有客户端和服务器持有,所以后续通信只用对称密钥加密即可安全通信。 这个方案就真的无懈可击了吗?并不是的,仍有欠缺。
中间人持有非对称加密的公钥M,私钥M' ---> 客户端向服务器发送请求获取公钥S ---> 服务器明文传送公钥S给客户端 ---> 中间人劫持数据报,获取公钥S,然后将自己的公钥M发送给客户端(客户端目前是没办法察觉到公钥被替换的)---> 客户端通过M加密对称密钥C发给服务器 ---> 中间人劫持,通过M'解密得到对称密钥C,然后通过前面拿到的S对对称密钥C加密后传给服务器 ---> 服务器通过S'解密拿到对称密钥C(双方都没有察觉到任何问题)---> 通过对称密钥C加密进行正常通信,由于中间人也有对称密钥C,所以他在劫持报文后可以解密查看里面的内容。
所以,如果能保证服务器的公钥S能安全的传给客户端,那么就可以保证后续通信的安全。 如何保证公钥S安全的送到客户端?用私钥S'对其进行加密吗?如果是这样的话,客户端拿到数据也无法解密呀!我们梳理一下这个逻辑:服务器通过私钥S'加密,将公钥S传给客户端 ---> 客户端收到数据后,需要通过公钥S解密才能获取被密钥S'加密后的公钥S。这很显然是有问题的,如果客户端一开始就有服务器的公钥S的话,还需要多此一举让服务器传过去吗?
事已至此,不得不引入第三方——CA机构。
数据摘要
在引入第三方机构CA之前,先谈谈数据摘要。
数据摘要就是通过散列函数对数据进行运算,然后得到一段长度固定的字符串,也就是数据摘要,它具有唯一性。不同的文本,哪怕只有一个标点符号不同,得到的数据摘要都会大相径庭,不会一样。因此,数据摘要被形象的称为数据指纹,它就像人的指纹一样,每个人的都不一样。
数据摘要通常用来进行数据比对,同一个文本,经过同一个散列函数运算,得到的摘要是一样的。
数字证书与数据签名
服务器在使用HTTPS之前,需要向CA(Certificate Authority,证书认证机构)申请一份数字证书,包含申请者的信息、公钥、域名等。所谓的CA,就是比较权威的、可信任的第三方机构。其作用就好比某宝,消费者在某宝上购物时,钱首先是到某宝的账户上,由它暂时保管,消费者确定收货以后,某宝便会把钱给到商家。为了完成这个交易,很重要的一点就是——信任第三方机构某宝。CA机构签发的证书就好比身份证,证明服务端公钥的权威性。
通过CA机构的密钥对明文信息的摘要进行加密,提取指纹,这一动作就叫做数据签名。
CA公钥内置于浏览器中,客户端收到证书后,通过CA内置的公钥对签名要进行解密,得到数据摘要 ---> 客户端对明文数据通过相同的散列函数形成摘要 ---> 比对两份指纹是否一致 ---> 如果一致,数据没有被篡改,即服务器的公钥S没有被替换过,是可信的,这样就可以保证服务器的公钥S安全的送到客户端。
可能会有这样的疑问——CA的公钥任何人都可以拿到,这样,中间人就可以对签名进行解密,拿到数据摘要,修改摘要和明文,怎么保证服务器公钥S的安全?
1)修改明文,不修改摘要 ---> 明文形成的摘要和签名中的摘要不一致,客户端在验证证书的时候可以察觉到,进而提醒用户。
2)修改摘要,不修改明文 ---> 同第一种情况。
3)既修改明文,又修改摘要
更具体的说,就是中间人在修改明文后,形成摘要,替换掉签名中的摘要。然后在对摘要加密。但是,中间人并没有CA机构的私钥,所以他只能用自己的密钥来加密,然后客户端无论如何都是用CA机构的公钥来对签名解密,这就导致解密失败,客户端就可以察觉到数据被篡改了,进而提醒用户。
4)中间人替换掉整个证书
因为中间人没有CA机构的密钥,所以无法制作假的证书。但是,他可以向CA机构申请真的证书。客户端就可以通过内置的CA机构公钥来对签名进行解密,结果发现两份摘要确实是一致的。但是别忘了,证书中是有域名的,而且域名具有唯一性,客户端可以发现域名不对而察觉。
综上,中间人只要敢修改,客户端就能够察觉到,进而提醒用户,避免中间人盗取用户信息。
HTTPS请求过程
下面通过完整的https请求来说明一下TLS握手的过程。
浏览器从URL中提取协议名和域名,通过域名解析系统DNS将域名转换为IP地址,因为是https请求,所以浏览器知道默认的端口号443。然后经过三次握手于服务器建立TCP连接,如果是http请求,后续就可以发送http报文了,https还需要在TCP连接上确保安全。
结语
为了确保安全,HTTPS使用了对称加密+非对称加密+证书认证的组合方案。
HTTPS工作过程中涉及到三组密钥:
1)CA的非对称密钥,私钥用于形成签名,公钥内置在浏览器中。
2)服务器的非对称密钥,公钥包含于证书中,私钥自己持有,以便解密经过服务器公钥加密后的客户端数据,得到对称密钥。
3)用于加密http报文的对称密钥,由服务器的公钥加密后,发送给服务器,进而让服务器解密拿到对称密钥。
感谢支持!