Given that almost every web dev's assumption is that TLS encrypts URL parameters, yes it does. Do search parameters in GET requests going across the wire in cleartext not count as possibly sensitive information to you or something?
A secure connection has an actual definition, and it is not "whatever a random web dev thinks happens when they use the internet".
URLs are resource locators. Any sensitive data needs to be in a POST. It's been in the RFC since day one.
Finally, the actual HTTPS connection and the HTTP transaction that occurs is fully secure and is in no way affected by this 'attack' [read: documented feature]. This is an info leak which does not affect the HTTPS protocol directly; it affects services and applications that use wpad.
I will amend my statement to say it is possible to expose query parameters that would otherwise have been secure, but this is still not a compromise of the security of the connection. It's an exploit/attack severity distinction. The net effect of this exploit (that's what it is, not an attack per se) is to provide a side channel to some other attack; but the integrity of the HTTPS connection remains intact.
TLS is __supposed to make URLS confidential__. I don't understand why you don't see this is a problem.
> "whatever a random web dev thinks happens when they use the internet".
I guess 'random web dev' means every single web app dev on the internet - dropbox puts sensitive info in the URLs, google does it, facebook does it, yahoo does it. I guess those engineers are just amateurs though.
> URLs are resource locators. Any sensitive data needs to be in a POST. It's been in the RFC since day one.
RFC 5246 makes no distinction between POST and GETs for it's security assurances - as part of the HTTP request, it should be confidential.
>This is an info leak which does not affect the HTTPS protocol directly; it affects services and applications that use wpad.
You mean HTTP, the one thing HTTPS is used with?
> The net effect of this exploit (that's what it is, not an attack per se)
There's no fucking difference.
> TLS is __supposed to make URLS confidential__. I don't understand why you don't
see this is a problem.
No it is not. TLS is supposed to provide a secure connection for applications. HTTPS is supposed to make URLs confidential. These are different RFCs.
This exploit does not affect TLS. Okay? It. Does. Not. Affect. TLS. This affects _your web browser_.
- When a Flash vulnerability exposes user data, do you say HTTPS is compromised? Of course not.
- When you send someone an e-mail virus that they download with their e-mail program, do you say IMAP is compromised? Of course not.
- If your browser sends all its URLs to some unauthenticated unauthorized random server on the internet because it was being 'overly friendly', is HTTPS compromised? Of course not!
Your browser is compromised! HTTPS is working fine! And HTTPS isn't even involved!!! All of the juicy parts of this exploit happens over plain HTTP!
Your web browser and plugins and e-mail client may be fucked up, but the protocols they work with are working fine. Even wpad is, ironically, working exactly as it's supposed to.
> RFC 5246 makes no distinction between POST and GETs for it's security assurances
- as part of the HTTP request, it should be confidential.
....Why are you bringing up TLS at all?
> You mean HTTP, the one thing HTTPS is used with?
Yes. This exploit does not affect HTTP or HTTPS. It affects wpad-enabled services and applications.
There are lots, and lots, and LOTS of HTTP and HTTPS connections out there that do not support wpad. None of them are affected. The HTTP protocol, and the HTTPS protocol, and TLS (why you keep bringing up TLS is beyond me) are not affected directly by this exploit. The services and applications are.
> > The net effect of this exploit (that's what it is, not an attack per se)
> There's no fucking difference.
Go get a dictionary, buddy, and look up vulnerability, exploit, and attack. Now pick one word and replace all cases of all those words with just the one word. We use specific words for things for a reason.
