Disable TLSv1 support in lighty / lighttpd? [2.2.2] aka POODLE

luckman212

One of our clients with a pfSense router happens to process the occasional credit card. The merchant bank has run a PCI compliance scan on our external facing IP and the report is failing with the following error:

I researched this myself and it appears that Lighttpd (the way it is configured in pfSense 2.2.2) is vulnerable to a 'downgrade attack'. I may be interpreting this wrong so please bear with me. I have found some related links:
http://www.astiostech.com/blog/?p=100
https://forum.pfsense.org/index.php?topic=82914.0
http://superuser.com/questions/631497/disable-weak-ssl-ciphers-in-lighttpd
http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL#PCI-DSS-compliance

…and even a patch from 27 days ago over on the lighty forums that adds an option which would allow one to insert the following snippet to /etc/inc/system.inc & disable TLSv1:

$lighty_config .= "ssl.use-tlsv1 = \"disable\"\n";

Is anyone aware of any other way to make this test "pass" (besides completely disabling access to the webConfigurator from outside, which is not an option for me at this time). I've already got the wC running on a non-standard port, so apparently that is not enough.

luckman212

Update: Through trial + error I found a cipher suite combo that seems to mitigate this "problem" for now. I am posting it here but if anyone sees anything wrong here please speak up. I tested this config with Chrome 42.0.2311.90, Safari 8.0.5 (10600.5.17) + IE 11.0.9600.17691 and had no issues accessing the page afterward but YMMV. sslscan comes up "clean" afterward, with all TLSv1 ciphers returning Rejected

ssh or console to your router
vi /etc/inc/system.inc
jump down to ~line 1350
comment out the ssl.cipher-list line and add the new cipher config below

$lighty_config .= "ssl.cipher-list = \"AES128+EECDH:!aNULL:!eNULL:!DSS\"\n";

restart lighttpd: /etc/rc.restart_webgui
re-test using sslscan … all should show Rejected

sslscan --tls1 192.168.1.1:443
```(replace with your router's IP:PORT)

:-\

(where to get sslscan? I used [homebrew](http://brew.sh) on my mac)

brew install sslscan

doktornotor

Hmmm. Leaving the web GUI wide open for anyone. Speechless.

luckman212

It's not "wide open" – the wC is running on an alternate port and in addition to that there is an IP whitelist in place as well as a secure password.

doktornotor

Why on earth is some bank on the IP whitelist? Are you managing the firewall from the bank? (On the "test" - why not just disable HTTPS altogether? No encryption -> no "downgrade". WTF.)

Gertjan

If I understand the issue:
You are using the pfSense web engine (Lighthttp) as a webserver that hosts your own pages (html/php) that deals with "banks and credit cards" ?
This is why you have to "open" Lighthttp on your WAN (on a different port, firewalled to limit to certain IP's, ok). Lets hoop your bank isn't Poodling.
And don't thell that you are using your firewall as a web server. You might receive some strange reactions from them ;)

Please understand that the pfSense GUI uses this Lighthttp webserver for its own needs, and by default, it's open to LAN. Doing more then that with it … well .... Your right, you're in trouble.
What about a web server behind your router/firewall (== pfSense) ? Running a web server on a firewall, well ... please, don't.
(but: killing the Poodle doesn't seem to to be a hard thing to me, you already mentioned the how-to-do-so. So, while your are patching your pfSense box, add one more patch ;))

luckman212

Guys I don't know why everyone is jumping in telling me not to use pfSense as a webserver. Where in the above posts did I say I was doing that? All I said was that the webConfigurator port is open and because of the scan that the bank does they do a full portscan and I guess just having the port open and accepting TLSv1 connections causes it to flag it as 'failed'. In any case today I got another call that the test is still failing despite me disabling all the TLSv1 ciphers so all of the above is for naught. Unless or until the patch I linked above is merged into lighttpd I suppose my only option is to close this port completely.

Gertjan

Don't worry, I just wasn't sure ;)

What about: remove the IP of your bank from the white list that rules pfSense GUI access ?
Or: use a VPN to have your pfSense GUI accessible from the 'out side.'

I fully agree that a web server, today, shouldn't be Poodle sensitive. Even if it controls my coffee machine.

phil.davis

What about: remove the IP of your bank from the white list that rules pfSense GUI access ?

The bank is likely using some automated testing-probing tool that might be run by some provider on behalf of the bank, so it might not be so easy to work out all the IP addresses from which the test might originate. If you are also moving around a similar state/region with your laptop, smartphone… and want webGUI access from whatever cafe you happen to be in, then it could be difficult to easily make a whitelist that works for this.

It really would be best to sort out what the real need is for remote webGUI access and then design a solution - like VPN.

luckman212

@phil.davis:

The bank is likely using some automated testing-probing tool

Yes I believe the tool they are using is from Trustwave.

If you are also moving around…and want webGUI access from whatever cafe you happen to be in, then it could be difficult to easily make a whitelist that works for this.

Bingo! that's exactly the situation I'm in unfortunately.

It really would be best to …design a solution - like VPN

Thanks for the advice. I have given up for now on locking down lighttpd (seems impossible without recompiling) and have just closed the webGUI port completely from outside and established a site to site from our office for management. More difficult especially when I'm not sitting at my desk (which is usually) but problem "solved" <shrug>:-</shrug>

doktornotor

Use the damned VPN for remote management. That's what should have been done in the first place. (Won't further comment on the bank's "testing", totally retarded to put it mildly…)

johnpoz

Yeah I just do not get this.. Why do people continue to open security devices or even network devices to the public net?? Use a vpn and there you go access all your admin stuff remotely from anywhere, be it starbucks or the open wifi as your driving down the street..

There just really is no excuse to having your admin shit open to the public net via whatever port you think your hiding on.. And a whitelist that would include some test site, how is that a whitelist? A whitelist would include the places you access it from, say work, your friends house. The starbucks at the corner.. Not the planet - if its planet, then its not a white list ;)

Nick

Sorry for the necro but I wanted to add this for anyone else who arrives here via Google.

We've ran into the same scenario with a company we deal with trying to do the Trustwave Scans.

The stuff they test for changes every month and it seems like we fail for something different each time.

I tried the above posted line but we still failed. After looking around, this is what I came up with:


 $lighty_config .= "ssl.cipher-list = \"TLSv1.2:!aNULL:!eNULL:!DSS\"\n";

SSLscan now shows protected on everything. BTW, you can add sslscan to pfSense via 'pkg install sslscan'