On Thu, Jul 30, 2020 at 7:58 AM Töma Gavrichenkov <[email protected]> wrote:
> Peace, > > On Thu, Jul 30, 2020, 4:39 PM Salz, Rich <[email protected]> wrote: > >> We have a product, site shield, that customers can use to limit the IP >> addresses of who can reach their origin server. Everyone else is blocked. >> Some use that to make sure that *only* Akamai servers will talk to them, >> and that everything else goes through us. Is that a proxy? How is it >> different from terminating TLS in the DMZ and sending it inside? How does >> the client know? >> > > I don't know, and this *is* the problem. > The point is, whatever server/device has a publicly trusted certificate for a domain name is authoritative for that domain. That server can get the content it serves (whether dynamic or static) from any source. TLS only provides guarantees about the connection between the client and server. It says nothing about whether the content served was obtained or generated in some secure manner. That content could be sourced locally, it could be aggregated or generated from other servers via connections over other secure protocols that aren't TLS, it could even come from some insecure source like transmitting an audio stream collected from an antenna connected to the server. I may be connecting to the service from a network I don't trust with my > information, and I have (almost) no tool to tell me whether it is served > from a different network via a secure connection *or* it is served from an > edge node deployed *in the same network I don't trust*, that node being > connected to the service through an unauthenticated channel. > If you're connecting to a service, at some point you have to trust that the service operator is running it in a reasonable way. TLS only tells you that your connection to the server is secure - it tells you nothing about the provenance of the content served, and even if such a mechanism exists (I am not advocating that such a thing should exist), the server can always claim that it generated it instead of that it got it from somewhere else. > > Like in [1], where this unauthenticated channel is being marketed as > "end-to-end encryption". This approach basically defies all the end-to-end > encryption efforts. > > When it comes to static content, with all the JS security implemented, > this is mostly fine. Dynamic content is a very different story. > > [1] > https://support.cloudflare.com/hc/en-us/articles/200170416-End-to-end-HTTPS-with-Cloudflare-Part-3-SSL-options > > -- > Töma > >> _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
