4 ms·
Good riddance. It had low adoption and pales in comparison to what will be achieved with Certificate Transparency. DNS redirect attacks (common/easy due to soc
by sigmar 9y ago
Good riddance. It had low adoption and pales in comparison to what will be achieved with Certificate Transparency.
DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming ("many of your users can't access your site unless you pay me for the key"). I've heard many surprised it hasn't happened yet. Particularly considering the lack of recourse options for victims.
- yebyen 9y agoWhat would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) If someone ransomed you, would you need to pay them for the key, and then use the key on your site from then on? So, you could pay the ransom and they'd be able to decrypt all of your traffic from then on? (I'm sure I just don't know how HPKP works, like there's some solution where the ransomer's key/the compromised key can be used to sign another key, and then HPKP pinners that cached the bogus key can now accept it as the new key... but then couldn't you use a compromised key to do the same attack again in the future?)
- mschuster91 9y ago> What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) The fix would be to embed the expected key fingerprint in DNS and have the browser issue either a 2nd request for it or have the DNS server return it as additional data just like when requesting a CNAME record and it returns the A record too. Then, to prevent DNS MITM attacks, have the whole zone and the domain's zonefile signed. On the other hand, given that DNS is UDP, this opens up the possibility of an MITM attacker simply suppressing the 2nd request for the HTTPS key, or corp firewalls/MITM boxes/crappy provider DNS servers simply filtering out the responses...
- posixplz 9y agoSounds a lot like DANE/TLSA.
- mschuster91 9y agoOh cool, haven't read about this one before. Wonder why it didn't get picked up despite being a standard :(
- rocqua 9y agoThe basic reason is that people really don't like DNSSEC. tptaeck (https://news.ycombinator.com/user?id=tptacek https://news.ycombinator.com/user?id=tptacek) has plenty of comments really supporting that argument.
- dane-pgp 9y agoI won't say he's wrong, but he presents a very one-sided view. It's worth reading the responses to criticisms like his: https://www.easydns.com/blog/2015/08/06/for-dnssec/ https://www.easydns.com/blog/2015/08/06/for-dnssec/
- detaro 9y agoDANE is used a bit for SMTP (where it also forms a clear "only talk to our mail servers over TLS" signal, which as far as I know didn't exist before) As a replacement for HPKP it doesn't solve the big attack scenario of someone taking over your DNS and obtaining a certificate to impersonate your site: if they can do that, they can also put false certificate details in DNS. It's also tied to DNSSEC, which isn't universally deployed for domains, would if I understand correctly putting a full DNSSEC-resolver in the browsers to protect against local MITM (which isn't practical in many situations) and often criticized.
- hannob 9y ago> Wonder why it didn't get picked up despite being a standard :( It doesn't work on the real internet, only on some fantasy internet that merely exists in the head of DNSSEC advocates. Basically you can only do DNSSEC if you can receive arbitrary DNS records. That's not the case for a non-negligible portion of Internet accesses, where those queries get filtered. Adam Langley has pointed this out years ago: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html So if you want to deploy DANE you can choose between falling back to insecure (so it's entirely pointless) or breaking the Internet for a large fraction of users. Neither is a very good plan.
- rocqua 9y agoAs the other commenter said, this sounds a lot like DANE. As such, it suffers from the same issue: it relies on DNSSEC. If you look at the trust chain for DNSSEC on the .com domain, you are trusting the US government and your registrar. The US government is the bigger issue here, as the NSA is also a part of them. You might argue that this is 'good enough' but considering the momentum that these kind of systems have, a wrong decision here could really enable NSA spying for a long time. Besides, CT logs seem like a much better solution than key-pinning anyway.
- amalcon 9y agoThis has always seemed like a really silly argument. You're already trusting the US government, VeriSign, and a multitude of other organizations that control CAs, so DANE doesn't make this worse. It's kind of a moot point, though, since DNSSEC is garbage for other reasons. Certificate transparency logs are the current best effort in this area.
- rocqua 9y agoThe point is not that DANE doesn't make things worse. The point is that it is not a solution. Originally, DANE was meant as a method to restrict rogue CA's from issuing certificates. The fact that state-actors can still do that after DANE makes DANE a bad solution.
- lmm 9y agoThe US Government is and should be the root of trust for US domains (certainly for .us, and de facto that's become the use of .com too). Since the US government can compel any US entity to follow secret orders, if you don't trust the US government you already couldn't use any US sites. DANE improves things compared to not, since it means you don't have to trust the US government if you're not using US sites, you don't have to trust the Chinese government if you're not using Chinese sites, you don't have to trust the government of Kazakhstan if you're not using Kazakh sites...
- 9y ago
- pfg 9y agoYou would indeed have to use the attacker's key until the pins of all visitors who visited the site during the attack expire. I believe the maximum HPKP max-age in Chrome is 2 months, it might be longer in Firefox. There is no mechanism that would allow you to use the attacker's key to sign another key: HPKP requires that the pinned key is present in the actual trust chain selected for your connection. You could switch to a non-compromised key a bit earlier by setting max-age to zero and waiting for a certain percentage of the affected visitors to return, if you're willing to accept that the remaining affected visitors cannot access the site for a few months.
- nly 9y ago> DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming How? Someone can hijack your resolver but they still need a valid certificate for the name before they can install the pin?
- Laforet 9y agoOnce an attacker controls a domain it is trivial to get a DV certificate signed with their own key.
- nly 9y agoHijacking a authorative DNS server is different kettle of fish to hijacking a resolver used by a client. You need to either infiltrate a CA or do the former for a DNS attack to work and get you a DV certificate.
- user5994461 9y agoOnce a site is breached, the attacker is usually in control of the domain and he can order any legitimate certificate for it.