WebGUI webserver will not protect a client from the BEAST attack



  • It seems that pfsense webGUI webserver (lighttpd) currently will not protect a client from the BEAST attack.

    Here's the output from the http://www.bolet.org/TestSSLServer/ tool run against a stock pfsense 2.1

    java -jar TestSSLServer.jar pfsense-ip port

    Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
    Deflate compression: no
    Supported cipher suites (ORDER IS NOT SIGNIFICANT):
     SSLv3
        RSA_WITH_RC4_128_MD5
        RSA_WITH_RC4_128_SHA
        RSA_WITH_AES_128_CBC_SHA
        DHE_RSA_WITH_AES_128_CBC_SHA
        RSA_WITH_AES_256_CBC_SHA
        RSA_WITH_CAMELLIA_128_CBC_SHA
        DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
        RSA_WITH_CAMELLIA_256_CBC_SHA
        DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
     (TLSv1.0: idem)
     (TLSv1.1: idem)
     (TLSv1.2: idem)
    –--------------------
    Server certificate(s):
     25dae313c5e741f6d6aed73f5c095931430dd3ad: EMAILADDRESS=Email Address, CN="Common Name (eg, YOUR name)", OU="Organizational Unit Name (eg, section)", O=CompanyName, L=Somecity, ST=Somewhere, C=US

    Minimal encryption strength:     strong encryption (96-bit or more)
    Achievable encryption strength:  strong encryption (96-bit or more)
    BEAST status: vulnerable
    CRIME status: protected



  • After changing lighttpd config file to include:

    ssl.cipher-list =  "ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM"
    ssl.honor-cipher-order = "enable"

    the TestSSLServer tool produces the following output:

    Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
    Deflate compression: no
    Supported cipher suites (ORDER IS NOT SIGNIFICANT):
      SSLv3
        RSA_WITH_RC4_128_SHA
        RSA_WITH_3DES_EDE_CBC_SHA
        RSA_WITH_AES_128_CBC_SHA
        RSA_WITH_AES_256_CBC_SHA
        RSA_WITH_CAMELLIA_128_CBC_SHA
        RSA_WITH_CAMELLIA_256_CBC_SHA
        TLS_ECDHE_RSA_WITH_RC4_128_SHA
        TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
      (TLSv1.0: idem)
      (TLSv1.1: idem)
      TLSv1.2
        RSA_WITH_RC4_128_SHA
        RSA_WITH_3DES_EDE_CBC_SHA
        RSA_WITH_AES_128_CBC_SHA
        RSA_WITH_AES_256_CBC_SHA
        RSA_WITH_AES_128_CBC_SHA256
        RSA_WITH_AES_256_CBC_SHA256
        RSA_WITH_CAMELLIA_128_CBC_SHA
        RSA_WITH_CAMELLIA_256_CBC_SHA
        TLS_ECDHE_RSA_WITH_RC4_128_SHA
        TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    –--------------------
    Server certificate(s):
      25dae313c5e741f6d6aed73f5c095931430dd3ad: EMAILADDRESS=Email Address, CN="Common Name (eg, YOUR name)", OU="Organizational Unit Name (eg, section)", O=CompanyName, L=Somecity, ST=Somewhere, C=US

    Minimal encryption strength:    strong encryption (96-bit or more)
    Achievable encryption strength:  strong encryption (96-bit or more)
    BEAST status: protected
    CRIME status: protected

    (note: the above mentioned lighttpd conf directives were used after very some quick googling at 5:00am local time; some further checking should be performed before committing them)



  • Hmm, upon further searching, it seems that TLS 1.2 and GCM suites should be preferred

    http://blog.ivanristic.com/2013/03/rc4-in-tls-is-broken-now-what.html



  • The reason I looked into this was because a poster at the PIAF forum had just reported that his IP-PBX was hacked via a BEAST attack:

    http://pbxinaflash.com/community/index.php?threads/beast-attack-patch.12680/

    Was victim of attacks that uses TLSv1 via SSL exploitation.
    It cost me dearly!!! The attacker virtually read my configuration of my registration trunk and made hundreds of dollars of long distance
    Seem the remedy is located here http://serverkb.co.uk/wiki/CentOS search for Beast Attack
    Also it may be well too to apply SSL CRIME attack at the same time
    Took me a little while to figure how they access my box when virtually i close almost all port to the external world.

    Frankly I'm quite skeptical of the report, but if confirmed, it means that cybercriminals have taken their game to a whole different level …



  • I'm bringing this up again, because it seems to be reason enough to fail a security audit.

    A quick google-search produces tens of cases, e.g.

    https://forums.bluecoat.com/viewtopic.php?f=1&t=24097

    BEAST (Browser Exploit Against SSL/TLS) Vulnerability
    Postby RayLilly » Wed Mar 20, 2013 11:19 am

    Proxy SG210-25 (used as a reverse proxy)
    SGOS 5.4.12.1

    Looking for some suggestions. Failing my PCI audit (Trustwave) for the BEAST (Browser Exploit Against SSL/TLS) Vulnerability.

    Support suggested the temporary workaround is to enable only HIGH cipher suites DES-CBC3-SHA, DES-CBC3-MD5 and AES256-SHA. From what I have read, this will not be acceptable to pass the PCI audit. This vulnerability exists in all CBC based ciphers like AES, DES and Triple DES used in SSL V3/TLS 1.0. Each of the cipher suites used in their temporary workaround…



  • If its just a case of enforcing an increased cypher strength seems like it should't be to tricky to fix, you could try submitting a redmine ticket: http://redmine.pfsense.org/projects/pfsense/



  • Well, since the diff is only a couple of lines, I just opened a pull request.
    However, it should be tested in case it introduces any regressions …

    I noticed this old issue at redmine http://redmine.pfsense.org/issues/2553



  • FYI: if you want to be protected against BEAST, don't get vulnerable against RC4 …
    http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html


  • Banned

    This whole PKI model is plain FUBARed… waste of time.



  • Well…OTPs are secure, everything else can be broken. Of cource, using an imperfect RNG for the OTPs would render them breakable as well.

    So, what are you suggesting? Ditch all attempts on reasonable security? What's the alternative? No security at all?

    Or going back to good old physical security? Yup, the Internet model is plain FUBARed…waste of time...exchange data via a station wagon loaded with magnetic tapes.

    Okay, let's get back on topic. The victim whose PBX was broken into suffered from dumbness, IMHO. C'mon...exposing the web management interface to the public internet...that's an, erm, "interesting" idea. I know that there are cases where this cannot be avoided without suffering some inconvinience. If it must be, whitelists can be employed, so even if an 1337 haxor finds out the secret password of the PBX still cannot get in.

    Btw, secret PBX passwords...you know 'em all. The all-time favourite, 123456. For less security inclined people, 1234. And the striong security passcode, 12345678. Yup, seen them all!

    Besides, I do not automatically assume that a web interface is secure. Secret backdoor passwords, web server vulnerabilities, whatever.

    Luckily, we are here on the pfSense forum. We are therefore enlighted, somehow, and can set up a VPN tunnel so we don't need to expose a web management interface (or SSH) to the internet.


  • Banned

    I am not suggesting anything. HTTPS (SSL/TLS) connection only tells you the connection is somehow encrypted. It does not ensure you are talking to the intended other side or anything similar in any way. The encryption may be broken as early as when the traffic hits your corporate proxy/router with a wildcard certificate installed by the device vendor on the box (which is set up as trusted root CA by the corporate policies -GPO or whatever similar). Even worse, some antivirus apps running on localhost do the same with HTTPS traffic. You trust PKI/certificates/HTTPS? Foolish at best.



  • @doktornotor:

    I am not suggesting anything. HTTPS (SSL/TLS) connection only tells you the connection is somehow encrypted. It does not ensure you are talking to the intended other side or anything similar in any way. The encryption may be broken as early as when the traffic hits your corporate proxy/router with a wildcard certificate installed by the device vendor on the box (which is set up as trusted root CA by the corporate policies -GPO or whatever similar). Even worse, some antivirus apps running on localhost do the same with HTTPS traffic. You trust PKI/certificates/HTTPS? Foolish at best.

    Not an expert here but what you just described sounds like a system that was under an untrusted party control at some point.  Can a man in the middle proxy/router with wildcard cert be effective if access and control has never been available to a second party?

    For example.  OpenVPN to home pfSense OpenVPN server from work through corp socks proxy.  Are you saying the corp can break into the VPN?



  • @dhatz:

    Well, since the diff is only a couple of lines, I just opened a pull request.
    However, it should be tested in case it introduces any regressions …

    Folks, could you help test this small BEAST mitigation patch
    https://github.com/pfsense/pfsense/pull/683
    to assure it doesn't negatively impact browsers ?

    I've only tested it with current versions of Chrome, Firefox and MSIE8 on Windows & Linux.

    However since this is lighttpd's "official" fix to mitigate the risk of BEAST attacks, and it has been published almost 1.5 year ago, and I couldn't find any reports about incompatibilities, I would assume it's reasonably safe to merge.



  • There is a quick fix.
    Run the pfsense web interface in HTTP only so that no one is craze enough to leave it facing the WEB.
    Personally, I like OpenvpnAS menu solution.  Put a tick box there "protect against Beast" that defaults everything to safer settings.



  • I have always sort of laughed at the concept of asking a big third party to gen me up a weak crap cert so I can get a green banner on my screen.  I gave a third party all my crypt and passwords…  Now I feel safe forever.
    But, green is such a pretty color.

    Anyway.  I saw this:

    http://blog.lighttpd.net/articles/2013/06/01/mitigating-beast-with-gnutls/

    and testing online here:

    https://www.ssllabs.com/ssltest/  (tick the Do not show the results on the boards box)

    I get an A (Ignoring trusted certs.  I self sign.  No beast or crime issues)
    (Now I feel so much safer than I did 30 minutes ago....)

    (But the port I had open to Stunnel is vulnerable to beast.  Not sure what to do about Stunnel)


  • Rebel Alliance Developer Netgate

    I went ahead and merged the patch since my testing showed it to be OK on all of the following:

    Chrome 28 on Android 4.1.1
    Browser on Android 4.1.1
    Browser on Android 2.3.4
    Chromium 27 on FreeBSD
    Konquerer 4.10.5 on FreeBSD
    Opera 12.16 on FreeBSD
    Firefox 22 on Windows
    Chrome 28 on Windows
    IE 10 on Windows 8
    Safari on iOS 6.1.3 (iPod Touch)
    Chrome 27 on iOS 6.1.3 (iPod Touch)
    Safari 6 on OS X 10.8.2
    Chrome 28 on OS X 10.8.2

    If anyone wants to try it on other browsers not listed there, it would still be appreciated. Just upgrade to a current snapshot and try any browser you can get your hands on.


  • LAYER 8 Netgate

    Just updated to Mon Jul 15 03:12:06 i386 NanoBSD and neither Firefox 22 nor Safari can establish an SSL connection (OS X 10.8.4).

    Firefox reports: "SSL received a record with an incorrect Message Authentication Code.  Error Code ssl_error_bad_mac_read"

    ETA: Also get an ERR_SSL_PROTOCOL_ERROR on Chrome 28.0.1500.71


  • LAYER 8 Netgate

    OpenSSL s_client output

    $ /usr/bin/openssl s_client -connect 172.30.30.1:443
    CONNECTED(00000003)
    depth=0 /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
    verify error:num=18:self signed certificate
    verify return:1
    depth=0 /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
    verify return:1
    –-
    Certificate chain
    0 s:/C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
      i:/C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address

    Server certificate
    -----BEGIN CERTIFICATE-----
    MIIEKDCCA5GgAwIBAgIJAIUV0hK0KPANMA0GCSqGSIb3DQEBCwUAMIG/MQswCQYD
    VQQGEwJVUzESMBAGA1UECBMJU29tZXdoZXJlMREwDwYDVQQHEwhTb21lY2l0eTEU
    MBIGA1UEChMLQ29tcGFueU5hbWUxLzAtBgNVBAsTJk9yZ2FuaXphdGlvbmFsIFVu
    aXQgTmFtZSAoZWcsIHNlY3Rpb24pMSQwIgYDVQQDExtDb21tb24gTmFtZSAoZWcs
    IFlPVVIgbmFtZSkxHDAaBgkqhkiG9w0BCQEWDUVtYWlsIEFkZHJlc3MwHhcNMTMw
    NzA5MDgwNDU2WhcNMTgxMjMwMDgwNDU2WjCBvzELMAkGA1UEBhMCVVMxEjAQBgNV
    BAgTCVNvbWV3aGVyZTERMA8GA1UEBxMIU29tZWNpdHkxFDASBgNVBAoTC0NvbXBh
    bnlOYW1lMS8wLQYDVQQLEyZPcmdhbml6YXRpb25hbCBVbml0IE5hbWUgKGVnLCBz
    ZWN0aW9uKTEkMCIGA1UEAxMbQ29tbW9uIE5hbWUgKGVnLCBZT1VSIG5hbWUpMRww
    GgYJKoZIhvcNAQkBFg1FbWFpbCBBZGRyZXNzMIGfMA0GCSqGSIb3DQEBAQUAA4GN
    ADCBiQKBgQDRoDMwP9ae97B5IheY4MZ8euLNoYMupCzAssPq4561Rr57K5pVAspL
    pdHwD0oLkQMUopHrUU+qulcT4+RlHA0SGYP7bluyLAgAOaZmNWFLa1loglhdAKcB
    iJo1NaSLC73uP/j5LWlOPjJ8NQCFt2Bchs57rRGlVSkDHJPd3Dgt0wIDAQABo4IB
    KDCCASQwHQYDVR0OBBYEFG1bzWWh5eS1rdjTY2YGwcnme3cmMIH0BgNVHSMEgeww
    gemAFG1bzWWh5eS1rdjTY2YGwcnme3cmoYHFpIHCMIG/MQswCQYDVQQGEwJVUzES
    MBAGA1UECBMJU29tZXdoZXJlMREwDwYDVQQHEwhTb21lY2l0eTEUMBIGA1UEChML
    Q29tcGFueU5hbWUxLzAtBgNVBAsTJk9yZ2FuaXphdGlvbmFsIFVuaXQgTmFtZSAo
    ZWcsIHNlY3Rpb24pMSQwIgYDVQQDExtDb21tb24gTmFtZSAoZWcsIFlPVVIgbmFt
    ZSkxHDAaBgkqhkiG9w0BCQEWDUVtYWlsIEFkZHJlc3OCCQCFFdIStCjwDTAMBgNV
    HRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4GBALL7gvNQsBG5RLUsvKYNxd+KFrzQ
    QR30syfu4MDNrgrogzRAU4YG6w4uGXDNzeWqnsYPY2vY/bcObabU3loOTaonL43m
    BDQP5Ny61ugJ8+dGEzDaNdYnLDhXAs2T3s7RV886bi5EMhaXHIWEZHrFmwWbCDHz
    +of9cfWPcrPJU7k7
    -----END CERTIFICATE-----
    subject=/C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
    issuer=/C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address

    No client certificate CA names sent

    SSL handshake has read 1225 bytes and written 316 bytes

    New, TLSv1/SSLv3, Cipher is RC4-SHA
    Server public key is 1024 bit
    Secure Renegotiation IS supported
    Compression: NONE
    Expansion: NONE
    SSL-Session:
        Protocol  : TLSv1
        Cipher    : RC4-SHA
        Session-ID: E2B56E5E4D6290A0F106A3501BB6CF184C2687EDE09D6FF9BF063166E67DE34C
        Session-ID-ctx:
        Master-Key: CD81CF270A34757E39CD1C359D4115BA944B88CDDB1FCC343F7ADF4BD8F994DE8C75A966ADC631C0D796BF894311FDFA
        Key-Arg  : None
        Start Time: 1374012478
        Timeout  : 300 (sec)
        Verify return code: 18 (self signed certificate)

    GET / HTTP/1.1
    1185:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:/SourceCache/OpenSSL098/OpenSSL098-47.1/src/ssl/s3_pkt.c:431:
    $



  • I very vaguely remember to have heard that Firefox and Chrome do not accept self-signed certificates under MacOS.

    Let me have a look…Google leads to this: http://stackoverflow.com/questions/7580508/getting-chrome-to-accept-self-signed-localhost-certificate (scroll a bit down to the answer beginning with "On the Mac"). Well, the OP claims that FF works - maybe my memory concerning this issue was a bit dim.


  • Rebel Alliance Developer Netgate

    The only issue I'm aware of in FF is that it won't take self-signed certs using an IPv6 IP address in the URL (but by hostname it's fine) on any OS, last I tried it.

    I tried Safari and FF on OSX and they worked for me, but I am a couple point releases behind on there.


  • Banned

    Have you ever tried browsershots.org?


  • LAYER 8 Netgate

    Self-signed certs work fine.  The only place I am seeing this is on webConfigurator on my test soekris with later 2.1 snapshots.

    Note that raw openssl s_client fails the same way and has nothing to do with any of the browsers.



  • @Derelict:

    Self-signed certs work fine.  The only place I am seeing this is on webConfigurator on my test soekris with later 2.1 snapshots.

    Note that raw openssl s_client fails the same way and has nothing to do with any of the browsers.

    I tried
    /usr/bin/openssl s_client -connect pfsense_ip:port
    from 3 different systems using openssl 0.9.8o to 1.0.1e and didn't notice any ill effects …

    The new settings also work with every web browser I've tried on Windows and Linux.


  • Banned

    @dhatz:

    The new settings also work with every web browser I've tried on Windows and Linux.

    Ditto, just WFM. SCNR - bitten fruit co. sucks once again.


  • LAYER 8 Netgate

    So this has degenerated into "blame apple" already?  Ok.

    I don't know that it's not localized to this laptop, but all I did was update the snapshot on the soekris and what was working fine is now not.


  • Rebel Alliance Developer Netgate

    It isn't really even Apple in general, all my other Apple tests were OK (iOS and OS X) so it could be specific to that laptop, that version of OS X, or something else.

    Until we get some more feedback from others, anything is speculation.

    Can you hit that same firewall with any other browser on another OS?
    Can you run a firmware upgrade on it again (using ssh or the console) to see if anything is different?


  • LAYER 8 Netgate

    I just put my 10.6.8 iMac on it.  Same thing using Firefox.

    Grabbed a random laptop.  Vista.  IE says it can't connect and Firefox gives me the same ssl_error_bad_mac_read.

    Looks like it's something on this pfSense install.

    I am going to save my config (in case anyone needs to see it later), wipe the config, reconfigure and see what happens.

    If it still exhibits the same behavior I'll re-flash the CF from the latest snapshot and try it again.


  • LAYER 8 Netgate

    Erasing the config and starting over did not fix it.


  • LAYER 8 Netgate

    So I took the Soekris home and reimaged the CF with gzcat pfSense-2.1-RC0-4g-i386-nanobsd-20130717-1018.img.gz | dd of=/dev/disk4 bs=64k

    On my first connection to http://192.168.1.1/ I am redirected to 443, prompted to confirm the self-signed certificate, and get ssl_error_bad_mac_read.

    Maybe this is nanobsd specific?  HIFN specific?

    All I know is it isn't working for me on this hardware since the BEAST fix was merged.

    For grins I removed the HIFN card and tried it again.  Worked fine.

    Replaced the HIFN card, failed again.

    I think it's something to do with HIFN somehow.


  • Rebel Alliance Developer Netgate

    Aha, that could be it. Wouldn't be the first time a crypto card caused something like that to happen.

    The Hifn card may not like the cipher being chosen by default.

    I guess I'll have to put in a checkbox somewhere and restore the old behavior by default with a note about some crypto accelerators not supporting it.

    I have a Hifn card here somewhere but it's not currently in my ALIX. I can swap it in and test.


  • Rebel Alliance Developer Netgate

    Yep, I put the Hifn in and the GUI won't load. Easy to reproduce it that way.


  • Rebel Alliance Developer Netgate

    OK it's now off by default and a checkbox option:
    https://github.com/pfsense/pfsense/commit/30adceda1fffe160d18bdcbcaccb0da5de000fdf

    I have the code disable the option in the GUI if it detects a Hifn card and also if the option is somehow set (restoring a config?) and it detects a Hifn card it will refuse to honor the option.

    Should result in a working GUI no matter how someone tries to break it. :-)


  • LAYER 8 Netgate

    All works for me now.  Thanks.



  • Interesting, I found this thread after hitting the problem 7-16, I fixed it by logging in through ssh and manually entering the update url for the 14th.  I was checking back today to see if the problem was solved.  And yes I do have a Hifn 7955 in an Alix.6e1 that it was installed on, I didn't test pulling the card out to see if it fixed it, as I didn't expect that to be an issue.



  • @dhatz:

    After changing lighttpd config file to include:

    ssl.cipher-list =  "ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM"
    ssl.honor-cipher-order = "enable"

    Hello

    A question: Why do you actually disallow AESGCM instead of putting it at the very front of the cipher order?


Log in to reply