mån 2003-08-04 klockan 19.24 skrev Geoff Thorpe: > Yes. There's normally no reason to cache more than one (client) session > for any given server, and usually the best strategy is to cache the most > recent one (or more correctly, the one that expires last). Question: how > are you handling client-authentication if it arises? There is a can of > worms waiting for you here, perhaps you're already aware of it?
There is limited support for "client" authentication here. Squid only supports a single client certificate per type of outgoing SSL connection when initiating SSL connections. Note that this use of SSL is not related to proxying of SSL requests from the end-users. Only when you set up Squid to SSL encrypt connections Squid make. Examples of uses are: * Encryption of connection between two Squid servers * Encryption between a Squid running in accelerator mode and the accelerated web server (to the end-user Squid is the endpoint). and the kind of moot operation these days: * Gatewaying to https:// for clients who do not support SSL > If squid > is proxying on behalf of multiple clients, then you risk introducing some > weird security issues. For better or worse, HTTPS is often used in a > rather layer-violating way. Eg. if web-server logic attaches/indexes > state based on SSL/TLS session details, then if you (as squid) reuse that > session for a different client, you risk having that client be > interpreted by the server as the client who happened to be proxying when > the session was negotiated. Ugh,, I think I get the problem. Some servers connect HTTP state information to the SSL state. This problem we have seen in HTTP alone already (servers connecting HTTP state information to TCP connections) and I imagine it can get a lot worse with SSL sessions.. But fortunately I do not think this will be much of a problem in the intended scopes of use. > https-https proxying is a different kettle of fish to > http-https proxying. How are you doing this anyway? By proxying the https:// request, not the SSL. Perhaps best described as https->https gatewaying if the client talks SSL/https to Squid. > Do you specify a new CA cert to the clients that, once accepted, > allows you to do dynamic MITM SSL/TLS proxying by faking server > certificates according to the CONNECT string? Or something else? Something else. The current implementation is mostly for accelerators and simply implement a standard SSL server with it's own certificate. It does NOT intercept CONNECT requests ot hijacked port 443 request, it just accepts whatever requests the client sends to a SSL enabled port to Squid, acting as a web server to the client. The main difference from a normal web server is that we do not have any original data of our own, but rely on http/https to fetch the data (there is also a few other differences at the HTTP layer originating from Squid being a caching proxy). > There's no harm reusing it for multiple concurrent connections - this is > the most common application (a browser negotiating a session for an html > page will then typically fire off various concurrent session resumes to > go back and pick up all the image files too). As I say, the question is > more how you identify/index SSL sessions in a satisfactory way (and with > suitable granularity) so that you get the maximum performance pay-off > from resumes, but without creating mistaken identities for any server > that matches up browser-clients to corresponding SSL/TLS state. Thanks. The SSL session concept is much clearer to me now, and you have highlighted a couple of DONT DO THIS issues we need to have clearly documented together with a few tuning knobs to tune when/how session reuse is allowed. I think I will limit myself to session reuse for known peers for the time being and leaving https:// proxying/gatewaying aside. This is the most interesting area for us at the moment, and gives a very controlled play field with easy mechanisms of tuning the desired behavior. Now back to questions: All examples I have found gets the session just before SSL_shutdown(). Would not a more appropriate place for a multi-connection application like Squid be just after a successful SSL_connect()? The SSL session can be immediately reused, right? Should not be any need to wait for a complete SSL connection to finish until shutdown before reusing the session from what I can understand from this discussion. Regards Henrik -- Henrik Nordstrom <[EMAIL PROTECTED]> MARA Systems AB ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
