From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] force transport encryption for WebUI logins Date: Sat, 23 Sep 2017 22:03:38 +0100 Message-ID: <1506200618.2489.5.camel@ipfire.org> In-Reply-To: <20170923215616.2f661007.peter.mueller@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8177713696794654832==" List-Id: --===============8177713696794654832== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, 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: > > > 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 > Yes, I saw Arne closing Core114 a few hours ago. Oh. :) > >=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 mu= ch > > 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-interface= .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 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. >=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. 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). >=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? No, not yet. Things have been very busy around me and this is solely on me. >=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/14= 13/) > > > > > >=20 > > > > > > During testing I found that every machine in my GREEN net was sud= denly > > > > > > able to login through https://[IPFIRE_GREEN_ADDRESS]:[444]. > > > > > >=20 > > > > > > No question for admin-username, no password authentification requ= est, > > > > > > 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 fi= les), 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 to = the > > > > > > > firewall's web interface, making the administrator using an > > > > > > > unencrypted > > > > > > > connection (i.e. via port 81). Username and password can be eas= ily > > > > > > > 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 --===============8177713696794654832== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUU1L3JXNWwzR0dl Mnlwa3R4Z0hudy8yK1FDUWNGQWxuR3pDb0FDZ2tRZ0hudy8yK1EKQ1FjNUVnLy9VR254anVkSXI5 eitwMVhZV3QzT2hqV3c5aW5rZnAwYmU0aEU0dFFaVTF6Z1ZLYzZoRER1ajladwpkRFFIY1NkYnJE K2M3cVJFMm9LUVhoSWtIclpoVHRRY1ZNK2Q2VDZVdkcycmpzYnFrNHUyYkgyTHpONzhHNmlTClE4 TnNTQTRucVBqWjB6c3U5Ukxic0dUV01GaTNwemJWcXF6b2hKU2Q0QmZhY2ZHN2Y4emErMXBKN2dS am5wb1UKQ3RBQjdVZ01GS0lTTm5oUnlDU1hiUjFxeE5EQ05oWDZCaUMrQkkzWWprVklkYVlQN2RB QmNRQzg0Y3VKc0NjdQpOdEpYTGJNUkovb01RTUlKaS9SWVBOOGR2cm96TlJFYkpBN3pDNFliNWFU UGY1NWFnQ2FabXNzQVBuaEJJY1E1CjA1NDEvQnhQYm1jL2RRVzVwcmgrdEpYSGxmdnpRUjJ1ZG5E OG4vVEZqQS9SNE5UUmFsK3JwdFdvbS9PV0UveGQKTU45a2I2cVR6aTBpT1FxanhLSnBVUmRTK1ht WFRKWFYwMFUzSVJLRS94alg5T1hPTmhSazYrQlVYMys1M1VUQwpKWWRLNXhrQ1I5WTlSUGNYR1cv d1VRRHBQRnNRRlZIUTVxalBzNXlMT2k0K0pXUjRpeHJ1UjUrWW5ZMG1IaWk4CkpqOUZzTlVKWDRX cnIwSjc5aTJ0M1RhNWNSNjFRcWEvSm1BeWZYNkpsRGdNdnl5cmpxQXBSVU5ndWtJRWNrNGsKcTRJ TFBueEI1c3EybnNTczFyUThjSWNYcm5uWmQrL1Z0eTJxTExDQmlOM2hnMlV3Q3BXdWkwZkZ4aHd3 UVpyTQoxNlpPR3hxeW81Q0dVbGdmK1ZMaGdmdXQ0MUV6YlNDZk84b1NQNkdoTThYY1FDZ0FhZkk9 Cj1KdVpNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============8177713696794654832==--