4 ms·

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

by terom 9y ago

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.

abofh 9y ago
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?
- foota 9y ago
  "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.
PuffinBlue 9y ago
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.
jgrahamc 9y ago
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 https://hackerone.com/cloudflare). Happy to assist.
- terom 9y ago
  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!
  - jgrahamc 9y ago
    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-tls-sni-01-and-shared-hosting-infrastructure/49996 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.
    - terom 9y ago
      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...
  - puddums 9y ago
terom 9y ago
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?
regecks 9y ago
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.
discreditable 9y ago
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).

by terom 9y ago

abofh 9y ago

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?

foota 9y ago
"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.

PuffinBlue 9y ago

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.

jgrahamc 9y ago

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 https://hackerone.com/cloudflare). Happy to assist.

terom 9y ago
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!
- jgrahamc 9y ago
  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-tls-sni-01-and-shared-hosting-infrastructure/49996 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.
  - terom 9y ago
    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...
- puddums 9y ago

terom 9y ago

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?

regecks 9y ago

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.

discreditable 9y ago

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).