From 97c56f64a86d244a86cfa38d07896dcbc0a3f8db Mon Sep 17 00:00:00 2001 From: SoniEx2 Date: Wed, 20 Feb 2019 11:15:04 -0300 Subject: [PATCH] Clarify Transparent Proxies --- mhttp.md | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/mhttp.md b/mhttp.md index 04be0de..bdd47ca 100644 --- a/mhttp.md +++ b/mhttp.md @@ -126,21 +126,25 @@ The CDN must then repeat the exact same request it was given, as in plain HTTP/1 specify how to identify the client to the server] The server may then choose to send the CDN a response. However, the response has some key differences from HTTP/1.1. -First, the response starts with the server's certificate. +First, the response starts with the server's certificate. -Second, the response must contain the cache control headers: +Second, the response must contain the server's domain name and the resource path. We don't rely on +the server certificate's domain name because it may be valid for multiple domain names. + +Third, the response must contain the cache control headers: - `Expires` - \[TBD] -It should contain additional cache control headers for use by the CDN and client. +It should also contain additional cache control headers for use by the CDN and client. -Third, the response (headers and body) must be signed by the provided certificate's key (server's -private key). The certificate itself is not included in this signature. +Fourth, the response (domain, path, headers and body) must be signed by the provided certificate's +key (server's private key). The certificate itself is not included in this signature. -If the CDN provides an expired response to the client, as defined by the `Expires` header, the -client must warn the user and discard the response. To account for network latency, the CDN may -choose to expire the response a few seconds or a few minutes before the true expiry date. +If the CDN provides an expired response to the client, as defined by the `Expires` header, or a +response for another domain or resource path, the client must warn the user and discard the +response. To account for network latency, the CDN may choose to expire the response a few seconds +or a few minutes before the true expiry date. If the server chooses not to send the CDN a response, it can do so in the next scenario. @@ -159,3 +163,11 @@ connection closed, which could be caused by another network factor not involving unnecessarily increase server load as well as reducing the reliability of the backwards compatibility mechanisms, or it'd involve a reverse TCP connection and we already know how that went for FTP.) + +## Use by ISPs - transparent proxies + +The CDN CA store is separate from the main CA store, and can only be used to sign CDN certs or +other CDN CA certs. This means it's fairly safe to put arbitrary certs in it. ISPs may use this +to provide transparent HTTPS proxies, in which case they act like a CDN as defined above, except +they do not send their cert upstream, instead relying on their capabilities as an ISP and using +the client's real IP address for the request.