How can I test a browser to see if it supports 128-bit encryption?

I have been given the task of finding a replacement for a piece of old code. I'm assuming it tested to see if the browser supports 128-bit encryption. Here's the old code: (I purposely split the link into 4 lines)

http://www.verisign.com/update-cgi/outPage.exe

?开发者_运维问答good=../docs/html/good.html

&nsbad=../docs/html/upgradeNSonly.html

&ie2=../docs/html/upgradeIEonly.html

Have you every seen this code before?

How can I duplicate this functionality inside a php page?

Clarification

The old webmaster found a link to verisign that that did the browser check. Verisign has since stopped supporting this link. Personally, I think we should simply tell our customers to click on the Help > About inside there browser and look for the cypher strength. If it's not at least 128 then we simply tell them to upgrade there browser.

All modern browsers support 128 bit encryption out of the box. Do you have a need to support browsers older than IE 5.5?

You could either check the User-Agent string of the browser and make assumptions, or you could direct them to a page that uses a 128 bit SSL certificate and if they continue through it.. well, they must support it.

The stuff you've pasted here is not code - its a URL.

If you don't understand the difference then I expect you won't really understand any answer to the implied question of 'how do you measure encryption quality in php?' but here goes anyway....

First, there is no way to test if a browser supports a particular encryption algorithm or key size other than to test connecting using that encryption method - so that means configuring multiple different levels of encryption on your server and creating web pages in each one then testing what the browser can connect to. This not a trivial task, and not something most people would ever come across in normal life.

If you are using mod_ssl on apache, combined with mod_php (you didn't say what OS/webserver the PHP runs in), then you'll be able to see all sorts of additional $_SERVER variables including "SSL_CIPHER", "SSL_CIPHER_USEKEYSIZE", "SSL_CIPHER_ALGKEYSIZE" and "SSL_SERVER_A_KEY"

See also

http://httpd.apache.org/docs/2.0/mod/mod_ssl.html#envvars

So really I suspect you are asking the wrong question, but I can't tell what the right question is until you can answer this:

What do you expect to achieve by knowing if a browser supports 128 bit encyption?

C.

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.

All modern browsers support 128 Bit. However, you should enforce this server-side administratively as someone could use an older browser or forge a request to use a lower bit-level of encryption (e.g. 40 or 56).

I suggest you ask how to set the web server up to enforce it based on your platform at:

http://serverfault.com