HTTPS是否基于用户端的私钥？

Question

HTTPS是否基于用户端的私钥？

首先，用户从哪里获得私钥？

假设用户通过下载浏览器(Chrome，Firefox)获得私钥，那么黑客难道不能通过中间人攻击来拦截密钥吗？

假设私钥来自Windows OS注册号，那么这是否意味着黑客可以通过中间人攻击拦截所有Linux浏览器下载的私钥，因为Linux没有注册号？

假设私钥是基于计时器函数的，那么强行强制私钥不是很容易吗？

如果HTTPS不是基于用户的私钥，那么HTTPS不是很不安全吗？

Answer 1

通常，对称密钥是动态协商的，并且在浏览器和服务器之间安全地交换。一个协议，使人们能够这样做(Diffie-Hellman密钥交换)解释在这个优秀的youtube视频：http://www.youtube.com/watch?v=3QnD2c4Xovk。

它的随机数据是使用任意数量的方法导出的；它肯定不是静态的，而且通常与当前时间没有多大关系。经典的例子是使用从时间到时间的微秒数，这是知道一天中的时间到第二个时间不会有帮助的事情。其他来源包括某些事件的时间安排(在linux中常见的按键和磁盘访问)、某个时刻半透明镜反射的光子数(量子衍生熵，就像许多SSL加速器使用的那样)，或者亚稳态振荡器(英特尔DRBG)的作用，以及其他一些东西。每次需要时都会收集这些随机数据，尽管在实践中有时可以将其存储在池中供以后使用(这也可能是一个漏洞，但这是另一个主题)。

因为钥匙是随机的，你需要做大量的蛮力才能得到它。如果您将密钥的熵值最大化，而密码使用256位密钥(AES-256等)，则需要多次尝试(2^256 * 0.50次尝试将给您50%的恢复密钥的机会)。在实践中，很多人使用的熵比这个更少，并且决定性地构造了其余的关键，这意味着如果他们只使用64位熵，那么这个公式就会改变为2^64 * 0.50，只要您知道密钥是如何生成的。对于DH密钥交换，就像我前面提到的，这个数学实际上要复杂一些，因为你必须考虑到，你选择的是两个随机数，而不是一个。

这是很多钥匙，而且大多数攻击者在你停止使用它之前用暴力破坏它的几率是很小的。

Answer 2

HTTPS是否基于用户端的私钥？

部分是的。

首先，用户从哪里获得私钥？

浏览器自动生成随机私钥。

假设用户通过下载浏览器(Chrome，Firefox)获得私钥，那么黑客难道不能通过中间人攻击来拦截密钥吗？

键不是浏览器的一部分，它是动态生成的。

假设私钥来自Windows OS注册号，那么这是否意味着黑客可以通过中间人攻击拦截所有Linux浏览器下载的私钥，因为Linux没有注册号？

与上述相同的答案

假设私钥是基于计时器函数的，那么强行强制私钥不是很容易吗？

为什么会这样？有一些随机性。