91–100 of 111 posts
Without key pinning, are threre other options for site operators to protect their users from MITM by traffic monitoring appliances?
Is there an alternative to prevent people from doing MITM attacks on mobile apps? With HPKP running, apps with Charles requires a rooted device.
For mobile apps it's easier than for websites because native apps have more control over what's going on than the website, and can read the details of http connections (so in worst case, you can roll out your own pinning). For Android there are a built-in facilities for that in modern versions: https://developer.android.com/training/articles/security-con... For iOS: not an expert, but this article seems good https://…
They've started changing that:
https://developer.android.com/about/versions/oreo/android-8....
Earlier quoted context omitted.
There's a list of pinned CAs at the top of the hsts preload list [1]. Which gives you an idea of who might be trusted. Cert pinning is pretty nasty if you get it wrong. If you don't pin, there's a large number of CAs in most client's default trust stores. If you do pin, and the CA you pinned turns out to be bad, it didn't help. If you pin, but the CA stops issuing from the intermediate or the root that you pinned, yo…
Maybe this is a dumb question... but do larger companies like Google attempt to set up their own CA so they can be sure of the longevity and security, and not rely on a 3rd party?
Google's is called Google Trust Services:
(Note, Google was already running a sub-ordinate CA which was issued by a third party which is why you might have seen them issue their 'own' certificates previously, but they were actually 'subordinate' to the Root CA that issued them to Google initially).
As part of this process of setting up a new trusted Root CA it's necessary to get your trusted Root certificates into all products that may need to use your services. This is a trust system and has to start somewhere, so there is a list of trusted Root CA's and certificates pre-installed in every device. As you can imagine this can take time to do. Sometimes you can cross-sign your Root certificates using another pre-existing trusted CA (I think this is what LetsEncrypt did?) so that all products that trust that third party will now trust your Root CA (well, it's certificate).
That could potentially still leave you/devices that don't have your own Root CA's specific Root certificate open to tampering if the CA you got to cross-sign your certificates went rogue.
In mitigation of that last point above you could just buy out a pre-existing CA so they couldn't go rogue and make them part of your new Root CA collection, which is what Google/Alphabet did:
https://security.googleblog.com/2017/01/the-foundation-of-mo...
Even so, as you can see from that post, the process can still be lengthy to reach all products, particularly those that might not be updated with new trusted Root CA's (embedded devices etc) so Google Trust Services still plans (and has now I think?) to cross-sign its certificates with two other third parties it trusts to never go rogue (allowing products which already trust the third parties to now trust Google's new Root CA) in order to let it reach some of those products that don't (and perhaps will never be updated to ever) have it's newly owned Root CA's already installed in them.
It's a question of risk management and as you mention, the only way to fully protect yourself is to get everyone to trust you (your CA) as a Root CA, the rest just leaves you open to meddling.
Earlier quoted context omitted.
Well, try explaining that to the HSTS and HPKP folks. They already have answers littered on stack overflow and HN to advise to enable it for anything and everything. With exactly zero consideration for the potential to backfire. It's only a matter of time before an intern or an audit guy have it deployed on majorcompany.com and result in a disaster. Symptom includes none of the client ever able to access the site aga…
HSTS should never result in "none of the client ever able to access the site again".
Earlier quoted context omitted.
This 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.
The 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.
Earlier quoted context omitted.
There's a list of pinned CAs at the top of the hsts preload list [1]. Which gives you an idea of who might be trusted. Cert pinning is pretty nasty if you get it wrong. If you don't pin, there's a large number of CAs in most client's default trust stores. If you do pin, and the CA you pinned turns out to be bad, it didn't help. If you pin, but the CA stops issuing from the intermediate or the root that you pinned, yo…
Maybe this is a dumb question... but do larger companies like Google attempt to set up their own CA so they can be sure of the longevity and security, and not rely on a 3rd party?
It's likely different if you only serve requests for clients you distribute, and can bundle a CA cert. But if you're serving browsers, you need your CA in the default trust store which means passing audits, which is time and money and requires a fairly rigorous setup. If you do that, you still need to get your CA cross signed by an existing CA to use it, until the root is widely distributed, if you support mobile browsers, it's a long wait until you're really distributed. I don't know how much a CA charges to cross sign, but I would guess it's very expensive; and using the cross signed cert means sending an extra cert during tls handshake. There's an extension for clients to indicate supported CAs, but it's not really used, I'm not sure it's very sensibly designed -- anyway there's not a good way to know and then provide different certs for clients that don't know your CA.
Earlier quoted context omitted.
Oh cool, haven't read about this one before. Wonder why it didn't get picked up despite being a standard :(
> 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://ww…
Earlier quoted context omitted.
The 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.
The 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'…
True, it's an improvement that only the dutch government can do this, and not the Hong Kong post office. On the other hand, it is a major downside that we are encoding the possibility of government dragnet surveillance.
In the end, certificate transparency logs will let me notice whenever anyone issues a certificate for my website.
Earlier quoted context omitted.
The .com domain is controlled by the USG. If they want to serve a false DNS response, they can access the key used to sign the .com domain. That key can be used to sign a new key for the relevant domain, which can be used to sign the response. That the .com domain is under USG controll follows from: "The domain was originally administered by the United States Department of Defense, but is today operated by Verisign,…
Verisign is just a company located in the USA. Does it then follow that any company located in the USA is 'controlled by the USG'? That seems like a bit of a stretch, to say the least. There is nothing else there. Your reference to history is irrelevant today. Also, I really don't understand what this has to do with DNSSEC? Without DNSSEC anyone can forge responses. With DNSSEC you limit that to the zone administrato…
Whilst that is an improvement, it is still bad. Specifically, I'd it is not good enough to build a secure system on. There is an argument to be made that it is nice for defense in depth, but it should not be stand-alone security.
There are other practical concerns regarding DNSSEC at the moment with failure handling.
Earlier quoted context omitted.
It is deeply fucked up if a scanning checklist demands PKP, since most sites --- including most commerce sites --- shouldn't pin.
Well, try explaining that to the HSTS and HPKP folks. They already have answers littered on stack overflow and HN to advise to enable it for anything and everything. With exactly zero consideration for the potential to backfire. It's only a matter of time before an intern or an audit guy have it deployed on majorcompany.com and result in a disaster. Symptom includes none of the client ever able to access the site aga…