2

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

Improve this question

1 Answer 1

Reset to default
3
  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.

Improve this answer
4
  • 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?
    – Ozwaldo
    Commented Feb 9, 2021 at 12:34
  • 2
    @Ozwel The part before the # is sent to the server, the part after it is not. Its as simple as that.
    – nobody
    Commented Feb 9, 2021 at 12:37
  • 1
    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 :)
    – Ozwaldo
    Commented Feb 9, 2021 at 13:06
  • 1
    +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 wired.com/story/firefox-send-encrypted-large-files.
    – mti2935
    Commented Feb 9, 2021 at 22:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .