20 Replies Latest reply on Oct 22, 2014 1:14 AM by Ivan Ristic

    BEAST vulnerability detection

    steve Level 1

      I just noticed that a new v1.0.87 has been deployed and displays a "BEAST attack: vulnerable".

       

      Based on what criteria are you concluding that a server is indeed vulnerable: does a lacking RC4 preferred cipher automatically mean that you consider a server prone to a BEAST attack?

       

      On a test server, I don't include RC4 (whether preferred or optional), but instead opted to activate empty fragments for TLS 1.0 and switched to OpenSSL 1.0.1-stable to get TLS 1.1.

       

      As far as I tested, only IE6 on Windows XP can't handle empty fragments. All other IE versions, whether on XP or 7 are able to connect just fine. Same for recent versions of Firefox, Chrome and Opera.

        • BEAST vulnerability detection
          Ivan Ristic Level 5

          Yes, you're right: in 1.0.87 I considered a server to be vulnerable if RC4 is not prioritized. However, as you point out, that's inaccurate. Short term, I will remove the warning for those servers that do not use RC4 as a mitigation technique, and only display "Not vulnerable" for those that do. Long term, I will improve the detection. Thank you for bringing this to my attention.

           

          If it's not a problem, please send me your server details so that I can test the improved detection with it.

           

          Thanks.

          • BEAST vulnerability detection
            steve Level 1

            Since one of the latest versions, BEAST vulnerability detection has changed. Just out of curiousity: based on what criteria are you deciding whether a host is "unknown" or "vulnerable" to the attack?

             

            With the following protocols:

            TLS 1.2  Yes
            TLS 1.1  Yes
            TLS 1.0  Yes
            

             

            one is unknown (dev.slimtrader.com, nginx):

            TLS_RSA_WITH_AES_256_CBC_SHA (0x35)     256
            

             

            while another is vulnerable (smtguru.com, IIS 7.5):

            TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)  128
            TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)     128
            TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)  256
            TLS_RSA_WITH_AES_256_CBC_SHA (0x35)     256
            TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)  128
            TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)     128
            TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)     256
            
              • BEAST vulnerability detection
                Ivan Ristic Level 5

                Steve, the BEAST test currently depends on the cipher suite preference test, and the latter is not always possible to carry out. It seems that some web servers chose to mitigate BEAST by forcing RC4 ciphers, even when they are not offered by the connecting client. In practice this works because virtually every browsers supports RC4. When it comes to SSL Labs, however, the forcing of RC4 breaks our cipher suite preference test, and thus the BEAST test.

                 

                We're saying "unknown" at the moment, which I thought is better than saying either "Vulnerable" or "Not vulnerable". I will fix the issue as soon as I can schedule some development time for it.

                  • BEAST vulnerability detection
                    Ivan Ristic Level 5

                    This is now fixed in 1.0.101. However, this is an area where server behaviour changes constantly and will continue as web sites mitigate against BEAST and deploy TLS 1.1 and TLS 1.2. We will continue to monitor the situation and tweak the test accordingly. Thanks for your help.

                      • BEAST vulnerability detection
                        steve Level 1

                        Thanks, I've checked a legacy server, that is known to be vulnerable and it is reported correctly again. On the other hand, the version is now already 1.0.102 and my own test host is reported as being "vulnerable to BEAST attack", although it shouldn't:

                         

                        SSL Cipher order, as configured in nginx:

                         

                        ssl_prefer_server_ciphers on;
                        

                        ssl_ciphers AESGCM:SHA384:SHA256:-AES128:AESGCM:SHA384:SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

                         

                        which is reported as:

                         

                        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                        TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
                        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
                        TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)
                        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                        TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
                        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
                        TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
                        TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
                        TLS_RSA_WITH_RC4_128_SHA (0x5)
                        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                        TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
                        TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84)
                        TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
                        TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
                        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                        TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
                        TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)

                         

                        The first 8 ciphers are TLS 1.2 only and the first TLS 1.0 one is RC4, so the configuration looks fine to me.

                          • BEAST vulnerability detection
                            Ivan Ristic Level 5

                            I think you need to remove SHA256 from the string. In my test, your server responded with TLS_RSA_WITH_AES_256_CBC_SHA when using TLS 1.0.

                              • BEAST vulnerability detection
                                steve Level 1

                                Indeed, after moving AES256_SHA256 after RC4, the warning doesn't appear anymore. This is really weird, as the SHA256-based ciphers are supposed to be TLSv1.2 only and shouldn't be selected for SSLv3 or TLSv1.

                                 

                                I've changed the cipher configuration as follows to make sure RC4 really comes before any SSLv3/TLSv1 ciphers:

                                AESGCM:SHA384:SHA256:-AES128:AESGCM:SHA384:SHA256:-SSLv3:RC4:HIGH:!MD5:!aNULL:!EDH

                                 

                                I guess this is a feature of the development release of OpenSSL 1.0.1 (ssl/s3_lib.c):

                                AES256-SHA256           SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256

                                 

                                The ciphers 0x3B to 0x40 are marked as SSL_TLSV1.

                      • BEAST vulnerability detection
                        Satyen Shah Lurker

                        The tester reports my windows server is vulnerable to BEAST.  The server does have automatic updates enabled, and KB2585542 installed.  Should I still be concerned about BEAST?