Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Blumenthal, Uri - 0553 - MITLL
Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"?

Clearly the device manufacturer is at fault here, but the punished party is the user - probably not what we should want?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Stephen Henson via RT
Sent: Thursday, February 11, 2016 17:27
To: [hidden email]
Reply To: [hidden email]
Cc: [hidden email]
Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

On Thu Feb 11 21:38:18 2016, [hidden email] wrote:
> The EK certificate is generated and burned into the TPM during
> manufacturing. The extraction operation always returns the same certificate.
>

I meant do you have any other examples of this anomalous encoding or is it some
rare glitch in the serial number generation?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"?

Clearly the device manufacturer is at fault here, but the punished party is the user - probably not what we should want?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Stephen Henson via RT
Sent: Thursday, February 11, 2016 17:27
To: [hidden email]
Reply To: [hidden email]
Cc: [hidden email]
Subject: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

On Thu Feb 11 21:38:18 2016, [hidden email] wrote:
> The EK certificate is generated and burned into the TPM during
> manufacturing. The extraction operation always returns the same certificate.
>

I meant do you have any other examples of this anomalous encoding or is it some
rare glitch in the serial number generation?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Kurt Roeckx
In reply to this post by Blumenthal, Uri - 0553 - MITLL
On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"?

This might be good advice for some things, but ussually not when it
comes to crypto.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"?

This might be good advice for some things, but ussually not when it
comes to crypto.


Kurt


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Blumenthal, Uri - 0553 - MITLL
In reply to this post by Blumenthal, Uri - 0553 - MITLL
Again, you are right, but what's the lesser evil‎ - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)?

Even in crypto (and that's the area I've been working in for quite a while) there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I won't gain from this decision, whichever way it turns. ;-) 

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: [hidden email]
Reply To: [hidden email]
Cc: Stephen Henson via RT; [hidden email]
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
Again, you are right, but what's the lesser evil‎ - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)?

Even in crypto (and that's the area I've been working in for quite a while) there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I won't gain from this decision, whichever way it turns. ;-) 

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: [hidden email]
Reply To: [hidden email]
Cc: Stephen Henson via RT; [hidden email]
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Peter Waltenberg

The problem with making those little "Oh we'll allow it for interoperability' choices is that they may end up as security vulnerabilities elsewhere. Particularly when there are multiple of them made.

So - it is quite reasonable to reject a change like that because it's near impossible to check all the little corner cases that it might expose.

Peter



Inactive hide details for "Blumenthal, Uri - 0553 - MITLL via RT" ---12/02/2016 10:13:22---Again, you are right, but what's the"Blumenthal, Uri - 0553 - MITLL via RT" ---12/02/2016 10:13:22---Again, you are right, but what's the lesser evil‎ - being unable to use the new OpenSSL because it r

From: "Blumenthal, Uri - 0553 - MITLL via RT" <[hidden email]>
To: [hidden email]
Cc: [hidden email]
Date: 12/02/2016 10:13
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format
Sent by: "openssl-dev" <[hidden email]>





Again, you are right, but what's the lesser evil‎ - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)?

Even in crypto (and that's the area I've been working in for quite a while) there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I won't gain from this decision, whichever way it turns. ;-) 

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: [hidden email]
Reply To: [hidden email]
Cc: Stephen Henson via RT; [hidden email]
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> Might I suggest that the right thing in this case would be to keep generation strict, but relax the rules on parsing? "Be conservative in what you send, and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

--
openssl-dev mailing list
To unsubscribe:
https://mta.openssl.org/mailman/listinfo/openssl-dev


--
Ticket here:
http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

[attachment "smime.p7s" deleted by Peter Waltenberg/Australia/IBM] --
openssl-dev mailing list
To unsubscribe:
https://mta.openssl.org/mailman/listinfo/openssl-dev




--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
In reply to this post by Rich Salz via RT
The problem with making those little "Oh we'll allow it  for
interoperability' choices is that they may end up as security
vulnerabilities elsewhere. Particularly when there are multiple of them
made.

So - it is quite reasonable to reject a change like that because it's near
impossible to check all the little corner cases that it might expose.

Peter





From: "Blumenthal, Uri - 0553 - MITLL via RT" <[hidden email]>
To: [hidden email]
Cc: [hidden email]
Date: 12/02/2016 10:13
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2
            fails to parse x509 certificate in DER format
