On Jan 17, 2014, at 11:51 AM, Ron Barber <rbar...@yahoo-inc.com> wrote:

> After some IRC conversations I believe we decided on adding a new
> key/value to the sslmulticert.config file which specifies the type of
> dialog for each cert.
> 
> ssl_key_pass_dialog=[builtin|exec:/path/to/program]
> 
>  Method used to provide a pass phrase for encrypted private keys.
>  Two options are supported: builtin and exec
>  builtin - Requests passphrase via stdin/stdout. Useful for debugging.
>  exec: - Executes a program and uses the stdout output for the pass
> phrase.
> 
> Example:
> 
> 
> ssl_cert_name=foo.pem ssl_key_pass_dialog="exec:/usr/bin/mypass foo"
> 
> Yes?

Yep, this looks like it would work. Bonus points for being 100% httpd 
compatible so that operators can reuse any passphrase scripts they already have.

> 
> 
> -Ron
> 
> On 1/15/14, 4:23 PM, "Ron Barber" <rbar...@yahoo-inc.com> wrote:
> 
>> Oops for got a comment on #2
>> 
>> On 1/15/14, 4:17 PM, "Ron Barber" <rbar...@yahoo-inc.com> wrote:
>> 
>>> James, Thanks for the quick feedback...
>>> 
>>> On 1/15/14, 3:08 PM, "James Peach" <jpe...@apache.org> wrote:
>>> 
>>>> On Jan 15, 2014, at 10:46 AM, Ron Barber <rbar...@yahoo-inc.com> wrote:
>>>> 
>>>>> All,
>>>>> 
>>>>> I have been asked to address TS-612
>>>>> (https://issues.apache.org/jira/browse/TS-612) by Œthe man¹.  I made a
>>>>> proposal on the ticket regarding configuration and would like some
>>>>> feedback at your leisure (well pretty quick since I am on it now).
>>>> 
>>>> 1. The 'builtin' dialog may be a problem, since traffic_server would be
>>>> the one running the dialog, and it's a couple of processes down the fork
>>>> chain.
>>> 
>>> Was going to include it primarily for completeness (and for my testing
>>> it’s useful).  Certainly I can remove it if it’s problematic (maybe it
>>> will create more questions), but just like it’s helpful for me, it may be
>>> useful to the person trying to implement/test his own exec or pipe
>>> solution.
>>>> 
>>>> 2. Compatibility with the Apache http dialog would be a good thing.
>>>> However, there's no ATS requirement to specify a dest_ip
>>>> (servername:portnumber in the httpd documentation), so I don't know that
>>>> it makes sense.
>> 
>> You are correct, thank you for pointing that out.  In looking at the docs
>> (https://trafficserver.readthedocs.org/en/latest/reference/configuration/s
>> s
>> l_multicert.config.en.html#std:configfile-ssl_multicert.config) the only
>> required field is ssl_cert_name, so I will make that first and provide the
>> other 2 if provided.
>>>> 
>>>> Are you planning to implement the httpd prompt-minimization logic?
>>>> 
>>>> It's difficult for me to see how a program could select a passphrase
>>>> using the http logic. It doesn't seem like there's a way for the program
>>>> to really know which key it is being prompted for. If the dialog was
>>>> specified in ssl_multicert.config, then it would be possible.
>>> 
>>> Short answer: No.  I thought that was a really cool feature in httpd so I
>>> looked at the implementation.  Httpd tries each password that it has seen
>>> previously before asking for another password..in order to do that it
>>> would take refactoring of the SSL config code which is beyond what I have
>>> time for.
>>> 
>>>> 
>>>> While you are at it, consider whether we can consolidate the number of
>>>> places in our code that calls fork+exec into a libts API that looks a
>>>> lot
>>>> like posix_spawn.
>>> 
>>> Will look at that.
>>> 
>>>> 
>>>> While this is useful from a compatibility point of view, I'd like the
>>>> provisioning and protection of private keys to go much further. The
>>>> linux
>>>> kernel keychain looks like the most promising infrastructure for key
>>>> management, and I'd like us to support that. Additionally, I think that
>>>> using a privileged helper (eg. traffic_manager?) is the right way to go
>>>> for accessing keys that are read-only for root, or protected in some
>>>> other fashion.
>>> 
>>> I agree with the idea (not sure keychain capability is available in all
>>> supported OSs) but is outside of my time horizon (and knowledge base
>>> atm).
>>> 
>>>> 
>>>> J
>>> 
>> 
> 

Reply via email to