4 ms·

The question wasn't whether if it is allowed, but how many implementations will actually accept it ;)

tialaramex 6y ago
Popular browsers don't accept these prohibited names, e.g. here's the relevant code for Mozilla's NSS: security/nss/lib/mozpkix/lib/pkixnames.cpp Likewise for Chromium: trunk/src/net/base/x509_certificate.cc (I've intentionally not linked these because burdening the relatively heavyweight source viewers with idle HN readers who are mostly going to glaze over and not read once they discover it's tricky C++ code seems unfair) My guess would be that because it's harder to process multiple wildcards at all, and indeed even the sketchy single wildcard in odd position (which Symantec used to issue and argued wasn't technically prohibited e.g. dev-*.auditcompany.example where auditcompany.example was a domain belonging to Symantec's auditors...) it's less likely anybody goes to the effort to do this even though it's a bad idea. But I guess if the wrong programmer is assigned the problem they might cheerfully write a nice loop to process wildcards even though it's more effort and the wrong thing so we can't rule out that it has happened somewhere at least once.
- tolqen 6y ago
  > I've intentionally not linked these because burdening the relatively heavyweight source viewers with idle HN readers who are mostly going to glaze over and not read once they discover it's tricky C++ code seems unfair Seems like a good use case for linking to their respective GitHub mirrors
  - vlz 6y ago
    > Seems like a good use case for linking to their respective GitHub mirrors https://github.com/chromium/chromium/blob/master/net/cert/x509_certificate.cc#L518 https://github.com/chromium/chromium/blob/master/net/cert/x5... https://github.com/mozilla/gecko-dev/blob/master/security/nss/lib/mozpkix/lib/pkixnames.cpp https://github.com/mozilla/gecko-dev/blob/master/security/ns...
    - snazz 6y ago
      Although I will say that the code-browsing experience on https://source.chromium.org https://source.chromium.org beats GitHub by a mile; you can hover over anything, the search tools are better, and it makes it easier to actually understand the code you're reading.
- edf13 6y ago
  > (I've intentionally not linked these because burdening the relatively heavyweight source viewers with idle HN readers who are mostly going to glaze over and not read once they discover it's tricky C++ code seems unfair) I'd say that statement seems a bit unfair and glad someone else linked to a source below.
  - cortesoft 6y ago
    It is also hilariously elitist
- rndgermandude 6y ago
  The two remaining browser engines are of course very important here, but there is a large number of other libraries and software that uses those libraries (in different configurations, and all with their particular bugs) as well. E.g. openssl didn't have a good name validation API (or any such API at all) for a long time, and a few years back I saw a ton of software which rolled their own stuff. I'd guess a lot of that code is still in production.

Popular browsers don't accept these prohibited names, e.g. here's the relevant code for Mozilla's NSS: security/nss/lib/mozpkix/lib/pkixnames.cpp Likewise for Chromium: trunk/src/net/base/x509_certificate.cc (I've intentionally not linked these because burdening the relatively heavyweight source viewers with idle HN readers who are mostly going to glaze over and not read once they discover it's tricky C++ code seems unfair) My guess would be that because it's harder to process multiple wildcards at all, and indeed even the sketchy single wildcard in odd position (which Symantec used to issue and argued wasn't technically prohibited e.g. dev-*.auditcompany.example where auditcompany.example was a domain belonging to Symantec's auditors...) it's less likely anybody goes to the effort to do this even though it's a bad idea. But I guess if the wrong programmer is assigned the problem they might cheerfully write a nice loop to process wildcards even though it's more effort and the wrong thing so we can't rule out that it has happened somewhere at least once.

tolqen 6y ago
> I've intentionally not linked these because burdening the relatively heavyweight source viewers with idle HN readers who are mostly going to glaze over and not read once they discover it's tricky C++ code seems unfair Seems like a good use case for linking to their respective GitHub mirrors
- vlz 6y ago
  > Seems like a good use case for linking to their respective GitHub mirrors https://github.com/chromium/chromium/blob/master/net/cert/x509_certificate.cc#L518 https://github.com/chromium/chromium/blob/master/net/cert/x5... https://github.com/mozilla/gecko-dev/blob/master/security/nss/lib/mozpkix/lib/pkixnames.cpp https://github.com/mozilla/gecko-dev/blob/master/security/ns...
  - snazz 6y ago
    Although I will say that the code-browsing experience on https://source.chromium.org https://source.chromium.org beats GitHub by a mile; you can hover over anything, the search tools are better, and it makes it easier to actually understand the code you're reading.
edf13 6y ago
> (I've intentionally not linked these because burdening the relatively heavyweight source viewers with idle HN readers who are mostly going to glaze over and not read once they discover it's tricky C++ code seems unfair) I'd say that statement seems a bit unfair and glad someone else linked to a source below.
- cortesoft 6y ago
  It is also hilariously elitist
rndgermandude 6y ago
The two remaining browser engines are of course very important here, but there is a large number of other libraries and software that uses those libraries (in different configurations, and all with their particular bugs) as well. E.g. openssl didn't have a good name validation API (or any such API at all) for a long time, and a few years back I saw a ton of software which rolled their own stuff. I'd guess a lot of that code is still in production.