On 05/29/2017 09:53 AM, Nikos Mavrogiannopoulos wrote: > On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx <[email protected]> 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 >>> <[email protected]> wrote: >>>> On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <[email protected]> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
