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

BEAST vulnerability detection

steve

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

    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

      No, it's no problem at all. Go ahead on the following hostname:

      mail.icanhasserver.com

    • Re: BEAST vulnerability detection
      rreith

      I just disabled the option "SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS" on my site. Then I tested my site with ssllabs scanner and it still tells me that my site is vulnerable to BEAST. Can you pease tell me if it is not enough to set the option, or I set it wrong. Or maybe the ssllabs scan does not consider this option?

       

      How can I test if the option is actually active on my site?

      • Re: BEAST vulnerability detection
        Ivan Ristic

        That option applies only to the server side of the communication and doesn't address BEAST, which is a client-side issue. The only way to mitigate BEAST is to use RC4 with SSL 3 and TLS 1.0. But beware, because RC4 is also insecure.

  • BEAST vulnerability detection
    steve

    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

      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

        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

          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

            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

              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

    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?

    • BEAST vulnerability detection
      Ivan Ristic

      In my opinion, yes. You should take the steps to address the BEAST problem, as explained here:

       

      https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls

       

      KB2585542 addresses only the client side of the BEAST attack, but there's nothing that can be done on the server side for it with a patch.

      • BEAST vulnerability detection
        rmoriz

        It seems that the BEAST detection produces false positives:

         

        e.g.

         

        https://www.ssllabs.com/ssltest/analyze.html?d=roland.io

        • BEAST vulnerability detection
          steve

          The warning looks perfectly correct to me.

           

          A TLS 1.0 client will use AES-256-SHA1, which is a CBC cipher and thus be vulnerable to the BEAST attack. You'd have to provide a "safe" cipher to this user, the only one available happens to be RC4.

          • BEAST vulnerability detection
            rmoriz

            using RC4 reduces the rating for ciphers :/

            • BEAST vulnerability detection
              Ivan Ristic

              That's only because we're slow to update the rating guide. Everyone vulnerable to BEAST should really get a zero score.

            • BEAST vulnerability detection
              steve

              While one can argue about the pro's and con's of using RC4, you should really ask yourself what's more important to you or your users:

              • being vulnerable (or not) to a known attack
              • or the "score" you're getting in some security test

               

              You could always politely inform the user to "upgrade" their browser security by displaying a warning when someone connects with SSLv3 or TLSv1, like discussed in some other thread and implemented by application servers for SSLv2 (i.e. sending an HTTP-500).

               

              While, in theory, this could give you a score of 100 if Ivan would extend this "refused" detection to all SSL/TLS versions, you'll lock out most users. As far as I know, there's no browser that comes with TLSv1.1 enabled by default:

              • Opera, MSIE (and some Safari versions?) are supporting this version, but it's disabled by default.
              • you'll have to wait for at least Firefox 14 or Chrome 21 in order to have TLSv1.1, while NSS has no plans to support TLSv1.2 in near future.

               

              So, what's your goal? Reaching (as close as possible) a score of 100 or merely providing your users a connection that's "secure enough"? I'm quite happy with 91 (2048 bit certificate) or 94 (4096 bit certificate) and don't prevent anyone from accessing my sites while still providing BEAST countermeasures.

              • BEAST vulnerability detection
                rmoriz

                My current goal is to get the max out of the possibilties and then check how to deal with clients. Quite a 'whitelist' approach.

                 

                I fully understand, that this is not usable outside a "lab condition" but I prefer this way instead of starting "fully vulnerable" and patching the holes as they get found...

                • BEAST vulnerability detection
                  Muhammad Anzar

                  Securitymetrics problem will solve with following SSL configuration.

                   

                          SSLEngine on

                          SSLProtocol -SSLv2 -TLSv1 +SSLv3

                          SSLHonorCipherOrder On

                          SSLCipherSuite RC4:HIGH:!AES256-SHA:!AES128-SHA:!DES-CBC3-SHA:!MD5:!aNULL:!EDH

                   

                   

                  One basic thing, Block negotiated ciphersuite negotiated which was mentioned compliance report. Example : AES256-SHA negotiated and listed in Compliance then block !AES256-SHA

                   

                   

                  Muhammad Anzar