On Windows Server 2008 R2 I can enforce 128bit SSL for a website by executing:

appcmd set config "Default Web Site" -section:access -sslFlags:Ssl,Ssl128 -commit:apphost

Is there a downside to that? Are there any reasons not to do this, or good reasons to always do this ?

3 Answers 3


No reason not to do it, unless you know you have customers with ancient or government-restricted browsers that cannot do 128-bit encyrption. In 2012, you probably don't.

  • Hmm... it seems even IE6 has support for 128 bit encryption. Not sure whats left after that ehow.com/…
    – TheLQ
    Sep 10, 2012 at 23:23

It's basically a tradeoff between security and performance. A 128-bit cipher will provide better performance (concurrency) than a 256-bit cipher but at a reduced level of security. In general though a 128-bit cipher has effective security.

  • I thought I'd ensure nobody uses less than 128bit... I'll have to check whether this prevents 256bit, too.
    – marapet
    Sep 7, 2012 at 13:27

Most browsers have supported at least one 256bit cipher since 2006-2008. You can't assume 256bit for the general public yet (though you'd be blocking out a very small minority at this point), but you can safely assume 128bit is supported these days.

Also, there are 4 different 128-Bit ciphers that are commonly implemented (RC4, 3DES, AES, and Camellia). Each has pros and cons. RC4 is the fastest, and probably least secure. 3DES has problems up and down, and should be disabled in my opinion. AES and Camellia are fairly secure, though FIPS requires AES currently.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .