Hacker News Reader

Comment by terom | Hacker News Reader

Do we get points for speculation based on these hints?

My guess would be that some major public CDN (Cloudflare etc) will let the attacker deploy their TLS-SNI challenge certs, and thus validate for other victim domains using the same CDN service.

EDIT: Main reasoning being that I can't think why it wouldn't work - apart from the TLS-SNI challenge certs somehow being considered invalid by the CDN provider and refusing to deploy them, but I find it hard to trust that happening with 100% certainty.

View on HN

Too late for me to edit this comment anymore, but in order to avoid spreading any false rumors, I'd like to explicitly state that I have no reason at all to believe that Cloudflare in particular would be affected by this, and I do not wish to imply that customers of cloudflare would be at risk from this vulnerability. That was just simply the first example of a public CDN deploying user-provided certificates that came to mind.

The big public CDNs would certainly have the most impact from this, but also the most likely to get their cert validation right. I'd reckon that the risk is probably in the larger number of smaller providers that have their own home-grown cert automation for deploying user-provided certificates.

In fact, it seems a little odd to me to hear LE talking about collecting a blacklist of vulnerable providers to prevent from using TLS-SNI... TBH, how can you tell what providers will be affected... should that be a whitelist instead?

I haven't seen anything on our internal security mailing lists about this. If it does somehow involve Cloudflare I'd be happy to receive a report directly via HackerOne (https://hackerone.com/cloudflare). Happy to assist.

I don't think CF is affected because TLS-SNI-01 has never worked for cf-proxied sites (I've tried). CF doesn't allow clients to use invalid certificates for domains they don't own, which is key for the tls-sni-01 process.

Sorry, I just chose cloudflare as a random example when speculating, I don't have any information about what specific providers this would affect, and I'm not implying that cloudflare would be affected.

Seems like my guess was right, though!

No, need to apologize.

When you say "Seems like my guess was right, though!" are you saying that there is some way that Cloudflare is involved?

EDIT: I see (https://community.letsencrypt.org/t/2018-01-09-issue-with-tl...) now. I don't think LE has been in contact with us so don't think we're affected but happy to be told otherwise.

I would indeed like to explicitly apologize, because I regret mentioning "cloudflare etc" as an example. That's exactly the kind of bad speculation that leads to harmful rumors based on misunderstandings.

> When you say "Seems like my guess was right, though!" are you saying that there is some way that Cloudflare is involved?

No. It seems like I was right about the general nature of the vulnerability. It remains to be seen what providers are affected.

That being said, at this point, I'd personally be happier seeing a list of providers NOT affected, rather than a list of affected providers... It's probably also in "major public CDN provider's" interest to demonstrate that their user cert validation processes would have prevented this attack, and their customers were not at risk before LE pulled the plug...

One of the requirements listed [1] as being needed for exposure to this for the provider is:

Users have the ability to upload certificates for arbitrary names without proving domain control.

When you say you were right, are you saying Cloudflare allows that?

[1] https://community.letsencrypt.org/t/2018-01-09-issue-with-tl...

I suppose it's possible in theory but I'm not sure if Cloudflare would perform other checks.

It's certainly the case with the Business and above accounts you can upload custom certificates but I don't have one of those accounts to check if further validation is made regarding domain control.

If they didn't it would seem on the face of it that both the conditions in the article* are met.

* >Many users are hosted on the same IP address

>Users have the ability to upload certificates for arbitrary names without proving domain control.

Indeed, I just tried a CDN provider that I recalled allowed custom SNI certs, and was able to deploy a ".acme.invalid" certificate to the global network. It's a real issue for public CDNs, but we can rejoice that Cloudflare and (I assume) Cloudfront are not affected, at least.

As long as we're tossing hats into the ring...

I don't think so - _maybe_ a MITM that would affect all TLS-SNI, but I don't think the model you propose exists (I'm a bit dated on that tho), and if it did, I think it would be 'wider' than the CDN's.

"It's an interaction between the protocol and provider services" -- I will wager it's that some providers don't validate the CA or RootCA authentication method/mechinism, and so would accept a SHA1 or MD5 where a SHA256 or ROT13 would be preferred. (Think JWK/JWS 'null' issues)

I assume standard rules apply - one internet point to the winner, in the event of a draw, fisticuffs at dawn facing opposite coasts until we're both bored with it?

"and so would accept a SHA1 or MD5 where a SHA256 or ROT13 would be preferred"

I don't think ROT13 means what you think it means.

I don't think Cloudflare/CDNs are affected since TLS-SNI-01 doesn't work for cf-proxied hosts. (I've tried.)

Reading the detailed report[1], it sounds like tls-sni-01 requires being able to serve an invalid certificate temporarily. As far as I know, CDNs won't let you do that. This problem is probably more related to shared webhosts (which is hinted at in the detailed report).

Reply on news.ycombinator.com