[gnutls-devel] DER decoding errors due to time format

[Tim Rühsen]

On 05/29/2017 09:53 AM, Nikos Mavrogiannopoulos wrote:
> On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>> On Wed, May 10, 2017 at 02:07:55PM +0200, Nikos Mavrogiannopoulos wrote:
>>> On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos
>>> <n.mavrogiannopoulos at gmail.com> wrote:
>>>> On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>>>>> On Tue, May 09, 2017 at 02:48:08PM +0200, Nikos Mavrogiannopoulos wrote:
>>>>>> Hi,
>>>>>>  gnutls 3.5.x is more strict in certificate decoding and performs
>>>>>> various checks in the Time fields to ensure they are properly DER
>>>>>> formatted. However, it is seems that this caused regressions with
>>>>>> certain certificates generated by ovirt as seen in [0]. I am not sure
>>>>>> which software was used to generate the problematic ones, however, it
>>>>>> is most likely openssl, or some other open source software. Are you
>>>>>> aware of other or similar decoding issues which were a result of 3.5.x
>>>>>> being more strict in DER rules?
>>>>>>
>>>>>> The options we have are:
>>>>>>  1. Ignore the error and insist on DER correctness in input certificates.
>>>>>>  2. Allow incorrect formatted time fields in certificates
>>>>>> unconditionally, e.g., with a special libtasn1 flag:
>>>>>> https://gitlab.com/gnutls/libtasn1/commit/16bad0c72dcdfbe5512cdd6b46b251ab7484e5dc
>>>>>>
>>>>>> any other option I've missed? While I favor the first for its
>>>>>> simplicity, reality has shown over the years we must yield towards the
>>>>>> 'work' part.
>>>>>
>>>>> NSS is strict in what it accepts. We've recently changed openssl to be
>>>>> more strict too (commit 80770da39ebba0101079477611b7ce2f426653c5,
>>>>> https://github.com/openssl/openssl/issues/2620), but maybe not
>>>>> strict enough yet.
>>>>
>>>> Thank you, that is really helpful. It seems that Kurt
>>>
>>> Sorry, I meant to write Tim here!
>>
>> And today someone filed this in Debian:
>> https://bugs.debian.org/862335
> 
> I have a patch set which will tolerate incorrectly formatted dates to
> work around these issues in openssl:
> https://gitlab.com/gnutls/gnutls/merge_requests/400
> 
> I am still not sure that tolerating invalid formatted data is a good
> thing, however, in case of infrastructure already deployed based on
> openssl tools, there is not much an administrator/user can do. What
> I'm thinking to do is set a cut-off date after which the original
> strict behavior will be re-instated, though I cannot see how would
> that help eliminating that issue.

OpenSSL just 'allows' an invalid format, it's not really buggy (at least
not 1.1.1-dev, maybe older versions !?). The question is how many public
deployments are really affected, e.g. how many of the top 1M sites use
certs with invalid dates ?

Maybe there are just a few broken scripts out there, generating invalid
certs. These should be fixed first to allow for a smooth update to a
'fixed' version of OpenSSL.

With Best Regards, Tim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170531/0a6fa508/attachment-0001.sig>