Can TLSv1.1 be disabled?
-
^ exactly... Your just making your job harder trying to meet compliance on something that would never be in scope.
-
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.
-
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 ...
-
@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..
-
@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. -
@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? -
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.
-
@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 ;)
-
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.
-
@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+?
-
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.