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. Cheers, Stefan > Am 07.01.2017 um 09:30 schrieb Reindl Harald <[email protected]>: > > * 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 > Stefan Eissing <green/>bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
