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