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