0

Say there is a client and a server. Assume the client sends a HTTP GET request GET /?secret=mysecret or GET /?token=mytoken via a) SSL and b) TLS.

SSL as I understand it is the connection is encrypted before the request details are being sent and TLS as I understand it an unencrypted request is being sent then encryption is established (maybe not).

edit: Here's an example of where my confusion is coming from: https://security.stackexchange.com/questions/5126/whats-the-difference-between-ssl-tls-and-https the first comment of the accepted answer.

To make the confusing perfect: SSL (secure socket layer) often refers to the old protocol variant which starts with the handshake right away and therefore requires another port for the encrypted protocol such as 443 instead of 80. TLS (transport layer security) often refers to the new variant which allows to start with an unencrypted traditional protocol and then issuing a command (usually STARTTLS) to initialize the handshake.

And that's the base reason for my question.

Anyhow my question is:

If client sends a HTTP request via a) SSL and b) TLS can the request URI be intercepted by a MITM attack aka is the interceptor able to see the request URI?

Let me rephrase the question: Is the HTTP request sent before encryption with a) SSL and b) TLS or after encryption?

Community
  • 1
  • 1
  • If the question is on `HTTP`, then the answer is YES, almost laughably easily. If the question is on `HTTPS` then the answer is a no (with the disclaimer that you are doing it right). – Aron Jul 19 '14 at 15:27
  • The question is a TCP connection is made, when is the HTTP protocol formatted request sent in SSL and in TLS mode? –  Jul 19 '14 at 16:11
  • Which is normally called https. – Aron Jul 19 '14 at 16:18
  • I'll admit being a bit biased, being the author of the [second answer](http://security.stackexchange.com/a/5152/2435) on the question you link to, but I'd invite you to read it and read what it links to, since it goes in some detail in the difference between SSL and TLS in this context. – Bruno Jul 20 '14 at 18:58

2 Answers2

2

First SSL/TLS channel is built, then the request is sent. Thus the URL, as well as any other request headers, are sent encrypted.

As pointed, passing secrets in the URL is bad because the secret gets to the bookmark where it can be harvested and also to server logs (which can be undesired).

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
  • Ok so oauth2 and openid connect are doing it "wrong" in redirecting an AuthN/Z'd user-agent to the client since they attach the code or token to the request uri or add a fragment with the code/token data. On the other hand how else would they do it. I'm trying to come up with a better security model. But the problem is probably that once a response is served the server can't initiate a redirect if the client wasn't sending a new request, except if the client was constantly polling the server. –  Jul 19 '14 at 16:18
  • @dalu indeed there's no other way for oauth to pass the data, but those tokens are short-term, won't be bookmarked and are not a problem to appear in the logs (cause the tokens have no meaning outside of context). – Eugene Mayevski 'Callback Jul 19 '14 at 16:19
1

If its SSL/TLS its encryted, no body can see the request. The problem with this method is that the request is conspicuous in the browser. If somebody bookmark's the site, the secret get stored in plain text.

dvasanth
  • 1,337
  • 1
  • 9
  • 10