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>
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>
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>
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.
@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>
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.
@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>
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.
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.
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>
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>
Hi,
On Sat, 2017-09-23 at 21:56 +0200, Peter Müller wrote:
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.
Oh. :)
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).
Agreed. This is what we should do. Looking back I have no idea why this was ever done this way. I remember historically the web if didn't have SSL and it was added later, but not all browsers supported it. So HTTP was meant to be working as well as HTTPS.
Since we have had this issue before Apache 2.4, I guess it does not make sense to delay the update for it.
(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.
Since we use SSL and nobody can properly validate the certificate, MITM is always super easy to do to be honest.
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.
Those misconfigured a lot. They are on their own.
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.
See above.
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?
No, not yet. Things have been very busy around me and this is solely on me.
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> >
Hello,
just sent in a second version of the patch. It should work now.
@Matthias: You were right. The "<RequireAll>" is needed in order to make both Require-directives mandatory (found here: https://httpd.apache.org/docs/2.4/howto/auth.html#beyond).
Further, the redirect to the SSL sites are marked with 301 ("permanently") so the browsers never forget them. :-)
Patch works here, but please test, too.
Best regards, Peter Müller
Hi,
On Sat, 2017-09-23 at 21:56 +0200, Peter Müller wrote:
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.
Oh. :)
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).
Agreed. This is what we should do. Looking back I have no idea why this was ever done this way. I remember historically the web if didn't have SSL and it was added later, but not all browsers supported it. So HTTP was meant to be working as well as HTTPS.
Since we have had this issue before Apache 2.4, I guess it does not make sense to delay the update for it.
(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.
Since we use SSL and nobody can properly validate the certificate, MITM is always super easy to do to be honest.
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.
Those misconfigured a lot. They are on their own.
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.
See above.
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?
No, not yet. Things have been very busy around me and this is solely on me.
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> > >
On 23.09.2017 20:19, Peter Müller wrote:
Hello Matthias,
your described scenario does not appear on my machine. :-(
Hm... Weird.
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?
Sorry, forgot. I'm using 2.4.27 from current 'next', built today, on Core 113.
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.
See above... It won't work here: I just verified this behaviour on my test machine. *With* "Require ssl" I get instant (https-)access, *without* "Require ssl" I'm asked for username / password.
Best, Matthias
@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>
Hello Matthias,
thanks for the quick reply.
On 23.09.2017 20:19, Peter Müller wrote:
Hello Matthias,
your described scenario does not appear on my machine. :-(
Hm... Weird.
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?
Sorry, forgot. I'm using 2.4.27 from current 'next', built today, on Core 113.
Ah, I was still at 2.2.x (where the patch has no effect) and tested against a 2.4.x web server I had at hand.
Promise to test better next time.
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.
See above... It won't work here: I just verified this behaviour on my test machine. *With* "Require ssl" I get instant (https-)access, *without* "Require ssl" I'm asked for username / password.
Well, according to the Apache docs (https://httpd.apache.org/docs/current/mod/mod_ssl.html#reqssl), one cannot assume that this breaks "Require valid-user". Looks somehow like a bug in Apache...
I think I will just replace the directories with HTTP 301 in the unencrypted file (as I mentioned in the other mail), but for the "ipfire-interface-ssl.conf" file, we can assume SSL is used, anyway.
We _can_ assume, but we are not sure. :-|
Will use a nightly build tomorrow and develop a better patch.
Best regards, Peter Müller
Best, Matthias
@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>
Sent from IBM Verse
Peter Müller --- Re: [PATCH] force transport encryption for WebUI logins --- From:"Peter Müller" peter.mueller@link38.euTo:"Matthias Fischer" matthias.fischer@ipfire.orgCc:development@lists.ipfire.orgDate:Sat, Sep 23, 2017 3:08 PMSubject:Re: [PATCH] force transport encryption for WebUI logins
Hello Matthias,thanks for the quick reply.> On 23.09.2017 20:19, Peter Müller wrote:> > Hello Matthias,> > > > your described scenario does not appear on my machine. :-( > > Hm... Weird.> > > 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? > > Sorry, forgot. I'm using 2.4.27 from current 'next', built today, on> Core 113.Ah, I was still at 2.2.x (where the patch has no effect) and testedagainst a 2.4.x web server I had at hand.Promise to test better next time.> > > 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. > > See above... It won't work here: I just verified this behaviour on my> test machine. *With* "Require ssl" I get instant (https-)access,> *without* "Require ssl" I'm asked for username / password.Well, according to the Apache docs (https://httpd.apache.org/docs/current/mod/mod_ssl.html#reqssl),one cannot assume that this breaks "Require valid-user". Looks somehowlike a bug in Apache...I think I will just replace the directories with HTTP 301 in theunencrypted file (as I mentioned in the other mail), but for the"ipfire-interface-ssl.conf" file, we can assume SSL is used, anyway.We _can_ assume, but we are not sure. :-|Will use a nightly build tomorrow and develop a better patch.Best regards,Peter Müller> > Best,> Matthias> > > @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/)%3E >> > > >> > During testing I found that every machine in my GREEN net was suddenly> >> > able to login through https://%5BIPFIRE_GREEN_ADDRESS%5D:%5B444%5D.%3E >> > > >> > 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>> >> > > > >> > > >> > > > > > > >
-
Matthias Fischer -
Michael Tremer -
Peter Müller -
tbuchanan＠vinu.edu -
Tom Rymes