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

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Nikos Mavrogiannopoulos-2
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.

regards,
Nikos

[0]. https://gitlab.com/gnutls/gnutls/issues/196

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel P. Berrange-2
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.

Have you succeeded in getting any contact with oVirt community to find
out how they are generating their certs ? That might give some clarity
on whether it is just a minor bug in their code, vs following common/
wide practice. It isn't clear if it even affects all oVirt users or
just some subset of them, vs likely to affect large numbers of non-oVirt
users too

While being lenient in what you accept has been a good strategy in many
cases, it feels like the web browser vendors in general have changed
tack over the past few years, to favour strictness wrt TLS/x509.

Regards,
Daniel
--
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Nikos Mavrogiannopoulos-2
On Tue, 2017-05-09 at 14:04 +0100, Daniel P. Berrange 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/16bad0c72dcdfbe5512cdd6b4
> > 6b251ab7484e5dc
> >
> > 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.
>
> Have you succeeded in getting any contact with oVirt community to
> find
> out how they are generating their certs ? That might give some
> clarity
> on whether it is just a minor bug in their code, vs following common/
> wide practice. It isn't clear if it even affects all oVirt users or
> just some subset of them, vs likely to affect large numbers of non-
> oVirt users too

Seems like a good point. I wouldn't know where to ask. Any suggestions?

regards,
Nikos


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Kurt Roeckx
In reply to this post by Nikos Mavrogiannopoulos-2
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.

Anyway, as the github issue says, I could only find 35
certificates that chain to the mozilla root store that fail
the most strict check.


Kurt


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Daniel P. Berrange-2
In reply to this post by Nikos Mavrogiannopoulos-2
On Tue, May 09, 2017 at 08:26:55PM +0200, Nikos Mavrogiannopoulos wrote:

> On Tue, 2017-05-09 at 14:04 +0100, Daniel P. Berrange 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/16bad0c72dcdfbe5512cdd6b4
> > > 6b251ab7484e5dc
> > >
> > > 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.
> >
> > Have you succeeded in getting any contact with oVirt community to
> > find
> > out how they are generating their certs ? That might give some
> > clarity
> > on whether it is just a minor bug in their code, vs following common/
> > wide practice. It isn't clear if it even affects all oVirt users or
> > just some subset of them, vs likely to affect large numbers of non-
> > oVirt users too
>
> Seems like a good point. I wouldn't know where to ask. Any suggestions?

Simplest is probably to ping #ovirt channel on irc.oftc.net  [1]

Regards,
Daniel

[1] https://www.ovirt.org/community/
--
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Nikos Mavrogiannopoulos-2
In reply to this post by Kurt Roeckx
On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <[hidden email]> 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 has found out
the culprit. There seem to be a user input validation issue in openssl
when generating certs:
https://gitlab.com/gnutls/gnutls/issues/196#note_29192381

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Nikos Mavrogiannopoulos-2
On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos
<[hidden email]> wrote:

> On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <[hidden email]> 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!

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Kurt Roeckx
On Wed, May 10, 2017 at 02:07:55PM +0200, Nikos Mavrogiannopoulos wrote:

> On Wed, May 10, 2017 at 2:06 PM, Nikos Mavrogiannopoulos
> <[hidden email]> wrote:
> > On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <[hidden email]> 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


Kurt


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Nikos Mavrogiannopoulos-2
On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx <[hidden email]> 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
>> <[hidden email]> wrote:
>> > On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <[hidden email]> 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.

regards,
Nikos

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Kurt Roeckx
On Mon, May 29, 2017 at 09:53:26AM +0200, Nikos Mavrogiannopoulos wrote:

> On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx <[hidden email]> 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
> >> <[hidden email]> wrote:
> >> > On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <[hidden email]> 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.

At least on the OpenSSL side we'll work on not allowing to create
such invalid files anymore.


Kurt


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Peter Williams
In reply to this post by Nikos Mavrogiannopoulos-2
Der compliance is required by pkix rfc compliance. It is unambiguous in dates. It has been unambiguous for 30+ years.

Assuming this community cares about pkix compliance. Netscape-compliance is also commonly accepted.

In general in the USA, anything to do with money (or insurance or warranty) requires pkix compliance.

Posting a rant to your blog site can be Netscape compliant.



Sent from my iPhone

> On May 29, 2017, at 12:54 AM, Nikos Mavrogiannopoulos <[hidden email]> wrote:
>
>> On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx <[hidden email]> 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
>>> <[hidden email]> wrote:
>>>> On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <[hidden email]> 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.
>
> regards,
> Nikos
>
> _______________________________________________
> Gnutls-devel mailing list
> [hidden email]
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel

_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Tim Ruehsen
In reply to this post by Nikos Mavrogiannopoulos-2
On 05/29/2017 09:53 AM, Nikos Mavrogiannopoulos wrote:

> On Thu, May 11, 2017 at 6:46 PM, Kurt Roeckx <[hidden email]> 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
>>> <[hidden email]> wrote:
>>>> On Tue, May 9, 2017 at 8:47 PM, Kurt Roeckx <[hidden email]> 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


_______________________________________________
Gnutls-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Nikos Mavrogiannopoulos-2
On Wed, May 31, 2017 at 9:37 AM, Tim Rühsen <[hidden email]> 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-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
Loading...