A good friend of mine called me with this question:
You work in computer security, right?
I want to login to this website called xyz.com.
Can anyone intercept my communications?
I ask: 1) Are you using https://xyz.com, and not http?
He replies: Yes
I ask: 2) Are you logging in from a browsing center using their desktop? If so, they may have installed a key logger which logs your every keystroke.
He replies: No, I am using my laptop.
I immediately thought of Superfish, where Lenovo shipped laptops with root CA certificates so that they can intercept the connection even if https is used. But I saw that he was using a Dell laptop. Note: Lenovo has since stopped snooping, so it is OK to use a Lenovo laptop.
Next I become a TSA agent and ask 3) Has the laptop always been in your possession? Otherwise someone (spouse, girlfriend, foreign country) could have installed a keylogger.
He replies: Yes, it has always been in my possession, and nobody other than me has used it.
Good. Next I ask 4) Did you visit the site by clicking on a link in an email? If so, you may be phished — the link may take you to another site xyzz.com (see the spelling) which looks just like the site you want to visit.
He replies: No, I typed in the url.
Next I ask 5) Are you using a free wifi connection at Starbucks or in a hotel lobby?
The answer is No.
Next I ask 6) If your browser shows a warning dialog that says "The certificate is not valid. Do you want to proceed", what do you do?
He is smart and so he says, "I click No and close the browser tab"
Good. I look at his browser window, see the url and say "the lock icon indicates that the connection to the site is encrypted, which is good, unless …"
Unless what, he says
Unless, the connection is securely encrypted to the bad guy who can decrypt it.
I ask 7) Did you install any software from unknown sources? You may have inadvertently installed some software that added some root certificates as trusted. This will allow third parties to impersonate xyz.com and many other sites.
Seeing his blank look, I check his laptop for suspicious looking CA certs in the root CA stores — this is not a foolproof process and I don’t know if I got them all. For his usecase, living in the US, does he need a root CA cert from Bulgaria or Ethiopia in his Firefox browser keystore? I also check to see that a proxy was not enabled.
He says: I am good, right?. Even if someone can see or capture my encrypted communications to xyz.com, they cannot decrypt them, correct?
I was about to say "If the bad guy has captured your encrypted communications, and at a later date, he is able to get the private key of xyz.com, he may be able to decrypt the messages, unless a PFS cipher was negotiated". But, this is too much. Hopefully, most servers support TLS 1.3 and that ciphers that use RSA key transport have been removed from the TLS 1.2 configuration.
Instead, I say Yes, you are good.
My friend was not done.
How about privacy? Can anyone tell that I have visited xyz.com?
I tell him that the browser needs the numeric address of xyz.com and so it will use a service called DNS to get it. My friend doesn’t wait for me to finish and says
Let me, guess, anyone can see your request to the DNS service and know that you plan to visit xyz.com, right?
Yes, I say admiringly.
Now, he says, I know you are going to tell me that the security wizards have figured a solution for this, right?
Yes. Not one but two, I reply. Just like we use https to encrypt traffic to servers, we can also use it to make a request to the DNS server. One is called DNS-over-https (DOH) and the other is called DNS-over-TLS (DOT).
He replies: So, with DNS lookup over an encrypted connection, no one will know that I am going to visit xyz.com?
Not quite, I say. Typically your ISP (Internet Service Provider) will be configured as the default DNS resolver.You can change it to a more secure DNS resolver. The browser will ask for xyz.com’s numeric address via an encrypted connection to the DNS resolver, which will talk to an authoritative DNS server and provide it. But the communications between the resolver and authoritative DNS server can be intercepted by an attacker who can poison the cache stored in the former. This means that you cannot be sure that the numeric address (the browser received over an encrypted connection) really belongs to xyz.com
My friend looks exasperated. Now what? What is the point of using an encrypted connection if the data received cannot be trusted, he asks?
I tell him that encryption gives you confidentiality, but not integrity.
Both the authoritative server and the resolver must support a spec called DNSSEC. The authoritative server will sign the responses and the resolver will verify the signatures.
Recently, a state actor was able to modify DNS records of dozens of domains belonging to government and private companies in the Middle East. Cisco’s Talos research division published an in-depth article on this DNS hijacking, which they have named DNSpionage. Traffic was redirected to an internet address controlled by the attackers. DNSsec would have foiled this attack as the signature verification of the DNS response would have failed.
My friend, who is getting smarter by the minute, replies: even with DOH and DNSsec, the resolver will know that I want to connect to xyz.com, correct?
I reply: Yes, and that is why, instead of using your ISP’s resolver, it is a good idea to use a widely trusted DNS resolver like 1.1.1.1 (from Cloudflare), 8.8.8.8 (from Google) or 9.9.9.9 (IBM et al) with good privacy guarantees.
Note that even if you use a VPN, the VPN server will know that you want to connect to xyz.com. There are several vendors selling VPN software, and they are frequent targets of attackers. One has to carefully check their privacy policy. Shady VPN vendors can log and sell details of your browsing activity.
My friend replies: I understand that the resolver needs to know that I want to connect to xyz.com — other than that, do I finally get confidentiality and integrity?
I say, "Sorry to disappoint you, my friend. The browser connects to the xyz.com using the numeric address and the first message it sends has the string "xyz.com" in plain text! Anyone monitoring the connection can see that you want to connect to xyz.com.
My friend is confused.
Wait, I don’t understand. The browser gets the numeric address of xyz.com and uses that to connect to xyz.com — why does it need to tell xyz.com that it wants to talk to xyz.com?
I understand your confusion, my friend.
An approximate analogy may help: John Smith and 2 of his friends share a landline. For those of you who don’t know what a landline is, you can skip this paragraph with no ill effect. You call 411 and get the telephone number of your friend John Smith. When you call, you have to ask for John Smith.
Similarly, even though the browser got the numeric address of xyz.com, there may be other servers like abc.com that share the same numeric address. So, that is why the browser has to mention "xyz.com" in its first request to the numeric address of the server.
My friend asks: "Ok, Why cannot the first request from the browser be encrypted?"
I reply, "Before 2 parties can have an encrypted session, they have to agree, in clear text communications, parameters such as protocols and ciphers. Also, the browser has to authenticate the server so that it knows that it is talking to the real xyz.com and not an impostor. So, the first request from the browser cannot be encrypted.
By the way, not only the first request from the browser has string "xyz.com", the response from the server will (typically) have the certificate for xyz.com in the clear.
My friend is getting irritated and asks "What is the point of using DNS over https with the idea that no one should know that I want to connect to xyz.com only to send the string "xyz.com" in clear text to the server?"
I say, "That is a very good question. As you may now come to expect from our conversation, there is a solution for this where the string "xyz.com" can be encrypted in the first request to the server.
But a prerequisite (necessary but not sufficient) is that both the browser and server (xyz.com) support the latest version of the TLS protocol namely TLS 1.3 — good news is that all major browsers and many websites support it."
My friend says, "You are confusing me again. You just said that the first request from the browser cannot be encrypted because the browser and server have not agreed on the ciphers. Now you are saying that this is not the case with TLS 1.3?"
I understand your confusion. Remember that I told you that the browser will use DNS-over-https to get the numeric address of xyz.com? In addition to the numeric address, the browser will also receive the X509 certificate of xyz.com. The browser will use the public key from this certificate to encrypt the string "xyz.com". So, while the rest of the initial request from the browser to the server is in the clear, "xyz.com" is encrypted.
My smart friend quickly interjects:
Why does this require TLS 1.3? Can’t TLS 1.2 use the public key from the certificate and encrypt the string "xyz.com"?
It can but it doesn’t solve the problem. With TLS 1.2, the response from xyz.com will have the certificate for xyz.com in the clear and an observer can see that. TLS 1.3 servers (unlike TLS 1.2) will encrypt the server certificate so that any observers in the path will not be able to see the server name xyz.com in the certificate.
Phew. My friend must be thinking "Why did I open this can of worms?"
He asks: "How do I know if I am getting this confidentiality and integrity when I connect to xyz.com from my browser?"
I say, you can test your browser by visiting Browsing Experience Security Check and clicking on "Check My Browser"
You can check the server by visiting SSL Server Test and entering xyz.com in the Hostname text field.
My friend says:
Thanks, I will do that. I am afraid to ask but I will: So, finally can we say that the problem has been solved?
I start to say "DNSSEC that authenticates the DNS responses could be disabled by BGP route hijacking …" when I hear a click — my friend has disconnected the call, before I could say "we have a solution for that too, namely Resource Public Key Infrastructure (RPKI)"
I perfectly understand why my friend disconnected the call. I would have done so much earlier.
This is too complicated to get it right for a technology that is essential for most people in their daily lives.
How can we simplify this mess?