On Wed, May 31, 2017 at 9:37 AM, Tim Rühsen <[email protected]> wrote:
>>> >>> 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 ? I guess none. My concern are the non-public deployments. E.g., imagine a custom CA infrastructure used to authenticate mobile applications or things like that. These may have had a timezone included in the date which renders the certificate invalid, meaning no gnutls application could be used with that PKI. regards, Nikos _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
