Professional Documents
Culture Documents
https相关
https相关
机密性 —— 对称加密/非对称加密/混合加密
为了确保信息传输的安全,必须使用加密算法对信息进行加密。加密和解密都需要依
靠密钥,因此问题的关键就在于如何在一开始安全地传递密钥,也就是所谓的“密钥
交换”。
加密和解密使用的是同一把钥匙(密钥)。但如何在最开始去传递钥匙成了一个问题,
如果黑客截获了钥匙,那么就可以劫持篡改信息,无法确保信息安全
用公钥加密,用私钥解密。假设客户端是发送方,服务端是接收方,那么服务端首先
生成一对公钥和私钥,私钥自己保存,公钥发送给客户端,客户端每次都通过公钥对
信息进行加密,然后把信息发给服务端,服务端再使用私钥进行解密。即使黑客截获
了公钥,意义也不大,因为信息必须依靠私钥才能解密
混合加密:
非对称加密虽然解决了密钥交换的安全问题,但是每次通信都需要进行耗时的加密和
解密,这会进一步拖慢双方的通信速度。而混合加密则将对称加密和非对称加密做了
一个结合:
服务端这边基于==非对称加密算法==生成一对公钥和私钥,然后把公钥传给客
户端
客户端这边基于==对称加密算法==生成一个后续通信使用的会话密钥(session
key),用会话密钥加密要发送的信息,用公钥加密会话密钥本身,也就是说,
客户端发给服务器的有两个东西:
o 一个是用公钥加密的会话密钥
o 一个是用会话密钥加密的信息
服务器拿到后,首先用私钥解密,拿到会话密钥,然后再用会话密钥解密,拿
到实际的信息。
在这之后,实际上已经解决了安全传递密钥(会话密钥)的问题。之后的每次通信中,
双端只需要用同样的会话密钥加密和解密即可,这样就确保了安全 + 性能。
完整性和身份验证 —— 摘要算法、数字签名、数字证书
目前为止只保证了一定的机密性,但是还有两个问题没有解决:第一个是身份验证问
题,服务端的公钥是自由分发的,意味着黑客可以拿着公钥冒充客户端;反过来,黑
客也可以冒充服务端分发公钥。不管是客户端还是服务端,确认对方的身份成了一个
问题;第二个是数据完整性问题,既然黑客可以冒充客户端或者服务端,那么也就可
以劫持并篡改数据,如何确保数据的完整成了一个问题。
数字签名:
数字签名和非对称加密是反过来的,用私钥进行加密,而用公钥进行解密。服务端这
边基于摘要算法,对要传输的数据进行 hash 计算,从而得到一个与数据对应的摘要
(digest),然后用私钥对摘要进行加密,形成签名,接着把 签名+数据 发送给客户
端。客户端收到签名和数据后:
解决身份验证问题:首先,用此前拿到的公钥进行验签(解密签名),拿到摘
要。公钥和私钥是一对的,客户端认为,既然自己可以用服务端当时发过来的
公钥对此时收到的签名进行解密,那么就可以确保这个签名确实是服务端自己
加密然后发送过来的,身份验证这一关就 ok 了;
解决数据完整性问题:接着,客户端对数据进行同样的 hash 计算,得到另一个
摘要,将这个摘要与签名中的摘要进行对比,如果一致,说明数据是完整没有
被篡改的 —— 因为如果被篡改(哪怕只是细微的变动),那么客户端基于被
篡改的数据进行 hash 得到的摘要会和签名中的摘要完全不同。
数字证书:
但是这一切建立在一个大前提下,那就是==客户端持有的公钥确实是服务端的公钥==。
要知道,这个公钥最开始也是服务端自由分发的,因此可能被黑客动过手脚,然后黑
客再将自己的公钥发给客户端,客户端不知道,可能自己一直在和黑客而不是服务端
通信,毕竟它坚信自己确实收到了服务端的公钥,且自己持有的公钥可以解密对方用
私钥加密的东西,因此不会产生怀疑。
为了解决这种情况,我们需要找一个受信任的第三方机构(认证机构 CA)参与其中,
通过它(而不是服务端)来进行服务端公钥的分发,从而确保客户端得到的公钥确实
是来自于服务端的。具体地说,服务端首先向 CA 提交相关信息,申请一个证书,证
书的内容是:
基本信息:CA 信息、服务端信息、服务端公钥、有效期等
签名:针对上述信息生成一个摘要,用 CA 的私钥去加密这个摘要,得到一个
签名。
现在,这个证书就是被签过名的了。CA 把生成的证书给服务端,服务端再把证书传给
客户端,客户端通过从 CA 那里获得的公钥进行验签,一旦通过即可认为证书确实是
来自于服务端的,自然也就可以使用证书中携带的服务端的公钥。自此,已经解决了
“确保客户端持有的公钥确实是服务端的公钥”的问题,之后的流程就和前面说的一
样了。那么如何确保 CA 是可以信任的呢?小的 CA 由大的 CA 来签名认证,形成一
条信任链/证书链,链条的最后是一个可以自签名的根证书,我们必须无条件信任它。
上面说了,服务端需要把证书发送给客户端,那么黑客是否可能在这个过程中对证书
做手脚呢?
比如说,黑客可能会篡改证书的基本信息?不可能,只要篡改了基本信息,后
续客户端拿 对信息进行 hash 计算得到的摘要 与 公钥解密签名得到的摘要 进
行对比的时候,就会发现两者是不一致的,因此就会认定这个证书以及它携带
的公钥是有问题的。
那么,黑客是否可以先篡改证书的基本信息,然后再生成对应的摘要,再去加
密这个摘要形成签名呢?这个也是不可能的,因为黑客没有 CA 的私钥,无法
自己形成签名。
3. 客户端验证证书,确认服务端身份无误后:
使用 ECDHE,双端需要互换密钥交换算法的参数,利用两个参数生成 pre-
master secret;使用 RSA,只需要由客户端这边直接生成 pre-master secret,并
共享给服务端。当然,最终都需要使用 pre-master secret + client random +
server random 生成 master secret,这点是一样的
使用 ECDHE 可以实现 TLS False Start,即抢跑,客户端可以在服务端尚未响
应 finished 的时候就开始发送 https 请求;使用 RSA,只能在双方都 finished
之后才能收发请求响应。
HTTPS 性能优化
相比 http,https 需要通过握手创建 tls 连接,最多需要消耗两个 rtt,因此 https 一般
会比 http 慢。如何优化 https 的连接速度呢?可以从以下几个方面入手:
TLS 连接的重点在于创建共有的主密钥(或者说会话密钥)。若是每次创建
TLS 连接都需要重新创建主密钥,未免太大费周章了 —— 假如这个主密钥可
以缓存下来,那么以后同一个客户端和服务端再次连接的时候就可以直接拿来
继续使用了。这就是会话复用,而实现会话复用有 session id 和 session ticket
两种方式。
为了安全起见,这几种方式都需要验证会话密钥的有效期。