Further incentivizing the use of HTTPS everywhere, imo. It's such a cheap standard now. Correct me if I'm wrong, but I don't see any good reasons for a site to be running HTTP any longer, other than laziness.
I'll give it a shot. If you put up your site behind HTTPS you are breaking the web for older web clients. Many sites have already deprecated TLS v1.1 so even 10 year old devices may no longer be able to access the web. HTTPS is great but it has a cost.
> even 10 year old devices may no longer be able to access the web
I think you mean 10 year old software, which is a much smaller bucket than 10 year old devices. And if you're browsing the web with 10 year old software, you have much bigger problems including but not limited to committing security-suicide.
I found some old Macs belonging to a non-profit to be apparently useless (for their purposes) because you couldn't upgrade the system software enough to let a browser operate properly with secure sites. Sure, there's Linux, but they appeared to be useless as Macs.
Well the TLS change breaks software (FF 26) (2015) and affects android versions <= 19 (2014). Kind of a bummer if you have old smartphone. But I agree, it's a tiny bucket and it's best to upgrade when you can.
Only if you have a cert that the browser trusts for that domain. If a CA was found to be illicitly minting certs, browsers and operating systems would untrust them. All their certs would stop working. Their business would be ruined.
That's interesting. Can someone elaborate on this? My understanding is once the session is established, that's it. just encrypted traffic. How to inject something into ecrypted traffic?
Of course, to distinguish HTTP traffic from non-HTTP traffic and to intelligently insert the code snippet only where it won't disrupt e.g. API call response or a file download, some basic level of DPI is required.
The attacker needs to generate a new cert that the client trusts. This is easy on a corporate network where you can force users to trust a private CA. Unlikely to happen with a US ISP, but possible if someone hacks the CA (eg DigiNotar) or the CA hands out unconstrained certificates to someone who acts badly (eg CNNIC).
Speaking of which, is there a published list of Root CA fingerprints a specific version of OS or browser is supposed to have that I can compare to? In other words, how can one tell if their browser/OS is not compromised with undesirable Root CAs.
Mozilla and Microsoft publish their lists. Chrome uses the OS's root store. I've seen other open source software use Mozilla's list, but I've never seen a list of what software does that.
Technically, yes, but the only way I know possible is having direct access to the target device to force it to trust fake certs, and is usually used to unwrap encrypted traffic being sent from applications on your own devices. I don't know of a way for the ISP to do this, unless they conspire with a certificate authority. I'd like think this isn't happening.
Only if the victim trusts the attacker's certs, right?
That said, Comcast is big enough that it might be in cahoots with at least one less-than-scrupulous CA (or might even be a CA; I don't follow these sorts of things closely enough).
Mozilla would kick Comcast out of the root CA list pretty fast.
Finally, there is certificate transparency logs, you can set CT headers on your site to require the certificate to be in CT logs.
Then you can monitor if anyone's creates certificates for your domain. And updated clients can validate that certificates is in the CT logs.
HTTPS is pretty robust these days. There's still a few corner cases around SNI, but that only leaks what host your visiting, wouldn't allow injection -- and specs are slowly closing those holes too.
Is there a published list of Root CA fingerprints a specific version of OS or browser is supposed to have that I can compare to? In other words, how can one tell if their browser/OS is not compromised with undesirable Root CAs.
> That said, Comcast is big enough that it might be in cahoots with at least one less-than-scrupulous CA (or might even be a CA; I don't follow these sorts of things closely enough).
The moment that was discovered, the CA would stop being a trusted CA.
There's a lot more appetite these days for enforcing requirements on CAs, ever since CT started going down the road towards mandatory, and ever since misbehaving CAs started getting forced to implement it immediately. Intentionally MITMing TLS on the broader Internet the way this thread is talking about would be a fairly quick death sentence.
Also, given the existence of Let's Encrypt, there's much less reason to be using a paid CA, and planned migration to a new CA provider isn't too much to ask. There'd likely be some work within browsers to provide clear error messages, and sites would need some amount of time to migrate, but I think we're talking days-to-weeks before there's a warning banner on the sites and months at most before the CA is dead.
>but you'd have to get a pretty nice VPN to not impact your experience by 250ms/req.
Eh? I was thinking the opposite, that's such a ludicrous latency overhead that it would be trivial to go to any VPS provider even sort of nearby and spin up a $5 instance with Algo. The only concern normally for some of them is the super cheap simple managed instances often have data caps too (though some provides are bandwidth limits only), but in this use case even that doesn't matter because the limits are still higher than Comcast's regardless. There are datacenters in Denver, but even if you had to go all the way to SF and it's a worst case adding 1800 miles RTT that should still only be around 10-14ms or so right? The article seems a little silly to go on so much about a few kb of data out of tens of gigabytes or a TB or whatever Comcast's caps are, but 250ms is wild, even without all the other breakage.
Although I've always heard that if you're ever forced to go Comcast, the average HN type would be best off seeking a Comcast Business connection that has actual support and customers that use the internet fully.
Agreed. I used to run all my traffic through a VPN I ran, and found that the average latency was lower than routing it to the default gateway.
This was possible because my server was well connected and very low latency talking to Comcast, and also very low latency talking to the rest of the Internet via Level-3, Time Warner, QWest and InterNAP. Where directly routed traffic would run over the Comcast network most of the way across the country.
One problem with this approach is many streaming content providers identify known VPN egress points, consider them methods for subverting region-restrictions, and thus won't serve ANY data to you. Netflix does this w/ PIA (and probably others) for instance.
