在HTTPS连接中,客户端和服务器交换公钥并使用这些密钥使用算法(例如RSA)加密其消息(非对称加密)
这不是真的。密钥对用于 建立 预主密钥,从中导出对称密钥。这可以通过在TLS中使用密钥协议(DH / DHE / ECDH / ECDHE密码套件)来完成,包括TLS 1.3。在该标准的早期版本中,还可以使用RSA加密来加密该秘密 - 由客户端生成 - 仅使用服务器的密钥对。
有趣的是,对于Web上的HTTPS连接,在双方确保他们拥有安全通道后,他们会发送密钥以发送由其他算法(对称加密)加密的其他消息。
不,预主密钥用于生成主密钥,然后使用密钥导出函数来导出会话密钥,密钥导出函数通常称为TLS标准中的PRF,高达1.3。
使用对称加密是因为非对称加密在计算上很重。
它还将密文扩展了比非对称加密大得多的数量。这取决于它是一种误解 只是 在计算上很重。否则这是正确的。
在他们就单个秘密加密密钥达成一致后,服务器和客户端可以轻松地传输消息(文本,图像,重视频等)。
首先,需要对以前的消息进行身份验证。否则,攻击者可以插入信息来攻击该方案。此外,使用两到四个密钥来加密数据帧。如果需要具有身份验证的密码,则使用一个密钥在任一方向上创建消息。如果使用未经认证的密码,则每个方向需要另一个密钥,以通过计算MAC(通常为HMAC)来提供完整性和真实性。
现在,我的问题是:如何管理用于https连接的密钥对?
这取决于密钥对和实现。
操作系统是管理它们还是浏览器?
这也取决于。 Firefox当然管理它自己的密钥和证书。但是,IE和Edge通常使用SChannel,这是Windows中使用Windows证书/密钥库的TLS实现。
它们存放在哪里?
短暂(临时)密钥对通常保存在内存中。静态密钥对通常保存在永久存储器中,或者甚至可以受硬件保护。
可以改变它们吗?
不,您可以生成新的,但如果您更改它们,那么它们将不再有效。
是否为客户端生成的每个https连接生成(新)密钥对?
基于DHE和ECDHE的密码组中的E意味着短暂的。对于稀疏使用的DH和ECDH方案,一个密钥对是静态的,另一个密钥对是短暂的。否则密钥对是静态的,答案是否定的。静态密钥对的公钥通常在X.509内 证书 。要使用静态密钥对,建立起来非常重要 信任 在公钥中。
从逻辑上讲,单个密钥对将终身服务于客户端。因此每个操作系统需要为每个算法生成一堆不同长度的密钥。
这完全是完全无稽之谈。客户通常甚至没有密钥对。证书都有一个需要使用的有效期。客户通常甚至没有证书。钥匙需要更新。临时密钥对是在运行中生成的。
具体来说,我非常好奇它是如何在android中完成的。我正在尝试决定如何在我的应用程序中管理https连接,但我没有找到任何允许我使用特定密钥对进行连接的库,这让我想到了所有这些东西。
你不应该思考,因为你上面写的任何东西都是完全的 错误 (除了那个单一的句子,这只是不完整的)。你应该是 读 - 适用于初学者的TLS RFC。在你建立了足够的知识基础之后,思考就来了。
如果你现在有任何有趣的想法:写下来,学习,然后检查它们是否值得保留。