SSL Cipher Suite Order best practice
We have a web server running IIS on Windows Server 2008 R2 x64. A PCI scan on the server failed because of BEAST vulnerability. The recommended fix is to disable all block-based cipher suites or configure SSL to prefer RC4 ciphers over block-based ciphers. I want to tread carefully so that we still allow users to our web site to achieve secure connections. First, I'm wondering if our system is already patched. I've seen lots of discussion about how Microsoft has addressed this in Security Bulletin MS12-006 and fixed this in KB2585542. I have confirmed that KB2585542 is installed on the server. So did the PCI scan maybe find a false positive, or is there still a vulnerability beyond what is fixed in the KB? I'm fairly certain that there's still a vulnerability because a separate scan from ssllabs.com also flags a BEAST vulnerability while other web sites are fine. The way to change the cipher suite order seems to be using Group Policy > Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order. My questions are: 1) What is the best order to use? 2) How do I know which ones are block-based ciphers? 3) When I set the cipher suite order, if the list that I provide excludes any, does that mean that IIS will no longer support that cipher? Assuming the answer to #3 is Yes: 4) How can I know what we risk by removing a cipher? For example, if I remove cipher XYZ, then Windows XP running IE6 will not be able to connect to the secure server. 5) By setting the cipher suite order to a specific list, am I preventing the server from supporting newer better cipher suites that become available in the future (e.g. when installing a service pack or upgrading to a newer OS)? I appreciate your guidance through this. I have not had to administer cipher suites until now. Cam
December 5th, 2012 3:59am

Does this help? http://www.burbageitsolutions.com/blog/2012/6/11/mitigate-the-beast-attack-in-iis-75-for-microsoft-server-200.htmlJason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
Free Windows Admin Tool Kit Click here and download it now
December 6th, 2012 1:22am

Does this help? http://www.burbageitsolutions.com/blog/2012/6/11/mitigate-the-beast-attack-in-iis-75-for-microsoft-server-200.html No, not really. This article explains how to set the cipher suite order, but doesn't resolve any of my concerns about excluding/disabling cipher suites. Cam
December 6th, 2012 1:58am

Does this help? http://www.burbageitsolutions.com/blog/2012/6/11/mitigate-the-beast-attack-in-iis-75-for-microsoft-server-200.html No, not really. This article explains how to set the cipher suite order, but doesn't resolve any of my concerns about excluding/disabling cipher suites. Cam The article suggests that placing RC4 at the top is sufficient; you shouldn't need to exclude or disable ciphers?Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
Free Windows Admin Tool Kit Click here and download it now
December 6th, 2012 2:08am

Same thing.. server has been passing PCI scan for months and started failing this last week. Unfortionately I have the same issue and have already re-arranged the cypher suite order but it still fails the PCI scan. Apparently the arrangement doesn't matter. I'm failing due to port 25, 443 and 143 and have already went through all the items I can find as well. I'm too the point where the only reason 443 and 143 are open is due to webmail and iphones which are all newer versions so I'm about ready to kill the block cyphers as well, but there appears to be direct answer given anywhere for "which ones do I remove and which ones to keep".
December 6th, 2012 4:58pm

The article suggests that placing RC4 at the top is sufficient; you shouldn't need to exclude or disable ciphers? Well, yes, the PCI scan does say that setting the order so that RC4 is at the top is adequate, but suggests that the ideal solution is to disable all block-based cipher suites. So it's not entirely clear whether I should disable or change the order. But what about future cipher suites? Right now, the server is using its default. If I explicitly set the order, I assume I am making the list of supported cipher suites fixed. That is, anything not on the list is not supported by the server. That may be fine now, but what about when new cipher suites become available and are included in a service pack install? How will I know when it's time to update this list? Cam
Free Windows Admin Tool Kit Click here and download it now
December 7th, 2012 2:34am

Hi, Thank you for clarifying the issue for us. I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience. Thank you for your understanding and support. Regards Kevin TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.
December 7th, 2012 8:50am

HI, here are some link for your reference. http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/bb870930(v=vs.85).aspx http://blogs.msdn.com/b/asiatech/archive/2010/11/18/how-to-determine-cipher-suite-between-ie-and-iis.aspx Best regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
December 10th, 2012 11:50am

http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx This blog says, "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." It goes on to describe how to use SSL Cipher Suite Order to change the order of the cipher suites that IE sends. Wait a minute. I am wanting to make changes to the web server. So does SSL Cipher Suite Order affect only IE, or does it affect the web server too? Cam
December 10th, 2012 10:34pm

HI, According to the blog, it seems affected IE. Best regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
December 12th, 2012 1:20pm

Kevin, I have unproposed Jason's responses as answer because I am concerned with configuring the web server and Jason said that the information he provided affects only IE. So I am still in need of an answer. To simplify the issue down to 2 questions: 1) What is the proper way to control how IIS (not IE) selects the cipher suite? 2) If I'm setting the cipher suite order to a hardcoded list, how do I know what order to use and what suites to include or exclude? I have found a number Internet resources giving suggestions, but nothing on a Microsoft site. I am nervous about blindly following the advice on these sites because they are not sites that I trust. I'd really like to find a Microsoft web page, or at least a MS engineer who can address these concerns. Cam
December 14th, 2012 8:44pm

