SoniEx2
/
paste
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Clarify Transparent Proxies

This commit is contained in:
SoniEx2 2019-02-20 11:15:04 -03:00
parent 1d86c2dbc6
commit 97c56f64a8
1 changed files with 20 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
mhttp.md
View File

@ -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.