Re: [PATCH] force transport encryption for WebUI logins

["Peter Müller" <peter.mueller@link38.eu>]

[-- Attachment #1: Type: text/plain, Size: 10255 bytes --]

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(a)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://[IPFIRE_GREEN_ADDRESS]:[444].
> > > > > > > 
> > > > > > > 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(a)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>
> > > > > > > >     
> > > > > 
> > > > >     
> > 
> >