Him Below are some other articles for your reference. http://blogs.msdn.com/b/asiatech/archive/2010/11/18/how-to-determine-cipher-suite-between-ie-and-iis.aspx http://support.microsoft.com/kb/980868 http://support.microsoft.com/kb/299520Best regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
December 15th, 2012 9:42am

Him Below are some other articles for your reference. http://blogs.msdn.com/b/asiatech/archive/2010/11/18/how-to-determine-cipher-suite-between-ie-and-iis.aspx http://support.microsoft.com/kb/980868 http://support.microsoft.com/kb/299520Best regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
December 15th, 2012 9:42am

Hi, Below are some other articles for your reference. http://blogs.msdn.com/b/asiatech/archive/2010/11/18/how-to-determine-cipher-suite-between-ie-and-iis.aspx http://support.microsoft.com/kb/980868 http://support.microsoft.com/kb/299520Best regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
December 15th, 2012 9:42am

Below are some other articles for your reference. http://blogs.msdn.com/b/asiatech/archive/2010/11/18/how-to-determine-cipher-suite-between-ie-and-iis.aspx http://support.microsoft.com/kb/980868 http://support.microsoft.com/kb/299520 Jason, it is clear that you do not understand what I am trying to do. The blog and KB299520 both tell me how to tell what cipher suite HAS BEEN negotiated between the server and client. This might be useful to test my change after I've fixed the server, but it doesn't tell me how to fix the server. KB980868 tells me how to make changes to the client, but I want to change the server. Cam
December 17th, 2012 7:40pm

Below are some other articles for your reference. http://blogs.msdn.com/b/asiatech/archive/2010/11/18/how-to-determine-cipher-suite-between-ie-and-iis.aspx http://support.microsoft.com/kb/980868 http://support.microsoft.com/kb/299520 Jason, it is clear that you do not understand what I am trying to do. The blog and KB299520 both tell me how to tell what cipher suite HAS BEEN negotiated between the server and client. This might be useful to test my change after I've fixed the server, but it doesn't tell me how to fix the server. KB980868 tells me how to make changes to the client, but I want to change the server. Cam Him or me? ;)Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
Free Windows Admin Tool Kit Click here and download it now
December 17th, 2012 7:45pm

Hi CAM, Do you mean you want to change this behaviors fronm IIS side? Please let me know. Best regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
December 18th, 2012 1:11pm

Do you mean you want to change this behaviors fronm IIS side? Please let me know. Yes, I need to make some sort of change to IIS or the computer running it. In order to be PCI compliant, an outside service does a security scan of our network. The scan failed because it says our web server is vulnerable to a BEAST attack. The recommended fix is either disable all block-based cipher suites or configure SSL to prefer RC4 ciphers over block-based ciphers. I'm hoping to find someone who knows how to fix this on the server. Cam
Free Windows Admin Tool Kit Click here and download it now
December 18th, 2012 8:20pm

