【问题标题】:HTTPS (SSL/TLS)HTTPS (SSL/TLS)
【发布时间】:2018-10-04 07:44:31
【问题描述】:

我正在尝试了解 HTTPS 的内部工作原理。 我了解服务器使用客户端生成的预主密钥并使用服务器的公钥加密的对称加密。我的理解也是服务器加密资源的哈希而不是实际资源,然后客户端将解密并验证哈希。但我有两个问题-

  1. 假设实际文件仍由服务器以纯文本形式发送并且浏览器仅因为能够对文件进行哈希处理并使用对称加密对其进行验证而信任其内容是否正确?
  2. 来自客户端的信息(例如 POST 有效负载或 URL 参数)在发送到服务器时如何加密?浏览器是否仍然会散列有效负载或 URL 参数,还是会简单地加密数据?

非常感谢您的帮助!

【问题讨论】:

    标签: ssl encryption https ssl-certificate


    【解决方案1】:

    我了解服务器使用客户端生成的预主密钥并使用服务器的公钥加密的对称加密。

    仅在某些密码套件中。一般来说,您应该只将会话密钥视为由密钥协商协议安全协商的,然后将其保留。

    我的理解也是服务器加密资源的哈希值而不是实际的资源,然后客户端将解密并验证哈希值。

    我不知道这是什么意思。服务器必须返回实际数据,而不仅仅是哈希。在握手和 SSL 数据消息中使用了哈希,但这与您无关:它只是 SSL 提供的隐私的一部分。

    但我有两个问题 - 假设实际文件仍然由服务器以纯文本形式发送是否正确

    不,当然不是,它是用会话密钥加密的。这就是会话密钥的用途。

    浏览器信任内容只是因为它能够对文件进行哈希处理并使用对称加密对其进行验证?

    没有。忘记散列。数据已加密。

    来自客户端的信息,例如 POST 负载或 URL 参数在发送到服务器时的加密程度如何?

    使用会话密钥。

    浏览器是否还会散列有效负载或 URL 参数

    没有。忘记散列。

    还是只是简单地加密数据?

    是的。

    【讨论】:

    • 非常感谢您的详细回复。会话密钥是否与握手时浏览器生成的“预主”密钥相同?
    • 没有。有一个预主密钥、一个从它派生的主密钥以及从主密钥生成的会话密钥(一个或多个)。如上所述,如何生成预主密钥的问题取决于密码套件。
    猜你喜欢
    • 2023-04-01
    • 1970-01-01
    • 2014-05-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-02-07
    • 2012-04-19
    相关资源
    最近更新 更多