Am 08.01.2017 um 11:01 schrieb Stefan Eissing:
> There is the reverse situation which is called opportunistic encryption, namely the transfer
of a http: request over a TLS connection.
>
> Both cases are tricky on HTTP/1.x because the URI scheme is not transported in requests
(commonly. the spec would allow it but no one does it, so no one is prepared to honor/handle
it). HTTP/2, with opportunistic encryption in mind, added the ":scheme" header for this. But
implementation is also tricky.
>
> So, mod_http2 has similar problems to this ATS setup: convincing the request processing
parts in the server that a request has a certain scheme, *independent* of mod_ssl's presence.
I think it would be nice if we could fix this.
>
> One approach that comes to mind:
> * add the uri scheme to request_rec->scheme
> * set it by:
> 1. parse the request uri
> 2. if not set, fix it in very late read hooks to "http:"
> 3. have mod_ssl install an earlier hook that sets "https:" if not present
> * check that URI host and Host: header are an allowed combination
> * check that r->scheme and r->server are an allowed combination
>
> ATS would then be configured to forward requests to the httpd backend by using absolute
request uris (so they carry the scheme) or HTTP/2. httpd would be configured to accept https:
uris from ATS remote ip.
>
> And while there are numerous parts/applications where the wheels fall off in such a setup,
it is not the default setup. No one initially needs to be able to get it right. But in a concrete
deployment, the configuration can be made and the application code fixed where necessary.
yeah - something more or less standard instead
a) change this in tttpd config
b) change this in ATS config, dunno how handle it with a different proxy
c) change this in your application
when there is something you can detect in the application code when
proxy / backend play in a more or less defined way together other
proxies and backend servers could follow
>> Am 07.01.2017 um 09:30 schrieb Reindl Harald <h.reindl@thelounge.net>:
>>
>> * Apache Trafficserver in front
>> * ATS configured for TLS-offloading
>> * connection to backend-httpd on the LAN unencrypted
>> * mod_remoteip correctly configured on backend httpd
>>
>> is there any way to make the backend php application aware that in fact $_SERVER['HTTPS']
and $_SERVER['REQUEST_SCHEME'] should be 'on' / https:// in case of generate absolute URLs
like for emails
>>
>> in a perfect world this would be handeled like the transparent translation of the
client IP with https://httpd.apache.org/docs/current/mod/mod_remoteip.html and it's RemoteIPInternalProxy
and a header like "X-Forwarded-TLS"
>>
>> something like below where "X-TLS-Offloading" is only evaluated from "RemoteIPInternalProxy"
pyhsical addressess
>>
>> RemoteIPHeader X-Forwarded-For
>> RemoteTLSHeader X-TLS-Offloading
>> RemoteIPInternalProxy 192.168.196.1
|