On 09/26/2011 08:54 AM, Rob Crittenden wrote:
Simo Sorce wrote:
On Mon, 2011-09-26 at 11:22 +0200, Martin Kosek wrote:
On Mon, 2011-09-26 at 08:31 +0200, Martin Kosek wrote:
On Sun, 2011-09-25 at 23:05 -0400, Rob Crittenden wrote:
Martin Kosek wrote:
On Fri, 2011-09-23 at 14:12 -0400, Rob Crittenden wrote:
Always require SSL in the Kerberos authorization block.
This also corrects a slight bug where if add is True then we always
re-update the file.
rob
ACK. Pushed to master, ipa-2-1.
Martin
Sorry guys, this breaks things pretty badly. We need to be able to
allow
some non-SSL access to parts of /ipa to fetch configuration and
return
errors, etc. for those clients that don't trust our CA yet.
Here is a working change, not fully tested yet:
diff --git a/install/conf/ipa.conf b/install/conf/ipa.conf
index 2339387..09b4b7a 100644
--- a/install/conf/ipa.conf
+++ b/install/conf/ipa.conf
@@ -42,10 +42,17 @@ WSGIScriptReloading Off
SetHandler None
</Location>
+# Ensure SSL is enabled in our APIs
+<Location "/ipa/xml">
+ NSSRequireSSL
+</Location>
+<Location "/ipa/json">
+ NSSRequireSSL
+</Location>
+
# Protect /ipa with Kerberos
<Location "/ipa">
- NSSRequireSSL
AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate on
@@ -114,6 +121,7 @@ Alias /ipa/ui "/usr/share/ipa/ui"
# migration related pages
Alias /ipa/migration "/usr/share/ipa/migration"
<Directory "/usr/share/ipa/migration">
+ NSSRequireSSL
AllowOverride None
Satisfy Any
Allow from all
Ouch, we can fix it right when you log in. The change looks good, we
will just have to update the conf version in case somebody already
installed this IPA version.
I was also thinking if /crl shouldn't be secured too but from what I
seen in world's common CAs, these are not secured either.
Martin
Since Rob may not be here today, and since I think this should be fixed
fast, I am sending the patch based on Rob's mail. I just bumped config
file version so that it is updated for configured IPA instances.
IPA server, client and replica installation and WebUI worked for me.
This patch seems to defeat the purpose as we are still allowing krb auth
on locations that do not enforce ssl.
NACK.
Simo.
Simo's concern is that if you enable the fake basic auth and go to an
HTTP page you could expose your credentials. Probably worth testing
with something like the LiveHTTPHeaders extension. Go to the webui
then grab the CA or something in /ipa/config and see if it sends the
Authorized header.
The only other solution I see is to duplicate the krb block for each
of our three authenticated uris: /ipa/ui, /ipa/xml and /ipa/json.
rob
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
/ipa/ui should not require Kerberos, just the RPC calls. However, we
need to be able to fetch that code from either port 80 or 443, I I think
it needs to be covered by both the SSL and non SSL blocks.
In general the only thing that should require SSL nad thus Kerberos is
the password migration paget and the RPC urls (/ipa/xml and /ipa/json)
the rest should be accessable via both SSL and non SSL, but should not
require authentication.
Any certificates should be safely fetchable from outside of SSL. Most
important is the CA, as you will not have SSL enabled when you fetch
that the first time or you'll be in the bad situation of having to
accept an "invalid" cert before accepting the CA.
But yes, Kerberos without SSL is bad, especially if the end user enables
basic auth as a fallback.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
