Answers:
整个请求都被加密,包括URL,甚至是命令(GET
)。诸如代理服务器之类的干预方唯一可以收集的是目标地址和端口。
但是请注意,TLS握手的Client Hello数据包可以通过SNI扩展名(感谢@hafichuk)以纯文本形式发布完全合格的域名,所有现代主流浏览器都使用了SNI扩展名(尽管有些仅在较新的OS上使用)。
编辑:(因为这只是给我一个“好答案”徽章,我想我应该回答整个问题……)
整个响应也被加密;代理无法拦截其中的任何部分。
Google通过https提供搜索和其他内容,因为并非所有内容都是公开的,并且您可能还希望对MITM隐藏一些公开的内容。无论如何,最好让Google 自己回答。
URL本身是加密的,因此查询字符串中的参数不会在整个网络中传播。
但是,请记住,包含GET数据的URL通常由网络服务器记录,而POST数据很少记录。因此,如果您打算做类似的事情/login/?username=john&password=doe
,那就不要;改用POST。
HTTPS在传输任何HTTP数据之前建立基础SSL连接。这样可以确保所有URL数据(用于建立连接的主机名除外)仅在此加密的连接内承载,并且受到与任何HTTPS数据相同的保护,免受中间人攻击。
以上是Google解答提供的非常全面的答案的一部分,位于以下位置:
http://answers.google.com/answers/threadview/id/758002.html#answer
安全发送主机名之后的URL部分。
例如, https://somewhere.com/index.php?NAME=FIELD
该/index.php?NAME=FIELD
部分已加密。该somewhere.com
是没有的。
一切都是加密的,但您需要记住,查询将保留在服务器的日志中,并且各种日志分析器等都可以访问(对于POST请求通常不是这种情况)。
是的,它是安全的。SSL加密所有内容。
POST请求摘录:
POST /foo HTTP/1.1
... some other headers
摘自GET请求:
GET /foo?a=b HTTP/1.1
... some other headers
在这两种情况下,套接字上发送的所有内容都会被加密。客户端在GET请求期间看到其浏览器中的参数的事实并不意味着中间的人会看到相同的结果。
SSL发生在头解析之前,这意味着:
Client creates Request
Request gets encrypted
Encrypted request gets transmitted to the Server
Server decrypts the Request
Request gets parsed
一个Request看起来像这样(不记得确切的语法,但这应该足够接近):
GET /search?q=qwerty HTTP/1.1
Host: www.google.de
这也是为什么同一IP上的多个主机具有不同的SSL证书会出现问题的原因,直到解密后才知道所请求的主机名。
HTTP/1.1
谈到在第一行的末尾。
使用HTTPS时,GET请求已加密-实际上,这就是受保护的网站需要具有唯一IP地址的原因-在解密请求之前,无法从请求中获取预期的主机名(或虚拟目录)。