[asterisk-dev] SSL encryption for Asterisk Manager Interface

[John Todd]

>Johansson Olle E wrote:
>>
>>29 mar 2006 kl. 01.20 skrev John Todd:
>>
>>>>>OK, so I've put forward the solution.  Someone other than me 
>>>>>should test it.  I'd like to get this approved and in SVN TRUNK 
>>>>>before the next freeze so it can be part of the distribution. 
>>>>>Please take a few moments away from Olle's gargantuan list of 
>>>>>test cases and poke at this for a bit to see if you can find any 
>>>>>flaws.  ;-)
>>>>>
>>>>
>>>>Now, who's talking now? :-)
>>>>
>>>>This is going to the test branch real soon... Opened a branch for 
>>>>it meanwhile.
>>>>
>>>>>http://bugs.digium.com/view.php?id=6812
>>>>
>>>>Go to the bug and start testing, we need input on this important 
>>>>addition now. Especially the configuration
>>>>options. Kevin and myself need it to support client certificates 
>>>>so we can have secure auth.
>>>
>>>Do we?  While I believe that client certs are a Good Thing, isn't 
>>>the Challenge: method sufficient to prove connection identity?  I 
>>>like client certs; don't get me wrong.  However, they have proven 
>>>to be complex and almost never used in my experiences with 
>>>designers.  The Challenge: method that the AMI uses seems to be 
>>>fairly robust in exchanging a shared secret, which would be 
>>>required for connection anyway.  Doubling up on the security does 
>>>not seem to have a compelling amount of usefulness (note my 
>>>wording doesn't say _no_ usefulness; I just can't think of why I'd 
>>>need both.)  Perhaps we just need some options that disallow 
>>>cleartext passwords under some define-able set of circumstances. 
>>>(unauth-passwords-ssl=yes, unauth-passwords-nossl=no)
>>
>>Using client certificates never really took off in the web world, 
>>but in application to application communication I keep
>>hearing about it all the time. in the case of Astmanproxy, it would 
>>be a good thing. I believe other developers
>>may be interested as well.
>
>Isn't there some room for starting with the Challenge approach and 
>enhancing it later to support certificates, maybe even optional?
>
>Rich

Yes, this was my point, though I suppose I didn't word it clearly 
enough.  I'd hope that the existing SSL patch doesn't get held up 
waiting for Godot (or waiting for client certs, as the case may be.) 
I would suggest that the Challenge: method is "good enough" for the 
moment, but nothing precludes client certs from being used in the 
future.  I just don't think this patch should be delayed on inclusion 
to TRUNK because it is waiting for that theoretical code to appear...

Perhaps that wasn't even the base for Olle's comments, so I may be 
mis-reading things.

  (though it still needs to be tested, and that will delay it unless 
some other people step up and patch their systems. There's even a 
client app included for testing without writing your own client 
tools!)

JT