3

Taken from Wikipedia, here is the pretext to my question:

A certificate authority (CA) is an organization that stores public keys and their owners and every party in a communication trusts this organization (and knows its public key). When the user's web browser receives the public key from www.bank.example it also receives a digital signature of the key (with some more information, in a so-called X.509 certificate). The browser already possesses the public key of the CA and consequently can verify the signature, trust the certificate and the public key in it: since www.bank.example uses a public key that the certification authority certifies, a fake www.bank.example can only use the same public key. Since the fake www.bank.example does not know the corresponding private key, it cannot create the signature needed to verify its authenticity.

I get that certification authorities help thwart man-in-the-middle attacks, but I don't understand the point of spending money to use a certification authority's certificate if browsers just hardcode the CA's public keys to validate it outside of HTTPS communications which seem to be somewhat browser-dependent because...assuming I use RSA encryption with SHA1 and OAEP padding on my server, isn't it just as secure if I:

  • Generate a secondary private and public key pair
  • Keep secondary key a secret, write it down somewhere and lock it inside a vault
  • Always sign my server's primary public key with the secondary private key
  • Hardcode the secondary public key in my client applications
  • Use my secondary public key to check if the server is the server they say they are by checking that the public key they issue to me is signed with my secondary private key?

I am thinking of using this model over a TCP socket server where I can specify my own protocol and essentially be my own "browser"...

Essentially, is this all that's behind a CA? That's pretty sad...it honestly feels like a money-grab scam when you can just become your own CA. I mean, if the CA is compromised, browsers need to get patched, keys reissued, etc. If my client application becomes compromised, I don't need to wait while the hole is closed, I can quickly push out a new public/private key pair and send the public key of my pseudo-CA to client applications.

Alexandru
  • 175
  • 7

2 Answers2

4

What you're describing is called certificate pinning; essentially, you ignore the whole CA process and just give the user application a certificate to trust. It's actually widely recommended for non-browser applications (e.g., mobile apps) for the exact reason you stated - if you rely on a CA and it goes down, you're in pretty deep trouble, whereas it's relatively easy to fix it quickly with certificate pinning by pushing a new certificate. Or better yet, you can have two certificates in your app, and rotate them if one goes down, then push a new certificate in the next update.

Of course, web browser makers can't amass and verify a collection of everyone's certificates ever, so they choose to trust a few centralized servers that then verify everyone else, and this is mostly successful at keeping users out of trouble. That's why the CA system exists.

I should clarify that you're still trusting a third party - it's just a different third party that doesn't charge you for the privilege. For instance, if we're talking about an iOS app, the app is signed by the App Store. That's what's preventing an attacker from swapping out your hard-coded certificate with another certificate.