Sent by: "openssl-dev" <[hidden email]>



Again, you are right, but what's the lesser evil‎ - being unable to use the
new OpenSSL because it refuses to deal with the cert that some dim-witten
TPM maker screwed up, or accept a certificate with a (minor) violation of
DER (but not of BER)? What bad in your opinion could happen if OpenSSL
allowed parsing an integer with a leading zero byte (when it shouldn't be
there by DER)?

Even in crypto (and that's the area I've been working in for quite a while)
there are some shades of gray, not only black and white.

P.S. My platform of choice is Mac, and Apple does not put TPM there - so I
won't gain from this decision, whichever way it turns. ;-)

Sent from my BlackBerry 10 smartphone on the
Verizon Wireless 4G LTE network.
  Original Message
From: Kurt Roeckx
Sent: Thursday, February 11, 2016 18:03‎
To: [hidden email]
Reply To: [hidden email]
Cc: Stephen Henson via RT; [hidden email]
Subject: Re: [openssl-dev] [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2
fails to parse x509 certificate in DER format‎

On Thu, Feb 11, 2016 at 10:53:25PM +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> Might I suggest that the right thing in this case would be to keep
generation strict, but relax the rules on parsing? "Be conservative in what
you send, and liberal with what you receive"?

This might be good advice for some things, but ussually not when it‎
comes to crypto.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

[attachment "smime.p7s" deleted by Peter Waltenberg/Australia/IBM] --
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

graycol.gif (146 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Erwann Abalea-4
In reply to this post by Blumenthal, Uri - 0553 - MITLL
Bonjour,

Le 12 févr. 2016 à 01:11, Blumenthal, Uri - 0553 - MITLL <[hidden email]> a écrit :

Again, you are right, but what's the lesser evil‎ - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)?

As shown yesterday, this INTEGER encoding isn’t even valid BER.

Being liberal in what you accept, when dealing with crypto, gives you stuff like this: https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/

Cordialement,
Erwann Abalea


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
FYI, I checked other machines that have a TPM device manufactured by STM,
but I could not find another with a serial number less than 20 bytes (I
guess they do padding in that case).
I also have a certificate from an Atmel device where I get a notice that
the serial number is negative.

For me personally, it would be perfectly fine if I could have a "relaxed
parsing" option that I could pass when I expect these kinds of broken
encodings.


On Fri, Feb 12, 2016 at 11:38 AM, Erwann Abalea <[hidden email]>
wrote:

> Bonjour,
>
> Le 12 févr. 2016 à 01:11, Blumenthal, Uri - 0553 - MITLL <[hidden email]>
> a écrit :
>
> Again, you are right, but what's the lesser evil‎ - being unable to use
> the new OpenSSL because it refuses to deal with the cert that some
> dim-witten TPM maker screwed up, or accept a certificate with a (minor)
> violation of DER (but not of BER)? What bad in your opinion could happen if
> OpenSSL allowed parsing an integer with a leading zero byte (when it
> shouldn't be there by DER)?
>
>
> As shown yesterday, this INTEGER encoding isn’t even valid BER.
>
> Being liberal in what you accept, when dealing with crypto, gives you
> stuff like this:
> https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/
>
> Cordialement,
> Erwann Abalea
>
>

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4301] [BUG] OpenSSL 1.1.0-pre2 fails to parse x509 certificate in DER format

Rich Salz via RT
In reply to this post by Erwann Abalea-4
Bonjour,

Le 12 févr. 2016 à 01:11, Blumenthal, Uri - 0553 - MITLL <[hidden email]<mailto:[hidden email]>> a écrit :

Again, you are right, but what's the lesser evil‎ - being unable to use the new OpenSSL because it refuses to deal with the cert that some dim-witten TPM maker screwed up, or accept a certificate with a (minor) violation of DER (but not of BER)? What bad in your opinion could happen if OpenSSL allowed parsing an integer with a leading zero byte (when it shouldn't be there by DER)?

As shown yesterday, this INTEGER encoding isn’t even valid BER.

Being liberal in what you accept, when dealing with crypto, gives you stuff like this: https://www.mozilla.org/en-US/security/advisories/mfsa2014-73/

Cordialement,
Erwann Abalea


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4301
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev