• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

WebGUI webserver will not protect a client from the BEAST attack

2.1 Snapshot Feedback and Problems - RETIRED
12
35
13.7k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • D
    dhatz
    last edited by Jun 30, 2013, 8:04 PM

    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…

    1 Reply Last reply Reply Quote 0
    • R
      Roots0
      last edited by Jun 30, 2013, 10:41 PM

      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/

      Mobile Computer & Network Support Stockport, UK
      www.timotten.co.uk

      1 Reply Last reply Reply Quote 0
      • D
        dhatz
        last edited by Jul 1, 2013, 1:50 AM

        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

        1 Reply Last reply Reply Quote 0
        • K
          Kossy
          last edited by Jul 1, 2013, 2:03 PM

          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

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by Jul 1, 2013, 2:06 PM

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

            1 Reply Last reply Reply Quote 0
            • K
              Klaws
              last edited by Jul 1, 2013, 2:40 PM

              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.

              1 Reply Last reply Reply Quote 0
              • D
                doktornotor Banned
                last edited by Jul 1, 2013, 2:46 PM

                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.

                1 Reply Last reply Reply Quote 0
                • N
                  NOYB
                  last edited by Jul 1, 2013, 4:18 PM

                  @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?

                  1 Reply Last reply Reply Quote 0
                  • D
                    dhatz
                    last edited by Jul 14, 2013, 7:32 PM

                    @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.

                    1 Reply Last reply Reply Quote 0
                    • K
                      kejianshi
                      last edited by Jul 14, 2013, 7:53 PM

                      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.

                      1 Reply Last reply Reply Quote 0
                      • K
                        kejianshi
                        last edited by Jul 15, 2013, 12:13 AM Jul 14, 2013, 9:58 PM

                        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)

                        1 Reply Last reply Reply Quote 0
                        • jimpJ
                          jimp Rebel Alliance Developer Netgate
                          last edited by Jul 15, 2013, 2:47 PM

                          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.

                          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                          Need help fast? Netgate Global Support!

                          Do not Chat/PM for help!

                          1 Reply Last reply Reply Quote 0
                          • DerelictD
                            Derelict LAYER 8 Netgate
                            last edited by Jul 16, 2013, 10:11 PM Jul 15, 2013, 9:05 PM

                            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

                            Chattanooga, Tennessee, USA
                            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                            Do Not Chat For Help! NO_WAN_EGRESS(TM)

                            1 Reply Last reply Reply Quote 0
                            • DerelictD
                              Derelict LAYER 8 Netgate
                              last edited by Jul 16, 2013, 10:12 PM

                              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:
                              $

                              Chattanooga, Tennessee, USA
                              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                              Do Not Chat For Help! NO_WAN_EGRESS(TM)

                              1 Reply Last reply Reply Quote 0
                              • K
                                Klaws
                                last edited by Jul 17, 2013, 1:18 PM

                                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.

                                1 Reply Last reply Reply Quote 0
                                • jimpJ
                                  jimp Rebel Alliance Developer Netgate
                                  last edited by Jul 17, 2013, 1:35 PM

                                  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.

                                  Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                  Need help fast? Netgate Global Support!

                                  Do not Chat/PM for help!

                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    Supermule Banned
                                    last edited by Jul 17, 2013, 2:02 PM

                                    Have you ever tried browsershots.org?

                                    1 Reply Last reply Reply Quote 0
                                    • DerelictD
                                      Derelict LAYER 8 Netgate
                                      last edited by Jul 17, 2013, 3:50 PM

                                      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.

                                      Chattanooga, Tennessee, USA
                                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                      1 Reply Last reply Reply Quote 0
                                      • D
                                        dhatz
                                        last edited by Jul 17, 2013, 4:12 PM

                                        @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.

                                        1 Reply Last reply Reply Quote 0
                                        • D
                                          doktornotor Banned
                                          last edited by Jul 17, 2013, 4:16 PM

                                          @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.

                                          1 Reply Last reply Reply Quote 0
                                          • First post
                                            Last post
                                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.