A method to bypass SSL certificate name vs. host name verification via NUL
('\0') character embedded in X509 certificate's CommonName or subjectAltName
was presented at Black Hat USA 2009:
Similar issues affected Qt's QSslCertificate used by QSslSocket. This implementation was not affected by problem with NUL characters in CommonName:
But the problem existed in handling of subjectAltNames:
Issue is fixed in upstream git, fix will be included in next scheduled Qt update.
Created attachment 359259 [details]
Patch backport to 4.3.5 (from Thiago Macieira)
Fix for recent Qt versions can be obtained from the git link referenced above, Thiago Macieira also provided backport for Qt 4.3.5 (we're unlikely to need it).
Due to the way Qt handles '*' wild card in certificates (it is allowed to match more than one host name component, even whole host name), certificate with subjectAltName as: *\0.whatever.com is a "universal" certificate as described in Moxies presentation (i.e. is treated as valid for any host name).
Upstream bug to track future changes to the way this wild card is handled:
Created attachment 359261 [details]
Trivial testing application using QSslSocket
Testing certificates are available at:
QSsl* classes were introduced in Qt 4.3, so this issue did not affect Qt versions as shipped in Red Hat Enterprise Linux 3, 4 and 5.
the fix is now included qt-4_5_2-13_fc12 in rawhide, it will be also added in qt for F10/F11 soon.
qt-4.5.2-3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
qt-4.5.2-3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #2)
> Upstream bug to track future changes to the way this wild card is handled:
This is known as QTBUG-4455 in the new Qt bug tracker: