Authentication over SSL

[Julien ÉLIE]

Hi Russ,

> In this case, I think we have to always advertise SASL if built with SASL
> support.

All right.


>> 483 would be if there was a possibility to authenticate after STARTTLS.
>
> Oh, hm, yes.  If that's available, we should return 483 instead.  I forgot
> about that.

I have just implemented that for AUTHINFO USER/PASS and AUTHINFO SASL.
However, I cannot change the behaviour of the legacy AUTHINFO GENERIC because
it does not use auth blocks; therefore, there is no possibility to know whether
SSL may be required for AUTHINFO GENERIC.

I do not think it is a problem, though, for that deprecated use of AUTHINFO.


>> Hmm...  What for:
>>
>> auth "nothing" {
>>   hosts: "*"
>> }
>>
>> access "nothing" {
>>   users: "<all>"
>>    read: "!*"
>> }
>>
>> auth "users" {
>>   hosts: "*"
>>   require_ssl: true
>> }
>>
>> access "users" {
>>   users: "<all>"
>>   read: "*"
>> }
>>
>> GROUP -> 502
>> AUTHINFO -> 502
>> ...
>>
>> No authentication possible but if 483 is sent, the client maybe will
>> negociate an encrypted connection and then have access to everything!
>
> Right, we should return 483 here, if we can detect this case, to the GROUP
> command and probably to AUTHINFO as well.  Good catch.  It might be hard
> to detect that we're in this case, though.

The main problem is that we then need to force a re-authentication after
a successful TLS negotiation (because we need to change the current
auth block).  I do not know if it is wise to do that.

-- 
Julien ÉLIE

« Dieu expire sa parole, et en l'inspirant l'homme se forme. »