Archive

On Thu, Jul 30, 2020 at 7:58 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:

> Peace,
>
> On Thu, Jul 30, 2020, 4:39 PM Salz, Rich <rsalz@akamai.com> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

Re: [OPSEC] [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp