> 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.
The fundamental problem is that both the proxy server and the target server would have to know the SSL encryption and decryption keys. These are different for each session, so the relationship between the proxy and the target would be hard to maintain. At the start of each session, one of them would negotiate the session keys with the client, then tell the other what they are. One proxy could be handling many targets, of course (and vice versa), which compounds the problem. The problem is further compounded by a bug in the IE browser. A browser should send keepalive messages when things are quiet to keep the SSL session open, but IE doesn't, so the session is highly likely to time out before the user sends the next page request. The upshot of that is that just about every page request from an IE browser involves creating a new session. This issue doesn't make the problem any harder to solve, but it means that a busy proxy and target will have to share new keys many times a second. Simon
