Thoughts about Trust on the Internet

Welcome. Thanks for joining me on a little journey about trust on the Internet. Hopefully you'll stick with me on this journey and I'll try to explain my thoughts on trust and why we may be misplacing some of it.

Trust me...

To begin, let me  define what I mean by "trust".  I mean, when I connect to a site that is providing a service, I can trust that the site is what I think it is and can the site trust that I am who I say I am.  How is trust established on the Internet where everyone can be anonymous?  Usernames+Passwords?  Tokens? Texts?  No. On the Internet trust in a site is established by the use of a certificate.  "Everyone knows that", I hear you say. But  what is a certificate?  What is it really?

Coloring book anatomy of a certificate

I call this the coloring book anatomy of a certificate because I am not going to specify what goes into a certificate in any detail.  At a high level, a certificate contains 3 parts.  The certificate information (subject, issuer, dates, etc), the certificates public key and the signature from the certificate signer.  To validate the certificate is, er... valid, the public key of the signer can be used to take the first 2 parts of the certificate in question and generate a signature.  If the generated signature matches the signature in the certificate then the certificate is valid.  But wait, how do we know the certificate used to sign our certificate is valid?  Well, we can do the same process with that certificates issuer information.  And so on, until we get to a certificate we trust.  This is often referred to the certificate chain of trust.

Chain of Trust

Our browsers trust the certificate from sites.  How?  Is every site's certificate stored in our browsers?  No.  Instead our browsers are shipped with a "Trusted Root Certificate Store" (TRCS).  For sake of argument this is a list of root certificates that the browser will trust and, by extension, anything signed by those root certificates, the browser will also trust.  Simple.  But wait... where do the browsers get those root certificates?  Is there a clearing house for root certs?  Can I create my own Root Certificate authority and get it added to all the browsers so now I'm trusted?  The answer to both those questions is also no.  Companies (governments) pay (or mandate) the browser makers to add their root certs to the certificate store. Do you trust those companies?  Have you even heard of the companies?  Do you trust your government?  My government?  Should you?  The point is, that while the certificates form a chain of trust to some Root Certificate, the trust of the root certificates is, at best, suspect.  What do I mean?  Well let's assume we have a perfect world and I choose to buy a certificate for my domain from one of the trusted certificate authorities.  The certificate authority should issue the certificate to me because, presumably, I was able to prove that I owned/controlled my domain.   If I tried the same thing for say, google.com, the certificate authority would see that I couldn't prove that I control the domain and tell me to pound sand.  This is in a perfect world.  But would would happen if one of the certificate authorities mistakenly issued a certificate?  Suddenly there would be two valid certs for google.com. How could you tell them apart?  Do you know the real root certificate for google.com?  You say, "Thankfully the scenario like this hasn't happened."  Not so fast. Look here, here, here, here, and here and here. These situations happens more than we think.  We only hear about this when it impacts large/noticeable sites.

Not to pile on, but the TRCS is different between different browsers and operating systems.  Each browser and operating system gets to set their own policy on what Certificate Authorities they trust.  So trust from one browser to another may not be the same. Who are you going to trust?

Do I know you?

How does the site trust I am who I say I am?  A certificate? Doubtful.  Its doubtful that a site issued you a certificate to prove your identity.  Instead, you "signed up" using a web page, provided some information, username password, email, cell phone.  Then clicked "Agree" on the terms of services acknowledging that you read it (which you didn't), and then proceeded to the site.  At best the site supported Multi-Factor Authentication (MFA) of some type and you turned it on.  However, after you sign into a site with your username + password + MFA?  the site sent your browser a "cookie".  A string of numbers, letters, etc, that when you present it back to the site, the site can verify it's you.  The site, in order not to inconvenience its users/customers, sets this cookie to not expire for days... weeks... or more.  Is this sufficient?  Ever have the experience of having to clear the browser cookies and then have to login to every site you visit again? (Good thing you use a password manager ;) )  Is having authentication cookies stored in the browser even important?  Depends.  If the cookie is for a login to the NYTimes Online, then almost certainly, no.  If something were to get my username + password or steal the cookie, is there any loss?  Probably not to me.  And the NYTimes, may have "lost" a paying reader... but let's be honest... they wouldn't have even noticed. Now if the site my bank.  And my money is transferred away, that I would care about! So is this trust sufficient?

You might say, "I authenticate with Google/Facebook/etc" when I login into  a site. Does that improve trust?  I argue no and that behavior may even lead to increased risk.  The site you are trying to login into is just outsourcing the user authentication interaction to a third party and "trusting" the third party to do the right thing? What happens if there is a problem at the third party?  The site you are connecting to is implicitly trusting the authentication from that 3rd party authentication vendor.  Isn't this behavior similar to using the same username/password on every site you connect to?  Trust is not increasing.  In fact it's placing greater weight of trust on that 3rd party authentication vendor with every site that relies on that vendor for authentication.  The counter argument is that the authentication provider is better equipped to provide and defend the service.  That is a reasonable assumption, but is it pertinent?  Does the authentication provider care about you.  Are you their customer?  Are you paying them money?  What did that agreement you clicked through say about liability for harm sustained while using the site/service? Will that authentication provider make you whole if you loose your money, home, freedom? Doubtful.

So where we?

I think we can probably trust the Certificate Authorities in the TRCS.  While mistakes can happen, the record, for now is that the registrars seem to be pretty well self regulated and try to maintain a sense or order, fairness and trust.  At the very least, there isn't much choice if we want to utilize the web as it works today.

However, trusting of users, I'm not sure there are any good options.  Usernames + passwords have given way to Usernames + password + MFA which will give way to username + password + "passkey", which will give way to some other username + something else.  We are moving the target, but I'm not sure in what direction. And we are not really increasing trust.  All this assumes the implementation of the authentication is easy and not too intrusive to daily life.  In addition we are now becoming beholden to the benevolence of these mega corporations who will administrator the authorization services.  I'm not sure that is a trade I want to make.

So, what is my solution?

Do I have a solution?  I think so.  It's not really my solution.  And it's not really new.  I just think it's been overlooked because it was deemed "too hard".  Which at one time may have been true.  My solution would be to utilize user certificates. That's correct.  Just as site certificates are used to trust sites, user certificates will be used to trust users.  These can be generated by the site itself or created by the user when they sign up on the site.  There doesn't need to be a chain of trust (but there could be). For every site, when signing up, we would provide our personal certificate as part of the signup process.  This certificate could even contain email and other contact information, meaning we wouldn't need to fill in any of this information manually (though there may be privacy issues).  Using a certificate manager like we use a password manager we could even create a new certificate for every site.  The certificate would be stored in the sites user database and used to authenticate the user.  No cookies would need to be stored in the browser or at the very least, the valid time on the cookies could be turned way down. Another advantage of using user certificates is that most services today, SMTP, IMAP, HTTPD already have provisions for validating client certs.  They are just not configured to utilize use the user certificates most of the time.

This is not a new, novel or even my idea.  It is basically how SSH Keys are used. I'm just applying this to all web authentication.

Taking this a step further, a site could issue certificates to its users.  A certificate manager would definitely be required in this case (or the browser would need to manage the certificates).  Then the site could be certain that a user is known.

I see a few challenges.  Apps, particularly on phones, may need to be updated to allow for certificates to be used as part of the authentication.  Certificates and certificate stores have not been the easiest things to deal with.  This is where a certificate manager application would be needed.  The certificate manager will need to be easy for users to create, update and manage certificates for many different sites.

Conclusion

Did I miss anything or overlook some point or aspect that I should reconsider?  Let me know via email.