Nathaniel Smith added the comment:

> I haven't dug in deeply, but it sounds like we handle IDNs in CNs and SANs 
> differently?

No -- Python's ssl module uses exactly the same hostname checking logic in both 
cases, and it's equally broken regardless. But, since CAs do all kinds of weird 
stuff with CNs, there's some chance that our brokenness and their brokenness 
will align and make things work by chance. Specifically, this will happen if 
the CA puts the U-encoded name in the CN field. Nick Lamb's concern is that CAs 
may be using this as justification for continuing to issue certs that are 
broken in this way. I don't know if that's true, but it's possible.

> one solution would be to simply drop support for CNs in match_hostname

That would indeed fix Nick Lamb's concern, but I'm dubious about this word 
"simply" :-). Obviously we should do this eventually, but it's going to break a 
bunch of people, you'll have to have a big fight about Python 2 and Redhat will 
probably refuse to take the patch and etc etc. OTOH fixing match_hostname to 
use A-labels would provide immediate benefits to Python's users (right now 
Python just... can't do SSL connections to IDNs) with minimal breakage, so you 
can call it a bug fix, and then worry about deprecating the CN field on its own 


Python tracker <>
Python-bugs-list mailing list

Reply via email to