3 ms·

The difference is Cloudflare is perfectly content to forward the backbone traffic unencrypted over public internet. In fact, they advertise this malfeature. An

by deno 10y ago

The difference is Cloudflare is perfectly content to forward the backbone traffic unencrypted over public internet. In fact, they advertise this malfeature. Anyway as I stated before the bar for calling it MITM is simply the intended behaviour of the protocol (HTTPS). Which is very much violated. Whatever negative or otherwise connotations the term has doesn’t change the fact that it is technically correct. Really all I’m arguing here. There’s plenty of better reasons to hate Cloudflare anyway.

snowwrestler 10y ago
> The difference is Cloudflare is perfectly content to forward the backbone traffic unencrypted over public internet. In fact, they advertise this malfeature. This puts you into segment #3 in my list above. And I agree with you: the CloudFlare "flexible" SSL that sends last-leg traffic in the clear over the open Internet is a terrible idea. But while that terrible idea opens up the potential for MITM attacks, it is not, itself, a MITM because the website owner has authorized CloudFlare to do that. And of course there are levels of CloudFlare service that do properly re-encrypt the last leg to the origin. > Anyway as I stated before the bar for calling it MITM is simply the intended behaviour of the protocol (HTTPS). Which is very much violated. Whatever negative or otherwise connotations the term has doesn’t change the fact that it is technically correct. Really all I’m arguing here. You need to understand that you are not correct on the technicality. None of the protocols used in HTTPS are violated by decrypting or encrypting a session using the proper keys, even if it happens several times along the way. Not every bad idea is a technical protocol violation. Not every bad idea is equivalent to an attack. Abusing the term "MITM" makes it harder to talk with specificity about actual MITM risks. If CloudFlare itself is always a "MITM", then how do we explain why their Flexible SSL service is riskier than their Full/Strict SSL service? The former makes it easier for some mid-point to impersonate or alter the origin website. But now what do we call that? An "actual" MITM? A "real" MITM? Let's just leave MITM to mean an attack. It's a lot clearer that way.
- deno 10y ago
  I think not having explicit support for proxies in HTTPs is a fundamental design mistake, so seeing how you’re keen on putting me in a camp, I’d like to volunteer for that one. The term MITM is appropriate because it shows the whole thing is a charade. If handing off secret keys to third parties with absolutely no transparency past the first hop is the standard modus operandi then the entire protocol is a big fat joke. The only purpose, as far as I can tell, is to further centralize the web. First it was ICANN with domain registration, now it’s certificate authorities. Soon you’ll need a special permission from government to host a website. HTTP(s) needs to be burned to the ground and replaced with something better. Liberty and freedom are at stake. How’s that for FUD.

by deno 10y ago

snowwrestler 10y ago

> The difference is Cloudflare is perfectly content to forward the backbone traffic unencrypted over public internet. In fact, they advertise this malfeature. This puts you into segment #3 in my list above. And I agree with you: the CloudFlare "flexible" SSL that sends last-leg traffic in the clear over the open Internet is a terrible idea. But while that terrible idea opens up the potential for MITM attacks, it is not, itself, a MITM because the website owner has authorized CloudFlare to do that. And of course there are levels of CloudFlare service that do properly re-encrypt the last leg to the origin. > Anyway as I stated before the bar for calling it MITM is simply the intended behaviour of the protocol (HTTPS). Which is very much violated. Whatever negative or otherwise connotations the term has doesn’t change the fact that it is technically correct. Really all I’m arguing here. You need to understand that you are not correct on the technicality. None of the protocols used in HTTPS are violated by decrypting or encrypting a session using the proper keys, even if it happens several times along the way. Not every bad idea is a technical protocol violation. Not every bad idea is equivalent to an attack. Abusing the term "MITM" makes it harder to talk with specificity about actual MITM risks. If CloudFlare itself is always a "MITM", then how do we explain why their Flexible SSL service is riskier than their Full/Strict SSL service? The former makes it easier for some mid-point to impersonate or alter the origin website. But now what do we call that? An "actual" MITM? A "real" MITM? Let's just leave MITM to mean an attack. It's a lot clearer that way.

deno 10y ago
I think not having explicit support for proxies in HTTPs is a fundamental design mistake, so seeing how you’re keen on putting me in a camp, I’d like to volunteer for that one. The term MITM is appropriate because it shows the whole thing is a charade. If handing off secret keys to third parties with absolutely no transparency past the first hop is the standard modus operandi then the entire protocol is a big fat joke. The only purpose, as far as I can tell, is to further centralize the web. First it was ICANN with domain registration, now it’s certificate authorities. Soon you’ll need a special permission from government to host a website. HTTP(s) needs to be burned to the ground and replaced with something better. Liberty and freedom are at stake. How’s that for FUD.