This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Arfrever, bkabrda, christian.heimes, fweimer, georg.brandl, gregory.p.smith, iankko, lemburg, mpessas, pitrou, tim.peters, timehorse, vstinner
Date 2013-05-17.09:21:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1368782487.24.0.556986441816.issue17980@psf.upfronthosting.co.za>
In-reply-to
Content
SSL certificate hostname matching is defined in RFC 2818:

 * http://www.ietf.org/rfc/rfc2818.txt

It's not very verbose on how exactly matching should be done:

"""
   Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.
"""

Given that it's underspecified, I doubt that anyone using wildcards in certificates for valid purposes would risk using anything but very simply prefix/suffix matching - most certainly not any matching that would require backtracking to succeed.

There are several variants out there of how the matching is done.
See e.g. http://search-hadoop.com/c/Hadoop:hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/ssl/SSLHostnameVerifier.java||dns
History
Date User Action Args
2013-05-17 09:21:27lemburgsetrecipients: + lemburg, tim.peters, georg.brandl, gregory.p.smith, pitrou, vstinner, christian.heimes, timehorse, Arfrever, iankko, bkabrda, fweimer, mpessas
2013-05-17 09:21:27lemburgsetmessageid: <1368782487.24.0.556986441816.issue17980@psf.upfronthosting.co.za>
2013-05-17 09:21:27lemburglinkissue17980 messages
2013-05-17 09:21:26lemburgcreate