https加密原理

294 阅读7分钟

为什么需要加密

http是明文传输的,内容会经过多个物理节点,如果在传输过程中信息被截取,传输内容就被获取,甚至篡改,导致中间人攻击.

对称加密

一把钥匙开一把锁.通信双方各持有同一个密钥,且没人知道.

有几个弊端:

1.但是无法保证你的密钥让对方知道的同时,又不被劫持.

2.如果提早预备各个站点的密钥,又非常不现实

非对称加密

有两把密钥,公钥&私钥,用公钥加密的内容,必须私钥才能解开.也就是公钥加密的内容需要对应的私钥解密,私钥加密的内容需要对应的公钥解密。

非对称加密改良方案

双边非对称加密.

1.某网站拥有用于非对称加密的公钥A1、私钥A2;浏览器拥有用于非对称加密的公钥B1、私钥B2。

2.浏览器向网站服务器请求,服务器把公钥A1明文传输给浏览器。

3.浏览器把公钥B1明文传输给服务器。

4.之后浏览器向服务器传输的所有东西都用公钥A1加密,服务器收到后用私钥A2解密。由于只有服务器拥有私钥A2进行解密,所以能保证这条数据的安全。

5.服务器向浏览器传输的所有东西都用公钥B1加密,浏览器收到后用私钥B2解密。同上也可以保证这条数据的安全。 非对称加密算法非常耗时.无法进行双边非对称加密.

非对称加密 + 对称加密

1.某网站拥有用于非对称加密的公钥A1、私钥A2。

2.浏览器向网站服务器请求,服务器把公钥A1明文给传输浏览器。

3.浏览器随机生成一个用于对称加密的密钥X,用公钥A1加密后传给服务器。

4.服务器拿到后用私钥A2解密得到密钥X。

5.这样双方就都拥有密钥X了,且别人无法知道它。之后双方所有数据都用密钥X加密解密即可。

但是仍然存在漏洞,浏览器无法确认自己收到的公钥是不是网站自己的。存在中间人攻击.

中间人攻击

1.某网站拥有用于非对称加密的公钥A1、私钥A2。

2.浏览器向网站服务器请求,服务器把公钥A1明文传输给浏览器。

3.中间人劫持到公钥A1,保存下来,把数据包中的公钥A1替换成自己伪造的公钥B1(它当然也拥有公钥B1对应的私钥B2)。

4.浏览器随机生成一个用于对称加密的密钥X,用公钥B1(浏览器不知道公钥被替换了)加密后传给服务器。

5.中间人劫持后用私钥B2解密得到密钥X,再用公钥A1加密后传给服务器。

6.服务器拿到后用私钥A2解密得到密钥X。

数字证书

数字证书里有证书持有者、证书持有者的公钥等信息。服务器把证书传输给浏览器,浏览器从证书里取公钥.

数字签名

我们把证书内容生成一份“签名”,比对证书内容和签名是否一致就能察觉是否被篡改。这种技术就叫数字签名.

左侧是数字签名的制作过程,右侧是验证过程

数字签名的制作过程:

1.CA拥有非对称加密的私钥和公钥。

2.CA对证书明文信息进行hash。

3.对hash后的值用私钥加密,得到数字签名

浏览器验证过程:

1.拿到证书,得到明文T1,数字签名S1。

2.用CA机构的公钥对S1解密(由于是浏览器信任的机构,所以浏览器保有它的公钥。详情见下文),得到S2。

3.用证书里说明的hash算法对明文T1进行hash得到T2。

4.比较S2是否等于T2,等于则表明证书可信。

为什么这样可以证明证书可信?

假设中间人篡改了证书的原文,由于他没有CA机构的私钥,所以无法得到此时加密后签名,无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致,则说明证书已被篡改,证书不可信,从而终止向服务器传输信息,防止信息泄露给中间人。

既然不可能篡改,那如果整个证书被掉包呢?

假设有另一个网站B也拿到了CA机构认证的证书,它想搞垮网站A,想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书,然后替换成自己的证书,传给浏览器,之后浏览器就会错误地拿到B的证书里的公钥了,会导致上文提到的漏洞。 其实这并不会发生,因为证书里包含了网站A的信息,包括域名,浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

制作数字签名时为什么需要hash一次?

最显然的是性能问题,前面我们已经说了非对称加密效率较差,证书信息一般较长,比较耗时。而hash后得到的是固定长度的信息(比如用md5算法hash后可以得到固定的128位的值),这样加密解密就会快很多。当然除此之外也有安全上的原因。

HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗?

显然每次请求都经历一次密钥传输过程非常耗时,那怎么达到只传输一次呢?用session就可以。 服务器会为每个浏览器(或客户端软件)维护一个session ID,在TSL握手阶段传给浏览器,浏览器生成好密钥传给服务器后,服务器会把该密钥存到相应的session ID下,之后浏览器每次请求都会携带session ID,服务器会根据session ID找到相应的密钥并进行解密加密操作,这样就不必要每次重新制作、传输密钥了

HTTPS 工作原理

1.client向server发送请求https://baidu.com,然后连接到server的443端口。

2.服务端必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面,这套证书其实就是一对公钥和私钥。

3.传送证书 这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间、服务端的公钥,第三方证书认证机构(CA)的签名,服务端的域名信息等内容。

4.客户端解析证书 这部分工作是由客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随机值(密钥)。然后用证书对该随机值进行加密。

5.传送加密信息 这部分传送的是用证书加密后的密钥(随机值),目的就是让服务端得到这个密钥(随机值),以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6.服务端加密信息 服务端用私钥解密,得到了客户端传过来的密钥(随机值),然后把内容通过该值进行对称加密。

7.传输加密后的信息 这部分信息是服务端用密钥(随机值)对称加密后的信息,可以在客户端被还原。

8.客户端解密信息 客户端用之前生成的密钥(随机值)解密服务端传过来的信息,于是获取了解密后的内容