1

I'm trying to figure out if it's possible while listening to the network to read URLs from the traffic.

Since privatebin uses the encryption key in the URL, what process could be in use to prevent spies to see the full URL?

I opened wireshark and checked what happens when I open an encrypted paste: I was surprised I couldn't see any full URL (only domains).

So it's a bit comforting, but I want to be sure I understand how I'm protected. Can you please confirm my understanding is good?

I launch my request to access the paste with the full URL containing the key.

  1. a DNS request is launched to find the IP of the domain, if I have DoH I only see TLS traffic and not even the domain name is leaked to MITM eyes.
  2. when my computer has the IP of the domain, a TLS tunnel is mounted.
  3. inside the TLS tunnel http requests are being sent and received, the ones with full URLs (and therefore paste keys).

Am I right? Also if the privatebin wbesite was not using HTTPS (only HTTP) I guess I would be able to see encryption keys right?

Thanks

Ozwel
  • 161
  • 7

1 Answers1

2
  1. a DNS request is launched to find the IP of the domain, if I have DoH I only see TLS traffic and not even the domain name is leaked to MITM eyes.

No, the domain can usually still be visible. The domain name of the website is present in cleartext, even if HTTPS is used, in the Server Name Indication (SNI). ESNI (Encrypted SNI) is being developed, but it is still a draft. Even if ESNI is used, the IP address of the server you are connecting to will be visible in the IP header of the packets you send it, so the domain name can be determined or shortlisted using a Reverse IP Lookup.

When my computer has the IP of the domain, a TLS tunnel is mounted. Inside the TLS tunnel http requests are being sent and received, the ones with full URLs (and therefore paste keys).

The paste keys are usually located in the part of the URL the follows after the # symbol. This part of the URL is not transmitted to the server and is only visible client-side. This means that even if HTTPS is not used, the encryption keys will not be visible with just a passive MitM. Of course, if TLS is not used and the attacker actively MitMs the connection (i.e. intercepts and then alters the data being exchanged), they can easily modify the webpage served to send the key from the victim's browser to them.

nobody
  • 11,251
  • 1
  • 41
  • 60
  • Thanks. Interesting to see not the whole URL is sent to the server. Actually, I know that every / is needed for the server to know the right folder, I know that ? is also needed to request the right information too (less sure about this one though), but is there a rule stating / must be sent, ? must be sent, but # must not? – Ozwel Feb 09 '21 at 12:34
  • 1
    @Ozwel The part before the `#` is sent to the server, the part after it is not. Its as simple as that. – nobody Feb 09 '21 at 12:37
  • Right, just noticed (had forgotten) it is used for anchors! So yes the browser can read it to go directly to the right place in a long page. No need for the server to know about this :) – Ozwel Feb 09 '21 at 13:06
  • +1, excellent answer by @nobody as usual. This service works essentially the same way that Firefox Send worked, before it was (sadly) shut down by Firefox a few months ago. See https://www.wired.com/story/firefox-send-encrypted-large-files/. – mti2935 Feb 09 '21 at 22:13