Disable SSL fallback and use only TLS for outbound connections in NET Poodle mitigation

Question

I am trying to mitigate our vulnerability to the Poodle SSL 3 0 Fallback attack  Our admins have already started disabling SSL in favor of TLS for inbound connections to our servers  And we have also advised our team to disable SSL in their web browsers  I m now looking at our  NET codebase  which initiates HTTPS connections with various services through System Net HttpWebRequest  I believe that these connections could be vulnerable to a MITM attack if they allow fallback from TLS to SSL  Here is what I have determined so far  Could some one please double-check this to verify that I am right  This vulnerability is brand new  so I have yet to see any guidance from Microsoft on how to mitigate it in  NET    The allowed protocols for the System Net Security SslStream class  which underpins secure communication in  NET  are set globally for each AppDomain via the System Net ServicePointManager SecurityProtocol property  The default value of this property in  NET 4 5 is Ssl3   Tls  although I can t find documentation to back that up   SecurityProtocolType is an enum with the Flags attribute  so it s a bitwise OR of those two values  You can check this in your environment with this line of code    Console WriteLine System Net ServicePointManager SecurityProtocol ToString     This should be changed to just Tls  or perhaps Tls12  before you initiate any connections in your app   System Net ServicePointManager SecurityProtocol   System Net SecurityProtocolType Tls  Important  Since the property supports multiple bitwise flags  I assume that the SslStream will not automatically fallback to other unspecified protocols during handshake  Otherwise  what would be the point of supporting multiple flags    Update on TLS 1 0 vs 1 1 1 2   According to Google security expert Adam Langley  TLS 1 0 was later found to be vulnerable to POODLE if not implemented correctly  so you should consider moving to TLS 1 2 exclusively   Update for  NET Framework 4 7 and above   As alluded to by Prof Von Lemongargle below  starting with version 4 7 of the  NET Framework  there is no need to use this hack as the default setting will allow the OS to choose the most secure TLS protocol version  See Transport Layer Security  TLS  best practices with the  NET Framework for more information

User · Answer

If you re curious which protocols  NET supports  you can try HttpClient out on https   www howsmyssl com      set proxy if you need to    WebRequest DefaultWebProxy   new WebProxy  http   localhost 3128     File WriteAllText  howsmyssl-httpclient html   new HttpClient   GetStringAsync  https   www howsmyssl com   Result       alternative using WebClient for older framework versions    new WebClient   DownloadFile  https   www howsmyssl com     howsmyssl-webclient html      The result is damning      Your client is using TLS 1 0  which is very old  possibly susceptible to the BEAST attack  and doesn t have the best cipher suites available on it  Additions like AES-GCM  and SHA256 to replace MD5-SHA-1 are unavailable to a TLS 1 0 client as well as many more modern cipher suites    As Eddie explains above  you can enable better protocols manually   System Net ServicePointManager SecurityProtocol   SecurityProtocolType Tls12   SecurityProtocolType Tls11     I don t know why it uses bad protocols out-the-box  That seems a poor setup choice  tantamount to a major security bug  I bet plenty of applications don t change the default   How can we report it

User · Answer

