[asterisk-dev] SSL encryption for Asterisk Manager Interface

[Rich Adamson]

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