Hello,
Hi,
On Sat, 2017-09-23 at 15:18 -0400, Tom Rymes wrote:
That makes sense to me. One step at a time!
On Sep 23, 2017, at 2:19 PM, Peter Müller peter.mueller@link38.eu wrote:
Hello Matthias,
your described scenario does not appear on my machine. :-(
However, the "Require ssl" directive seems not to work with the 2.2.x branch, here, we still need the old "SSLRequireSSL". (On the other hand, it was intended to be used with the new version.)
Which version are you running?
I think the best solution for now is to disregard this patch. After the Core Update with 2.4.27 version was released, I'll give it another try.
Well, the update for Apache 2.4 is in next right now.
Yes, I saw Arne closing Core114 a few hours ago.
If there is any doubt on whether SSL is always enforced or not we should investigate as soon as possible. I don't think that we should wait too much longer with the entire update any ways, but this certainly delays it.
SSL enforcement is not the problem here. The problem is to make sure SSL is enforced in case sensitive data (logins, configuration settings, ...) are transmitted.
Enforcing SSL globally on IPFire is not possible AFAIK, since we need some plaintext transfer for Squid error messages, and the update accelerator, and things like that.
At the moment - without the patch I sent in - it is possible to log in to the WebUI without SSL by using port 81.
The patch was intended for Apache 2.4.x, since on 2.2.x, the "Require ssl" is just ignored. On the other hand, "SSLRequireSSL" would work on both versions, but is depreached in 2.4.x.
Since I cannot reproduce the scenario Matthias wrote, I strongly recommend not to apply the patch until this has been clarified. If possible, I will test this in a VDI/Nightly Build image tomorrow.
Besides from that, there are two aspects to discuss in the meantime: :-) (a) Looking at the actual configuration files in "/etc/httpd/conf/vhosts.d/", it might make sense to delete all directory blocks in the "ipfire-interface.conf" which require an authentication and replace them with a HTTP 301 redirect to the SSL location.
That way, even if Apache ignores the whatever-named directive to force SSL, transmitting login data in plaintext is not possible. Thinking about this, I like this idea better than my original one.
Resources without authentication must remain untouched (as mentioned above).
(b) Although this is a security vulnerability, it is not a very severe one in the default configuration - as far as I am concerned.
It requires a MITM between IPFire and the administrator's computer, and an admin who accesses the unencrypted resource on port 81 every time or in case the MITM blocked encrypted connections to 444.
Of course, in case anybody created a firewall rule allowing traffic from RED to IPFire's internal port 81 and 444, this issue becomes quite critical. According to Shodan, a lot of people do so.
To sum it up: We/I should fix this as soon as possible, but in case it needs some more time, it's severity does not require a delay to Core 114 as far as I am concerned.
I would be happy to get feedback, especially to (a).
Hopefully, I have a working patch ready by tomorrow evening.
Best regards, Peter Müller
@Michael P.S.: What about the other patches (ECDSA, SSL ciphers and all the minor WebUI stuff)? Are they not working, too?
Best, -Michael
@All: Anybody against or in favor?
Best regards, Peter Müller
Hello Matthias,
tanks for reporting this. I am trying to reproduce here...
Best regards, Peter Müller
Hi Peter,
Please review this patch... (http://patchwork.ipfire.org/patch/1413/)
During testing I found that every machine in my GREEN net was suddenly able to login through https://%5BIPFIRE_GREEN_ADDRESS%5D:%5B444].
No question for admin-username, no password authentification request, nothing.
It seems as as if the Authentication Header is missing(?).
Only when I remove the "Require ssl" lines (I did this in both files), a browser restart leads to the usual login procedure.
Best, Matthias
On 08.09.2017 19:19, Peter Müller wrote: Force SSL/TLS for any WebUI directory which requires an authentication. This prevents credentials from being transmitted in plaintext, which is an information leak.
Scenario: A MITM attacker might block all encrypted traffic to the firewall's web interface, making the administrator using an unencrypted connection (i.e. via port 81). Username and password can be easily logged in transit then.
Signed-off-by: Peter Müller peter.mueller@link38.eu
diff --git a/config/httpd/vhosts.d/ipfire-interface-ssl.conf b/config/httpd/vhosts.d/ipfire-interface-ssl.conf index 6f353962e..5ceaa1f32 100644 --- a/config/httpd/vhosts.d/ipfire-interface-ssl.conf +++ b/config/httpd/vhosts.d/ipfire-interface-ssl.conf @@ -24,6 +26,7 @@ AuthType Basic AuthUserFile /var/ipfire/auth/users Require user admin
Require ssl</DirectoryMatch> ScriptAlias /cgi-bin/ /srv/web/ipfire/cgi-bin/ <Directory /srv/web/ipfire/cgi-bin>
@@ -33,6 +36,7 @@ AuthType Basic AuthUserFile /var/ipfire/auth/users Require user admin
Require ssl <Files chpasswd.cgi> Require all granted </Files>@@ -50,6 +54,7 @@ AuthType Basic AuthUserFile /var/ipfire/auth/users Require user dial admin
Require ssl</Directory> <Files ~ "\.(cgi|shtml?)$"> SSLOptions +StdEnvVars
@@ -86,5 +91,6 @@ AuthType Basic AuthUserFile /var/ipfire/auth/users Require user admin
Require ssl</Directory>
</VirtualHost> diff --git a/config/httpd/vhosts.d/ipfire-interface.conf b/config/httpd/vhosts.d/ipfire-interface.conf index 619f90fcc..58d1b54cd 100644 --- a/config/httpd/vhosts.d/ipfire-interface.conf +++ b/config/httpd/vhosts.d/ipfire-interface.conf @@ -16,6 +16,7 @@ AuthType Basic AuthUserFile /var/ipfire/auth/users Require user admin + Require ssl </DirectoryMatch> ScriptAlias /cgi-bin/ /srv/web/ipfire/cgi-bin/ <Directory /srv/web/ipfire/cgi-bin> @@ -25,6 +26,7 @@ AuthType Basic AuthUserFile /var/ipfire/auth/users Require user admin + Require ssl <Files chpasswd.cgi> Require all granted </Files> @@ -42,6 +44,7 @@ AuthType Basic AuthUserFile /var/ipfire/auth/users Require user dial admin + Require ssl </Directory> Alias /updatecache/ /var/updatecache/ <Directory /var/updatecache>