Hacker News new | ask | show | jobs
by nothrabannosir 3669 days ago
Cloudflare wouldn't be e2e in the sense that the SSL would terminate at Cloudflare, which would then open a new SSL connection to GitHub. Everything would be properly encrypted, but Cloudflare would indeed have access to the plaintext (i.e. it isn't e2e).
1 comments
kevincox 3669 days ago
This isn't necessarily true. For example when you want to direct example.com to example.github.io Akami (serving for Github) will serve the certificate for *.github.io. Because this certificate is obviously invalid for the request you have to disable certificate validation in Cloudflare.

So client to Cloudflare is well protected but Cloudflare to Akami is vulnerable to MITM.

(And according to this new news Akami to Github is properly protected now)

link
nothrabannosir 3669 days ago
You're right. And it's a shame, because they're so close.

CloudFlare appears to support this, but they actually don't. What they disingenuously call "Full SSL" is just "there has to be any SSL certificate, but we don't event check with a CA." It's completely MITM sensitive.

The only level higher than that is "Full SSL (strict)", which immediately requires a cert valid for the request host available on the origin, as you mention.

Ideally, they'd have an option in between: "Fuller SSL" (or just stop lying about their current options). Require a valid SSL certificate on the origin, for the origin, not for the request host. This way Cloudflare would ask Akamai for the *.github.io cert, and the browser would ask CloudFlare for the custom domain cert.

Yay, tears.

link