3 ms·

Yes, assuming you have a non compromised browser or certificate trust chain

commandersaki 2y ago
Tangential question: how are IP addresses in certificates validated? Cloudflare was subject to a BGP hijack of the 1.1.1/24 prefix, how does it prevent someone from running a malicious DNS server?
- dist-epoch 2y ago
  But wouldn't the malicious DNS server need the private key of that certificate?
- galliher 2y ago
  It’s still imperfect AFAIK. Your provider may or may not have upstream routers speaking BGP and running RPKI validation at ASN boundaries which validate prefixes against certificates blessed by the appropriate RIRs (maybe analogous to CAs for routes). Since you mentioned Cloudflare I’ll just cut to the chase and link an instance of their blog on the subject : https://blog.cloudflare.com/rpki/ https://blog.cloudflare.com/rpki/ First example of imperfection which springs to mind first for me are misconfigurations in the network which ultimately allow for leaks to be accepted. IMHO this compounded with the nature of DNS recursion across name authorities on the far side of any ASN boundaries (that may be out of your provider’s control) makes any assurances weak at best when searching for name resolution trust. (Edit : oh and I think DNSSEC is probably another layer worth considering. But it’s also inconsistently deployed.) (Second edit : Sorry! I made a mental leap to RPKI when I saw “BGP hijack”, “certificate”, & “IP addresses”. IIRC a webserver’s x509 certificates don’t contain an OID of any inaddr{,6}, nor cidr type. i.e. a browser doesn’t verify a httpd’s ip against anything in the cert vended. Only that the cert is signed by a chain leading to a CA trusted by the client/browser(s).)
- Scion9066 2y ago
  Generally when you configure DoH, you either choose a provider from a list of options or enter both an IP and a hostname manually. With a host name it has enough to use to verify the identity of the server to prevent spoofing/a malicious server.
- StrLght 2y ago
  Technically it's possible to specify an IP address in a X.509 certificate. With OpenSSL you'd do something like that when issuing new certificate: subjectAltName=IP:192.168.1.1 And that's actually exactly what Google's 8.8.8.8 and Cloudflare's 1.1.1.1 use in their certificates. Also both issuers use certificate transparency [0], so BGP hijack shouldn't affect this — sure, your system might try to connect to hijacked IP, but TLS connection will fail due to invalid certificate (assuming certificate trust chain wasn't compromised and there are no malicious CAs installed on your system). [0]: https://crt.sh/?q=1.1.1.1 https://crt.sh/?q=1.1.1.1
  - notpushkin 2y ago
    > sure, your system might try to connect to hijacked IP, but TLS connection will fail due to invalid certificate I think the parent is asking if malicious actor can issue a certificate in case of BGP hijack. I think they could, but then it would be visible in the CT log.
    - commandersaki 2y ago
      Nah StrLght set me straight. I really didn't know how an IP address was embedded in a certificate, and I was viewing the output of the certificate from the lens of openssl s_client -connect 1.1.1.1:443 which obscures the fact that there's more than CN=cloudflare-dns.com. I think it'd be pretty hard to get a certificate for 1.1.1.1 after a BGP hijack, unless you had some control over a CA. I don't think LetsEncrypt issues certificates for IPs.

Tangential question: how are IP addresses in certificates validated? Cloudflare was subject to a BGP hijack of the 1.1.1/24 prefix, how does it prevent someone from running a malicious DNS server?

dist-epoch 2y ago
But wouldn't the malicious DNS server need the private key of that certificate?
galliher 2y ago
It’s still imperfect AFAIK. Your provider may or may not have upstream routers speaking BGP and running RPKI validation at ASN boundaries which validate prefixes against certificates blessed by the appropriate RIRs (maybe analogous to CAs for routes). Since you mentioned Cloudflare I’ll just cut to the chase and link an instance of their blog on the subject : https://blog.cloudflare.com/rpki/ https://blog.cloudflare.com/rpki/ First example of imperfection which springs to mind first for me are misconfigurations in the network which ultimately allow for leaks to be accepted. IMHO this compounded with the nature of DNS recursion across name authorities on the far side of any ASN boundaries (that may be out of your provider’s control) makes any assurances weak at best when searching for name resolution trust. (Edit : oh and I think DNSSEC is probably another layer worth considering. But it’s also inconsistently deployed.) (Second edit : Sorry! I made a mental leap to RPKI when I saw “BGP hijack”, “certificate”, & “IP addresses”. IIRC a webserver’s x509 certificates don’t contain an OID of any inaddr{,6}, nor cidr type. i.e. a browser doesn’t verify a httpd’s ip against anything in the cert vended. Only that the cert is signed by a chain leading to a CA trusted by the client/browser(s).)
Scion9066 2y ago
Generally when you configure DoH, you either choose a provider from a list of options or enter both an IP and a hostname manually. With a host name it has enough to use to verify the identity of the server to prevent spoofing/a malicious server.
StrLght 2y ago
Technically it's possible to specify an IP address in a X.509 certificate. With OpenSSL you'd do something like that when issuing new certificate: subjectAltName=IP:192.168.1.1 And that's actually exactly what Google's 8.8.8.8 and Cloudflare's 1.1.1.1 use in their certificates. Also both issuers use certificate transparency [0], so BGP hijack shouldn't affect this — sure, your system might try to connect to hijacked IP, but TLS connection will fail due to invalid certificate (assuming certificate trust chain wasn't compromised and there are no malicious CAs installed on your system). [0]: https://crt.sh/?q=1.1.1.1 https://crt.sh/?q=1.1.1.1
- notpushkin 2y ago
  > sure, your system might try to connect to hijacked IP, but TLS connection will fail due to invalid certificate I think the parent is asking if malicious actor can issue a certificate in case of BGP hijack. I think they could, but then it would be visible in the CT log.
  - commandersaki 2y ago
    Nah StrLght set me straight. I really didn't know how an IP address was embedded in a certificate, and I was viewing the output of the certificate from the lens of openssl s_client -connect 1.1.1.1:443 which obscures the fact that there's more than CN=cloudflare-dns.com. I think it'd be pretty hard to get a certificate for 1.1.1.1 after a BGP hijack, unless you had some control over a CA. I don't think LetsEncrypt issues certificates for IPs.