只是想验证一下，在进行 SSL 连接（http post）时说：
https://www.example.com/some/path?customer_key=123123123
如果您不想让任何人知道 customer_key，即使我正确建立了 https 连接，这种方法也不起作用？
我想要保护的所有数据都必须在请求正文中，对吗？
【问题讨论】：
引用HTTPS RFC：
当 TLS 握手完成时。然后客户端可以启动 第一个 HTTP 请求。所有 HTTP 数据必须作为 TLS 应用程序发送 数据”。
本质上，首先建立安全的 SSL/TLS 通道。只有这样才能使用 HTTP 协议。这将使用 SSL 保护所有 HTTP 流量，包括 HTTP 标头（包含 URL 和 cookie）。
握手中可能显示的是主机名本身，因为它包含在服务器证书中，在握手中清晰可见（而且通过查看目标 IP 地址通常很容易猜出主机名)。
使用服务器名称指示时，请求的主机名也应该在ClientHello 消息的server_name 扩展中可见。
否则，如果证书对多个主机名有效（例如，多个主题替代名称或通配符），则从证书中猜测主机名可能会有些模糊（对于窃听者）。在这种情况下，窃听来自客户端的 DNS 请求可能会给攻击者提供线索。
阅读其他人的答案和 cmets，有些人提到了关于 Referer 的问题（在规范中丢失了一个 r）和日志。
剩下的潜在弱点之一是如何您将该链接提供给用户。如果它嵌入到通过纯 HTTP 提供的网页中，那么任何可以阅读该页面的人都可以看到它。您也应该通过 HTTPS 提供这样的页面。如果您改为通过电子邮件发送该链接，我会说所有的赌注都没有了，因为邮件服务器很少加密它们之间的连接，而用户也经常在没有任何加密的情况下访问他们的电子邮件帐户。
编辑：
此外，如果您使用的是客户端证书身份验证，则如果在初始握手期间协商客户端证书，它将是可见的。这可能会泄露访问网站的用户名（通常主题 DN 包含用户名）。如果在重新协商的握手期间发送客户端证书，则客户端证书将不可见。
【讨论】：
请求数据会在建立安全连接后发送，所以不用担心上面的URL，但记住你的数据没有加密，只有服务器和客户端之间的通道是加密的，如果有人能破解这个通道，那么可以清楚地看到你的数据.
SSL 是您数据之上的封装加密通道。如果数据是普通的，任何能够破解 SSL 的人都可以清楚地看到你的数据。
【讨论】：
这取决于..
如果您使用数据包嗅探器，您将看不到通过网络发送的数据。这种方法的主要问题是请求 url 通常以纯文本形式保存在服务器的日志中，浏览器历史记录会保留 url，URL 在 Referrer 标头中传递，并且可能由第三方服务（谷歌分析）保存。
【讨论】：
Referer 不应通过 HTTPS 传递：stackoverflow.com/a/8848843/372643
只有www.example.com 对窥探者可见。请求的路径部分受 SSL/TLS 保护。
显然，您也需要通过 HTTPS 发送原始超链接。
【讨论】：
修改我对“否”的回答！ 显然，在建立 SSL 连接之前，只有主机名以明文形式发送。
【讨论】：