21–30 of 48 posts
Earlier quoted context omitted.
I think the problem is, always on encryption, is always off caching...
That's not true, your browser still handles caching just fine. More bandwidth trumps caching anyway, and caching forward proxies will be a thing of the past.
In Russia, for example, there are explicit regulations which says that no telecom company can operate unless it provides "monitoring and law-enforcement facilities".
My guess is that each country nowadays has regulations of this sort, so telecom equipment manufactures are forced to "add required functionality". Of course, US has such "secret" regulations.)
So, it is much better to face the reality and to standardize this shit to reduce the pain of telecom "workers".)
Earlier quoted context omitted.
This simply means that phone/tablet manufacturers together with carriers will pre-install and trust the proxy certificates of the carrier, without any end user consent. This will easily allow the carriers to perform their duty of Lawful Interception
This is not a new security hole. Carriers can do this today and transparently MITM all current HTTPS traffic: no new risk is present.
* get an alert when going to e.g. www.google.com as the carrier tries to hijack the session with a fake certificate.
* the carrier have their own versions of libraries/browsers/etc. installed on the phone that disables certificate checks/alerts that would pop up when they hijack a session.
* the carrier have actually gotten hold of a certificate for www.google.com - which I'm sure is doable, but harder, and is thus able to perform a successful mitm attack.
With this approach, the carrier just needs to generate their own certificate, install it on the phone they sell, and can proxy any service they want without user alerts. A significant lower entry bar.
Earlier quoted context omitted.
That's not true, your browser still handles caching just fine. More bandwidth trumps caching anyway, and caching forward proxies will be a thing of the past.
Heh, bandwidth can help, but caching helps primarily with latency.
I particularly like how the Privacy section is completely blank.
Wasn't this already discussed on Hacker News, in quite some detail, yesterday? And wasn't the big revelation that this only applied to traffic that was not CA verified and thereby was inherently man-in-the-middle-attackable anyway (as the actually-secure https connections are marked in a way where this feature does not apply), making this a misunderstanding?
I thought the whole point of HTTP2.0 was to make traffic encrypted by default, and not let bit vulnerability holes in the protocol like this. Saying "it just makes it as before" doesn't make me feel better. Why are we moving to HTTP2.0 otherwise? For a 5 percent increase in speed? The big selling point of HTTP2.0 from my perspective was the "always-on encryption".
Some context: http://lauren.vortex.com/archive/001076.html "What they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping."
As discussed yesterday, this is not a new MITM vulnerability. To make this work you need to establish a TLS connection to the proxy which is verified in the usual certificate authority way. Note that the standard says that user agents that discover they're talking to a trusted proxy should obtain user consent to talk to that proxy. Any situation in which someone can force your machine to trust one of these proxies is…
I don't really care to argue this point so I'll just explain why I find this extremely problematic. What percentage of browser users have any concept of how TLS works? This an exceedingly low number. You're essentially creating a dragnet to capture and decrypt the contents of transfers for a huge number of people who likely have no idea that they're volunteering their (sensitive) information. Browser users are not TL…
Wasn't this already discussed on Hacker News, in quite some detail, yesterday? And wasn't the big revelation that this only applied to traffic that was not CA verified and thereby was inherently man-in-the-middle-attackable anyway (as the actually-secure https connections are marked in a way where this feature does not apply), making this a misunderstanding?
Earlier quoted context omitted.
This is not a new security hole. Carriers can do this today and transparently MITM all current HTTPS traffic: no new risk is present.
Sure it is, the old way you either * get an alert when going to e.g. www.google.com as the carrier tries to hijack the session with a fake certificate. * the carrier have their own versions of libraries/browsers/etc. installed on the phone that disables certificate checks/alerts that would pop up when they hijack a session. * the carrier have actually gotten hold of a certificate for www.google.com - which I'm sure i…
This is simple on the client and avoids any security warnings. It's supported in quite a few firewalls and even squid, so it would be very easy for a carrier to roll out tomorrow if they needed to.