Expect-CT
Wondering what Expect-CT is? This bloke knows what he is on about:
https://scotthelme.co.uk/a-new-security-header-expect-ct/
RIP HPKP: Google abandons public key pinning
Google is abandoning a next-generation web crypto technology it initially championed. HTTP Public Key Pinning (HPKP) is a standard that allows a host to instruct browsers to only accept certain public keys when communicating with it for a given period of time. While HPKP can offer a lot of protection, the technology was open …
-
Monday 30th October 2017 14:19 GMT streaky
Problem with PKP
Basically if you had a problem with your cert and needed to drop it you were up shit creek with a conventional cert deployment, PKP makes sense only if it's long-lived so you had to maintain two (or more) separate certs for every domain and ensure those digests are both being sent to clients, it's not a cost issue it's a complexity/maintenance issue. Without a backup cert if you year-long your PKP header and your cert is compromised or similar in the first few months any client that connected in that first months won't be able to connect to your server. Your backup cert can't be near production servers either because if your main cert is compromised your backup one probably would be too so how do you digest it to clients? It's a nightmare to maintain that sort of set up.
Behaviour of browsers with regards to what happens on revoke with PKP isn't well defined and behaviour of CA's themselves with regards to cert revocation itself isn't well defined - and that's ignoring misconfiguration giving people completely unusable domains for year-plus periods - and all this has obviously led to poor uptake of the technology.
That being said the principle of the domain owner/admin being able to specify precisely which certificates are allowed to serve the domain is a very powerful tool when clients respect it. It's just not clear if there's another way to offer the same level of protection (cert transparency doesn't, although it potentially has a wider appeal and may or may not be "enough" protection). This is one of the reasons we need to do a better job of securing zones - which DNSSEC equally isn't up to the task of. Once we have a secure DNS system we can tag keys to domains in a more reliable and secure way and tools like PKP and cert transparency will be completely unnecessary.
-
-
-
-
Tuesday 31st October 2017 14:49 GMT streaky
Re: Still waiting for DANE
It's worse than that, one of the strongest perceived threats to crypto security is state actors (well, it's not perceived, it's a fact) - and state actors in most cases will have far more ability to screw with DNS than anything else.
There's a moral hazard here though - securing PKI this way calls PKI's existence into question. If a domain owner can specify keys for sites it operates and DNS is cryptographically secured in terms of data content (records signed by domain controller, as opposed to the DNS provider) then PKI providers will probably face questions about the necessity of them continuing to exist. Security of DNS record would be the prime concern of domain registrars and DNS providers but when DNS is secured properly and you can specify any key and it's equally secure as PKI infrastructure would otherwise be (and arguably more so) then they're going to have an issue. That's why expect never to actually see a secure DNS system; because it's not in the cert authorities best interest to secure it.
-
-
-
Monday 30th October 2017 18:29 GMT John Smith 19
Odd thing for Google to supply. It doesn't help them slurp more of your data faster.
What's it for?
As for certificate management (both live and offline backup in case of compromise)
Is there not (by now) an app for that?
Or at least a plug in for some management framework to do this?
If not, why not?
-
Wednesday 28th February 2018 02:10 GMT aberglas
How will secruity software proxy TLS?
Many corporate tools work by issuing all their clients with an internal trusted root cert. This then enables them to proxy TLS and do deep inspection of the packets by simply providing their own site based certificates.
Will CT prevent this trick from working? Is that the point? Or does it just mean that the Loggers also need to be proxied?
(The real solution is not to rely on PKI at all, but to use Secure Remote Password. Also kills phishing dead. Passwords should never be sent to servers, just a proof of possession.)
Biting the hand that feeds IT