Him or me? ;) Sorry, I forgot that there were 2 Jasons replying to this post. My remarks ("it is clear that you do not understand...") were referring to the 3 links that Jason Mei posted ("Below are some other articles for your reference.". I had been trying to do my best to be clear that I need to fix the perceived vulnerability on the server, but the links he posted were either about how to configure IE or monitoring the client and server encryption. Cam
December 18th, 2012 8:31pm

Hi CAM, If the IIS server apply following policy settings, it will take effect from the server side. Group Policy > Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order. From the blog provided before, we could know we'll see that vy default IE presents the algorithms in decreasing order of strength, but places the shorter bit-lengths first. So the default order is security. If we don't want to use some lack securiy SSL Cipher, we could remove it from above policy settings. Best regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
December 19th, 2012 11:24am

If the IIS server apply following policy settings, it will take effect from the server side. But I read that IIS selects the first cipher suite in the list that IE sends. Here's a hypothetical example: IE wants to make a secure connection and sends this list in this order: A,B,C,D,E. On the IIS side, its SSL Cipher Suite Order is set to C,B,E. How does IIS decide what to use? If IIS uses the first cipher suite in the list that IE sends, then it would be B. But if IIS uses its own list, then it would use C. Can you point to any documentation on the Microsoft site that corroborates your answers? Cam
December 19th, 2012 11:04pm

Saw this in another thread: https://www.nartac.com/Products/IISCrypto/Default.aspxJason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
Free Windows Admin Tool Kit Click here and download it now
December 19th, 2012 11:27pm

Hi CAM, 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. See below. http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx So in you example, it must be CBest regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
December 20th, 2012 11:45am

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. See below. http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx So in you example, it must be C Jason M, please forgive me; I don't know what's wrong with me but it sounds like you are contradicting yourself. In your previous message, you said, "If the IIS server apply [SSL Cipher Suite Order] settings, it will take effect from the server side." But in this message, you say that the server selects the first one from the list sent by the client that it can match. Also in this message, you said that if the server uses the client's list, it will select C. But I think it is B. Again, the server supports C,B,E and the client sends A,B,C,D,E. Scenario #1: The server uses its own list (C,B,E). The first in the server's list is C. The client supports C so the server selects C. Scenario #2: The server uses the order sent by the client (A,B,C,D,E). The first in the client's list is A. The server doesn't support A so the server looks at the second entry in the client's list which is B. The server does support B so the server selects B. According to the "Changing the SSL cipher order" blog, it is Scenario #2 that is used. So I'm still not confident that I know how to configure the server to control which cipher suite it selects. Cam
Free Windows Admin Tool Kit Click here and download it now
December 20th, 2012 8:01pm

Okay, I did some testing. It seems that if the cipher suite order is set on the server, the server IGNORES the list that IE sends. I used MS Network Monitor to watch the handshake between the client and server. If I set the cipher suite order on the server and remove the top one, the next one down is selected. If I move a lower one to the top, that one is selected. So now I am clear on how to configure what cipher suites are supported and the order on the server. Even though the technet blog says the GP setting is for IE, I have seen that it affects IIS too. But most of my original questions still remain: What is the best order to use?How do I know which ones are block-based ciphers? How can I know what we risk by removing a cipher? For example, if I remove cipher XYZ, then Windows XP running IE6 will no longer be able to connect to the secure server.By setting the cipher suite order to a hard list, how do I make sure to include new cipher suites that are introduced in the future (e.g. when installing a service pack or upgrading to a newer OS)? Cam
December 21st, 2012 12:10am

As mentioned by someone higher up in this thread https://www.nartac.com/Products/IISCrypto/Default.aspx The program at the above link has a PCI compliance button you can click. It will automatically disable the weak ciphers and allow you to rearrange the cipher order. Put all the RC4 ciphers at the top and the remaining CBC ciphers below.
Free Windows Admin Tool Kit Click here and download it now
December 21st, 2012 12:33am

As mentioned by someone higher up in this thread https://www.nartac.com/Products/IISCrypto/Default.aspx The program at the above link has a PCI compliance button you can click. It will automatically disable the weak ciphers and allow you to rearrange the cipher order. Put all the RC4 ciphers at the top and the remaining CBC ciphers below. Yep that was me :) It looks a great tool; just by looking at the templates you get a good deal of information... To try and answer your specific question Cam: A1: Hopefully the tool answers that with the Beast template. A2: I believe the block-based ciphers are denoted with the CBC reference. A3: Not sure that is an easy answer as you also need to consider browser support, not just OS. You may have to make the changes on a test systems and then perform client testing to be 100% sure anyhow. The permutations and combinations are probably quite large and hence difficult to predict fully. A4: I would imagine new ciphers would only be added with new OS versions, not updates. I guess you will have to compare what is included with newer operating systems and see how the old settings from the tool are still applicable (or not). Security should never really be' fit and forget' anyhow ;) I agree an area on technet to cover this subject would be very useful (unless it exists and we just don't know about it!!!). Cheers JJ Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
December 21st, 2012 2:30pm

Hi, If the IIS server apply following policy settings, it will take effect from the server side. I mean the Server side will not use the default SSL Cipher Suite, it will use the one we set. Group Policy > Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order. Example. If some client send a SSL Cipher Suite with low level security in the first older, but the server side has been configured as a high level security, then it will use the high level SSL Cipher Suite. Best regards, Jason Mei Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
December 21st, 2012 2:41pm

If the IIS server apply following policy settings, it will take effect from the server side. I mean the Server side will not use the default SSL Cipher Suite, it will use the one we set. After doing my own testing and observing the server's behavior for myself, I agree that this is true. The cause of much confusion was that the Microsoft blog (see above) says, "The server... selects the first [cipher suite] from the list [sent by the browser] that it can match." It doesn't say that if you set the SSL Cipher Suite Order on the server, that overrides the order sent by the client and the server then uses its own order, which is what I have found to be true. Cam
December 22nd, 2012 1:51am

Thank you everyone for your input on this issue. I think this is one of those cases where Microsoft's official voice is unfortunately quiet. Otherwise it would have saved a lot of time. Regarding the recommendation to use IIS Crypto, it probably would very effectively configure the security the way it would be. But I decided not to use it for the following reasons: In terms of the amount of work I need to do, it does not really save me much. The SSL Cipher Suite Order GP setting is very easy to find and set. The hard part is knowing what cipher suite order to use.Knowledge is power. I would prefer to educate myself on the differences between the various cipher suites and then use that knowledge to select the most suitable order. IIS Crypto hands me the cipher suite order that it recommends without telling me how it came by it. Its web site references KB245030, but from what I could understand of it, that article only tells you how to enable or disable specific algorithms and says little if any about how to know which ones are safe to disable and what is the best order to use. I am not familiar with the developer of the product so I'm not comfortable putting my trust in it. Disabling encryption algorithms on a production web server is a serious matter and I don't want to hand the ability to do that to an application that I'm not familiar with. What I ended up doing is comparing the cipher suite order recommended by PhoneFactor with the default order in Windows and coming up with my own order which I think should satisfy the PCI people. Cam
Free Windows Admin Tool Kit Click here and download it now
December 22nd, 2012 2:16am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics