Re: TLS neverbleed design

2022-01-25 Thread William A Rowe Jr
Considering this from the most extreme example, a hosting service where co-parties to using the server container are in contention to steal one anothers' identities, it seems the right answer is... Entirely isolate the network transport to the specific physical or SNI-based vhost in a distinct

Re: TLS neverbleed design

2022-01-17 Thread Graham Leggett
On 17 Jan 2022, at 19:17, Ruediger Pluem wrote: >> I see. Thanks for the clarification. Did not really now about that >> interface. Then I see no pressing point in adding an additional API, indeed. > > I haven't looked deeply in this, but based on the pointers from Joe I guess > this can be

Re: TLS neverbleed design

2022-01-17 Thread Ruediger Pluem
On 1/17/22 5:32 PM, Stefan Eissing wrote: > > >> Am 17.01.2022 um 16:42 schrieb Joe Orton : >> >> On Wed, Jan 12, 2022 at 03:37:05PM +0100, Stefan Eissing wrote: >>> My current, rough idea would be: >>> >>> - fork a process, like mod_cgid does, that can be communicated >>> with over a unix

Re: TLS neverbleed design

2022-01-17 Thread Stefan Eissing
> Am 17.01.2022 um 16:42 schrieb Joe Orton : > > On Wed, Jan 12, 2022 at 03:37:05PM +0100, Stefan Eissing wrote: >> My current, rough idea would be: >> >> - fork a process, like mod_cgid does, that can be communicated >> with over a unix domain socket >> - have an ap_hook to load a key and

Re: TLS neverbleed design

2022-01-17 Thread Joe Orton
On Wed, Jan 12, 2022 at 03:37:05PM +0100, Stefan Eissing wrote: > My current, rough idea would be: > > - fork a process, like mod_cgid does, that can be communicated > with over a unix domain socket > - have an ap_hook to load a key and return an opaque key handle > - have an ap_hooks to

Re: TLS neverbleed design

2022-01-12 Thread Stefan Eissing
> Am 12.01.2022 um 11:07 schrieb Joe Orton : > > On Fri, Jan 07, 2022 at 11:34:47AM +0100, Stefan Eissing wrote: >> A nice new year to everyone! >> >> I was looking at the design of https://github.com/h2o/neverbleed which >> - loads TLS private keys in a separate process >> - creates EVP_PKEY

Re: TLS neverbleed design

2022-01-12 Thread Joe Orton
On Fri, Jan 07, 2022 at 11:34:47AM +0100, Stefan Eissing wrote: > A nice new year to everyone! > > I was looking at the design of https://github.com/h2o/neverbleed which > - loads TLS private keys in a separate process > - creates EVP_PKEY instances that in the sign callback call into the >

TLS neverbleed design

2022-01-07 Thread Stefan Eissing
A nice new year to everyone! I was looking at the design of https://github.com/h2o/neverbleed which - loads TLS private keys in a separate process - creates EVP_PKEY instances that in the sign callback call into the separate process to create the TLS handshake signature This is surprisingly