Re: Client-Cert Header draft

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.

On 2020-04-20 7:59 p.m., Lucas Pardue wrote:
> Hey,
>
> On Mon, Apr 20, 2020 at 11:28 PM Soni L. <fakedme+http@gmail.com 
> <mailto:fakedme%2Bhttp@gmail.com>> wrote:
>
>     you'd still have a reverse proxy that's terminating TLS and
>     talking HTTP with the backend.
>
>     you'd just also have a way for that reverse proxy to pass a raw
>     TLS stream through, so the client can talk HTTPS with the backend
>     when needed. it'd still be in the middle of the connection and
>     fully capable of terminating it if it detects potentially abusive
>     behaviour.
>
>     On 2020-04-20 7:20 p.m., Brian Campbell wrote:
>>     That's really quite different than the intended scope of the
>>     draft, which was/is a reverse proxy that's terminating TLS (from
>>     the client's perspective anyway) and taking HTTP with the backend.
>>
> I'm with Brian on this; CDN/reverse proxies provide an offload of HTTP 
> processing from the origin that brings advantages such as performance, 
> scale, and security. Although it could be technically possible to pass 
> through TLS (pretty much covered by CONNECT already), the concept 
> negates the value proposition of a CDN architecture. I think Brian's 
> document has more value with the scope that he has described.
>
> Cheers
> Lucas
>
>