Hildenbrand, Patrick wrote: > > > -----Original Message----- > > From: Eli Marmor [mailto:[EMAIL PROTECTED] > > > > Simon Ritchie wrote: > > > > > > > Is it possible to have 2 different SSL sessions (tunnels) > > - one with > > > > the server and one with the browser? > > > > > > > > I know that it may cause warnings, and that there is a > > danger of "a man > > > > in the middle", but sometimes there is no other option... > > > > > > You can do this using the rewrite module. There is an > > example of an HTTP to > > > HTTP reverse proxy in the rewrite module guide. Extending > > that to do what > > > you want is easy. > > > > No. Simple rewrite rule to proxy https traffic, generates > > https->https, > > which isn't decrypted to http, but passed as-is. > This is not true, as the apache acts as an https server, reads the get > request and applies all rules. The connection to the server behind the > reverse proxy will look as it would come from the apache (i.e. you can't use > certificate based authenication on this system, as the certificate can not > be used to establish this session. The following rules at least work this > way with 1.3.19. > > <VirtualHost reverseproxy:443> > SSLEngine on > SSLEnable > [ ... ] > ReWriteRule ^/something/(.*)$ https://somehost.somedomain.com/other/$1 > [P,L] > </VirtualHost> > > All this will only work for reverseproxies as you will have to supply a > server certificate matching the request.
I'm talking about 2.0, and the limitation of "reverse proxy" is not so limiting, since you can always replace a "real" proxy by a transparent one. In 2.0, you can insert "filters", which may parse the content, and optionally modify it. It works great with http->http, http->https, and https->http. However, it doesn't work with https->https, because there is no point of time, during the whole process, that the content is readable. I'm sure it's possible to implement it, because all the needed functionality is already implemented either in http->https or https->http, and the new https->https will have to only combine these (en/de)cryptions. However, I agree that the current https->https (as-is, without decryption+encryption) should remain the default. > > Do you mean two different rules, one to rewrite the https request > > coming from the browser to simple http request to another port, and a > > second rule to rewite http requests of that "another port", to the > > target https port? > will only make it more complex. Of course it's more complex. This is why I want Apache 2.0 to support it directly, without needing two tiers. Currently, this is the only way to implement filtering in SSL sessions. What I want, is internal support for https->http->https in Apache. I think that it is not too hard to do. And in the worst case, if the people agree that it's needed but nobody will volunteer, I may consider implementing it. > > So I understand that if you want to proxy https traffic, but yet to > > able to parse and/or understand it, you must have two > > separate tiers of > > Apache (which means much more overhead); Is it true? > not for reverse proxy. You can't do it for a real proxy (because of protocol > reasons). You can always use a transparent proxy instead of a real one, so I guess that it resolves the problem too. But now it should be implemented... -- Eli Marmor [EMAIL PROTECTED] CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __________________________________________________________ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel
