Fingerprints

The internet is built upon the transfer of information and is now used constantly in communication. The transfer of data on the internet uses HyperText Transfer Protocol (HTTP), which transmits information between the clients and servers. The information in HTTP is stored in plain text, so anyone who intercepts can read the message and the user input. This unsecured transfer can be disastrous as hackers can easily steal private information and passwords. Therefore, a more secure version of HyperText Transfer Protocol Secure (HTTPS) was created to solve the two problems of privacy and security by using a key to encrypt the plain text content into something undecipherable without the same key. This key is exchanged during the first interaction between the client and server, called the Transport Layer Security (TLS) handshake, previously the Secure Sockets Layer (SSL). The TLS handshake is an exchange of vital data between the web server and the client that ensures the remote server's identity.

The first step of the handshake is the versions, cipher, and algorithms to be used in the future. Once this is agreed upon, the server must prove that this server is authentic by sending a Digital Certificate. The body of the certificate includes various data, including serial numbers, valid dates, versions, algorithms, ciphers, the subject, and the issuer of the certificate, which is the Certification Authority that authorizes them. The server also sends its public key to prepare for data decryption. All of this is signed by the aforementioned Certification Authority with a Digital Signature to prove the certification is authentic (Gibson).

To decrypt information, a key must be used. However, sending the key in a symmetrical system where only one key is used is dangerous if it is sent in plain text. An asymmetrical design is used with a private and public key to solve this. The public key can only decrypt data encrypted from its corresponding private key and vice versa. However, outsiders cannot decipher the private from the public key, so it is safe to give the public key as long as the private key is kept secure. The client receives the certificate with the public key, and once it verifies the certificate to be genuine, it generates a symmetric key pair to be used in further messages. The user’s key is encrypted with the server’s public key and sent to the server, meaning that only the server can decrypt and read the user’s key. Upon completion of the handshake, both the server and client have a symmetrical key that either can use to decrypt and encrypt data ("What happens in a TLS", 2022).

Before the client sends their key, however, they need to trust that the certificate isn’t fake. The client relies upon Certificate Authorities, trusted third-party sources who sign with their Digital Signature, to confirm that the web server and public key are authentic ("What is a Certificate Authority", 2021). To create the Digital Signature in this context, the Digital Certificate is first hashed - meaning irreversibly, cryptographically transforming the data into a fixed-length value. Hashing is usually done with a highly secure hash such as Secure Hash Algorithm 256-bit (SHA-256). A hash generally needs to change dramatically with minor updates and be relatively unique to be secure. The value is then encrypted with the Certificate Authority’s private key, completing the Digital Signature. The signature is then sent along with the Digital Certificate to the client. On the client side, the Digital Certificate they received is hashed following the earlier agreed upon hash during the first part of the handshake, then compared with the Digital Signature decrypted with the Certification Authority’s public key stored on the client’s computer. If the signatures match, then the client is sure that the certificate was issued by the actual Certificate Authority and not altered, as the public key can only decrypt its corresponding private key, which they should hold ("Digital Signature vs. Digital Certificate", 2021).

As more websites begin using HTTPS instead of unencrypted HTTP, organizations find it harder to see the user's data to either use, store, or check that they comply with their policy. To counteract this, these organizations use a man in the middle attack to read your information even if the website uses a secure HTTPS connection. A man in the middle attack is a general term for someone who positions themselves in the middle of a conversation to siphon information away while still giving information to the other side, so nothing seems wrong. The attack presents a risk to the client as they would not assume that their organization is spying on them as the interaction still seems normal. On the internet, the attack can be achieved through an HTTPS Proxy Appliance, which in this context refers to a fake server set up between the actual server and the client. When clients ask for a website, the organization’s network can redirect them to their HTTPS Proxy Appliance. For the client to trust the proxy, however, a general TLS handshake still has to occur. However, this time, the proxy sends a fake Digital Certificate with a fake Certificate Authority authorizing said certificate. Usually, the client’s computer would not trust the fake Certificate Authority as it does not recognize it. However, if the organization also controls the computer, it can add the phony authority to the list of trusted authorities and their corresponding public key. If they do this, the client’s computer cannot recognize the illegitimacy of the Certificate Authority, and therefore, the handshake continues with the proxy. The client sends their key as usual, and now the proxy can decrypt all information sent by the client to store or interpret. To create an aura of normalcy, the proxy establishes another connection with the actual server, completes a different TLS handshake, and sends the user data encrypted with the proxy/server key to the server. When the server responds with new information, the proxy decrypts the data, reads it, then encrypts it again with the proxy/client key and sends it to the client. If done correctly, the client would not suspect anything (Gibson).

I believe that although compliance with the policy is essential, the fundamental right of privacy should still hold, and schools, governments, or Internet Service Providers should not have a right to have unrestricted access to all information sent by you without evidence of illegal acts. Although this behavior usually cannot be prevented as the organization can force this exchange, detection is possible. This is because the certificate exchanged with the proxy would not match the actual certificate exchanged with the server. A simple way of comparing certificates is with a “fingerprint”, also called a “thumbprint,” which is a hash of a certificate and, therefore, should be unique for each certificate. The fingerprint is similar to the Digital Signature but is usually not used in the computer’s verification process. The fingerprint is often generated afterward and is often for the user. The fingerprint can still be in SHA-1 instead of SHA-256, as the security aspect is not as vitally important, and SHA-1 is good enough for the client to use (Lynch). The user can compare this fingerprint to a list of verified authentic fingerprints. If the fingerprints don’t match, it indicates that the certificates are different and that you might be connecting to a proxy server that is spying on you. A false positive is when the fingerprint is different, but the reality is that it is still safe. Massive companies, such as Amazon or Google, use multiple authenticators and various certificates. Malware applications can also purposefully intercept information to scan for viruses, such as BitDefender and Kaspersky A/V. Strange web configurations creating multiple certificates for almost identical addresses or proxy servers that do not steal information can also be considered a false positive (Gibson).

On the other hand, false negatives are when a fingerprint is the same, and the client marks it as negative for any interception, but in reality, it is not. After ruling out human error, this is almost impossible unless the proxy has somehow obtained the Certificate Authority’s private key. There is a hypothetical chance that if you use SHA-1 to compare fingerprints, such as the list of authentic fingerprints in grc.com, there can be a duplicate fingerprint with different certificates. Despite being nearly impossible, security experts still transitioned the critical hashes, such as the Digital Signature, to SHA-256. This is to maintain security and privacy on the internet, attempting to make a secure connection actually secure (Gibson).

References

Digital Signature vs. Digital Certificate - the difference explained. Savvy Security. (2021, January 26). Retrieved August 25, 2022, from https://cheapsslsecurity.com/blog/digital-signature-vs-digital-certificate-the-difference-explained/

Gibson, S. (n.d.). GRC : SSL TLS HTTPS web server certificate fingerprints . GRC | SSL TLS HTTPS Web Server Certificate Fingerprints . Retrieved August 25, 2022, from https://www.grc.com/fingerprints.htm

Lynch, V. (2020, November 11). Why your SSL certificate still has a SHA-1 thumbprint. Hashed Out by The SSL Store™. Retrieved August 25, 2022, from https://www.thesslstore.com/blog/ssl-certificate-still-sha-1-thumbprint/

What happens in a TLS handshake? | SSL handshake. (n.d.). Retrieved August 25, 2022, from https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/

What is a Certificate Authority (CA)? SSL.com. (2021, December 9). Retrieved August 25, 2022, from https://www.ssl.com/faqs/what-is-a-certificate-authority/