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

PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
| compressors:
| NULL
| cipher preference: server
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A

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

PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A

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