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?
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.
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?
http://arstechnica.com/security/2015/03/bogus-ssl-certificat...
So, sure. If you can hack a trusted CA, you can do bad things. That was true before.
Would not MITM just remove that header?
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.
M2Ys4U 35 days ago
According to their 31C3 talk, they will use multiple
connections from multiple locations (possibly including
Tor?) to mitigate against these attacks.
This isn't really a failing on Let's Encrypt though, because tons of other CAs issue certs by only verifying this exact same stuff. Certs are only as secure as the least secure CA. Since the security was already this weak, Let's Encrypt has not made it any weaker.
#1 letsencrypt blocks any request for domains which SSLObservatory (https://www.eff.org/observatory) reports as having observed a certificate, and additionally require that you show proof of possession of the private key. Every domain letsencrypt has served will also be treated with this requirement.
#2 letsencrypt will use multiple paths through the Internet. They have not given the exact details yet (I would guess that they will take different path by AS numbers).
#3 There is a block list. I don't remember the exact method used here, but I think it was simply based on Alexa rank.
Their technical overview explains how it works: https://letsencrypt.org/howitworks/technology/