Recently, the question of using AES for SSL has come up in the newsgroups and at some conferences. When IE makes an HTTPS connection to a web server, it offers a list of cipher supported cipher suites. The server then selects the first one from the list that it can match. The default order that IE follows is this:
When you study the list, you'll see that IE presents the algorithms in decreasing order of strength, but places the shorter bit-lengths first. Why? If longer bit lengths are more secure, shouldn't they be listed first?
Remember, encryption is the thing that buys you time against Immutable Law #3. But performing encryption itself takes time. So when choosing an algorithm and a bit length, one important consideration is to ask yourself this question: "How long do I need for my secrets to remain secret?"
We configure IE to use shorter bit lengths -- but never shorter than 128 bits, except for the last two that use no encryption -- because it gives you better performance than the longer bit lengths. In almost all cases, a 128-bit key is more than sufficient to protect the information you're exchanging over HTTPS.
However, if you require something longer, and want to change the default, you can. Here's how.
Most of you probably won't need to do this -- I haven't. But for those who have regulatory requirements for using 256-bit AES, follow these steps and you'll be compliant.
Dumb question.. Why does it appear that Win2k8RC0 still defaulting to SSLv2 when it sets up SSL'd web sites?
Shouldn't it default to SSLv3?
External PCI/DSS scan tools knock down a web site for supporting SSLv2.
P521: Is it a mistake? Perhaps it should be P512 ?
"except for the last two that use no encryption"
Uh, what? Am I missing something here? Having a fallback to a non-encrypted link when the user will surely expect the link to be encrypted seems like a Bad Thing...
It's so much fun how this workaround is not even possible on Windows XP Home, which does not allow one to use the group policy editor
P521 refers to a particular pseudo-random elliptic curve defined in FIPS 186. Curve P-521 is defined over the prime field GF(p) where p=2^521-1 (a prime number).
Scott-- The TLS specifications require TLS_RSA_WITH_NULL_MD5 and TLS_RSA_WITH_NULL_SHA as part of any cipher suite. Every web browser includes these in its list of offerings.
It's true that they don't provide encryption, but they do provide authentication. This is useful, for instance, if an application on a server wants to authenticate the user (and, of course, authenticate the server to the user) but doesn't require the data to be encrypted.
Practically, however, these never get used. Unless specifically configured, web servers won't accept these suites.
Someone-- Here's the registry key where these are stored. This is from my Vista Enterprise computer. I don't have an XP home computer to verify this on, and I also don't know whether editing the registry directly for this will work, but I suspect it will:
//sample code to set TLS cipher suite on vista
//set TLS_RSA_WITH_AES_256_CBC_SHA as prefered
//will fail if TLS_RSA_WITH_AES_256_CBC_SHA already TOP
//query for prefered provider
printf("prefered TLS suite = %S\nreboot required\n",pBuffer->rgpProviders->pszFunction);
//now reboot the machine and you're good to go
Azi a fost pentru mine "ziua Steve Riley", am fost la doua sesiuni de prezentari si la un "panel discussion".
A couple of points to make here:
1. If you're concerned about compliance, you generally won't succeed by simply changing cipher order - you will need to prevent the use of the non-compliant ciphers.
2. For some environments, only FIPS compliant algorithms are accepted - see article http://support.microsoft.com/kb/811833/en-us for some good information on that.
3. The ciphersuite used is a negotiation between the server and the client - while you can use the group policy features above to limit what the browser will choose, it's probably better to limit what the server will offer. There are a few reasons - there are fewer servers than browsers; GPO will only limit Internet Explorer and browsers that use SChannel rather than OpenSSL; limiting browsers may prevent them from accessing remote servers.
4. NULL should never be used. The only time when it's appropriate is when you are a developer, and you are experiencing SSL alerts that you think could be related to incorrectly handling the data from the SSL encryption into the network stream. Then you can watch the stream in a network capture, and see whether you have indeed messed up the data. The NULL encryption protocols should never be used for HTTPS, IMHO.
One question (kind of comment - lack of info ...for me): WHEN the server has chosen one of the cipher suites; WHERE can "I" as client see which one that’s active? for a particular SSL session ? Where can "I" as a client control/set the "minimum" cipher suites combination (drop SSL if lower than I need and want ?) ?
Claes, I suppose you could delete from the registry the ones you didn't want your browser to use. We haven't tested this, so I can't predict how it would behave. And I don't know of any websites that would return details on which suite was chosen. If anyone else knows, please comment. Thanks.
While the "NULL" ciphers are in the list, Internet Explorer is hardcoded to refuse zero-bit ciphers.
please tell me how to select cipher suites in IE 6.