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

Steve Gibson <[email protected]> writes:

>I opted to enable CRYPT_SSLOPTION_DISABLE_NAMEVERIFY, which first appeared in
>the latest release, v3.4.2.

It used to be turned off by default because too many people reported problems
with it (self-signed certs, use on non-DNS-enabled networks, etc).  Now it's
enabled by default but with an option to disable.

>(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.)

It should work with SANs and wildcards and whatnot (despite the complex
calisthenics you have to jump through for this), if anyone runs into a
situation where it doesn't, please let me know.

>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

That's a CRYPT_ERROR_NOTFOUND, it's almost certainly a session-cache issue,
for the second connect it's resuming the session so no certificate exchange is
done.

>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.

My guess is that there's some difference between the two that means that the
cache isn't being activated for grc.com, so it's doing a full handshake each
time, which exchanges the cert.  If you run it under a debugger and look at
the debug output window you can see a full message trace as the handshake is
performed, one will be a full handshake with certs exchanged and the other
will be just a quick resume.

Peter.

_______________________________________________
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.