In part one, we have talked about Symmetric and Asymmetric Encryption. In part two, we have discussed hash functions and digital signatures. In part three, we will look at TLS, HTTPS and Certificate Authorities.
If you have read any previous text from the series, you can skip the next two introductory paragraphs and go to TLS section.
This series of texts aims to compose thoughts and deepen understanding of how people apply cryptography to cyber security. I am yet to find where the research will lead. That said, wondering through the technologies spawns those happy “now I get it” moments, with a sense of admiration for the developers of crypto systems.
Cryptographic algorithms can be mathematically intensive and mind taxing. Thus, I will attempt to skim the surface enough to know what, when, why, without going into details. This way will save time and enable enough fundamental understanding to pinpoint weaknesses during penetration tests and how to mitigate risks that arise.
SSL and its successor TLS prevent traffic eavesdropping and data alteration across a network. We commonly see TSL used with HTTPS and web browsing, but we use it with other protocols like FTP, VPN and others. To make a working security protocol, TLS is complex. It uses the symmetric and asymmetric algorithms, hashes, digital signatures and message authentication codes.
- Confidentiality because it encrypts the data. The connection is private because a symmetric algorithm, such as AES, is used to encrypt the data transmitted. The keys for this symmetric encryption are generated uniquely for each connection and based on a secret negotiated at the start of the session.
- Authentication, as the identity of the communicating parties can be authenticated using public key cryptography, certificates, and digital signatures. This is optional.
- Integrity, because each message transmitted includes a message integrity check, using a Message Authentication Code (MAC), to prevent undetected loss or alteration of the data during transmission.
To illustrate, we can view the characteristics of an encrypted connection by clicking on the padlock icon in a browser’s address bar. It can say:
Connection Encrypted TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128-bit keys, TLS 1.2. Which means this is an encrypted connection, protocol TLS 1.2, using Elliptical Curve with Diffie-Hellman using RSA. The symmetric key is AES 128-bit with GCM mode of operation. The connection uses SHA256 for data integrity checks.
Secure configuration of TLS involves many configurable parameters, and not all choices provide the security services of privacy, authentication, and integrity. TLS supports many methods for exchanging keys, encrypting data, authenticating, and message integrity.
At the time of writing, all SSL protocols are insecure and obsolete. TSL 1.0 and TLS 1.1 are insecure. TLS 1.2 and 1.3 are currently in use and secure.
TLS Handshake and connection
When we access a website with HTTPS, the client sends a message to a server with a request to secure the connection along with a list of cipher suites and the SSL/TLS versions it supports. In response, the server sends selected configuration from the client’s lists it wants to use. The client says it is prepared to use a selected key exchange algorithm and symmetric key, and the server compares those security parameters to its own until it finds a match. We call this stage “handshaking.”
A server authenticates the client by sending it a digital certificate, which we’ll be covering next, and if the client trusts the server, the process continues. The client verifies the server’s certificate, extracts the public key and uses the public key to encrypt a new shared secret key that it sends to the server. The server uses its private key to decrypt the shared secret key. Without the asymmetric connection, the client and the server could not share securely this secret key.
The server can require the client to send over a digital certificate too for mutual authentication, but because of overhead, we do not use by default the two-way authentication.
Once established, the session itself uses this single shared secret key to perform symmetric encryption of sent data, which makes a secure connection.
Let’s get back to establishing TSL connection with a server and exchanging keys. In order to agree keys with the server securely, we need to authenticate that the server is the real server we want to connect to exchange keys, because if a man sat in the middle, he could send a fake public key pretending to be the server.
To authenticate a server, we can use digital certificates with digital signatures. Digital certificates are digitally signed and contain information about the owner of a certificate. The public key and the digital signature, that proves the public key, are validated by an authorized Certificate Authority. A certificate authority is an administrative unit that is saying that the owner is who he claims to be, and that the public key on the specified certificate is genuine, and has not been altered.
CA signs a certificate, and their certificate is included too. This brings us to a chain of trust. Because the public key for certificate authority certificate must decrypt the signature on this first certificate, to get the SHA-256 hash, which must match the SHA-256 hash computed over the rest of the certificate, so that the client knows it is genuinely from that certificate authority.
The same process validates that the Certificate Authority certificate is valid, going back one up the chain of trust, which is the root certificate. How the client knows that this root certificate is valid and trust-worthy? This can happen because an operating system and browsers contain an entire list of root certificates issued by certificate authorities. So this is not that we trust them, but it’s the Microsoft, Apple or whomever has supplied those certificates trusts them.
HTTPS relies on certificates for authentication that a site is real and a public key belongs to that site. Absence of certificates will break security of HTTPS. Yet, it is possible to create a bogus certificate, make the system trust it, and a victim will now know that the data sent over HTTPS can be intercepted and read. The HTTPS protocol will be there, the padlock will appear as normal, and everything will look fine, but the issuer of a certificate can decrypt the traffic.
There are hundreds of certificate authorities trustable by Microsoft, Apple and others. Certificate authorities exist in about 50 countries. We have subsidiary certificate authorities like the US Department of Homeland Security. And our browsers would trust those certificates as a trusted CA would issue them. Therefore, the risk of exploiting this weakness and sniffing data is significant.
One way to mitigate the risk of trusting a bogus certificate is a technique called Certificate Pinning. Pinning is associating a host with their expected certificate. It is a way of accepting only one specific public key. For example, mobile banking apps use certificate pinning because the banking apps do not need to go to lots of other sites. An app allows only a specific set of public certificates, therefore if a man in the middle tries to change those certificates, it won’t work, because we pin the app to only a selected set of certificates or public keys. Pinning works for HTTPS, VPNs, TLS and other protocols we can use with certificates.
Rarely we type
https:// in the address bar. What happens is, we go to a HTTP address and then the server sends us 302 redirect to HTTPS version. Another way that we get to HTTPS websites is directly by clicking a link.
An attacker can exploit this mechanism and position himself as a proxy in the middle between the source and destination of traffic and change HTTPS connection to HTTP. The proxy sends back an HTTP version to the client, while talks in HTTPS to the original server, stripping the SSL. The server knows no difference; it thinks it is talking to the client, and what the client sees is virtually identical to the actual.
Another way of performing this attack is for the attacker to sit on a client local network, physically through the Ethernet cables or wirelessly through Wi-Fi. An attacker can trick victims’s machine into sending traffic through them, which is known as ARP poisoning (spoofing). The attacker sends out ARP packets, pretending to be the victim’s default gateway. It works because Ethernet has no authentication mechanism. Any machine can send out what’s known as ARP packet and claim that they are any other machine that is on the network, including the gateway or router, which means we end up sending traffic through a fake router, and then that router forwards on the traffic back and forth stripping out the SSL.
Exploiting TLS configuration
An attacker can try to exploit the configuration of TLS. He can make a client that during the handshake phase will negotiate a vulnerable connection using weak cypher-suite and TLS version, or no secure connection at all. The potential attack surface depends on the configuration of TSL on the server. Attacker can focus on any weak encryptions that we have discussed previously, like SHA1 algorithms, 3DES, algorithms with weak keys.
TLS provides privacy, integrity and optional authentication. TLS is a complex cryptosystem. The fundamental understanding comes down to knowing the handshake process, and, if we enable the optional authentication, the basics of digital certificates.
HTTPS security has become a standard on many websites, regardless of the data type being sent. Properly configured encryption in security can be very effective. We can find many attacks on SSL/TSL, such as BEAST, POODLE, Sweet32 and more. However, in most cases, adversaries will avoid attacking encryption directly, if any bypass is possible.
That is it.