使用HTTPS,请求正文是否保护URL和请求标头？

Question

只是想验证,在进行SSL连接(http post)时说:

https://www.example.com/some/path?customer_key=123123123

如果您不希望任何人知道customer_key,即使我正在建立https连接,这种方法也行不通？

我想要保护的所有数据都必须在请求正文中吗？

Answer 1

引用HTTPS RFC:

TLS握手完成后.然后,客户端可以发起第一个HTTP请求.所有HTTP数据必须作为TLS"应用程序数据"发送.

实质上,首先建立安全的SSL/TLS信道.只有这时才使用HTTP协议.这将使用SSL保护所有HTTP流量,包括HTTP标头(包含URL和cookie).

握手中可见的是主机名本身,因为它包含在服务器证书中,在握手中可以清楚地看到(通过查看目标IP地址通常很容易猜出主机名).

使用服务器名称指示时,请求的主机名也应显示在消息的server_name扩展名中ClientHello.否则,如果证书对多个主机名有效(例如,多个主题Alt.名称或通配符),则可能存在一些歧义(对于窃听者)从证书中猜测主机名.在这种情况下,窃听来自客户端的DNS请求可能会给攻击者一个线索.

阅读其他人的答案和评论,一些人提到Referer(r在规范中丢失)和日志的问题.

• 从HTTPS转到HTTP时不应发送引用者(但通常在从一个HTTPS站点转到另一个HTTPS站点时发送它们).
• 关于历史:你只需要相信任何可以合法地获得该密钥的人(即你的用户)不要传播它.如果需要,有一个策略,偶尔改变它.
• 关于日志:我假设你是在通过网络保护之后.URL(包括查询)确实会在日志中,但如果有人能够攻击您的计算机以获取日志,您还需要担心您的应用程序密钥.

剩下的潜在弱点之一是如何将该链接提供给用户.如果它嵌入在通过普通HTTP提供的网页中,那么任何能够阅读该页面的人都能够看到它.您也应该通过HTTPS提供此类页面.如果您通过电子邮件发送该链接,我会说所有赌注都已关闭,因为邮件服务器很少加密它们之间的连接,用户也经常访问他们的电子邮件帐户而不进行任何加密.

编辑:

此外,如果您正在使用客户端证书身份验证,则在初始握手期间协商客户端证书将是可见的.这可能会泄漏访问网站的用户的名称(通常主题DN包含用户名).如果在重新协商的握手期间发送客户端证书,则该证书将不可见.

Answer 2

只有www.example.com窥探者才能看到.请求的路径部分受SSL/TLS保护.

显然,您还需要通过HTTPS发送原始超链接.