6

Correct me if I am wrong, according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client. its only after the tunnel is created that the complete GET or POST request is sent. What is initially sent is a stripped down version of a GET/POST request to initiate the SSL.

When the SSL is initiated, as for my knowledge, an evesdropper can only see the destination IP, source IP and the PORT in the TCP/IP packet. Everything else is encrypted. please do correct me again, if I have wrong idea about the same. This is merely a collected set of information to which I require confirmation.

If What I have said so far is correct,

calling the URL: www.websiteurl.com?username=name&password=PASSWORD

Should be perfectly safe as long as only an eavesdropper looking at the packets travelling between server and client is concerned. I know since URLs are logged everywhere in the local computer it can be dangerous. I am not planing to implement a system with this knowledge, but I do need to confirm if I know what I know correctly.

So would it be safe to send sensitive information over GET when using HTTPS after the SSL session is initiated with the server?

This question may have no practical implementation as sending sensitive information over URLs is not needed.

SPRBRN
  • 7,379
  • 6
  • 33
  • 37
Denis
  • 273
  • 1
  • 10

3 Answers3

8

Correct me if I am wrong, according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client. its only after the tunnel is created that the complete GET or POST request is sent.

No, this is not a HTTP CONNECT, it is a TCP connection request. The HTTP CONNECT method is only used if you are connecting over a HTTP proxy and the proxy server's certificate is not trusted by the client browser. This will make future requests travel over the proxy as pure SSL data (encrypted), rather than as HTTP requests (decrypted on the proxy and then reencrypted for the destination journey).

When the SSL is initiated, as for my knowledge, an evesdropper can only see the destination IP, source IP and the PORT in the TCP/IP packet. Everything else is encrypted. please do correct me again

Almost. They can see source and destination ports and IPs, and if SNI is enabled they can see the destination domain name.

So would it be safe to send sensitive information over GET when using HTTPS after the SSL session is initiated with the server?

Yes, for these purposes. A MITM would not see the path or query string parameters on the URL, although as you mention it is easy for these to leak in places such as browser history, the logs of any trusted proxy servers (e.g. a proxy in a corporate environment that is trusted by the client machine) or possibly in the referer header.

texnic
  • 193
  • 1
  • 7
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
4

according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client.

Not really correct. CONNECT is only used together with proxies. And even then it does only establish a tunnel directly to the other side, but not yet the SSL tunnel. The SSL tunnel is with and without proxy only established with the SSL handshake between both parties.

When the SSL is initiated, as for my knowledge, an evesdropper can only see the destination IP, source IP and the PORT in the TCP/IP packet.

He also can see the requested hostname in most cases, because all modern browsers use SNI (server name indication) to provide support for multiple certificates behind the same IP. And even without this he can see the certificate from the server, which usually includes the requested hostname (but there might be other names inside too). The eavesdropper can also see that it is SSL, which ciphers are used, which protocol version is spoken etc.

But he can not see the full URL or any other information from the request like cookies etc.

So would it be safe to send sensitive information over GET when using HTTPS after the SSL session is initiated with the server?

If the sensitive information are not in the hostname, but in the path or query string or the payload of a POST request, then TLS is sufficient.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
1

It might already be answered, but, in a normal enviroment (for example at home) you would only see the TCP handshake and the SSL handshake between host and OCS (Original content server) or webserver. Only if you are in an explicit proxy setup, would you see the HTTP CONNECT request, but that would be from the host to the proxy. The proxy would then intercept the traffic. You would then see the SSL handshake between host and proxy and nothing more.

Asger
  • 11
  • 1