Scott Helme

Browsers stopped showing the banner a couple of years ago[1-3], around the time of the Ian Carroll’s Stripe, Inc. of Kentucky demonstration[4]; maybe that was it?

It caused a great outcry from CAs, and I would’ve normally been against a single-sided, mostly Google-driven change like this, but the discussion[5] shows, at least as I read it, that CAs are unwilling to clearly communicate that the EV “green bar” does not imply “trustworthy”, it just upgrades “you have been securely connected to satan.com”, an authenticated DNS name, to “you have been securely connected to Satan LLC”, an authenticated legal-entity name.

And as Stripe, Inc., of Kentucky shows, it’s not clear this is an upgrade at all, because while the rules for domain uniqueness in the DNS are relatively (barring IDNA) straightforward and well-known, the rules for uniqueness for names of legal entities are complex and dependent on jurisdiction to such an extent that neither users nor even CAs can be reasonably expected to follow them all. (I think one discussion on the CA/Browser Forum list mentioned that—forget state-scoped legal names in the US Stripe case—Germany has township-scoped legal names, so jurisdictionOfIncorporation would literally have to record, and UAs to show, the address of a specific town hall in Germany. Sure you know which one it should be?) Even today you will find CA websites[6-8] proudly proclaiming “customers think the EV green bar means trustworthy” (and, presumably, if they don’t, you…

>You're forgetting that they had a charge for revocation, which was also automated.

I did not forget that, I was just talking about the authentication and certificate issuance side. But though it didn't fall under the umbrella of authentication it is something that actually cost real money at that point. You misunderstood the situation and how revocation functioned in a way that's extremely important (since it's finally getting fixed but the improvements could use more widespread deployment). The original certificate revocation mechanisms, CRL and OCSP, are and always have been completely broken in terms of fundamental scaling and failure modes. Scott Helme just did an excellent summary on the situation and upcoming developments [1] which I strongly encourage you to read, but in essence due to the way they work seriously offering CRL/OCSP (as in, in a way that won't instantly die when someone breaths on it hard) services and adding certs to them requires significant distributed infrastructure, which has not always been cheap. They were bad approaches even with that though due to other practical failure modes that were beyond a CA's control anyway. Both stink to the point that many (most? all?) operating systems/applications/browsers just soft fail by default or even ignore them entirely. "Revocation" for the wider web has largely been a mirage.

StartCom did in fact have an explainer about this at one point, and their position was reasonable. Other CAs hid the cost in large…

I have been trying to explain the importance of HTTP headers to some younger/junior devs I am working with. I have noticed that headers are often considered to be 'too technical' or even 'old tech'.

I'm going to recommend them to read this, but I do think I need to explain a couple of things that the article is not clear about:

- Be sure that you understand the concept of HSTS! Simply copy/pasting the example from this article will completely break subdomains that are not HTTPS enabled and preloading will break it permanently. I wish the authors made that more clear. Don't use includesubdomains and preload unless you know what you are doing. Scott Helme also did a great article about this [0].

- CSP can be really hard to set up. For instance: if you include google analytics, you need to set a script-src and a img-src. The article does a good job of explaining you should use CSP monitoring (I recommend sentry), but it doesn't explain how deceptive it can be. You'll get tons of reports of CSP exceptions caused by browsers plugins that attempt to inject CSS or JS. You must learn to distinguish which errors you can fix, and which are out of your control.

- Modern popular frontend frameworks will be broken by CSP as they rely heavily on injecting CSS (a concept known as JSS or 'styled components'). As these techniques are often adopted by less experienced devs, you'll see many 'solutions' on StackOverflow and Github that you should set unsafe-inline in your CSP. This is bad…

I agree that RansomPKP itself isn't that big a real-world concern (which was part of my point), but it did motivate the first wide discussions that I'd seen questioning whether HPKP should exist.

The linked Qualys blog post / HN thread was shortly after our talk, which (along with our conversation with Scott Helme around that time) led to Scott's post "Using security features to do bad things"[1]. RansomPKP and related follow-ups are directly highlighted by Scott's recent post "I'm giving up on HPKP"[2] in which he announced his decision to remove HPKP from the Security Headers tool[3], and Scott himself is cited in this post by Chris Palmer.

Note that I'm not suggesting that Scott himself is responsible for this, or that anything he's said has been in bad faith. My point is simply that my talk was one part of the chain of events that started the ball rolling on this conversation.

I'm also not saying that RansomPKP / hostile pinning is the most important reason that people have for not liking HPKP — in this case Chris lists it as only one of three motivations. Clearly, the usability issues with its implementation have been a much bigger problem, which is what I would like to see serious attempts to improve on before throwing out all the work that's been done up until now.

---

Edit: re: sleevi edit: the tweet you linked doesn't say anything about regretting the concept of TLS key pinning entirely, just that it's done as a header. I'll admit it's ambiguous, but that…

Thank you for fleshing out the comparison between HSTS and encrypted email. I just have a couple of points to add.

1. For the avoidance of doubt, there is a proposed "HSTS for email", but it doesn't provide end-to-end encryption (so it's not particularly relevant here). The technology I'm talking about is MTA-STS,[0] as described in RFC 8461, which you probably already know about, but it might be new to other people.

I'm not sure how different the dynamics are between the web and email, though. Surely there are more operators of web servers than email servers? Also, over 90% of the email client market is attributable to Google, Microsoft, Apple, and Yahoo! collectively.[1] That doesn't seem very different to the situation with browsers.

2. I think it's worth highlighting that if a user is shifted from HTTPS to HTTP, that may mean that their password (or session cookie) is being sent unencrypted to/through an attacker. Once the attacker has this, they can access all the details of a user's account, which, in the case of webmail or a forum, includes all previous messages and grants them the ability to send new messages as that user.

That seems like a worse failure mode than just losing the privacy of a single message, and I think people are just as likely to die if you leak information about them over insecure email as over insecure HTTP. In both cases the threat model would assume that the adversary is recording everything, all the time.

[0]…

> But that's why I think the role of the CA should change so that the signatures actually gives some form of tangible trust that people can relate to.

But this is a tough thing to do. The best way to do this would be to introduce a new type of certificate, that can be stapled onto web requests maybe (eg. a signature at the end of the http body), that isn't controlled or authenticated by any existing system. This would allow clients to implement this system based on merit and based on whether or not it solves problems and concerns these clients have. For example, if it's literally just EV certificate boogaloo[0], then Chrome can choose to not implement it.

But when you try to force it onto people in the form of QWACs or what have you, and have it government-mandated, this goes against the theory of 'open source' standards being adopted because they're a good standard, and instead degrades user experience by forcing client vendors to implement them regardless of their flaws.

0: https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-ca/