一、HTTP中使用对称加密?
如果使用对称加密,那么客户端和服务端使用同一个密钥对数据进行加解密,那么黑客同样拿到这个密钥。
二、HTTP中使用非对称加密?
客户端发送请求获取服务端的公钥,客户端使用公钥对数据进行加密传送到服务端,服务端使用私钥对数据进行解密,但是在服务端向客户端发送数据的时候,如果使用私钥进行加密传送出去,那么黑客在截取到加密信息后也可以通过服务端的公钥进行解密。
三、HTTP使用非对称加密+对称加密完成信息传输?
客户端使用非对称加密来完成对称加密密钥的协商,即使用服务器的公钥(客户端需要首先请求服务端的公钥)将待约定的对称密钥加密传送给服务端,而这个密文只有用服务端的私钥才能解密,确定对称加密的密钥之后,黑客使用私钥向客户端发送确认信息。接下来使用对称密钥进行信息的传输。
四、HTTP使用非对称加密+对称加密一定安全吗?
不安全,因为不能防范中间人攻击。中间人攻击过程:客户端向服务端发送消息请求服务端的公钥,但是此时消息被黑客劫持,此时黑客将自己的公钥发送给客户端,客户端使用此公钥将对称加密的密钥发送给黑客,黑客使用自己的私钥进行解密得知对称加密的密钥,从而与客户端建立基于对称加密的数据传输。在此同时,黑客向服务端请求公钥来进行对称加密密钥的协商,并使用此密钥进行数据加密传输。综上,黑客完全作为一个中间人窥探到了客户端与服务端之间的所有数据。
五、如何解决中间人劫持问题?
引入权威机构CA,在进行客户端与服务端的数据交互之前,首先CA使用私钥对服务端的公钥进行加密作为证书将其发送给服务端,CA的公钥是写死在客户端的操作系统中的(这一点可以避免客户端与CA之间的中间人攻击)。那么数据传输的过程如下:客户端请求服务端的证书,然后使用写死在OS中的CA公钥对服务端证书进行解密,如果解密成功,那么说明这个公钥是得到了CA权威机构的认可,而不是中间人所伪造发送的自己的公钥(浏览器会提示不安全的证书)。
六、SSL/TLS协议的运行过程
HTTPS其实是由两部分组成:HTTP+TLS/SSL,也就是在HTTP上又加了一层处理加密信息的模块。SSL介于应用层和TCP层之间,应用层数据不再直接传递给传输层,而是传递给SSL层,SSL层对从应用层收到的数据进行加密,并增加自己的SSL头。
"握手阶段"涉及四次通信,我们一个个来看。需要注意的是,"握手阶段"的所有通信都是明文的。
4.1 客户端发出请求(ClientHello)
首先,客户端(通常是浏览器)先向服务器发出加密通信的请求,这被叫做ClientHello请求。
在这一步,客户端主要向服务器提供以下信息。
(1) 支持的协议版本,比如TLS 1.0版。
(2) 一个客户端生成的随机数,稍后用于生成"对话密钥"。
(3) 支持的加密方法,比如RSA公钥加密。
(4) 支持的压缩方法。
这里需要注意的是,客户端发送的信息之中不包括服务器的域名。也就是说,理论上服务器只能包含一个网站,否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。
对于虚拟主机的用户来说,这当然很不方便。2006年,TLS协议加入了一个Server Name Indication扩展,允许客户端向服务器提供它所请求的域名。
4.2 服务器回应(SeverHello)
服务器收到客户端请求后,向客户端发出回应,这叫做SeverHello。服务器的回应包含以下内容。
(1) 确认使用的加密通信协议版本,比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致,服务器关闭加密通信。
(2) 一个服务器生成的随机数,稍后用于生成"对话密钥"。
(3) 确认使用的加密方法,比如RSA公钥加密。
(4) 服务器证书。
除了上面这些信息,如果服务器需要确认客户端的身份,就会再包含一项请求,要求客户端提供"客户端证书"。比如,金融机构往往只允许认证客户连入自己的网络,就会向正式客户提供USB密钥,里面就包含了一张客户端证书。
4.3 客户端回应
客户端收到服务器回应以后,首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期,就会向访问者显示一个警告,由其选择是否还要继续通信。
如果证书没有问题,客户端就会从证书中取出服务器的公钥。然后,向服务器发送下面三项信息。
(1) 一个随机数。该随机数用服务器公钥加密,防止被窃听。
(2) 编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
(3) 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供服务器校验。
上面第一项的随机数,是整个握手阶段出现的第三个随机数,又称"pre-master key"。有了它以后,客户端和服务器就同时有了三个随机数,接着双方就用事先商定的加密方法,各自生成本次会话所用的同一把"会话密钥"。
至于为什么一定要用三个随机数,来生成"会话密钥",dog250解释得很好:
"不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说,pre-master-key本身就是一个随机数,再加上hello消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数,如果随机数不随机,那么pre master secret就有可能被猜出来,那么仅适用pre master secret作为密钥就不合适了,因此必须引入新的随机因素,那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。"
此外,如果前一步,服务器要求客户端证书,客户端会在这一步发送证书及相关信息。
4.4 服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后,计算生成本次会话所用的"会话密钥"。然后,向客户端最后发送下面信息。
(1)编码改变通知,表示随后的信息都将用双方商定的加密方法和密钥发送。
(2)服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值,用来供客户端校验。
至此,整个握手阶段全部结束。接下来,客户端与服务器进入加密通信,就完全是使用普通的HTTP协议,只不过用"会话密钥"加密内容。