3 ms·

> A secure connection has an actual definition TLS is supposed to make URLS confidential. I don't understand why you don't see this is a problem. > "whate

by Chlorus 10y ago

> A secure connection has an actual definition 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.

peterwwillis 10y ago
> 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.

> A secure connection has an actual definition TLS is __supposed to make URLS confidential__. I don't understand why you don't see this is a problem. > "whate

by Chlorus 10y ago

peterwwillis 10y ago

> 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.