ECDHE_RSA 和 gmail

信息安全 加密 tls 证书 x.509 中间人
2021-08-26 03:29:27

我在 Ubuntu Linux 上使用 Chrome 连接到 Gmail。连接信息表明 ECDHE_RSA 用于 https 对称密钥交换。

根据我对TLS和 Gmail 的理解,我的客户端创建了一个对称密钥,使用其证书中列出的 Google 公钥加密,然后发送给 Google。由于我的浏览器可以识别 Google 的证书,是否可以安全地假设我的连接是安全的并且不会被中间人攻击?中间的人怎么可能查看对称密钥,因为他没有 Google 的私钥来解密消息?

我的浏览器中没有导入证书。我使用 Wireshark 来窥探 TLS 协商。我在“client hello”数据包中看到我发送了关于我的客户端支持哪些密码套件的信息、一个随机数和椭圆曲线信息。在gmail服务器以“服务器问候”和“证书,服务器密钥交换,服务器问候完成”响应后,我的客户端然后发送“客户端密钥交换,更改密码规范,加密握手消息”。假设用谷歌的公钥加密的对称密钥在“加密握手消息”下的这个数据包中是否正确(TLSv1.1 Record Layer: Handshake Protocol: Encrypted Handshake Message)。

服务器是否可以通过我的客户端在上面生成的对称密钥在不同网络上的未来 TCP 连接中对我的客户端进行指纹识别(即唯一标识)?

1个回答

使用 ECDHE_RSA,实际的密钥交换使用Elliptic Curve Diffie-Hellman服务器的 ECDH 公钥不在其证书中,而是在ServerKeyExchange消息中,服务器使用其私钥签名(并且您的浏览器会相对于服务器证书中的公钥验证该签名)。ECDH产生的对称密钥不是由客户端单独“选择”的,但它仍然是客户端和服务器共享的密钥,而不是其他人。这不像您的描述那么直接,但您的想法是正确的:确实,只要实现正确并且您的浏览器正确验证服务器证书,交换的数据就不会受到窃听者、假冒和恶意更改的影响。

如果您的客户端尝试重新连接到同一台服务器(这在 Web 环境中是正常的,因为服务器倾向于在 15 秒不活动后断开连接),它将尝试重用来自 ECDH 的对称密钥,以避免整个不对称加密业务,更重要的是,避免一次网络往返。这是SSL /TLS的缩写握手如果客户端和服务器都还记得之前的连接(称为“SSL 会话”),那么这将起作用。在这些条件下,服务器可能会将客户端识别为“与以前相同”。

但是,SSL 会话参数(协商的对称密钥)不会存储在永久存储区域中,并且容易被遗忘。如果您关闭浏览器,它将忘记所有此类会话。默认情况下,Apache 服务器将记住 SSL 会话参数5 分钟,如果它处理许多连接,则可能会更短(因为它的此类参数的存储空间具有可配置但有限的大小)。

有关 SSL 协议的详细演练,请参阅此答案