When str.lower() is a security vulnerability in Python – Seth Larson

> This is why calling str.lower() represents a difference in the implementation and the specification, and therefore a vulnerability:

I wish there was some explanation how this is a vulnerability and not just a bug generating erroneous data.

Vulnerability for me sounds like there’s a reasonable way to create an exploit from the bug, and I don’t see one here as someone who’s not very familiar with the topic.

This idiocy is a big part of why it was so important to get Python people working on TLS implementations to understand that the defined mechanism for SANs (no the "alternative" in Subject Alternative Name doesn't mean in the sense of more than one, X.509 is originally for the X.500 system and the Internet repurposed X.509 so these are alternative names from the Internet) says that these are DNS names, they specifically are not to be understood as some sort of human readable text, and thus "decoding" them to Unicode is definitely nonsense even though Python really wanted to do that and I think used to do it or at least proposed to.

The rule for how SAN DnsNames match againt like names, from the DNS is very, very simple so that you don't screw it up. You handle a single wildcard (ASCII * code 42 matches any single DNS label) and beyond that it's literally byte comparison. You don't care what these bytes mean, either the bytes are all identical or that's not a match and we're done.

Reminds me of an old security incident at Spotify https://engineering.atspotify.com/2013/06/creative-usernames

I was also startled when python did ß.upper() returns "SS". Which is kind of unsuspected in some cases (if string length changes with an upper call)

That's a little over the top. string.lower() is not a security vulnerability. Not following the spec is the security vulnerability.

the horrors of versioning

it would be good to look for ".lower()" squatters if you host on an idn.