Can TLSv1.1 be disabled?

zonda

Hello,

I have pfSense appliances that are failing PCI compliance scans because TLSv1.1 is enabled. The scan is ran against the management IP for the web GUI. How/where can TLSv1.1 be disabled?

Found a previous post from several years back related to this topic but I can't find the "ssl.cipher-list" line in the /etc/inc/system.inc file referenced in that post. Is this still a valid way to disable older TLS versions?

https://forum.netgate.com/topic/83167/disable-tlsv1-support-in-lighty-lighttpd-2-2-2-aka-poodle/3

Running latest release of pfSense, 2.4.3-p1.

Here is a nmap scan result from one of the appliances showing TLSv1.1 enabled:

Starting Nmap 7.70 ( https://nmap.org ) at 2018-06-13 16:28 Eastern Daylight Time
Nmap scan report for <FQDN hostname omitted> (IP ommitted)
Host is up (0.017s latency).

zonda

Going to answer my own question

Was able to disable TLSv1.1 by editing a different line in the /etc/inc/system.inc file.

Changed the following line:
$nginx_config .= "\t\tssl_protocols TLSv1.1 TLSv1.2;\n";

To:
$nginx_config .= "\t\tssl_protocols TLSv1.2;\n";

nmap scan shows only TLSv1.2 now:

Starting Nmap 7.70 ( https://nmap.org ) at 2018-06-13 23:01 Eastern Daylight Time
Nmap scan report for <FQDN hostname ommitted> (IP ommitted)
Host is up (0.010s latency).

Maybe this may help someone else looking to do the same thing.

johnpoz

@zonda said in Can TLSv1.1 be disabled?:

The scan is ran against the management IP for the web GUI.

Why would your scan run against that? This web gui should never ever be exposed to the public internet. So why would need to be scanned to meet compliance?

zonda

It is not exposed to the public internet only to internal networks but PCI traffic goes through this appliance so it is considered in scope.

Gertjan

@zonda said in Can TLSv1.1 be disabled?:

It is not exposed to the public internet only to internal networks but PCI traffic goes through this appliance so it is considered in scope.

Then the "through" part isn't set up well.
If the traffic goes from WAN to a some sort of DMZ interface, and you lock down all console and GUI access on this DMZ interface, you'll be fine.
Console and GUI access can be disabled on all 'LAN' type interfaces if needed (but you didn't ??).
It's a question of 'just another firewall rule'.

pfSense as a router doesn't behave any different a any other router on the planet. Up to the the admin to set it up as needed.
Local 'VGA" + keyboard or serial console access will always exist, so the admin won't be locked out for good.

Years ago, the internal GUI web interface server changed from httpd to nginx - so the setting file changed also.

Btw : I'd like to understand how a 'scan' from the outside (Internet) that connects to WAN, to end up on some device behind the router/firewall pfSense, can wind up accessing the LAN interface, so it can 'see' the GUI access ...

johnpoz

^ exactly... Your just making your job harder trying to meet compliance on something that would never be in scope.

kpa

I think the issue here is that the webgui is accessible from the inside and shows up in the scans made from the inside network. Still not an excuse though because if you're serious about security you lock down access to the webgui only to a separate trusted management interface.

Gertjan

I guess the final issue is something like this :
@zonda works for a company that wanted to buy a certified PCI report.
The company that performs the PCI scan, probably (I hope so) has a big name in "security", includes a test that shows that LAN interface can access GUI port on router / firewall (like : "when you have the keys, you can actually 'take' the car and drive it away").

The concerned LAN interface should have a condemned GUI pfSense access before the tests started.

So, the PCI compliance test did a good thing : it detected a human - admin -error. (@zonda : fire the admin and you're half way).

Btw : not enabling the pfSense GUI on LAN by default would be a solution, but this forum would explode with "help I'm new at this - can't access the GUI" because these days people can only click and don't know what SSH/console/serial access is ...

johnpoz

@gertjan said in Can TLSv1.1 be disabled?:

So, the PCI compliance test did a good thing : it detected a human - admin -error

Very Very true - but vs fixing the access from the lan they are editing source files.. Which will just revert on the next upgrade, and now 1.1 would be available again..

So yeah the fire the admin is prob a good suggestion ;) Problem is I think that is zonda in this case..

oz9els

@johnpoz
PCI requires that all admin traffic (that would mean mostly internal ;-) has to be encrypted - Because of the requirements of TLS, it has to be at least TLS 1.2.

JeGr

@oz9els said in Can TLSv1.1 be disabled?:

PCI requires that all admin traffic (that would mean mostly internal ;-) has to be encrypted - Because of the requirements of TLS, it has to be at least TLS 1.2.

Including Admin traffic that they never even have to see in the first place? Seems wrong to me?
If the webUI ist only exposed on an admin-only mgmt network that you can't scan because you have to actually BE in it (that's in the definition of OOB management) it can't be scanned and thereby is not subject to the scope of PCI, is it?

jimp

The last time we revisited changing the TLS versions in the GUI web server was 3 years ago, so it's probably overdue for a refresh. Especially now that on 2.5.0 we have OpenSSL 1.1.1 and TLS 1.3 support.

https://redmine.pfsense.org/issues/9607

https://github.com/pfsense/pfsense/commit/aa618753171d9fe8d7f3c46f49a1ea16832e138b

Works fine for me locally. Though you can't apply that patch to 2.4.4-pX because it doesn't have TLS 1.3. You could make a similar change by hand to remove TLS 1.1 if you need to, though.

JeGr

@jimp I'd drop TLS1.1 for CP, too but as you already set the redmine task to resolved I didn't want to intrude. But as our internal tests and checks with services like qualys etc. showed was that if TLS1.2 is available - and to the most browsers it is! - TLS1.1 is actually never used and only used for trying to downscale attacks. Most if not all cipher suites existent with TLS 1.1 were also covered with TLS1.2. In fact we never had any client connect via 1.1 at all. Almost any connected to 1.2 and if they didn't they were only able with to run with 1.0 as they used ciphers that - if enabled - bring in 1.0 compat again.

So - while your mileage may of course vary - I'd say it safe to assume that 1.2+1.3 are enough. For CP one could argue to bringing some sort of compat switch to toggle for old devices but no need for anything lower than 1.2 for sure and the "hammer" of bringing in PCI as argument is working in our favour in this ;)

jimp

When it comes to Captive Portal, you have no idea what kind of janky mess people will connect with on BYOD and hospitality networks, especially in countries that don't always have access to the latest tech.

Not that many people use SSL with Captive Portal anyhow. We could remove it, but I'd rather leave it for the moment to be safe. Chrome just finally removed 1.1 support earlier this year.

JeGr

@jimp said in Can TLSv1.1 be disabled?:

When it comes to Captive Portal, you have no idea what kind of janky mess people will connect with on BYOD and hospitality networks, especially in countries that don't always have access to the latest tech.

I concur ;)

@jimp said in Can TLSv1.1 be disabled?:

Not that many people use SSL with Captive Portal anyhow. We could remove it, but I'd rather leave it for the moment to be safe. Chrome just finally removed 1.1 support earlier this year.

Actually I know quite a few and having ACME package available made it even wider acceptable. So perhaps a custom options or toggle setting would be nice to enforce some stricter security settings - or set that as default and a compatibility switch for 1.0+?

jimp

Might be nice to have a CP option to enable compatibility with older clients, but I'm still thinking it's safe enough just to keep 1.1 around for a little while like we did with 1.0.