From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH] force transport encryption for WebUI logins Date: Sun, 24 Sep 2017 09:11:31 +0200 Message-ID: <20170924091131.44878950.peter.mueller@link38.eu> In-Reply-To: <1506200618.2489.5.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0039797305888801194==" List-Id: --===============0039797305888801194== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, just sent in a second version of the patch. It should work now. @Matthias: You were right. The "" 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=C3=BCller > Hi, >=20 > On Sat, 2017-09-23 at 21:56 +0200, Peter M=C3=BCller wrote: > > Hello, > > =20 > > > Hi, > > >=20 > > > On Sat, 2017-09-23 at 15:18 -0400, Tom Rymes wrote: =20 > > > > That makes sense to me. One step at a time! > > > > =20 > > > > > On Sep 23, 2017, at 2:19 PM, Peter M=C3=BCller wrote: > > > > >=20 > > > > > Hello Matthias, > > > > >=20 > > > > > your described scenario does not appear on my machine. :-( > > > > >=20 > > > > > 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.) > > > > >=20 > > > > > Which version are you running? > > > > >=20 > > > > > 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. =20 > > >=20 > > > Well, the update for Apache 2.4 is in next right now. =20 > >=20 > > Yes, I saw Arne closing Core114 a few hours ago. =20 >=20 > Oh. :) >=20 > > >=20 > > > 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. = > >=20 > > 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. > >=20 > > 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. > >=20 > > At the moment - without the patch I sent in - it is possible to log in > > to the WebUI without SSL by using port 81. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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-interfa= ce.conf" > > which require an authentication and replace them with a HTTP 301 redirect= to > > the SSL location. > >=20 > > 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. > >=20 > > Resources without authentication must remain untouched (as mentioned abov= e). =20 >=20 > 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. >=20 > Since we have had this issue before Apache 2.4, I guess it does not > make sense to delay the update for it. >=20 > > (b) Although this is a security vulnerability, it is not a very severe one > > in the default configuration - as far as I am concerned. > >=20 > > 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. =20 >=20 > Since we use SSL and nobody can properly validate the certificate, MITM > is always super easy to do to be honest. >=20 > > 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 critic= al. > > According to Shodan, a lot of people do so. =20 >=20 > Those misconfigured a lot. They are on their own. >=20 > > 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. =20 >=20 > See above. >=20 > > I would be happy to get feedback, especially to (a). > >=20 > > Hopefully, I have a working patch ready by tomorrow evening. > >=20 > > Best regards, > > Peter M=C3=BCller > >=20 > > @Michael P.S.: What about the other patches (ECDSA, SSL ciphers and all > > the minor WebUI stuff)? Are they not working, too? =20 >=20 > No, not yet. Things have been very busy around me and this is solely on > me. >=20 > > =20 > > >=20 > > > Best, > > > -Michael > > > =20 > > > > >=20 > > > > > @All: Anybody against or in favor? > > > > >=20 > > > > > Best regards, > > > > > Peter M=C3=BCller > > > > > =20 > > > > > > Hello Matthias, > > > > > >=20 > > > > > > tanks for reporting this. I am trying to reproduce here... > > > > > >=20 > > > > > > Best regards, > > > > > > Peter M=C3=BCller > > > > > > =20 > > > > > > > Hi Peter, > > > > > > >=20 > > > > > > > Please review this patch... (http://patchwork.ipfire.org/patch/= 1413/) > > > > > > >=20 > > > > > > > During testing I found that every machine in my GREEN net was s= uddenly > > > > > > > able to login through https://[IPFIRE_GREEN_ADDRESS]:[444]. > > > > > > >=20 > > > > > > > No question for admin-username, no password authentification re= quest, > > > > > > > nothing. > > > > > > >=20 > > > > > > > It seems as as if the Authentication Header is missing(?). > > > > > > >=20 > > > > > > > Only when I remove the "Require ssl" lines (I did this in both = files), a > > > > > > > browser restart leads to the usual login procedure. > > > > > > >=20 > > > > > > > Best, > > > > > > > Matthias > > > > > > > =20 > > > > > > > > On 08.09.2017 19:19, Peter M=C3=BCller wrote: =20 > > > > > > > > Force SSL/TLS for any WebUI directory which requires an > > > > > > > > authentication. > > > > > > > > This prevents credentials from being transmitted in plaintext= , which > > > > > > > > is > > > > > > > > an information leak. > > > > > > > >=20 > > > > > > > > Scenario: A MITM attacker might block all encrypted traffic t= o the > > > > > > > > firewall's web interface, making the administrator using an > > > > > > > > unencrypted > > > > > > > > connection (i.e. via port 81). Username and password can be e= asily > > > > > > > > logged in transit then. > > > > > > > >=20 > > > > > > > > Signed-off-by: Peter M=C3=BCller > > > > > > > > --- > > > > > > > > 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 > > > > > > > > > > > > > > > > ScriptAlias /cgi-bin/ /srv/web/ipfire/cgi-bin/ > > > > > > > > > > > > > > > > @@ -33,6 +36,7 @@ > > > > > > > > AuthType Basic > > > > > > > > AuthUserFile /var/ipfire/auth/users > > > > > > > > Require user admin > > > > > > > > + Require ssl > > > > > > > > > > > > > > > > Require all granted > > > > > > > > > > > > > > > > @@ -50,6 +54,7 @@ > > > > > > > > AuthType Basic > > > > > > > > AuthUserFile /var/ipfire/auth/users > > > > > > > > Require user dial admin > > > > > > > > + Require ssl > > > > > > > > > > > > > > > > > > > > > > > > SSLOptions +StdEnvVars > > > > > > > > @@ -86,5 +91,6 @@ > > > > > > > > AuthType Basic > > > > > > > > AuthUserFile /var/ipfire/auth/users > > > > > > > > Require user admin > > > > > > > > + Require ssl > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > ScriptAlias /cgi-bin/ /srv/web/ipfire/cgi-bin/ > > > > > > > > > > > > > > > > @@ -25,6 +26,7 @@ > > > > > > > > AuthType Basic > > > > > > > > AuthUserFile /var/ipfire/auth/users > > > > > > > > Require user admin > > > > > > > > + Require ssl > > > > > > > > > > > > > > > > Require all granted > > > > > > > > > > > > > > > > @@ -42,6 +44,7 @@ > > > > > > > > AuthType Basic > > > > > > > > AuthUserFile /var/ipfire/auth/users > > > > > > > > Require user dial admin > > > > > > > > + Require ssl > > > > > > > > > > > > > > > > Alias /updatecache/ /var/updatecache/ > > > > > > > > > > > > > > > > =20 > > > > >=20 > > > > > =20 > >=20 > > =20 --===============0039797305888801194==--