> On 26 Nov 2015, at 11:49 AM, Paul Millar <[email protected]> wrote: > > On 25/11/15 19:22, Roland Zink wrote: >> The resolution of a certificate is the domain name, e.g. it is valid for >> all services on the machine. If you get the certificate for a port then >> you may misuse it to intercept traffic to other ports / services. > > This is certainly true for any certificate that asserts the DNS name only > (irrespective of the vetting: DV, OV or EV). There's an inherent trust > relationship between everyone running services under the same DNS name. > > One potential solution is for the CA to issue a certificate that assert the > DNS and port number together; for example, with a URI as the only > SubjectAltName. > > Unfortunately, it looks like there is no support in openssl/libressl for > certificates with only URI-based SubjectAltName.
That is one issue. The other is that it goes against section 3.1 in RFC 2818: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Yes, you could have a URI SAN, but clients would ignore that one and take the server name from the CN field or another dNSName SAN. So the certificate would still apply to all ports. Even if we decide to update 2818, all existing browsers and clients would have the above behavior, so they would be vulnerable to the privilege escalation. Yoav _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