Eddie Loeffen s answer seems to be the most popular answer to this question  but it has some bad long term effects   If you review the documentation page for System Net ServicePointManager SecurityProtocol here the remarks section implies that the negotiation phase should just address this  and forcing the protocol is bad practice because in the future  TLS 1 2 will be compromised as well    However  we wouldn t be looking for this answer if it did   Researching  it appears that the ALPN negotiation protocol is required to get to TLS1 2 in the negotiation phase   We took that as our starting point and tried newer versions of the  Net framework to see where support starts   We found that  Net 4 5 2 does not support negotiation to TLS 1 2  but  Net 4 6 does   So  even though forcing TLS1 2 will get the job done now  I recommend that you upgrade to  Net 4 6 instead   Since this is a PCI DSS issue for June 2016  the window is short  but the new framework is a better answer   UPDATE  Working from the comments  I built this   ServicePointManager SecurityProtocol   0      foreach  SecurityProtocolType protocol in SecurityProtocolType GetValues typeof SecurityProtocolType                  switch  protocol                        case SecurityProtocolType Ssl3              case SecurityProtocolType Tls              case SecurityProtocolType Tls11                  break              default                  ServicePointManager SecurityProtocol    protocol              break                    In order to validate the concept  I or d together SSL3 and TLS1 2 and ran the code targeting a server that supports only TLS 1 0 and TLS 1 2  1 1 is disabled    With the or d protocols  it seems to connect fine   If I change to SSL3 and TLS 1 1  that failed to connect   My validation uses HttpWebRequest from System Net and just calls GetResponse     For instance  I tried this and failed           HttpWebRequest request   WebRequest Create  https   www contoso com my web resource   as HttpWebRequest          ServicePointManager SecurityProtocol   SecurityProtocolType Ssl3   SecurityProtocolType Tls11          request GetResponse      while this worked           HttpWebRequest request   WebRequest Create  https   www contoso com my web resource   as HttpWebRequest          ServicePointManager SecurityProtocol   SecurityProtocolType Ssl3   SecurityProtocolType Tls12          request GetResponse      This has an advantage over forcing TLS 1 2 in that  if the  Net framework is upgraded so that there are more entries in the Enum  they will be supported by the code as is   It has a disadvantage over just using  Net 4 6 in that 4 6 uses ALPN and should support new protocols if no restriction is specified   Edit 4 29 2019 - Microsoft published this article last October   It has a pretty good synopsis of their recommendation of how this should be done in the various versions of  net framework

User · Answer

We are doing the same thing  To support only TLS 1 2 and no SSL protocols  you can do this   System Net ServicePointManager SecurityProtocol   SecurityProtocolType Tls12    SecurityProtocolType Tls is only TLS 1 0  not all TLS versions   As a side  If you want to check that your site does not allow SSL connections  you can do so here  I don t think this will be affected by the above setting  we had to edit the registry to force IIS to use TLS for incoming connections   https   www ssllabs com ssltest index html  To disable SSL 2 0 and 3 0 in IIS  see this page  https   www sslshopper com article-how-to-disable-ssl-2 0-in-iis-7 html

User · Answer

watson  On windows forms it is available  at the top of the class put    static void Main string   args                ServicePointManager SecurityProtocol   SecurityProtocolType Tls12           other stuff here         since windows is single threaded  its all you need  in the event its a service you need to put it right above the call to the service  since there is no telling what  thread you ll be on    using System Security Principal    is also needed

User · Answer

I had to cast the integer equivalent to get around the fact that I m still using  NET 4 0  System Net ServicePointManager SecurityProtocol    SecurityProtocolType 3072     Note the property type       System Flags     public enum SecurityProtocolType           Ssl3   48       Tls   192       Tls11   768       Tls12   3072

User · Answer

I found the simplest solution is to add two registry entries as follows  run this in a command prompt with admin privileges    reg add HKLM SOFTWARE Microsoft  NETFramework v4 0 30319  v SchUseStrongCrypto  t REG DWORD  d 1  reg 32  reg add HKLM SOFTWARE Microsoft  NETFramework v4 0 30319  v SchUseStrongCrypto  t REG DWORD  d 1  reg 64   These entries seem to affect how the  NET CLR chooses a protocol when making a secure connection as a client   There is more information about this registry entry here   https   docs microsoft com en-us security-updates SecurityAdvisories 2015 2960358 suggested-actions  Not only is this simpler  but assuming it works for your case  far more robust than a code-based solution  which requires developers to track protocol and development and update all their relevant code  Hopefully  similar environment changes can be made for TLS 1 3 and beyond  as long as  NET remains dumb enough to not automatically choose the highest available protocol   NOTE  Even though  according to the article above  this is only supposed to disable RC4  and one would not think this would change whether the  NET client is allowed to use TLS1 2  or not  for some reason it does have this effect   NOTE  As noted by  Jordan Rieger in the comments  this is not a solution for POODLE  since it does not disable the older protocols a -- it merely allows the client to work with newer protocols e g  when a patched server has disabled the older protocols  However  with a MITM attack  obviously a compromised server will offer the client an older protocol  which the client will then happily use   TODO  Try to disable client-side use of TLS1 0 and TLS1 1 with these registry entries  however I don t know if the  NET http client libraries respect these settings or not   https   docs microsoft com en-us windows-server security tls tls-registry-settings tls-10  https   docs microsoft com en-us windows-server security tls tls-registry-settings tls-11

[.net] Disable SSL fallback and use only TLS for outbound connections in .NET? (Poodle mitigation)

Examples related to .net

Examples related to ssl