[concept question] proxied host vs. 3rd party content

[ghost]

Not sure whether I fully grasp the concept of the extention and thus the question. To my humble understanding there could be the following scenarios, and please correct where I am wrong:

1. website hosted on corporate MitM with proxied TLS (certificate)
2. website hosted outside corporate MitM but with proxied TLS (certificate) by deploying corporate MitM security features
3. website hosted outside corporate MitM without proxied (true) TLS (certificate) but fetching content (CDN) from third party corporate MitM

Does this extention make a distinction between the 3, considering the 3rd option may not constitute a MitM, at least to my understanding. Or is there no such distinction and either way such sitea are flagged regardless as MitM?

[ghost]

Sure, waiting for @nym-zone.

For the 3rd option I would reckon that any 3rd part content would be fetched by the browser through the initial non-proxied (true) TLS connection, but then I my understanding might be wrong

[nym-zone]

To clear up some confusion, first I must clarify the term “MITM”.

Here is an ordinary TLS session, with everything working properly:

  {   TLS Encrypted with Session Key X   }
You--------------------------------------example.com

A “Man-in-the-Middle” (MITM) interposes himself and forms two different encryption sessions: One to you, and one to example.com. He passes the data back and forth, with or without modification; meanwhile, he can read all of it:

   { Session Key X }    { Session Key Y }
You----------------<MITM>---------------example.com

There exist ready-made hacker tools such as sslstrip which will do that automatically. Some people run sslstrip on open wifi for lulz and profit; and Tor Project needs to keep an eye out and assign BadExit flags to exit nodes which pull that junk. But such connections are typically not authenticated with the server’s certificate. This is exactly why you should never ignore or click through certificate validation errors in your browser: A MITM with a bogus certificate can pretend to be somebody else, but can’t prove it! The whole purpose of the (badly broken for other reasons) certificate system is to prevent MITM attacks.

There are some ignorant people who set up TLS with self-signed certificates, claiming that any encryption is none at all. This is not true. When you have an encrypted TLS session, you know that you have a secure connection to somebody. But, who is that somebody? Is it the server with which you believe you are communicating? Or is it a MITM, pretending to be that server?

Certificates do stop amateur MITM attacks. But Cloudflare are the MITM professionals; they interpose themselves into a connection using a proper, “legitimate” certificate which certifies that they are example.com. Thus, there is no browser warning:

   { Session Key X }          { Session Key Y }
You----------------<Cloudflare>---------------example.com
  { Authenticated }
  { with cert for }
  { example.com!  }

Now, examine one of Cloudflare’s own diagrams of how their system works. Look carefully to the boxes which say “Session key”, because that’s what you care about as a user: Who has the session key.

For their enterprise customers, Cloudflare also has an option they call “Keyless SSL” in marketspeak. But that name is a lie, or rather, a half-truth. With “Keyless SSL”, Cloudflare does not get the server’s long-term asymmetric private key; the endpoint holds the private key, and provides in real time the digital signatures “authenticating” Cloudflare’s impersonation of them. However, Cloudflare still gets each and every session key—and that’s the part used for actual encryption and decryption of your session!

Look again at who holds the “Session key”:

---

To better understand this, think in terms of connections and endpoints. TLS by design provides end-to-end encryption of a connection between one endpoint (you) and another endpoint (example.com). But now, there are literally millions of websites where the encryption is “endpoint-to-Cloudflare-to-endpoint”.

Transport Layer Security (TLS) is a pseudo-transport-layer protocol (although technically, it operates on the application layer of the network stack—below the actual application). Whether you are connecting to a “first-party” or “third-party” server is a higher-level application-layer matter, irrelevant to TLS. If example.org is not on Cloudflare, but loads third-party content from content.example.net behind Cloudflare, then your browser is obviously establishing multiple different TLS sessions on multiple connections with multiple endpoints: The session connected to example.org; and the session connected to content.example.net, which is really your private encrypted connection to Cloudflare.

This means that Cloudflare will be able to see what first-party site and pages you are visiting, via the HTTP Referer: header, etc. If the “first-party” site makes your browser send sensitive information via GET parameters or other means to content.example.net. Also, Cloudflare has the power to modify anything you send to or receiver from content.example.net—including Javascript.

“Mixed content” with plain-HTTP embeds in an HTTPS site is bad for the same reasons; and it thus provides here an instructive analogy. In both cases, you are relying on a “secure” connection to the “first-party” site while that security can be partly or totally compromised by the unsecure “third-party” content.

I hope this answers your questions.