On Mon, Feb 13, 2012, Dirk-Willem van Gulik wrote: > Based on yesterdays post (DN of issuer and DN of subject seemed to be > compared string fashion) - we dove a bit deeper in a specific case where > folks seemed to be able to bypass/fool the security of an internet chat app > and found the following with a cert signed by a CA cert (each cert has its > own differing key pair): > > 1) When subject and issuer DN are identical > 2) Or when they are case-insensitive identical > > We get openssl its 'verify' confused. It requires a case-insensitive non > equal set of DNs to get back to sane behavior. > > What am I missing; or are we looking at a bug in openssl which can be > exploited (well, is exploited but that assumes certain humans and process > 'faults' and UI confusion in play). And is this the app build on top of > openssl misinterpreting - or openssl doing a case-insenstive comparison in > the wrong place ? >
OpenSSL explicit trust of a single certificate (if apparently self signed) is a special case. It doesn't just compare the DNs of any matching certificate it matches the hashes of the certificate itself. So you cannot spoof a trusted certificate by using one with exactly the same DNs. Note that for various reasons OpenSSL no longer verifies the signature on the root CA by default. The command line option -check_ss_sig can be used to do this. The apparent "confusion" of this is caused by lack of extensions. If you'd included extensions in the certificates (which avoids the obsolete V1 format) and SKID/AKID it will no longer think that certificate is self signed. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
