Apparent Readily Reproducible Bug in v3.4.1 and v3.4.2

Hi Peter.

I believe I've stumbled upon a reproducible bug in the last two versions of 
Cryptlib. (I haven't checked for it under v3.3.3) It involves a problem 
obtaining the server's session certificate following a non-exact 
certificate name match, following either a wildcard match or a match in the 
server's Subject Alternative Name record.

Quick background:

Given a public web domain, I want to obtain some certificate info from 
whatever remote server answers the secure connection. Since wildcard domain 
names and Subject Alternative Name (SAN) records are becoming quite common, 
and since the application is just to display the cert for a user -- always 
showing the cert's Common Name for verification -- I opted to enable 
CRYPT_SSLOPTION_DISABLE_NAMEVERIFY, which first appeared in the latest 
release, v3.4.2.  (At the time, I believed that it was necessary to use 
that SSLOPTION under v3.4.2 to enable wildcard and SAN record matching. But 
subsequent experiments under v3.4.1 revealed that you were already 
considering such certificates to be name-matched.)  The behavior appears to 
be subtly different under v3.4.2 with CRYPT_SSLOPTION_DISABLE_NAMEVERIFY, 
but mostly similar:

Using your highest-level "CreateSession" and "SetSessionActive" semantics, 
and using either my own domain and server cert (where I have a Subject 
Alternative Name record) or wikipedia.org's (where their cert is for 
*.wikipedia.org) as examples:

My server's cert Common Name is just 'grc.com' and I have both 'grc.com' 
and 'www.grc.com' in the cert's Subject Alternative Name record.

If I use Cryptlib to connect to the domain 'grc.com', then ask for the 
session's cert with CRYPT_SESSINFO_RESPONSE, all goes well.  And I can do 
that multiple times.

But if I connect to 'www.grc.com' then ask for the session cert, it WORKS 
ONLY the FIRST time...

... the SECOND and subsequent times I receive an error code from the call 
to cryptGetAttribute(cryptSession, CRYPT_SESSINFO_RESPONSE, &cryptCertificate);

Return code is: 0xFFFFFFD5
(The cryptCertificate value is set to -1)
Error Locus is: 0x00001781
Error Type is:  0x00000003

Now get this... all subsequent connections to 'www.grc.com' followed by a 
request for the session cert similarly error.  But a connection & request 
to just 'grc.com' succeeds.

And AFTER that success things appear to be 'reset' such that the FIRST 
connection & cert request to 'www.grc.com' succeeds... but subsequent one's 
fail.

Those results were obtained under v3.4.2. Under v3.4.1 things seem to be 
subtly different, but there's still a problem. The same behavior can be 
seen with wikipedia.org's wildcard matching.

I believe that if you experiment with successively obtaining a session's 
certificate following a wildcard or SAN record match, you'll be able to 
reliably reproduce the trouble.

Thanks!
__________________________________________________________
Steve.

If the devil really is in the details... I guess I'm going straight to hell!


_______________________________________________
Cryptlib mailing list
[email protected] via Mail: [email protected]
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.