[Freeipa-devel] [PATCH] 882 always require SSL in Kerberos block

[Adam Young]

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