[gnutls-devel] support of stapled OCSP responses under TLS1.3

[Stefan Bühler]

Hi,

On 11/21/2017 01:39 PM, Nikos Mavrogiannopoulos wrote:
> On Tue, Nov 21, 2017 at 11:03 AM, Stefan Bühler <stbuehler at lighttpd.net> wrote:
>> Hi,
>>
>> On 11/20/2017 08:56 AM, Nikos Mavrogiannopoulos wrote:
>>> On Fri, Oct 13, 2017 at 1:50 PM, Nikos Mavrogiannopoulos
>>> <n.mavrogiannopoulos at gmail.com> wrote:
>>>> Hi,
>>>>  I'm going through the support of stapled OCSP responses under TLS1.3.
>>>> The major change in TLS1.3 is that there can be an OCSP response for
>>>> each certificate sent, rather than one response for the
>>>> end-certificate, and such responses can be provided also for the
>>>> client certificate.
>>>> Supporting multiple responses when verifying the certificates seems
>>>> straightforward as we were doing that transparently without the
>>>> application intervening.
>>> [...]
>>>
>>> Hi,
>>>  The merge request introducing multiple OCSP staples under TLS1.3 is at:
>>> https://gitlab.com/gnutls/gnutls/merge_requests/548
>>>
>>> It tries hard not to require new APIs by enhancing
>>> gnutls_certificate_set_ocsp_status_request_file() to parse the
>>> response file and associate it with a certificate. On the other hand,
>>> a new callback could not be avoided to retrieve more than one
>>> responses, hence
>>> gnutls_certificate_set_ocsp_status_request_function3() is added, as
>>> well as gnutls_ocsp_status_request_get2() for application to read the
>>> responses.
>>
>> As far as I can see gnutls_certificate_set_ocsp_status_request_function3
>> provides the necessary interface.
>>
>>> I'd appreciate a review on that new functionality if you are already
>>> familiar with the previous OCSP handling code, or intend to use it.
>>>
>>> After a discussion with Hubert Kario, I've also opened [0] which is
>>> about automating the retrieval of OCSP responses and association with
>>> server credentials, to reduce complexity from servers. It's currently
>>> a bit low priority in the tls1.3 plan [1], and up for grabs, but it
>>> would make an application server's code much simpler.
>>
>> A first step to make usage simpler would be to add a function similar to
>> gnutls_certificate_set_ocsp_status_request_file which accepts a
>> gnutls_datum_t instead of a filename.
> 
> Thank you Stefan. If I remember well, my original intention for not
> bringing that function was that I assumed that OCSP responses are
> something volatile that will need to be updated now and then. As the
> credentials structure is supposed to be accessed concurrently, do you
> imply here having a set data buffer function which protects against
> concurrent access, or an "unsafe" set function which is expected to be
> used once, while later the credentials structure is recycled? (i.e.,
> the server app, creates a new credentials structure for new sessions).

My usecase so far is to simply restart the server after updating OCSP
(we implemented an "angel" process that keeps the listening socket open,
and it will wait for the new worker to be up before it stops the old one
and so on, so restart doesn't cost much).

So an "unsafe" set function is ok for me.

Now that you need multiple files for multiple OCSP responses,
gnutls_certificate_set_ocsp_status_request_file sounds even worse than
before; you probably need a cronjob to update the files anyway, so if
your server can handle a restart (or "reload ssl") well, it would be
better to to have a "fixed response" interface.

Add to this that if the file update is screwed (e.g. not atomic, or
somehow fails to match the certificate it matched before), you'll have a
hard time debugging it - either you won't see the error, or you'll get
flooded with the same error...

>> And even simpler would be auto-loading these responses from "OCSP
>> RESPONSE" pem blocks in certificate files (or separate "ocsp" files).
>> (I made up the term "OCSP RESPONSE"; afaik there is no standard name for
>> this).
> 
> Is the use of such a file format something that is being used? As the
> OCSP response lifetime is much shorter than certificate lifecycle, I'd
> expect that combo to cause an inconvenience.

I used such file format (right now I'm back to a single file with DER);
but mod_gnutls in lighttpd2 should support it.

I think now that we might need many OCSP responses it will be easier to
load multiple responses from one file, so a PEM encoding is useful imho.

I also like having a way to put everything into one file; that way I can
use a simple key-value lookup interface to load certs dynamically based
on filenames (the backend could also use stat() for file-based lookup,
or trigger ACME).

But it would be sufficient if there is a generic
"load_ocsp_responses_from_pem" which simply ignores other blocks, and
perhaps makes sure all required responses are present and all responses
match a loaded certificate.

cheers,
Stefan