WebGUI webserver will not protect a client from the BEAST attack
-
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 -
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.
-
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.
-
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?
-
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)
-
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.2If 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.
-
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
-
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 AddressServer 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 AddressNo 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.
-
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.
-
Have you ever tried browsershots.org?
-
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.
-
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.
-
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.
-
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.
-
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?
