This content originally appeared on DEV Community 👩💻👨💻 and was authored by jmau111⭐
Most security experts will recommend using HTTPS everywhere. It's undeniably a good advice you should apply.
However, it's often misleading for most users, including tech savvies.
What problem does HTTPS solve?
HTTPS implements TLS (Transport Layer Security) for the HTTP protocol. You send HTTP requests every day when you use your browser to interact with websites, and these interactions are called HTTP requests and responses.
The idea with TLS is to prevent the data from being sent in plain text (like in HTTP), allowing attackers to read it if they manage to intercept the requests. Such attacks are quite frequent and cybercriminals like to sniff their victim's traffic to collect confidential information.
TLS secures communications with cryptographic keys, so theoretically, even if someone manages to intercept the requests (e.g., Man-In-The-Middle attacks), the data will be impossible to exploit (random strings of characters).
TLS Handshakes in short
Behind the scene, a TLS handshake happens between the user's device and the server. Roughly speaking, it is how the client and the server agree to use specific session keys to communicate to through a secure channel.
These handshakes involve a series of messages and various steps we won't cover here, but let's just say there are ways to abuse the mechanism.
Researchers and cybercriminals have found various angles of attack to spoof identities and impersonate the TLS client. That's why TLS has evolved and the recent versions no longer support RSA and other ciphers that are vulnerable to attacks.
TLS certificates in short
Hosting services often provide SSL certificates for free (e.g., Let's encrypt) or for a specific fee.
The certificate holds the website's public key and other information to allow devices that want to establish a connection to verify the server's identity and the website's ownership, which aims to prevent fake copies.
Certificates are delivered by a certificate authority (CA) that is independent from hosting providers, but they usually handle the installation and activation for their customers. Once it's activated and the certificate is valid, you see a lock icon (usually in green), and the communications can be ciphered.
A website can also have a self-signed certificate that is not verified by any official authority (CA), but it will be likely flagged as "not secure" by the browser.
It does not mean self-signed certificates are always malicious, but public websites that aim to reach millions of users should be verified by a CA, at the very least.
Don't trust the padlock
The lock icon may give a false impression of security, as cybercriminals can obtain legitimate SSL certificates for typo-squatting domains too. Indeed, most phishing and scamming websites are HTTPS.
It's not complicated to register a domain name that is similar to a popular website and activate an SSL certificate to make it appear as legitimate. In 2017, Xudong Zeng even managed to spoof apple.com using Punycode (xn–pple-43d.com). Clients that do not display those special characters by default would not let users see the difference.
A "more sophisticated" scenario can consist of manually routing all the victim's traffic to an external server. The attackers can also create fake networks or routers. In other words, it's possible to act as a proxy under certain conditions without any knowledge from the victims who wouldn't change their behavior, as nothing would look wrong.
HTTPS traffic can be decrypted
An attacker who manages to sniff traffic can use open-source software such as Wireshark to analyze TLS packets. Of course, TLS is precisely meant for such case, but software that implement TLS (e.g., browsers) write keys and secrets to specific files on the system, allowing adversaries to decrypt intercepted packets if they can read the configuration files.
Each operating system has its own implementation, but when you own the victim's machine, it's not the hardest task to achieve, for example, using the SSLKEYLOGFILE.
Does HTTPS hide the URLs?
TCP connections and unencrypted DNS queries happen behind the scene when you go to a website, so HTTPS won't hide critical information such as the hostname. Theoretically, an adversary can't see the specific pages a targeted user is visiting, but if the website does not use HSTS (HTTP Strict Transport Security), a policy that forces the browser to use HTTPS connections only, many MITM attacks can succeed.
Motivated adversaries can also run more in-depth analysis and deduce some paths with the length of some HTTP responses or through specific HTTP headers (e.g. referer). It's especially true with websites that have mixed contents and serve some resources such as JavaScript or CSS over HTTP. Indeed, modern browsers would raise an alert but the victim can ignore it.
Why would anyone ignore security warning?
Dunno, maybe there's an iPhone 14 to win or any other rewards that would explain such crazy behavior.
Data is not encrypted everywhere
The purpose of HTTPS is to secure the transit but data can be intercepted in various places, for example, on web servers or databases. The data will become static eventually, so HTTPS does not make it "unhackable."
Wrap up
HTTPS is necessary but not sufficient. You should harden your browser's configuration or move to a more secure alternative that does not allow non-HTTPS traffic.
Likewise, if the website does not have a strict policy, don't even go there.
The "s" in "HTTPS" does mean "secure" but it's misleading, as even phishing websites can have it.
This content originally appeared on DEV Community 👩💻👨💻 and was authored by jmau111⭐
jmau111⭐ | Sciencx (2022-09-18T00:38:58+00:00) Debunking myths about HTTPS. Retrieved from https://www.scien.cx/2022/09/18/debunking-myths-about-https/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.