WebGUI webserver will not protect a client from the BEAST attack

jimp · 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.

Supermule · Jul 17, 2013, 2:02 PM

Have you ever tried browsershots.org?

Derelict · 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.

dhatz · 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.

doktornotor · 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.

Derelict · Jul 17, 2013, 5:36 PM

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.

jimp · Jul 17, 2013, 5:39 PM

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?

Derelict · Jul 17, 2013, 6:23 PM

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.

Derelict · Jul 17, 2013, 7:00 PM

Erasing the config and starting over did not fix it.

Derelict · Jul 18, 2013, 6:19 AM

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.

jimp · Jul 18, 2013, 12:13 PM

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.

jimp · Jul 18, 2013, 12:44 PM

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

jimp · Jul 18, 2013, 1:36 PM

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. :-)

Derelict · Jul 18, 2013, 10:25 PM

All works for me now. Thanks.

dweimer · Jul 19, 2013, 1:35 AM

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.

A Former User · Aug 15, 2013, 6:25 PM

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