5 ms·

Could somebody clarify: LetsEncrypt allows anybody to create certificate for any domain, so would not that allow anybody to create MITM certificate for any such

by okigan 11y ago

Could somebody clarify: LetsEncrypt allows anybody to create certificate for any domain, so would not that allow anybody to create MITM certificate for any such domain?

mholt 11y ago
No, it allows site owners to create a certificate for any domain they can prove they own. Then, the certificate has to be installed on the server serving the site. Using it from any other server will cause browsers to reject the certificate.
alfredxing 11y ago
Let's Encrypt does validate that you own the domain, using certain "challenges" involving the web server, etc. Their technical overview explains how it works: https://letsencrypt.org/howitworks/technology/ https://letsencrypt.org/howitworks/technology/
dfabulich 11y ago
As a condition of being trusted, LetsEncrypt has promised to do "domain validation" before creating such a certificate. Domain validation is usually done by sending an email to the technical contact in the domain's WHOIS records.
- mjevans 11y ago
  It can also be placing a file of authentication data at a chosen resource location within the domain in question. (which is, I think, what their tool automates doing)
ubernostrum 11y ago
Look at the tech overview: https://letsencrypt.org/howitworks/technology/ https://letsencrypt.org/howitworks/technology/ You can only obtain a certificate for a domain if you can validate that you control the domain. Their steps for that (place arbitrary content at an arbitrary URL they request, or create an arbitrary DNS record they request) are such that, if you weren't the legitimate controller of the domain but could do those things, you wouldn't need a fake cert -- you'd already have pwned it thoroughly enough to be able to MITM it in other ways.
- flashman 11y ago
  > You can only obtain a certificate for a domain if you can validate that you control the domain. Technically, you only have to make their systems think you control the domain. If their servers or 'establish proof of ownership' process are hacked, wouldn't this allow an attacker to do the same thing that happened in the DigiNotar hack? https://en.wikipedia.org/wiki/DigiNotar https://en.wikipedia.org/wiki/DigiNotar
  - Laforet 11y ago
    It's not like it ain't broken already. http://arstechnica.com/security/2015/03/bogus-ssl-certificate-for-windows-live-could-allow-man-in-the-middle-hacks/ http://arstechnica.com/security/2015/03/bogus-ssl-certificat...
  - ubernostrum 11y ago
    Again we're in the realm of "if you could do that, you already could MITM or do other malicious stuff in a dozen other ways". So, sure. If you can hack a trusted CA, you can do bad things. That was true before.
  - alwillis 11y ago
    This is why HTTP Public Key Pinning was created as a way to tell browsers to trust only a particular certificate, not just any certificate that was signed by a CA in the browser's trust store: https://news.ycombinator.com/item?id=10418144 https://news.ycombinator.com/item?id=10418144.
    - okigan 11y ago
      Another follow up: from your link, looks like the server adds a header specifying which certificates are allowed. Would not MITM just remove that header?
      - alwillis 11y ago
        From the RFC: https://tools.ietf.org/html/rfc7469 https://tools.ietf.org/html/rfc7469 Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].) The UA will not be able to detect and thwart a MITM attacking the UA's first connection to the host. (However, the requirement that the MITM provide an X.509 certificate chain that can pass the UA's validation requirements, without error, mitigates this risk somewhat.) Worse, such a MITM can inject its own PKP header into the HTTP stream, and pin the UA to its own keys. To avoid post facto detection, the attacker would have to be in a position to intercept all future requests to the host from that UA. Thus, key pinning as described in this document is not a perfect defense against MITM attackers capable of passing certificate chain validation procedures -- nothing short of pre-shared keys can be. However, it provides significant value by allowing host operators to limit the number of certification authorities that can vouch for the host's identity, and allows UAs to detect in-process MITM attacks after the initial communication.

by okigan 11y ago

Could somebody clarify: LetsEncrypt allows anybody to create certificate for any domain, so would not that allow anybody to create MITM certificate for any such domain?

mholt 11y ago

No, it allows site owners to create a certificate for any domain they can prove they own. Then, the certificate has to be installed on the server serving the site. Using it from any other server will cause browsers to reject the certificate.

alfredxing 11y ago

Let's Encrypt does validate that you own the domain, using certain "challenges" involving the web server, etc. Their technical overview explains how it works: https://letsencrypt.org/howitworks/technology/ https://letsencrypt.org/howitworks/technology/

dfabulich 11y ago

As a condition of being trusted, LetsEncrypt has promised to do "domain validation" before creating such a certificate. Domain validation is usually done by sending an email to the technical contact in the domain's WHOIS records.

mjevans 11y ago
It can also be placing a file of authentication data at a chosen resource location within the domain in question. (which is, I think, what their tool automates doing)

ubernostrum 11y ago

Look at the tech overview: https://letsencrypt.org/howitworks/technology/ https://letsencrypt.org/howitworks/technology/ You can only obtain a certificate for a domain if you can validate that you control the domain. Their steps for that (place arbitrary content at an arbitrary URL they request, or create an arbitrary DNS record they request) are such that, if you weren't the legitimate controller of the domain but could do those things, you wouldn't need a fake cert -- you'd already have pwned it thoroughly enough to be able to MITM it in other ways.

flashman 11y ago
> You can only obtain a certificate for a domain if you can validate that you control the domain. Technically, you only have to make their systems think you control the domain. If their servers or 'establish proof of ownership' process are hacked, wouldn't this allow an attacker to do the same thing that happened in the DigiNotar hack? https://en.wikipedia.org/wiki/DigiNotar https://en.wikipedia.org/wiki/DigiNotar
- Laforet 11y ago
  It's not like it ain't broken already. http://arstechnica.com/security/2015/03/bogus-ssl-certificate-for-windows-live-could-allow-man-in-the-middle-hacks/ http://arstechnica.com/security/2015/03/bogus-ssl-certificat...
- ubernostrum 11y ago
  Again we're in the realm of "if you could do that, you already could MITM or do other malicious stuff in a dozen other ways". So, sure. If you can hack a trusted CA, you can do bad things. That was true before.
- alwillis 11y ago
  This is why HTTP Public Key Pinning was created as a way to tell browsers to trust only a particular certificate, not just any certificate that was signed by a CA in the browser's trust store: https://news.ycombinator.com/item?id=10418144 https://news.ycombinator.com/item?id=10418144.
  - okigan 11y ago
    Another follow up: from your link, looks like the server adds a header specifying which certificates are allowed. Would not MITM just remove that header?
    - alwillis 11y ago
      From the RFC: https://tools.ietf.org/html/rfc7469 https://tools.ietf.org/html/rfc7469 Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].) The UA will not be able to detect and thwart a MITM attacking the UA's first connection to the host. (However, the requirement that the MITM provide an X.509 certificate chain that can pass the UA's validation requirements, without error, mitigates this risk somewhat.) Worse, such a MITM can inject its own PKP header into the HTTP stream, and pin the UA to its own keys. To avoid post facto detection, the attacker would have to be in a position to intercept all future requests to the host from that UA. Thus, key pinning as described in this document is not a perfect defense against MITM attackers capable of passing certificate chain validation procedures -- nothing short of pre-shared keys can be. However, it provides significant value by allowing host operators to limit the number of certification authorities that can vouch for the host's identity, and allows UAs to detect in-process MITM attacks after the initial communication.