Re: [openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Annie Yousar via RT
Am 19.01.2015 um 05:29 schrieb Uri Blumenthal via RT:
 Well, technically you’re correct - but from semantic point of view,
 how different is an empty list, and a list presented as ASN.1 NULL?
 Don’t we have an empty list in both cases? And aren’t these two the
 only two ways to represent an empty list (so there’s little chance of
 somebody utilizing this difference to craft an attack)?

It is the difference as of an empty tumbler on the table and no tumbler at
all ;-)

RFC 4055 as well as RFC 5754 do not make this difference, both say:
   When any of these four object identifiers appears within an
   AlgorithmIdentifier, the parameters MUST be NULL.  Implementations
   MUST accept the parameters being absent as well as present.

If OpenSSL declines an empty paramter field then this is non-conformant
with theses RFCs.

/Ann.




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


[openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Stephen Henson via RT
On Mon Jan 19 04:49:27 2015, u...@mit.edu wrote:

 Does the consensus on the list agree with my statement of the problem,
 and the proposed fix? I hope we all agree that semantically
 parameter list presented as ASN.1 NULL is equivalent to an empty
 parameter list, and should be treated as such?


The problem is that the two fields containing the signature algorithm do not
match.

From RFC5280:

4.1.2.3. Signature

...

This field MUST contain the same algorithm identifier as the
signatureAlgorithm field in the sequence Certificate (Section
4.1.1.2).

Now whether the same algorithm identifier means identical or the same
meaning is debatable. Currently it goes with the former and if that is taken
to be the case the certificate presented is encoded incorrectly.

The question is whether an OpenSSL workaround should be added to tolerate this.
Before this change OpenSSL completely ignored the signature field (so it could
contain anything) and only used the signatureAlgorithm field.

In general the ASN.1 NULL value and absent can be very different depending on
the ASN.1 structure being represented and empty can have a third distinct
meaning.

Example: imagine an OPTIONAL field where NULL represents a status value of
some sort. In that case an absent field would indicate no status available
while a NULL would indicate a specific status.

So in general changing ASN1_TYPE_cmp in the proposed fashion is not a good
idea.

In the very specific case of a certificate and certain digest algorithms absent
and NULL do have the same meaning.

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

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


[openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Stephen Henson via RT
On Mon Jan 19 09:30:24 2015, a.you...@informatik.hu-berlin.de wrote:

 RFC 4055 as well as RFC 5754 do not make this difference, both say:
 When any of these four object identifiers appears within an
 AlgorithmIdentifier, the parameters MUST be NULL. Implementations
 MUST accept the parameters being absent as well as present.

 If OpenSSL declines an empty paramter field then this is non-conformant
 with theses RFCs.


OpenSSL will tolerate both an absent parameter list and a NULL one. It did
before this change and still does after it. This specific case rejects a
certificate where the two AlgorithmIdentifier values in the certificate
(signature and signatureAlgorithm) do not match.

It seems odd that an implementation having decided it should represent an
algorithm in one way for one field should then decide to represent an identical
algorithm in a different way for another.

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

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


[openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Stephen Henson via RT
On Mon Jan 19 14:40:32 2015, steve wrote:

 The problem is that the two fields containing the signature algorithm
 do not match.


The current 'x509' utility can't show this difference (I have an option I'm
testing which will). It is possible to use the cms command diagnostic output
though:

openssl crl2pkcs7 -nocrl -certfile RabbitMQ_Test.pem | openssl cms -cmsout
-print -inform PEM

...
signature:
algorithm: sha256WithRSAEncryption (1.2.840.113549.1.1.11)
parameter: ABSENT
...
sig_alg:
algorithm: sha256WithRSAEncryption (1.2.840.113549.1.1.11)
parameter: NULL

[sig_alg is the name of the field used internally by OpenSSL to store the
signatureAlgorithm field]

Whereas another case (e.g. test apps/server.pem) shows:

signature:
algorithm: sha1WithRSAEncryption (1.2.840.113549.1.1.5)
parameter: NULL

sig_alg:
algorithm: sha1WithRSAEncryption (1.2.840.113549.1.1.5)
parameter: NULL

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

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


[openssl-dev] [openssl.org #3666] [PATCH] build with no-ts fails

2015-01-19 Thread s.resc...@avm.de via RT
Hello,

Fix build of apps without ts (define OPENSSL_NO_TS)



Regards 
Sebastian


--
Mit freundlichem Gruß

Sebastian Reschke

AVM GmbH
Sebastian Reschke
Internetworking
Telefon 030 39976-794
s.resc...@avm.de
www.avm.de

AVM Audiovisuelles Marketing und Computersysteme GmbH, Alt-Moabit 95, 
10559 Berlin
HRB 23075 AG Charlottenburg, Geschäftsführer: Johannes Nill 


openssl.no-ts.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Rob Stradling via RT
On 19/01/15 14:47, Stephen Henson via RT wrote:
 On Mon Jan 19 14:40:32 2015, steve wrote:

 The problem is that the two fields containing the signature algorithm
 do not match.

 The current 'x509' utility can't show this difference (I have an option I'm
 testing which will).

Steve, while you're there...

I've been caught out a few times in the past because the 'x509' utility 
displays the outer signature algorithm in the place where it should 
display the inner signature algorithm.  This is fine when they match, 
but it's rather unhelpful when they don't match!

Please consider this trivial patch.  Thanks.

diff --git a/crypto/asn1/t_x509.c b/crypto/asn1/t_x509.c
index 89115c7..97abd51 100644
--- a/crypto/asn1/t_x509.c
+++ b/crypto/asn1/t_x509.c
@@ -168,7 +168,7 @@ int X509_print_ex(BIO *bp, X509 *x, unsigned long 
nmflags, unsigned long cflag)

 if(!(cflag  X509_FLAG_NO_SIGNAME))
 {
-   if(X509_signature_print(bp, x-sig_alg, NULL) = 0)
+   if(X509_signature_print(bp, ci-signature, NULL) = 0)
 goto err;
  #if 0
 if (BIO_printf(bp,%8sSignature Algorithm: ,) = 0)

-- 
Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online


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


[openssl-dev] [openssl.org #3665] Bug report and a patch for OpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Stephen Henson via RT
On Mon Jan 19 16:19:50 2015, rob.stradl...@comodo.com wrote:

 Steve, while you're there...

 I've been caught out a few times in the past because the 'x509'
 utility
 displays the outer signature algorithm in the place where it should
 display the inner signature algorithm. This is fine when they
 match,
 but it's rather unhelpful when they don't match!

 Please consider this trivial patch. Thanks.

 diff --git a/crypto/asn1/t_x509.c b/crypto/asn1/t_x509.c
 index 89115c7..97abd51 100644
 --- a/crypto/asn1/t_x509.c
 +++ b/crypto/asn1/t_x509.c
 @@ -168,7 +168,7 @@ int X509_print_ex(BIO *bp, X509 *x, unsigned long
 nmflags, unsigned long cflag)

 if(!(cflag  X509_FLAG_NO_SIGNAME))
 {
 - if(X509_signature_print(bp, x-sig_alg, NULL) = 0)
 + if(X509_signature_print(bp, ci-signature, NULL) = 0)
 goto err;
 #if 0
 if (BIO_printf(bp,%8sSignature Algorithm: ,) =
 0)


Ah that's a bug. It will be fixed.

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

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


Re: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Uri Blumenthal via RT
Steve, you’ve made several good points. But please consider:

 The problem is that the two fields containing the signature algorithm do not 
 match.

But they do according to RFC 5754 - I interpret it as declaring that in this 
particular case (optional parameters of AlgorithmIdentifier) NULL is equivalent 
to (the same as) absent. In fact, RFC 5754 (page 4) states
that the correct encoding is omitting the empty list altogether, but some uses 
defined their encoding
as NULL, and it’s OK. It reveals some history of this duality:

The two alternatives arise from the loss of the OPTIONAL associated with the  
algorithm identifier parameters when the 1988 syntax for
   AlgorithmIdentifier was translated into the 1997 syntax.  Later, the
   OPTIONAL was recovered via a defect report, but by then many people
   thought that algorithm parameters were mandatory.  Because of this
   history, some implementations encode parameters as a NULL element
   while others omit them entirely.

 Now whether the same algorithm identifier means identical or the same 
 meaning is debatable. Currently it goes with the former and if that is taken 
 to be the case the certificate presented is encoded incorrectly. 

I see your point. However I don’t find it stated anywhere that the same object 
in a certificate must be encoded the same way if it occurs more than once. 
Thus, it may be a silly and bad idea to encode AlgorithmIdentifier one way 
first, and the other way next time - but it doesn’t appear prohibited.

Is 2*2 the same as 4? :-)  Or better, is “2” the same as “two”? :-)

 The question is whether an OpenSSL workaround should be added to tolerate 
 this.

Considering the growing popularity of Apple platforms, my humble opinion is yes 
- a workaround should be added to tolerate this legal (and ugly) case.

 Before this change OpenSSL completely ignored the signature field (so it 
 could contain anything) and only used the signatureAlgorithm field. 

Exactly. And there are a few certificates deployed that are legal in every 
aspect of the published RFCs that 1.0.1k patch invalidates unnecessarily.

 In general the ASN.1 NULL value and absent can be very different depending on 
 the ASN.1 structure being represented and empty can have a third distinct 
 meaning. Example: imagine an OPTIONAL field where NULL represents a status 
 value of some sort. In that case an absent field would indicate no status 
 available while a NULL would indicate a specific status. So in general 
 changing ASN1_TYPE_cmp in the proposed fashion is not a good idea. 

Yes I see your point, and I agree with you. In general it isn’t a good idea to 
change ASN1_TYPE_cmp(). That means my patch isn’t good as is, and should be 
re-worked.

 In the very specific case of a certificate and certain digest algorithms 
 absent and NULL do have the same meaning. 

Exactly. I understand you as stating that a patch like what I’m proposing 
should be limited to this specific narrow case.

 It seems odd that an implementation having decided it should represent an 
 algorithm in one way for one field should then decide to represent an 
 identical algorithm in a different way for another.


Yes it is very odd, and I can only speculate as to how that implementation came 
about to doing that weird and strange thing. But it is not illegal, because 
both representations are legal, and there is no explicit requirement to stick 
with one representation, and no prohibition to mix representations. I’m not 
saying that it makes sense to do so, merely that (a) it appears legal, and (b) 
it has already been implemented and deployed by a big vendor - this is not just 
a theoretical discussion.

 This specific case rejects a certificate where the two AlgorithmIdentifier 
 values in the certificate (signature and signatureAlgorithm) do not match.

Since such a “mixed” representation is legal, according to the definition of 
that specific object AlgorithmIdentifier, these two do match. Therefore, I 
think rejecting such a certificate is wrong, and a workaround is necessary. 
Such a workaround - if correctly implemented - will not detract from OpenSSL 
security, and will ensure that corner cases are handled correctly (even if we 
don’t love corner cases very much).

Thanks!
--
Uri Blumenthal
u...@mit.edu




smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k)

2015-01-19 Thread Uri Blumenthal via RT
Also, the way I read the current code (crypto/asn1/a_type.c, line 120 - it 
would (incorrectly) reject a certificate where both algorithms are encoded with 
absent parameter lists:

 if (!a || !b || a-type != b-type) return -1;

I think we all agree that such a certificate would be valid/legal?
--
Uri Blumenthal
u...@mit.edumailto:u...@mit.edu


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