Neil Fitzgerald
  • 374
  • 1
  • 2
  • 10
  • You said, "web browser makers can't amass and verify a collection of everyone's certificates ever,". But they essentially just offload the work of amassing certificates to CAs...I can't believe that it hasn't been standardized to simply have them trust a set of CAs they all manage together that issue certificates for free. I mean, I'm paying for two integers to get generated on a server and one of them signed. – Alexandru Jul 04 '14 at 01:08
  • Actually the more I think about it, what's stopping a man-in-the-middle attacker from buying and then presenting a certificate for my domain from the same CA my actual domain uses? – Alexandru Jul 04 '14 at 01:10
  • 1
    I was under the impression they did some due diligence to verify that people applying for certificates actually own the domains in question. I might be wrong about that, though. – Neil Fitzgerald Jul 04 '14 at 01:10
  • Well $&@#, I hope you're right. – Alexandru Jul 04 '14 at 01:11
  • With things like domain privacy and hosted domains, how in the world would they know who requested that certificate? Maybe they just want that paycheque at the end of the day. – Alexandru Jul 04 '14 at 01:15
  • I'm afraid you're out of my expertise there. I don't know anything about the logistics of applying for a certificate. – Neil Fitzgerald Jul 04 '14 at 01:16
  • 1
    Check this out: http://security.stackexchange.com/questions/38199/can-a-nation-state-adversary-perform-a-mitm-attack-by-compelling-a-ca-to-issue-t – Alexandru Jul 04 '14 at 02:02
  • 1
    Then check this out: http://security.stackexchange.com/questions/36781/how-ca-ensures-that-a-certificate-request-is-coming-from-me – Alexandru Jul 04 '14 at 02:06
  • And then, if you're thinking what I'm thinking...CAs can go #$@% themselves. – Alexandru Jul 04 '14 at 02:06
  • 1
    Well...to be fair, if a sufficiently resourceful nation-state is out for your blood, you're gonna have a bad time no matter what. – Neil Fitzgerald Jul 04 '14 at 02:11
  • Hahaha, yeah...I agree, because EVEN if you did use certificate pinning, the app store in question can become compromised right? Your users might be downloading your app, except with minor touch-ups that include the NSA's pinned certificates for example. I think certificate pinning is still probably the way to go, and its even better if you don't use a middle-man to distribute your application (no app store to worry about means no issues - ideally you deliver the product physically), assuming you don't rely on a web client. This is just a terrible system, and I don't like it. – Alexandru Jul 04 '14 at 02:17
  • 1
    Right, although the App Store is less likely to be compromised than some CA in Turkey. – Neil Fitzgerald Jul 04 '14 at 02:19
  • Still, it would be rare to have something like that go under the radar at a major company that runs its own app store. I mean, with so many employees using the same code repository, you don't think someone will speak out about it? – Alexandru Jul 04 '14 at 02:19
  • "What should I do tonight? Oh, let me look back at some of that old App Store code I've already seen, that was some good stuff," said nobody ever. I'm being a little cheeky, but I don't think it's impossible. – Neil Fitzgerald Jul 04 '14 at 02:20
  • Hmm...that's true. People don't care enough. Not much you can do to stop someone from modifying your subversioning server's files if they have access to it and they want to be extremely sneaky about it. Pinning without some app store and with a physical client app delivery method is the best way to go...I can't think of a better way to do it...it was fun talking to you about this :) now its time for bed...to dream of butterflies and unicorns and live in denial in a world where everyone is OK with the current setup and oblivious to internet security LOL. – Alexandru Jul 04 '14 at 03:13
  • In case anyone was wondering if this ever actually happens: http://googleonlinesecurity.blogspot.com/2014/07/maintaining-digital-certificate-security.html – Neil Fitzgerald Jul 08 '14 at 19:30
  • Yeah. Better think twice before you decide to write web apps over SSL which 90% of companies do. :) Imagine if banks got hit? An informed social hacker in some cases could probably persuade a CA that they are a part of your organization, and that they need a certain certificate signed for your domain...and some CAs actually store your private key. Thats a big no-no. You need to make sure you get them to only sign your public certificate. – Alexandru Jul 08 '14 at 22:29
2

What you intend to do by signing your primary key with a secondary key is essentially using your own CA. In theory, a CA is a third party trusted by the participant who tries to verify the identity of his communication party to reliably verify this identity. In practice, in web context this decision which CAs are trustworthy is not made by the end-user itself but by the browser vendor who includes the CAs root certificate (although a few users make their own decisions by modifying this preset list). In your setup, you control what the trustworthy issuers are, because you control your end users software. You don't even need another protocol, you could just use x509 certificates and configure that only your own CA is trusted.

Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
Drunix
  • 298
  • 2
  • 7
  • I could, but it won't be transparent. In terms of multiplayer games, almost all users don't know how to configure a certificate and add it to the list of trusted certificate authorities, and if they had to even do that across every device that I distribute my client app on, then they'd probably decide to not use my app at all. – Alexandru Jul 04 '14 at 12:10
  • 1
    Since you wrote you intended to implement you own protocol, I thought you game was only playable by app where you could control the list of trusted CAs. – Drunix Jul 04 '14 at 12:56
  • Oh, I see. You mean to do all the pseudo-CA validation in the app itself, not to use the (for example) iPhone's built-in CA validation scheme. – Alexandru Jul 04 '14 at 13:00
  • Yes. In java apps you could for example supply your own truststore with your CA certificate ("secondary key") included or provide a custom X509TrustManager. Don't know how to do that on iOS. – Drunix Jul 04 '14 at 13:07