5 ms·
> As a simple case, you will sometimes come across documentation that thinks that DNS names cannot start with a digit, which does not match reality at all. I w
by bluejekyll 8y ago
> As a simple case, you will sometimes come across documentation that thinks that DNS names cannot start with a digit, which does not match reality at all.
I wish that were true. It’s seriously annoying that DNS names are nearly indistinguishable from ipv4 addresses.
- technion 8y agoTo complicate this further, there are certificates issued with IP addresses as names. One of the early bugs in CT Advisor[0] involved not knowing what to do with such a thing. I'd be interested in whether those writing this report considered these a valid URI. An obvious example: https://1.1.1.1/ https://1.1.1.1/ [0] https://ctadvisor.lolware.net/ https://ctadvisor.lolware.net/
- tialaramex 8y agoOlder versions of Microsoft Windows don't understand the ipAddress SAN at all. Instead they parse the dnsName SANs as a generic text field into which you can write host names, IP addresses, or whatever you like. This was fixed in modern Windows (maybe Windows 7 onwards?) As a result, and with enforcement never total, CAs would often issue non-compliant garbage for IP addresses because "it works on Windows". In the last few years this has improved as older Windows systems rust out and enforcement becomes more proactive. 1.1.1.1 is an example of how this should look.
- deleted 8y ago[deleted]
- XMPPwocky 8y agoI'm seeing the SAN for the cert served by 1.1.1.1 to contain the IP 1.1.1.1, not the domain 1.1.1.1. Or am I misunderstanding?
- technion 8y agoYes, the name is listed in the SAN on that cert. That said, that's one of the fields that's parsed, and potentially a source of issues in this paper.
- cryptonick 8y agoI am the main author of the paper, I am glad to see such an interesting discussion aroused on our work. In general, to address the concerns about the validation of the information found in the certificate, I remark that we targeted only syntactic checking: that is, we just verify that the format of the IP address or the DNS names is compliant to the X.509 specifications. Instead, the validation of the information retrieved by the parsing can be done by an application built on top of our parser. Therefore, a URI/DNS/IP address is valid if it is compliant to the syntactic format described in the standard. Regarding the specific example, I run our parser on that certificate: since the IP addresses in SAN have the correct format, they are correctly recognized. This certificate provides an example of a bad DNS name: indeed, it contains a DNS name starting with *. Although I could expect that this might sounds reasonable, such a Domain Name is not allowed by X.509 specification.
- praseodym 8y agoSubject Alternative Name has explicit differentiation between IP address and DNS names [1]. And fortunately the fallback to the the common name (CN) attribute that does not have this explicit differentiation was deprecated since 2000 in RFC 2818, and more recently also by both Chrome and Firefox [2,3]. [1] https://tools.ietf.org/html/rfc5280#section-4.2.1.6 https://tools.ietf.org/html/rfc5280#section-4.2.1.6 [2] https://www.chromestatus.com/features/4981025180483584 https://www.chromestatus.com/features/4981025180483584 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 https://bugzilla.mozilla.org/show_bug.cgi?id=1245280