4 ms·
"We show that HTTPS cannot provide security when WPAD is enabled." That's effectively a lie. The HTTPS connection itself is definitely still secure. The only d
by peterwwillis 10y ago
"We show that HTTPS cannot provide security when WPAD is enabled."
That's effectively a lie. The HTTPS connection itself is definitely still secure. The only difference is the browser is telling an attacker what URL it wants to go to. You can also watch what virtual hosts someone is visiting by sniffing DNS requests, statistical packet analysis can show exactly what you're looking at, and there are plenty of attacks on browsers and the client OS to get more data that don't require wpad.
If you want to browse securely, you have to tunnel everything. You should not assume a browser will ever be able to hide all possible traceable data about your connection & request.
- cpitman 10y agoIsn't the host that a user is requesting passed unencrypted anyways via SNI?
- Chlorus 10y agoAlso plain as day in the DNS lookup - but a MITM-attacker knowing the host you're connecting to isn't the problem here; it's that the attacker knows which particular URLs you have requested.
- keyme 10y agoThe full URL contains much more than just the host. Open fiddler, log in to a Google account, see how much sensitive data is sent inside URL params. All of this data is disclosed in this attack.
- peterwwillis 10y agoDid I dispute that? I pointed out they are lying that it compromises the HTTPS connection. It does not.
- Chlorus 10y agoGiven 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?
- peterwwillis 10y agoA 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.
- 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.
- Chlorus 10y agoI don't think you know the difference between a hostname & a URL