Can we please stop naming things after directions? I don't want to shift left/right/up/down and my data center has no north/south/east/west. Just say what you actually want to say without obfuscating.
I guarantee your data center has a north, south, east and west. I'm willing to bet that the north, south, east and west of your data center are the same as the north, south, east and west of the office I'm sitting in!
> I'm willing to bet that the north, south, east and west of your data center are the same as the north, south, east and west of the office I'm sitting in!
Not really. Magnetic declination is a thing. And besides, unless we're standing in the same place, my "north" is not your "north." If you want to fight me on that I'll meet you one degree due north.
Not to downplay this vulnerability, but I feel like relying on (valid tls cert+domain name) combination as the only line of defense for code paths which allow remote code exec is a recipe for disaster. At a minimum, if your application is downloading and executing some artifact from the internet, it should always be fixed to a particular version of the artifact and it should verify the hash of the downloaded artifact before executing.
>At a minimum, if your application is downloading and executing some artifact from the internet, it should always be fixed to a particular version of the artifact and it should verify the hash of the downloaded artifact before executing.
Gut instinct I was with you, but actually yes--there's some places I definitely want to be aware and/or involved when software updates and the torrent client is one of them. Not that it should force you to go download and install your own updates, I'd just prefer it to notify me and wait for approval.
Edit to note I don't quite agree with GP either, I see their point but cert-based security is pretty much the best we've got as far as I'm aware, likely what I'd use if designing this system.
On windows at least you can use a code signing certificate in your build tooling and ask the OS to verify any binaries that you download. Just make sure you use a timestamping server for your code signing or things will break when the certificate expires.
I think that would be challenging due to the nature of a potential man-in-the-middle attack here. An attacker could view and change contents of the request therefore making the hash check useless (other than for integrity)
Automatic updates and/or checks to a domain from a desktop app is a security angle that doesn't seem to be given as much attention overall. There are other scenarios like a hostile domain takeover (e.g. the original author stops renewing) which I haven't found a good solution to.
Sure, but how do you deal with expiration or revocation of that key? If someone is using an old version which doesn't know about the new key then you're back at square one right?
Linux package managers like apt and dnf deal with this as well. When a key is getting old, you generate a new key with an updated expiration and push it out using the old key to verify it.
If the old key expires before a new key is delivered, then you have a problem. This has happened to me a few times and it is a pain in the butt. You basically have to disable key checking in order to receive the new key, which breaks the security.
I would say it doesn't break it, it means you must manually inspect it to verify it Is indeed a key being published from the source you expect. But that's kind of the point right? If automated checks don't work, then you have to rely on the user doing a manual inspection.
None of the solutions offered address the risk that pinning tries to mitigate, namely that you have a client who trusts a misbehaving/rogue/malicious CA (perhaps you installed a VPN or AV or something that added a system-wide CA to your machine?) and their connection to your service gets mitm-d.
Shorter certificate lifetimes - does nothing to mitigate that risk.
CAA records - not checked by client, only ensures that if a malicious actor somehow gets a hold of your domain, they need to use a particular CA to issue their publicly-trusted malicious cert.
CT monitoring - yes, for WebPKI certs, but does not protect against the risk above, as the bad CA-s are likely not sending certs to CT log.
Distributed DCV checks - sure, this is something CA-s should be doing, not something you have control over.
ACME URI in CAA - operational issues quite likely, good if you can pull it off, but again, does not address the risk above.
What is an actual alternative to cert pinning? Your API should have an additional layer of encryption with keys that you have full control over.
While I agree this is a low quality article in desperate need of an editor (there were large sections that were essentially just repeated), I'm not sure I agree with your analysis, especially as it relates to CAA records.
I think the fundamental issue is that all of the players in the PKI world want to essentially enforce that services must be able to deal with short-lived certificates and certificate revocations. As an example, see the recent HN article where Digicert tried to do mass certificate revocations due to a bug with their certificate issuance, and were then sued by a client (Alegeus) who did not have things set up to deal with revocations quickly, so Digicert postponed the revocation: https://news.ycombinator.com/item?id=41114794 . So basically, the powers that be are trying to say "certificate cycling is part of the process - 'set it and forget it' is a thing of the past."
Now, in your objections, you state "None of the solutions offered address the risk that pinning tries to mitigate, namely that you have a client who trusts a misbehaving/rogue/malicious CA", but CAA with CT monitoring should largely prevent that. With CAA monitoring you state "only ensures that if a malicious actor somehow gets a hold of your domain..." - well, if a malicious actor somehow gets ahold of your domain, you're generally fucked in any case - if they've got control of your domain it's probably not a huge step up to get control of your signing cert.
I think your comment brings up good points to someone like me who's not an expert, but it still feels like the overall point that needs to be addressed is that "certificates should be expected to expire or be revoked at any instant" and certificate pinning breaks that.
There are ways a bad actor can get enough temporary control of your domain that they can issue a domain-validated certificate without actually breaching your service (BGP, DNS hijacks, Cloud provider vulnerabilities, etc). These cases you really need to catch with CT monitoring and CAA does help somewhat as well. And ACME uri pinning should mitigate this completely.
Edit: just to clarify, I agree with the article in principle, pinning public certs is just not a workable solution in the current TLS ecosystem and should be avoided, but the author of the article does not understand what attacks pinning is supposed to prevent in the first place, as the solutions offered do not offer the same security guarantees.
Also, the "Understanding the trade-offs of different certificate pinning implementations" misses one important thing : you can pin the CA, and still requires the cert to be valid for your FQDN
I've seen this a couple of time, and this is wonderful : fully secure, and denies the managed mitm setup by the security team.
And the only one time where I have seen this (in a private discussion of the mobile app with a bank employee), they said that they see no valid use case for a managed MitM against their production website. Preventing proxies like Charles and mitmproxy from working was one of their explicit goals for the app.
Tried it out, looks like at least on Debian the filter gets invoked with limited user privileges, so not world-ending, but still bad. And it does require user interaction, but my gut feeling is that this can be bypassed with some cleverness.
However, this is only for this particular exploit. The behaviour where cups-browsed automatically downloads and installs printers from random untrusted places on the internet is insane, especially as it does it for all printers it discovers on the local network by default. At minimum anyone on a LAN can cause a DoS type attack against all Linux workstations on the same LAN by just advertising a few million printers via zeroconf.
I do not ever use any OS or other software in my native language, however I do want most non-technical websites to display in it when possible. How do I communicate that?
These are all extremely good suggestions. Especially the flattening bit - yes, it's verbose as hell, but it just makes so much sense whenever you have to deal with the code any time after writing it. Helm charts, please take note, the docs even say that "In most cases, flat should be favored over nested.", yet almost every time I have to deal with a Helm chart, it's a mess of nested structures.
reply