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 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 these services 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.
Top comments (10)
Great Article :) Thanks!
Nice blog 🚀. While I agree to most of the points. I don't think the points mentioned in section
Data is not encrypted everywhere,HTTPS traffic can be decryptedare shortcomings of HTTPS.HTTPS traffic can be decryptedis possible only if:In all other cases, I think it's practically* infeasible to decrypt it.
The "S" stands for "secure" (in transit). So it's not misleading (at least for me). To check for previous phishing attacks I usually got to
virustotal, or similar webpages. TLS certs were never designed to solve this thing.I short, HTTPS is meant to protect the data in transit. And it does its job flawlessly. So I don't specifically think the pointers in blog as shortcomings. Feel free to correct me. 🙂
The post mentions all the points you raise and doesn't say HTTPS/TLS is meant to fight against phishing websites.
It's just that cybercriminals can have HTTPS too, so the lock icon is not a proof of security. The website can be flawed at multiple levels.
For phishing you can use phishtank
https today is absolutely necessary for webs. Website without will get warnings, will be decreased in search etc. Meanwhile it is not the protection against sensitive data it is just the privacy for your browser use. Nobody can prevent that phishing website will buy certificate as well, what is the problem?
HTTPS is absolutely necessary but not sufficient, and users should not trust the padlock blindly. You can harden your configuration to display "malicious" ASCII chars and force HTTPS everywhere.
The website can have HTTPS and be legitimate but still vulnerable to other attacks such as injections, and HTTPS won't be enough to protect sensitive data. Many users believe that unfortunately.
Let me say in 2 words. https is when you will go to pornhub your ISP will not log exactly what video you are looking it and what is the actual link. It is not for exchange of sensitive data or info which is big valuable and makes big and serious interest to be stolen. Meanwhile it is ok for credit card info, it is enough. Nothing to be trusted 100%. It's life.
This attack allows intercepting cleartext communication. However, simply proxying traffic does not allow decryption.
Decryption as you describe requires compromising the host OS, which would allow an attacker to do anything a user can. A compromised OS has no expectation of security, regardless of which measures you put in place.
A better attack would be to add an additional CA to the OS and browser CA bundles. This would let an attacker add their own TLS certificates to sites without getting rejected by the browser. However, once again, this requires an attacker to compromise the host OS.
The only convincing HTTPS-compromise mentioned is interception of an unencrypted initial connection before it’s upgraded to HTTPS; this is a valid concern for sites not on the HSTS-Preload lists or lacking HTTPS service-binding DNS records.
A better argument would be that TLS doesn’t normally encrypt Server Name Indication (SNI) or obfuscate record sizes; SNI-sniffing or traffic analysis could reveal domain names or pages, respectively.
I’d say that HTTPS combined with random record padding and Encrypted Client Hello (TLS 1.3 extensions) and a form of encrypted DNS (DoT, DoH, DoQ) can offer pretty good privacy protections against a MITM: the only reliable information leakage with these measures in place is at the IP layer. IP addresses are less specific than hostnames, since one IP can correspond to multiple hostnames.
POSSE note from seirdy.one/notes/2022/09/19/re-deb...
In terms of security in SSL certificates. Does EV certificates provide more security than free one like Letsencrypt?
No. In technical terms, an EV certificate contains a small bit of data that says "Hi, I'm an EV certificate!". From a cryptographic perspective they are no different than non-EV certs, it's only up to browsers to decide if they want to treat them differently, which the used to.
Browsers have been gradually phasing out special treatment of EV certificates because they don't provide any meaningful benefit to the end user, and can be abused: bleepingcomputer.com/news/security...
LetsEncrypt is 100% sufficient for production workloads when configured correctly (I.E. with CertBot)
unfortunately, security is always inconvenient and brings no visible benefit to many.