Comment by mieko | Hacker News Reader

Comment by mieko | Hacker News Reader

Here's an issue not mentioned in the article, which gives me the half-baked feeling about HPKP:

Thought experiment: (just using companies I think HN will be familiar with, I'm not involved with these.)

1. You're Tumblr or Basecamp or Slack with thousands/millions of user.example.com user subdomains

2. You want to protect all of them with a root HPKP policy with includeSubdomains, because users will be bouncing between them, and with that many trust-on-first-use gaps, it'd be pointless otherwise.

3. And then you want status.example.com hosted at StatusPage, blog.example.com hosted at Medium, and someapp.example.com hosted via GitHub Pages with a CNAME. Assume there are long-lived links to all of these subdomain URLs.

You can even assume that the third parties implement HPKP, and that they'll never have a hiccup.

There's no way to make this work without either:

A) Removing includeSubdomains, and no longer catch a large amount of cases as users traverse your site, barely solving a problem anymore

B) Serving a concatenation of every third party pin, opening up gaps huge enough where suddenly every CA is now authorized again, not solving a problem at all.

C) Noticing something I haven't.

And note that there are security (not merely vanity) reasons for using subdomains instead of paths for hosting user-generated content. I don't think this is too crazy of a scenario.

That's fairly easy to fix by putting your users on user.fooapp.com and your corporate pages on *.foo.com, just like you're already (for a different reason) putting static resources on foo-static.com.

I think a plumbing-level security implementation detail should be a little less intrusive than having to move either the corporate domain or millions of user's addresses. I can't imagine Tumblr rolling out HPKP now with this workaround (though github did do the .com -> .io thing, so who knows).

The spec should've just included excludeSubDomains=

For security, especially at the plumbing-level, simplicity is a virtue.

This. It's already best practice because fooapp.com should be on the public suffix list (which allows Let's Encrypt to be used with subdomains, among other things).

There's still a decent size contingent of non-technical people that look at exampleapp.com the way I'd look at wellsfargo-online-banking.com. I don't blame them: subdomains imply authority.

While I'm sure there's more, github.io, herokuapp and GAE/Appspot are the only services I know of following this practice, and they cater to a developer-level technical audience with the assumption that they'll work out a better name.

i was wondering if this is more a problem with how third parties are handling SSL custom domains rather than HPKP. I would have thought SSL custom domains would have been you just upload a certificate/private key you want to use or you click a checkbox saying that you are happy to use letsencrypt. But I'm guessing for various reasons (no SNI support, etc) some of these companies are using a massive shared certificate.

also, if you are building a competing product with someone that is doing custom SSL domains it might be useful to check out if your competitor is using a shared cert because you can get a list of companies that are paying for the premium product :)

This is a really good point, and I feel like the two issues are intertwined. I think HPKP being heavily adopted as it's spec'ed now makes it even harder for third parties trying to do the Right Thing, and their customers from taking advantage of it.

Most of the problems I've seen with pushing HTTPS and the vulnerable CA problem forward really do break down at the "third party provider" boundary, which is a little surprising, because it's an amazingly common situation now, and has been for a while.

Reply on news.ycombinator.com