My Solution to Fix the Screwed Up Internet Encryption
Summary
Transcript
They’re supposed to be bonded, audited, supplied with vaults and physical security, all for the purpose of building our trust. But as I said in a prior video, this whole thing is so zucked up that we can no longer trust it. Here’s the scoop. Any government or organization can call themselves a root certificate authority and by doing so can basically impersonate any website. The latest to do this is the EU.
All of what we consider to be encrypted would actually be readable in plain text to various parties. Well, this is screwed up and we cannot accept it. So in this video I propose a revamp. We need a new way to handle certificates that completely dumps the existing public key infrastructure, which as I described, can be bypassed. I will propose how we should do this. However, I’m a nobody, so likely no one will listen.
But still I will state my technical explanations of a solution that will save us from the current complete failure of the PKI. This is very important. Without a revamp of the PKI, we basically have no real encryption on the Internet. What we have instead is mass surveillance. Who can save us? Basically, I’m asking Google to step in. Unbelievable for me to say that, but you’ll see why later.
Stay right there for this deep dive web encryption, known to many as the HTTPs protocol, is actually officially called TLS transport layer security. HTTPs is the entire protocol that uses TLS. For the encryption portion, the old standard was called SSL, which is probably more familiar to most, but this is now retired. TLS is powered by public and private keys. The browser manages this by looking at the public keys, which are advertised by the website.
First, the browser negotiates an encryption key with the website, and this is done by the unique feature of DLS. If you have a public key, you can encrypt. If you know the private key, you can decrypt. The browser encrypts a message to the website and the website can decrypt it because the site’s private key is found on that server. Anyone with the private key can decrypt the message, presumably only the website server has the private keys so messages can be decrypted.
So this is the primary function of the TLS encryption provide a way to initiate encryption. The secondary function of TLS is to verify identities. The certificate has to be verified as actually belonging to the announced website identity. I just want to make this clear. The actual encryption portion of TLS is fine. In fact it was improved over the years and is the unbroken portion of this encryption standard.
But what is broken is the identity verification infrastructure. This is the public key infrastructure, or PKI. In order to understand the problem and solution, I will explain the structure of the public key infrastructure as clearly as I can. This will be technical, but it should be understandable for any power user. You will not likely get this simplified explanation elsewhere, as any I’ve read in the past has always left glaring holes.
The primary implementation of PKI actually resides on the browser in what we know as the HTTPs protocol. Whenever we go to any website we have the choice to prefix the website address or URL with HTTP or HTTPs. The difference between HTTP and HTTPs is that HTTP is not encrypted, all the traffic is in plain text. HTTPs, on the other hand, requires that the website show a public key certificate.
This is enforced by the browser. The browser checks that the public key matches the domain. So if the website is YouTube. com, it will check that the certificate matches the website. Actually, if you check YouTube. com you will see that it does not literally match the certificate of YouTube shows a certificate asterisk google. com which is a wildcard certificate. The validation is actually not based on the text content of the certificate name, but based on mathematically verified digital signatures.
What actually happens is that the certificate has a digital signature and it also has a certificate authority key, and both of these have to mathematically match some certificate authority public key on your certificate authority chain. The mathematical technique, by the way, is called hashing, which is a one way verification method. All of this is handled by the browser. While you think of certificate authorities as actual physical organizations, to your computer they’re just a list of files with certificate authority public keys.
Certificate authorities are part of a hierarchy. The top level is a root certificate authority, and then below it are intermediate certificate authorities. When validating certificates, the browser will validate a certificate up the chain of the hierarchy of certificate authorities that it has on record, so that all certificates, including intermediate certificate authorities, are always validated up to the root certificate. Now this is the part that most people don’t understand.
The certificate authorities are actually managed by the OS. So on windows you can actually view the certificates in control panel. By the way, in windows, the actual certificates are stored in the registry. You can find them if you use regedit in Linux. The certificates are actually kept in EtC SSL certs directory, and you can see they’re nothing more than just text files. What I want to explain here is that while the certificate authorities are real organizations with staff, offices, physical security, and are bonded, that image should really end when you look at your actual computer.
Anyone can insert a root certificate file in your computer, and by doing so they function as a root certificate authority just to establish this image in your head. Back in the day, verisign, the original root certificate authority, was sold to Symantec for 1. 2 billion. That guarantees that Verisign root certificates get placed in every single computer in the world. On the other hand, a vast antivirus which you can install for free, will install itself as a root certificate on your computer.
In fact, you can create your own set of public and private keys using various SSL utilities and install your root certificates on your computer or other people’s computer. And you basically become a root certificate authority without paying 1. 2 billion. You can see too that if you look at both Microsoft Windows and Linux computers, that Microsoft root certificates are preinstalled on these devices. Even though officially Microsoft is not an actual root certificate authority, they can just force themselves on there since all it takes is to put a file on a computer.
On Linux. They have cloud too, since they are part of the Linux foundation. So to extend this logic further, the EU is going to implement digital ids for all EU citizens. And part of this implementation is that an EU root certificate is going to be required of all browsers. The EU will also create its own hierarchy of certificates by inserting intermediate certificate authorities for each country in the EU, basically allowing each country to function as a CA.
And to make matters worse, they intend to make it illegal to untrust or remove EU certificates. So it should be clearly apparent now, after this explanation, that the identity verification of the PKI is flimsy at best. It can be overridden by anyone with lots of power, like a government that has power by law, a corporate it that has power over employees, or an OS maker that controls the OS, or any software that can insert a root certificate surreptitiously.
Now here’s the other dilemma with certificate authorities. TLS by itself is not limited to web browsing. In fact, TLS as an encryption architecture used in email client server communications like SoAp, and specifically in the case of Microsoft, Apple and Google. They are used for app signing. App signing is a way for an app developer to ensure that distributions of their products are authentic. They include a public key in the distribution of the app and the distributing entity like the Apple App Store, Google Play or Microsoft Store can validate that it was in fact provided by the original entity that had the private key.
This is the legitimate use of the root certificates provided by OS makers like Apple, Google and Microsoft. Unfortunately, the way the OS handles root certificates, it doesn’t really distinguish users of the certificates for various purposes. There’s no way to limit a root certificate to just validating websites versus validating apps. Currently you can use the root certificate for any purpose. This for one allows more root certificate authorities to exist, and these certificate authorities can be maneuvered into supplying certificates for a completely different purpose, like mass surveillance.
For example, there are Microsoft root certificates in practically every computer OS, including Linux, although I haven’t found it on an Apple machine. But beyond app signing, Microsoft could theoretically assign some other entity as an intermediate certificate authority and then have that private key be handed to a government. This would enable mass surveillance of every device and there is no check and balance on this. This could be done by Apple, Microsoft and Google, the makers of the OS.
The other general issue with the whole PKI architecture is what each certificate authority does is completely opaque to the public. There’s no actual public record of what certificates are issued. This then allows a certificate authority to issue fake certificates ad nauseam and power any mass surveillance interceptor device in every country. We need transparency. This is the only way we can develop trust. So what is the answer? I will propose a series of changes that could actually be implemented piecemeal and the main party that would be responsible for execution of this would be the browser maker.
You would think. There are many browsers, but actually they are based only on a few base source code providers, chromium, Mozilla, Firefox and Safari, which is webkit. Chromium, for example, is the basis for Chrome, brave Edge, Vivaldi, opera, Duckduckgo to name a few. Firefox also powers waterfox and Tor. Safari is just for apple versions. So you can see even just making this change on chromium would likely affect 60% of the browser traffic.
So this is very significant. Again, to make it clear, what we need to solve here is the PKI identity issue and that is what I will propose here. Number one, all certificates issued by any accredited certificate authority will need to record the provided certificate in a blockchain. Now there are many ways to implement this, but let’s first talk about why a blockchain. The blockchain, as many of you know, is used to power cryptocurrencies, but that is not the only purpose.
A blockchain is an invention based on the principle of immutability, meaning it is not changeable. Once something is recorded on the blockchain, there is no possibility of ever undoing or modifying an entry. Ever. This is based on a math technique called hashing. If every CA inserts every certificate issued in a public blockchain, we could easily verify if they were cheating, since we could check it historically, we can see if the certificates match the one we publicly see, and this would basically end the possibility of fake certificates.
A couple of issues here. Blockchain technology does not have to be reinvented here. This kind of logging could be integrated with an existing blockchain using Ethereum, and ERC tokens could be used with very little effort. Now cas could band together and create a brand new peer to peer network with a new blockchain, but that’s not even necessary. In order to record a certificate in the blockchain, there has to be a check for duplicates.
The CA must not allow a duplicate entry or the blockchain infrastructure should prevent it. If a new certificate is needed, the new certificate must supersede the old certificate and the old certificate reported as inactive or expired. Verification can be done as usual by putting validation text on the server and read by the CA. Number two, each browser needs to verify their certificate against the blockchain. What I’m talking about need not be a single type of technology.
A browser could announce support for a new standard while still allowing the current PKI to exist, but the difference will be in how the website is verified. As an initial implementation, the browser could state if the website is validated against the blockchain identity or not. If not, then maybe a different symbol would indicate a lesser level of trust. This would not stop, let’s say, a local machine from operating without a trusted certificate.
Just the appropriate warning will be given to the user so they know what the risks are. If I’m the only user of a local machine, then I don’t need to be disrupted by a browser about validating the entity or even the encryption. Number three, there should be a way to verifiably view all the website certificates issued by every certificate authority, assuming every transaction is immutably recorded in a blockchain.
A publicly accessible database should also be provided that can sort through every entry by CA. This way anyone can audit any CA for any hanky panky business. This will also protect people in authoritarian countries since they can verify if their communications are actually private or if there’s an interceptor man in the middle device in their Internet. Again, the goal here is transparency. Both a new method and an old PKI method can coexist while website owners transition, but the browser will force the transparency here.
Number four, there should be an MITM warning from the browser. If the browser checks the blockchain and there is an unexpired certificate issued for the site, but the same named site shows a completely different certificate, then the browser should then infer that there is a man in the middle and state an appropriate warning. Once a website transitions to a blockchain based certificate, then this should protect that website from nonblockchain based certificates which will now be guaranteed to be a spoof or impersonation attack.
Number five, cas must specify the purpose of their root certificate. Each CA must supply separate certificates for each functional purpose of the certificates they are issuing. If used only for app signing or email then that should be stated. If used for website identity then that should be stated. The browser must not allow cross use of certificates for other purposes without stating that the certificates is invalid for that purpose.
This will allow a Microsoft, Apple or Google to put app signing certificates on a device, but prevents those from being used to create fake website certificates. The advantage of specifying function could be that app signing certificates need not record on the blockchain. The main thing we need to focus on first is website identity. That’s it. A simple solution that mostly requires browser changes. The CAS just need an automated way to send their approved certificates to this central blockchain.
The nice thing about this is that it’s a solution that can coexist temporarily with other solutions and a gradual retraining of users will also occur to set their expectations of what to trust. This system is trustless. There is no entity that becomes centrally responsible for auditing since it is self auditing. The website owner can easily verify from the browser if the issued certificate is recorded in the blockchain.
Who can implement this? Well, Google could implement this very quickly via chromium and they could easily build an open source public API that could be provided to every CA to record their certificates on a blockchain. Google was an early victim of site impersonation not only from the evil actions of Symantex bluecode systems, but also from several chinese cas that have been doing fake certificates. Google built a protection for themselves by putting the signature of the certificates directly into Chrome so Chrome itself can check if a Google certificate is authentic.
But this protection can exist only for Google. They basically built an immutable entry for the certificate signature in Chrome itself. This is called certificate pinning, just like I’m recommending we do for all sites but stored in a public blockchain. The problem is that this method I’m talking about will be rejected by three letter agencies and five eyes governments. Stakeholders with an interest in mass surveillance will reject it.
It requires someone like a Google to actually, for a change, not do evil, but do good. If Google does this, they will do good for humanity in general and substantially limit mass surveillance and enhance the value of web encryption. So Google, can you take the ball on this? I created a company to offer solutions to privacy instead of just talking about problems. All these products are in the store on my app Braxme.
Sign up on there. Don’t worry, you will not be asked to give any personal information to sign up. Thank you for watching and see you again soon. .
