0

In theory, visiting a website with HTTPS and seeing the neat, little lock icon next to the address (e.g.: enter image description here) should give us a warm, cozy feeling of safety. However, how safe is it really?

As it stands, HTTPS (if implemented correctly), can prevent man-in-the-middle attacks, so that no one knows what is exchanged between my client and the server. But that is not a given.

Q1: Are there tools to verify whether or not the servers are set up correctly? In 2021, is (for example) Chrome Dev Tools Security tab sufficiently reliable to determine the security of the contents transferred between my client and the server? Are there scenarios, where that Security tab is all green, but (given I do not use a VPN, and my computer and (if applies) proxies are not compromised), a third party can still see my traffic?

Aside from web content, another important piece of data to protect is the domains that I visit. In theory, a third party can easily know the IP address of the server, but can they know the domain name? E.g. TLS's plaintext SNI field can be used to find out the domains that certain clients visit. TLS 1.3 has introduced Encrypted SNI (ESNI) to circumvent censorship and tracking. Because of that, China, for example, has started banning TLS 1.3+. Cloudflare made a big point about upgrading to ESNI right away, and Firefox apparently was the first to support ESNI in 2018. Thus the question:

Q2: How can I verify whether someone can sniff the domains of my visited servers? Are there good tools for that?

A first answer to this question is: Cloudflare Browser Security Check. But it is not enough, since I want to check individual connections, not just my browser.

schroeder
  • 125,553
  • 55
  • 289
  • 326
Domi
  • 101
  • 4
  • What kind of "someone" are you talking about? A random kid in CoD saying he'll hack you? A criminal organization? Your own government targeting *you* specifically? –  Apr 21 '21 at 14:51
  • [SSL labs has a neat test site.](https://www.ssllabs.com/ssltest/) Not sure what it does exactly, but it might be what you are looking for. – Anders Apr 21 '21 at 15:52
  • The weak link in HTTPS is PKI, where we place all of our trust in CA's to issue certificates rightly. If a CA acts improperly, or a CA is breached or coerced, things can go very wrong. See https://security.stackexchange.com/questions/230689/if-an-adversary-took-over-a-major-certificate-authority-what-bad-things-could-t for more info. – mti2935 Apr 21 '21 at 20:54

2 Answers2

1

TLS secured web connections are the basis of the web. Within ordinary usage, this is as good as it gets.

True, the system is not perfect and any organization capable of obtaining an appropriate cert can perform a MiTM, but this is a pretty high bar. In some ways it's like asking about counterfeiting cash, good counterfeits are difficult but not entirely impossible.

As far as what you can personally do:

  • Check the TLS Certificate and CA
  • Encrypted SNI is still not common, although I believe Cloudflare supports it.

If you feel you need something more:

  • Escalate to using a VPN.
  • The last practical step is to use Tor, specifically the TBB Browser.
schroeder
  • 125,553
  • 55
  • 289
  • 326
user10216038
  • 7,933
  • 2
  • 16
  • 20
  • While this addresses the general spirit of my post, it does not directly answer any of my questions. The ESNI comment is a weaker version of what I already pointed out and even provided references for, which tells me that you did not really read my post. – Domi Apr 21 '21 at 18:46
  • Referring specifically to MITM attacks, I wouldn't be relying on tor in any sense to protect against that. Someone running a tor node is in a great position to do SSL decryption... – D0gfather Apr 21 '21 at 21:33
  • @D0gfather The point is that it would be harder to target your stream for a MITM if you're using Tor. A Tor node operator would have to have some external information or there be some unknown attack on Tor allowing deanonymization for them to do anything than a generalized disruption of TLS. They won't be able to magically decrypt TLS traffic unless they have compromised the keys to a server or a user bypasses a cert warning. – john doe Apr 22 '21 at 03:29
0

A third party can still see the size of the encrypted requests, so if they know you visited an 8.2 MB web page over HTTPS, and there is few or only one web page that is of a size 8.2 MB on that particular server, then an attacker can surmise which page was visited.

The padlock could be green and the contents still monitored if a malicious root certificate authority is installed and trusted by your system and/or browser. Firefox displays "Connection verified by a certificate issuer not recognized by Mozilla" when you click on the padlock if this is the case. Note that if an attacker can install a malicious root CA on your computer, you may have bigger issues to worry about.

If certificate pinning is not enabled for the website (Most major websites have this enabled in the major browsers), then an attacker could hack into a CA, and sign their own certificate for that website and simply present you with the certificate that they signed maliciously. This issue only affects smaller websites and/or obscure/outdated browsers. You could ensure that the certificate used is signed by the correct CA, by doing some google searching regarding that specific websites certificate. There is also something known as "Certificate Transparency Logs", which are open source repositories which track which certificates have been signed for which domains. You can look up a domain's certificate transparency logs from many sites, one good one is Google's, which can be found at https://transparencyreport.google.com/https/certificates. If the certificate your browser displays has a different CA than the CA that the target website typically uses (most companies stay with 1 primary CA as far as I know), that could be an indicator.

Someone could monitor which domain's you're visiting by simply monitoring DNS traffic, unless you use DNS over HTTPs or DNS over TLS, then DNS queries are plaintext and easily monitored.

The server name indication (SNI) is also a possible method you mentioned. If you wanted to see if a particular site is vulnerable to this, you can open up wireshark and attempt to find the SNI during the TLS handshake.

Many IPs can be resolved into the domain name via a reverse lookup, so an attacker could simply look at the IP addresses and reverse them. Many cloud providers make it hard to reverse and find the original domain, but an attacker could look at the TLS certificate presented by an IP address, and find out that it is only valid for "*.malware.com", which means that the site is related to "malware.com".

john doe
  • 668
  • 4
  • 15
  • Would you mind answering the questions I asked (`Q1` and/or `Q2`)? Also, about your point about "installing a malicious root CA": I already pointed out that I assume that my own computer is not comprimised. – Domi Apr 21 '21 at 18:51
  • I answered Q1 and Q2, with the unknown root certificate and the wireshark to check if SNI is being exposed on the sites you visit. an addon to Q1, if you're using a modern browser, then you're not going to see a solid green padlock unless its a secure cipher suite, so unless there is a malicious root CA, then the security is TLS 1.2 and above... This is why I mentioned the malicious CA. Unless images or scripts are being served over HTTP, which if the padlock is solid (firefox) they arent, then TLS encryption is assured – john doe Apr 22 '21 at 03:16
  • If you're worried about plaintext leaking out then force HTTPS only mode in firefox in the settings, im sure Chromium (and googles spyware'd version) has a similar functionality, or you can try to find an extension to perform a similar task – john doe Apr 22 '21 at 03:23