Do browsers offer any kind of certificate pinning for arbitrary sites? It seems strange that this is a default feature in ssh but not https.
As for certificate pinning, some browser do e.g. I'm pretty sure that Chrome has certificate pinning for at least some google services.
Also HSTS with HPKP (HTTP Public Key Pinning) can be used to further increase the resilience of HTTPS services against MITM attacks (both local and network adjacent).
That said if an adversary is capable of doing even basic network adjacent attacks they can still do a redirection via DNS which is why it's important to not have HTTP support only or have a fully enforced redirect which will likely to get the target stuck on a redirect loop.
For DNS redirection attacks all they need to do is to be faster than the DNS responder or poison the local DNS cache.
How does it increase the attack surface?
An additional library e.g. OpenSSL (heartbleed), HTTPS crypto attacks (e.g. beast), an additional business processes that can be compromised both from the CA/issuers standpoint and from the website admin POV, and an additional resource to protect and securely distribute(private keys).
All and all you now have a greater attack surface as an entity, it doesn't mean that you shouldn't use HTTPS, but as far as risk management goes things change.
You as a user aren't affected unless you erroneously implicitly trust encrypted traffic considerably more than unencrypted one.
HTTPS also doesn't stops MITM attacks from non-state actors. People trust untrusted certificates, the certificate supply chain can be easily poisoned as time and time again we've seen that everyone and their mother managed to make CA's issue certificates under false pretences or otherwise erroneously and DNS / packet racing attacks still can work unless the website implements HTTPS strictly.
If these things are attacked, your security is not worse than HTTP.
HPKP and HSTS fix the problems you've described.
And no if these things are attacked, at least as far as the library goes things aren't no worse than HTTP because it's a completely different threat scenario which can actually compromise the website/host rather than just poison a single client session.
For example https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6309 which poentially allows for RCE if you use a vulnerable version of OpenSSL exposes your website to completely different threats than if you would only use HTTP, not worse, not better just an additional and quite different threat.
This is why when you implement HTTPS or any other additional service you need to understand how it changes the attack surface of your service from both a technical and operational perspective.
Encrypted traffic cannot easily be snooped by a man in the middle. It's arguably the entire point of HTTPS. With HTTP, I have no hints, much less guarantees, that the website I'm talking to is actually who it says it is. There is no mechanism whatsoever to establish trust, and my traffic is up for easy analysis.
HTTPS may not fix that problem completely (CAs are the biggest weak point) but it does wonders to solve MITM type snooping of my traffic (a boon to me, as a user) and has the mechanisms in place for me to inspect the certificate chain if I need to be sure of the server I'm communicating with. I agree with a great many of your criticisms against the standard and feel like CAs in particular need to be re-thought, but don't dismiss the entire technology because you assume that the "user" is too stupid to know how to use it.
Neither do I, which is why I never made any such claims. Encrypted traffic even in ideal circumstances can and is equally untrustworthy especially under certain threat models ;)
Technically yes, but in practice no.
Sure, you can't MITM a running HTTPS connection. But in HTTPS without HSTS it's easy to transparently stop users getting to HTTPS in the first place, and unless they reliably check the URL bar and verify they have a cert and exactly the right domain then that gives you almost as much damage as a MITM, super easily. We can all agree that users are terrible at constant vigilance, and attacks like this are surprisingly practical.
MITMing HTTPS sites that you browse to directly:
* You type "site-without-hsts.com" into your URL bar. * Your browser makes an initial plain HTTP request to site-without-hsts.com, and instead of getting an HTTPS redirect I MITM you, and just proxy the plain HTTP to the real HTTPS-only site. * I see and/or change everything on your 'secure' site. Game over.
301's sort-of protect you here, but a) you don't want to user security to depend on browser caching, b) that doesn't work for the first load of a site, and c) if I'm running a wifi hotspot, it's reasonably easy to get people to clear their caches before you let them log in, since it's a fairly standard technical fix now.
Alternatively, MITMing HTTPS sites reached through some other page:
* You load any plain HTTP page while browsing, on route to a secure site. * I MITM the plain HTTP, replace 'https' with 'http' in all links in the page, and MITM every subsequent page as above, proxying through to real HTTPS sites where required. * I see and/or change everything on your 'secure' site. Game over.
Functionally, if you have any insecure step in your browser session, I can stop you reaching the secure step, and if you're not carefully paying attention you won't notice. Sometimes, sure, you might, but most of the time you won't, and 99.9999% of the time your average computer user won't ever check. HTTPS coverage is getting better, but I suspect the vast majority of browsing sessions still go through an insecure step somewhere along the pipeline.
HTTPS doesn't fully protect your users from MITMs. Add HSTS though (so the browser will refuse to ever make a plain HTTP request to your HTTPS site), and you get substantially closer.
I agree with you.
We'll also continue to look at key pinning, although that's also some time away due to the increased burden of certificate management (essentially we'd need to have at least two valid certificates, one kept offline, at all times to mitigate against another heartbleed or similar attack).
It just takes the user clicking through some scary prompts, which they'll do if they're unconcerned or desperate enough to get to whatever website they're trying to reach.
This is actually an enormous percentage of users. Google's research on real live Chrome users suggests up to 70% of those big full page HTTPS security warnings are being clicked through: http://static.googleusercontent.com/media/research.google.co...
If you turn on HSTS, you actually stop this completely. Chrome and Firefox will not allow you to click through the prompt for an HSTS site - you're just blocked.
At some stage we hope to list theguardian.com in the preloaded HSTS list that ships with the browsers, but unfortunately this is some time away as there are a handful of other subdomains on theguardian.com that are not yet HTTPS (you can only preload a domain along with all of its subdomains).
Ivan puts it better than me: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-ke...