You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Ron Barber <rb...@yahoo-inc.com> on 2014/01/15 19:46:14 UTC
TS-612 RFC 'ATS does not allow password protected certificates'
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).
You guys Rock!
Thank you,
--
Ron Barber
Yahoo! Edge Development
Work: 214-570-3866
rbarber@yahoo-inc.com
Re: TS-612 RFC 'ATS does not allow password protected certificates'
Posted by James Peach <jp...@apache.org>.
On Jan 17, 2014, at 11:51 AM, Ron Barber <rb...@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" <rb...@yahoo-inc.com> wrote:
>
>> Oops for got a comment on #2
>>
>> On 1/15/14, 4:17 PM, "Ron Barber" <rb...@yahoo-inc.com> wrote:
>>
>>> James, Thanks for the quick feedback...
>>>
>>> On 1/15/14, 3:08 PM, "James Peach" <jp...@apache.org> wrote:
>>>
>>>> On Jan 15, 2014, at 10:46 AM, Ron Barber <rb...@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
>>>
>>
>
Re: TS-612 RFC 'ATS does not allow password protected
certificates'
Posted by Ron Barber <rb...@yahoo-inc.com>.
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?
-Ron
On 1/15/14, 4:23 PM, "Ron Barber" <rb...@yahoo-inc.com> wrote:
>Oops for got a comment on #2
>
>On 1/15/14, 4:17 PM, "Ron Barber" <rb...@yahoo-inc.com> wrote:
>
>>James, Thanks for the quick feedback...
>>
>>On 1/15/14, 3:08 PM, "James Peach" <jp...@apache.org> wrote:
>>
>>>On Jan 15, 2014, at 10:46 AM, Ron Barber <rb...@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
>>
>
Re: TS-612 RFC 'ATS does not allow password protected
certificates'
Posted by Ron Barber <rb...@yahoo-inc.com>.
Oops for got a comment on #2
On 1/15/14, 4:17 PM, "Ron Barber" <rb...@yahoo-inc.com> wrote:
>James, Thanks for the quick feedback...
>
>On 1/15/14, 3:08 PM, "James Peach" <jp...@apache.org> wrote:
>
>>On Jan 15, 2014, at 10:46 AM, Ron Barber <rb...@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/ss
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
>
Re: TS-612 RFC 'ATS does not allow password protected
certificates'
Posted by Ron Barber <rb...@yahoo-inc.com>.
James, Thanks for the quick feedback...
On 1/15/14, 3:08 PM, "James Peach" <jp...@apache.org> wrote:
>On Jan 15, 2014, at 10:46 AM, Ron Barber <rb...@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.
>
>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
Re: TS-612 RFC 'ATS does not allow password protected certificates'
Posted by James Peach <jp...@apache.org>.
On Jan 15, 2014, at 10:46 AM, Ron Barber <rb...@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.
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.
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.
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.
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.
J