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