Re: Client-Cert Header draft

easy: the client can only punch through the CDN with a bearer token.

On 2020-04-20 8:44 p.m., Lucas Pardue wrote:
>
> On Tue, Apr 21, 2020 at 12:10 AM Soni L. <fakedme+http@gmail.com 
> <mailto:fakedme%2Bhttp@gmail.com>> wrote:
>
>     the CDN would have to consent to the client interacting with the
>     server, thus not affecting performance, scale and security, and
>     it'd only be for non-CDN-safe resources such as private content
>     anyway.
>
> The CDN provides those features for the origin. That's the purpose. 
> Allowing clients direct access to the origin means that the origin has 
> to duplicate the functions a CDN provides or not have them at all. I 
> don't think that's what people are asking for, particularly people 
> that are happy to delegate their TLS termination as happens today. 
> What I am aware of is a desire to understand a property of the TLS 
> connection, just like wanting to see the negotiated ALPN ID, 
> ciphersuite, client IP address etc. for the purposes of auditing, 
> analysis or some application logic.
>
> Plus, what you're describing requires a client that is savvy enough to 
> understand content and the distribution architecture of deployments in 
> order to decide when to punch through the CDN. That becomes fragile 
> very quickly.
>