https加密
为什么需要https
当我们往服务器发送比较隐私的数据(比如说你的银行卡,身份证)时,如果使用http进行通信。
首先数据在传输的过程中,数据可能被中间人抓包拿到,那么数据就会被中间人窃取;
其次数据被中间人拿到后,中间人可能对数据进行修改或者替换,然后发往服务器;
最后服务器收到数据后,也无法确定数据有没有被修改或替换,当然,如果服务器也无法判断数据就真的是来源于客户端;
总结下来,http存在三个弊端:
1)无法保证消息的保密性;
2)无法保证消息的完整性和准确性;
3)无法保证消息来源的可靠性。
对称加密
这种方式加密和解密同用一个密钥。加密和解密都会用到密钥。没有密钥就无法对密码解密,反过来说,任何人只要持有密钥就能解密了。
服务器每次发送真实数据前,会先生成一把密钥传输(密钥容易被劫持)给客户端,服务器给客户端发送的真实数据会先用这把密钥进行加密,客户端收到加密数据后再用密钥进行解密(客户端给服务器发送数据同理)。
非对称加密
公开密钥加密使用一对非对称的密钥。一把叫做私有密钥,另一把叫做公开密钥。顾名思义,私有密钥不能让其他任何人知道,而公开密钥则可以随意发布,任何人都可以获得。使用公开密钥加密方式,发送密文的一方使用对方的公开密钥进行加密处理,对方收到被加密的信息后,再使用自己的私有密钥进行解密。利用这种方式,不需要发送用来解密的私有密钥,也不必担心密钥被攻击者窃听而盗走。
服务器在给客户端发送真实数据前,先用客户端明文传输给服务器的公钥进行加密,客户端收到后用自己的私钥进行解密,反之同理
对称加密+非对称加密
https使用对称加密+非对称加密(以非对称加密的方式传输对称加密密钥),接着就可使用对称加密的密钥传输数据。
鉴于非对称加密在加密时速度特别慢,对称加密又不够安全。可以将对称加密与非对称加密结合起来,充分利用两者各自的优势,将多种方法组合起来用于通信。在交换密钥环节使用非对称加密方式,之后的建立通信交换报文阶段则使用对称加密方式。具体做法是:发送密文的一方使用对方的公钥进行加密处理“对称的密钥”,然后对方用自己的私钥解密拿到“对称的密钥”,这样可以确保交换的密钥是安全的前提下,使用对称加密方式进行通信。所以,HTTPS 采用对称加密和非对称加密两者并用的混合加密机制。
数字证书
数字证书申请的过程大致是:
1)自己本地先生成一对密匙,然后拿着自己的公匙以及其他信息(比如说企业名称啊什么的)去CA申请数字证书。
2)CA在拿到这些信息后,会选择一种单向Hash算法(比如说常见的MD5)对这些信息进行加密,加密之后的东西我们称之为摘要:
单向Hash算法有一种特点就是单向不可逆的,只要原始内容有一点变化,加密后的数据都将会是千差万别(当然也有很小的可能性会重复,有兴趣的小伙伴鸽巢原理了解一下),这样就防止了信息被篡改。
3)生成摘要后还不算完,CA还会用自己的私匙对摘要进行加密,摘要加密后的数据我们称之为数字签名。
4)最后,CA将会把我们的申请信息(包含服务器的公匙)和数字签名整合在一起,由此而生成数字证书。
5)然后CA将数字证书传递给我们。
可以使用使用数字证书(即找到一个大家都认可的认证中心CA)证明客户端接收的公钥是属于服务器的。
服务器在给客户端传输公钥的过程中,会将公钥+服务器个人信息通过hash算法生成信息摘要,为防止信息摘要被掉包服务器会用CA提供的私钥对信息摘要加密形成数字签名。最后还会将设有进行hash算法计算的服务器个人信息+公钥和数字签名合并在一起形成数字证书
客户端拿到数字证书后,用CA提供的公钥对数字签名进行解密得到信息摘要,然后对数字证书中服务器个人信息+公钥进行hash得到另一份信息摘要,两份信息摘要进行比对,若一样则是目标服务器,否则不是
https加密原理
我们了解对称加密与非对称加密的特点和优缺点,以及数字证书的作用。https没有采用单一的技术去实现,而是根据他们的特点,充分的将这些技术整合进去,以达到性能与安全最大化。这套整合的技术我们称之为SSL(Secure Scoket Layer 安全套接层)。![](https://img2020.cnblogs.com/blog/1234412/202004/1234412-20200402121006782-1473000416.png)
https先是利用数字证书保证服务器端的公匙可以安全无误的到达客户端。然后再用非对称加密安全的传递共享密匙,最后用共享密匙安全的交换数据(采用对称加密)。
流程:
证书验证阶段:
- 浏览器发起 HTTPS 请求。
- 服务端返回 HTTPS 证书。
- 客户端验证证书是否合法,如果不合法则提示告警。
数据传输阶段:
- 当证书验证合法后,在本地生成随机数。
- 通过公钥加密随机数,并把加密后的随机数传输到服务端。
- 服务端通过私钥对随机数进行解密,解密成功开始正常传输数据。
- 服务端通过客户端传入的随机数构造对称加密算法,对返回结果内容进行加密后传输。
详细流程:
1)客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密匙长度等);
2)服务器可进行SSL通信时,会以Server Hello报文作为应答。和客户端一样,在报文中包含SSL版本以及加密组件。服务器的加密组件内容时从接收到的客户端加密组件内筛选出来的;
3)服务器发送证书报文。报文中包含公开密匙证书;
4)最后服务器发送Server Hello Done报文通知客户端,最初阶段的SSL握手协商部分结束;
5)SSL第一次握手结束之后,客户端以Client Key Exchange报文作为回应。报文包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密匙进行加密;
6)接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器,在此报文之后的通信会采用Pre-master secret密匙加密;
7)客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功,要以服务器是否能够正确解密该报文作为判定标准;
8)服务器同样发送Change Cipher Spec报文;
9)服务器同样发送Finished报文;
10)服务器和客户端的Finished报文交换完毕之后,SSL连接就算建立完成。当然,通信会收到SSL的保护。从此处开始进行应用层协议的通信,即发送HTTP请求;
11)应用层协议通信,即发送HTTP相应;
12)最后由客户端断开连接。断开连接时,发送close_notify报文。上图做了一些省略,这步之后再发送TCP FIN报文来关闭与TCP的通信。
一定要用https吗?
https那么的安全,是不是我们在什么场景下都要去使用https进行通信呢?答案是否定的。
1)https虽然提供了消息安全传输的通道,但是每次消息的加解密十分耗时,消息系统资源。所以,除非在一些对安全性比较高的场景下,比如银行系统,购物系统中我们必须要使用https进行通信,其他一些对安全性要求不高的场景,我们其实没必要使用https。
2)使用https需要使用到数字证书,但是一般权威机构颁发的数字证书都是收费的,而且价格也是不菲的,所以对于一些个人网站特别是学生来讲,如果对安全性要求不高,也没必要使用https。