In SSL the client connects and sends the list of ciphers it supports; then the server selects one of the ciphers it also supports, and that cipher is used for the connection. Only when the connection is established (the "handshake" is finished) does HTTP come into play.
In your setup, this means that you should configure your SSL server to accept a variety of ciphers, but to favor those with a private key of 128 bits or more over others. Thus, a less-than-128-bits cipher will be selected only if no 128-bits-or-more cipher is supported by both client and server. Then, the page sent within that connection would be altered, depending on the actually negotiated cipher.
For such a setup, you need to be able to do the following:
- to configure the list of ciphers supported by the SSL server;
- to enforce the server preference over the client preference, within the list of ciphers supported by both client and server;
- to access the cipher actually used from within your page generating engine, e.g. PHP.
In Apache's mod_ssl, it appears that point 1 is easy ("SSLCipherSuite" directive) and the section on "Environment Variables" seems to indicate that the SSL server is willing to give some information on what cipher was selected to the page generating engine; in particular, the SSL_CIPHER_USEKEYSIZE
variable looks quite good. Hence point 3 looks easy too. I am not sure how this translates into the PHP world, however.
For point 2, it is a bit more difficult. The documentation of "SSLCipherSuite" seems to tell that the server, by default, uses its own preference order, so point 2 would be easy too, but this would require a bit of testing.
Now only remains a minor point, which is the status of 3DES. Nominally, it uses a 192-bit key. Any decent cryptographer or programmer would point out that out of those 192 bits, only 168 bits are used (the extra bits were supposed to act as parity check bits, but nobody bothers verifying those, they are just ignored). Now, some academics have also shown that the actual algorithm strength is lower, somewhat equivalent to a 112-bit key, at least when seen in the proper academic light. The NIST (the US federal institution which deals with such standards) has therefore issued a recommendation, that 3DES should be considered as offering "only 112 bits of security", and 112 is lower than 128.
Of course, 112 bits is still quite far into the realm of the technologically infeasible (and should remain so for at least 30 years, even if technological progress keeps on its hectic pace), so this is not a real problem for any practical situation, but if you are in a standard-maniacal frame of mind and wish to enforce "real" 128 bits then this is a question to consider.