> -----Original Message----- > From: Eli Marmor [mailto:[EMAIL PROTECTED] > Sent: Montag, 25. Februar 2002 15:49 > [ ... ] > Hildenbrand, Patrick wrote: > > > > > > 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.
Can't see how this could be achieved for SSL servers (see also below). > 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. it is my understanding from reading the standards, that the get request of the client is allready encrypted, except where a transparent encryption is being used. So if I understand your statement correctly, and we could not parse the content, then mod_rewrite will no longer work in an ssl configuration on a 2.0 apache, as this also would be encrypted. Right ? Would be more than only surprising to me. I guess what you mean is the proxy: command. You are right, that a proxy request to an other system can be parsed but not the actual get request. Similiar a transparent proxy is unable to even read the getrequest. But this intended by the SSLv2 protocol. > [ ... ] > > 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... as far as I understand you can neither use a transparent nor a usual forwarding proxy for SSL connections (only SSLv1 will work) as you can't provide the client with the correct server certificate (except for the case, that you have access to all the host keys and certs of the servers behind your proxy, or you clients do not have a problem with being unsue, what host they really are connected to). The solution I use will only work for reverse proxy setups (this is intended by the design of SSLv2 to assure end2end integrity of the data), as there you have the server certificate bound to the proxy, not to the server answering the request. > > -- > Eli Marmor Mit besten Grussen, Kind regards, Patrick Hildenbrand
