Public key cryptography is actually excellent when used correctly, but this is not the case for modern web browsers (which is mostly what it’s all designed for), and I’ll show you why. As an average Joe, you’ve probably used a web browser to visit a web site on the internet many times:
As shown above, the site your browser talks to is hosted on a server (some computer out there, connected to the internet). You may be interested to do online banking, so you really don’t want that server you’re speaking with to be someone else pretending to be them:
This is called a man-in-the-middle attack. Public key cryptography is supposed to stop this from happening. If I own a website, I can try and ensure this doesn’t happen by enabling SSL on my site. To enable SSL, I need to initiate a certificate signing request. IIS does a lot of this transparently, but basically it will create both public and private key pairs for my server and all the details I need to get a signed certificate. I then go to some certificate authority, send them all the details of my request (except my private key, which Windows stores internally in its Cryptographic Service Providers), pay them some money, and get them to sign my public certificate. They then return this public key certificate back to me:
I then add that certificate to my server. The certificate only exposes the public key to the outside world and IIS will use the private key within the Cryptographic Service Providers for its key exchange mechanism:
When Joe connects to my site using his web browser, my site gives him the signed public certificate if he connects using SSL (usually, the “https” prefix to a URL will indicate that the connection is secure, versus the unsecure “http” prefix):
Joe’s web browser checks to see if that signed public certificate’s signature is valid by comparing it to a cache of public key certificates that it has from all of the different certificate authorities it supports:
Joe’s browser will establish a secure communication channel with that site. If it can’t verify the signature of that certificate, it will warn him:
Not being able to verify indicates the possibility of a man-in-the-middle – or does it? That’s pretty much the process, and yes – you heard right. Web browsers have a local cache of public key certificates from certificate authorities that they use to check signature accuracy on certificates that sites present to them. This is a huge flaw, for so many reasons. If a certificate authority’s private key is cracked and they need to reissue key pairs (and thus, new certificates), you may be vulnerable until your web browser manufacturers release a patch or somehow push new certificates down to your browser, if you ever end up updating the browser itself that is, or if they actually push new certificates securely. This is just one problem. But what I really wanted to get at is this – nothing is stopping a man-in-the-middle from posing as your server if he can get a certificate claiming to be you from any browser-supported certificate authority. All he needs is a signed certificate from any certificate authority that your browser supports, since your browser caches certificate authorities’ public certificates (and it will show as “Verified” for any certificate authority-signed certificate). As such, he can relay messages between you and your actual server, snooping on all the traffic, unencrypted:
You see, nothing is really stopping an attacker from gaining a certificate like I did for my site except maybe the level of protection you pay for (meaning, if you originally paid for some sort of Extended Validation Certificate from your certificate authority, the attacker might have a harder time getting a certificate signed that claims he’s you from that same certificate authority). Extended validation doesn’t solve much of a problem, because not only can he actually obtain a signature from my certificate authority, he might be able to obtain one from any other certificate authority and claim to be my site, and you would have to know what certificate authority you’re using originally to actually detect such a thing (as well as periodically monitor your site for changes in signatures using external requests from across the globe since an attacker may only snoop based on IP geolocation):
Not to mention the fact that a government can subpoena any certificate authority to forge a certificate claiming to be “someone else”, from the very same certificate authority that “someone else” used, and transparently monitor all traffic across that site unencrypted. So even if you do use HTTPS to connect to a site, it may still be monitored unencrypted by somebody. Are you skeptical that this could ever happen? Here’s some proof that’s its been done before. Also, some certificate authorities actually require that they generate both public and private key pairs for your server. This is a big no-no. You should never, ever expose your private key to anyone. Even certificate authorities go to extreme lengths to never let this happen to the private key they use to sign certificates.
But fear not, for there are nice and elegant ways to avoid such things. One way is to not expose vital information over the internet, physically distribute client software as applications, and have those applications use a mechanism known as certificate pinning. Essentially, this lets you become your own certificate authority…because as an average Joe, you aren’t allowed to add your own certificate authority certificate into a web browser’s cache unless you shake hands with the manufacturers and have some pretty deep connections.
So I ask you all this, armed with this knowledge, and after having read my article, do you trust certificate authorities?
If you want to read more on the underlying mechanism for key exchange, SSL certificates will usually use the RSA cryptosystem, which has been around since 1977 and has proven itself. Its based on the difficulty of factoring a number computationally. Its hard to find the factors of an extremely large number…but, I guess that’s a moving target, especially with supercomputers out there that have so many cores that threading out such a mathematical computation would likely break your private key in no time at all.
