[openssl-users] X509_verify_cert cannot be called twice

[Blumenthal, Uri - 0553 - MITLL]

I'm sure I'm missing something obvious, but why isn't the operation XXX_verify_xxx() idempotent? It seems very weird that two subsequent calls to verify() wouldn't return exactly the same thing.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Szilárd Pfeiffer
Sent: Thursday, March 24, 2016 16:21
To: openssl-users at openssl.org
Reply To: openssl-users at openssl.org
Subject: Re: [openssl-users] X509_verify_cert cannot be called twice

On 2016-03-24 19:12, Viktor Dukhovni wrote:
>> On Mar 24, 2016, at 2:02 PM, DEXTER <mydexterid at gmail.com> wrote:
>> 
>> So let me get this straight.
>> If someone had a software where they called X509_verify_cert from
>> SSL_CTX_set_cert_verify_callback callback twice (to verify first with
>> crls, and maybe verify again without crls) and it worked as expected,
>> after this patch their software is broken.
> 
> If they re-used the same X509_STORE_CTX, yes their software depended
> on undefined and likely insecure behaviour. "Worked as expected" is
> likely more along the lines of "did not appear to fail". Verification
> is not only expected to succeed for valid chains, but is also expected
> to reliably fail for invalid chains.
> 

You are absolutely right in your last sentence, but an application which 
should have expected (before the patch) that it does not get the error 
code ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED, as it was permitted (according 
to the documentation) to call the X509_verify_cert more than once. IMHO 
an API compatible fix (1.0.1p was a security update) should consider 
this, otherwise the undefined behavior shifted from the library to the 
application.

The problem what I try to explain is not just a theory. Consider the 
situation when a function in an application tries to verify a 
certificate by calling X509_verify_cert twice with different parameters 
(it is a questionable, but a permitted way) during the handshake. It 
works very well before the patch. After the patch the second call 
returns error, so the function also returns error and the SSL handshake 
fails. So a security update contains the patch breaks the application.

Szilárd




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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160324/d9b6ca65/attachment.bin>