Domain Management and Security Authentication
Certificate Authorities have been a central part of maintaining DNS and the internet since their inception, and have played a significant role in keeping the internet secure. In short, Certificate Authorities (CA) are trusted anchors for the modern web that issue digital certificates on behalf of other entities on the internet. Digital certificates are verified credentials that come in the form of an online, digital identity. CA’s ensure that information is protected while encrypting the data that’s then sent between parties (a client and a host).
CA also issues SSL certificates, which bind the ownership of a website to a set of publicly verifiable cryptographic keys. However, with the growing threat of state-level attacks, this centralized repository of certificates could pose a counterparty risk for users in the future. Attacks are on the rise with over 267 million phishing URLs being sent in 2017. Moreover, Zscalar published a Cloud Security Report which reported blocking over 1.7 billion advanced threats hidden in SSL traffic in 2018 alone.
Now we’re 30 plus years into the web, and we are in need of a modern, robust solution, that would mitigate suck attacks while reducing the reliance of third-party intermediaries (CAs).
Handshake is the newest protocol aiming to offer a robust alternative DNS solution while solving some of the biggest hurdles we experience today. As a follow up to my article on Handshake, I will dive deeper into the functions of the internet protocol suite, and how the Certificate Authority work in tandem to make the modern web function.
How does SSL/DNS Function in the Network Stack?
Internet Protocol Suite
The internet that we use today is powered by the Internet Protocol Suite. The suite is a layered network stack that allows computers to send and receive data packets, globally. The HyperText Transfer Protocol (HTTP) is used with the Secure Socket Layer (SSL) protocol to allow a browser to make an encrypted connection to a host computer in order to receive data in return. SSL is a layer that works in tandem with HTTP and offers an encrypted connection that powers the browser.
In order for us to understand how HTTP & SSL actually work, I will give an example of how Alice is connecting to Bob’s website.
- Alice uses the browser and types in Bob.com as her URL
- Alice’s browser will then communicate with a DNS resolver to find the intended web server (Unencrypted)
- Once resolved, Bob’s server will send Alice’s computer a certificate and public key
- Alice’s computer will then verify the legitimacy of Bob.com’s certificate with the certificate authority they used
- Once verified, the parties will acknowledge the session and establishes an encrypted SSL/TLS connection
- Both Alice’s client (her computer) and Bob’s server can now send encrypted data to each other
The internet protocol stack is a suite for delivering data amongst peers, but heavily relies on your Certificate Authority or more importantly Public Key Infrastructure (PKI), to ensure your web browsing remains private and uncompromised.
What is Public Key Infrastructure
Trust is an important factor in making sure that exchanged data is both accurate and secure. PKI is a system that sets policies, structure, and procedures on how entities should trust and exchange messages, securely.
There are several intermediaries that help coordinate trust between two entities. Within the public internet, you are trusting the Root Certificate Authority to serve you accurate information. CA’s task is to manage digital certificates on behalf of other entities. Digital certificates are issued to prevent man in the middle (MITM) attacks that could circumvent trust and lead users to a malicious site. For example, IdenTrust is a Certificate Authority that manages certificates on behalf of other entities, such as Twitter.
So in this case, IdenTrust would issue a X.509 certificate to the user that is requesting access to Twitter. This digital certificate contains the verified public key, expiration date, digital signature, and other important items. Once the user receives the digital certificate, it verifies the identity and public key of that entity. Usually, a public key is generated through the RSA (Rivest-Shamir-Adleman) algorithm and or ECDSA (Elliptical Curve Digital Signature Algorithm). Both RSA and ECDSA are asymmetric encryption techniques meaning that the user can encrypt their messages to the host (Twitter in this case) using only the host’s public key and send the encrypted message on the public internet. Only the host can decrypt the message using the associated private key.
The Many Problems with The Certificate Authority
Now that we have an understanding of how PKI and CA work within the Internet Protocol Suite, let’s discuss some of the issues that can arise.
The Certificate Authority acts as a central validation organization, one that stores certificates and acts as an intermediary between two entities. Each CA has its own validation procedure to determine whether or not the domain is valid and secure. Further, there are three for-profit organizations that have roughly 90% of the global market share. And finally, there can be security vulnerabilities with the way certificates are being stored and issued. W3 Tech recently published a report below stating the global market share of dominant certificate authorities.
Clearly, there is room for some improvement here.
Domain validation is a process where potential entities such as Twitter could receive a digital certificate from a known CA. Trustworthy SSL certificates give users confidence against phishing, scams, and fraud. However, the process of receiving a digital certificate is modestly easy. Certificate Authorities will issue a domain validated digital certificate to anyone that is listed in the domain contact in the WHOIS record. That’s it.
All a user has to do is apply for a digital certificate and they will email the domain contact with the approved certificate. For additional security, an entity could sign up for an extended validation service which goes through an identity check amongst other things. But a typical user will not know the difference unless they see a green bar or click on the padlock within the upper left corner of the browser.
This is dangerous because a malicious user could purchase a similar domain name to Twitter such as Twiter.com and show that it’s certified through a CA.
The Domain Validation process, key storage, and CA subversions have opened up the door to many types of MITM such as MITB (Man in the Browser), HTTPS spoofing, ARP spoofing, and others. For example, Verisign a notable CA in the early 2000’s issued a digital certificate to a malicious user claiming to be Microsoft Corporation. They then spoofed users to think they were receiving relevant Windows updates but in reality, they were being compromised. In an incident on March of 2011, Comodo (CA) issued fraudulent certifications to malicious users for sites like Microsoft and Google. In this case, users were led to believe that they were logging onto Google but in reality, it was a malicious site. Comodo eventually caught the compromise and revoked access to the certificate.
Handshake’s Proposition
Currently, all of the Top-Level Domains (TLDs) are managed by 13 for-profit organizations globally. While Certificate Authorities are managed by thousands of organizations of which three manage 90% of the global market share. Both organizations that manage TLDs and Certificates are central points of failure. This will continue until trust could be shifted from central organizations to decentralized solutions. The internet protocol suite and the public key infrastructure heavily relies on the overall public infrastructure.
Why can’t we rely on the public for domain management and security authentication?
A shift that is currently taking underway is the shift of state-controlled money in the hands of the public. With the invention of Bitcoin, money as we know it is being shifted from countries to the people. This will empower citizens globally to hedge against there owns countries political risks, while maintaining the freedom to take action.
- Handshake offers the same value proposition but instead of money, it is the flow of information. As I have written in the past, Handshake is a decentralized protocol that manages Top-Level Domains at the root level. Since Handshake’s TLD’s are stored directly at the root level, you wouldn’t need CA’s to manage digital certificates or private keys.
How Would Handshake solve the Issues with Certificate Authority?
Today, Certificate Authorities manage digital records that contain public keys, signatures and other related information. So when you are trusting CAs you are trusting that the digital document that they have is secured and the identity is verified. The importance of the Handshake protocol is that the private keys are directly signed and controlled by the owner at all time. This means that when I purchase the domain, “TokenDaily.co”, Handshake would anchor the ownership of the domain onto the protocol and propagate this throughout the network of nodes. When a user resolves to a namespace it would directly point to a compact certificate and verify the validity of the request. This would be the canonical point of truth between private keys and the registered domain.
Summary
The Handshake Protocol is reducing the need for TLDs or CAs and will diminish our reliance on third-party providers. This shift will ultimately lead to a reduction in intermediaries and will bring fortified security to users. This would mean that information would flow freely while not having to worry about attackers spoofing your domain. Billions of attacks are taking place today, and anyone can be the victim of phishing URL scams or threats hidden in SSL. As we are relying more on trust, we must quickly find a solution to this problem.
With the invention of the Handshake Protocol, Handshake Alliance, Urkel, and Handshake Academy, we are starting to see a pivot from trusting people to trusted code — making the web that much more secure.
<a href="https://medium.com/media/c94ed893c892e52fecbeeeb6bd351253/href">https://medium.com/media/c94ed893c892e52fecbeeeb6bd351253/href</a>