And your VPN’s ISP too. If they’re receiving encrypted traffic and resending it decrypted on the same upstream ISP, traffic correlation is trivial.
Your ISP is a middle-man between you and where you’re connecting, so they can see all your traffic. Unavoidable really as they’re the ones that need to get your traffic back and forth.
which, sadly, is disabled by most servers…
Yes, and in some cases the IP address might be enough to identify which website you are visiting. However, if there are multiple websites served from the same IP address (e.g. a Cloudflare server) then it makes things more difficult.
(I don’t know how many websites there would typically be on a single IP.)
That’s true. I live in Canada and we can basically download with abandon.
But I’ve gotten got twice just downloading.
if you torrent - you typically both upload and download.
If those downloads were torrents, you were also uploading the entire time. With Usenet there’s no swarm to share the file with, just a direct download of binary posts that get assembled into a file for you.
You’re right, I confused my terms!
Yes, and in some cases the IP address might be enough to identify which website you are visiting.
When is the IP address not enough to identify which website a customer is visiting?
No, the session decryption keys are never passed in clear, the use of Diffie-helman key exchange (don’t ask me to explain it, the maths makes my brain hurt) that allows each side to infer the key used by the other in a secure manner without having to transmit the key in cleartext.
TLS is designed for use where you cannot trust the privacy of a communications channel.
No, the keys used for symetric cryptography (the actual traffic) are first exchanged using asymetric cryptography (the handshake). If you want to understand how this is done without exposing your private keys to your ISP, or any of the internet traffic routing middlemen, then this is a great video by computerphile explaining the process and the math behind key exchange handshakes.
Decryption keys are not transmitted in plain text, that would negate the entire purpose. I’m not a crypto expert by any means, but if you do some reading on asymmetric/public key cryptography you may get better answers. The private key of the server is never transmitted/shared, only the public key is transmitted. So anyone can receive the public key and encrypt data with it, but only the server with the private key can decrypt.
It’s also not just your ISP in the middle technically, it’s every ISP between you and the destination, and also every piece of networking equipment between the two. These days almost every enterprise-ish piece of network equipment has some form of packet capture utility, so the admin of any network you connect to (work, school, public wifi, etc.) could feasibly capture all your internet traffic. TLS still protects the contents of that data, though some info like the domain could be visible to an outsider by watching the public cert being exchanged. You’re also likely leaking all your DNS traffic unless you’re using an encrypted DNS method, since regular DNS is all plain text, so anyone in the middle would be able to see every DNS lookup. So its pretty easy to see where you’re going on the internet, but not necessarily what you’re actually doing.
When multiple websites are served from the same IP address (e.g. a Cloudflare server).
E.g. it is pretty common to use reverse proxys to provide multiple websites or services with different domains from the same IP.
Not disagreeing, but contextualizing a bit.
For TLS/SSL:
- The connection is initiated in the clear (because it has to be) , client requests secured connections and gives a list of cipher suites it supports.
- Connection negotiation involves the server responding which cipher suite presented that it will use for TLS, and then transfers it’s certificate (from a trusted CA) and the client checks the validity of the certificate, and if agreed, the client moves to generate…
- Session keys (not decryption keys, they sound the same, but session keys are invalidated ideally after the session terminates) that are either:
- random number generated using the server’s public key, which the server can decrypt using it’s private key, or
- DH Key Exchange (or ECDH) generated.
- Then data can be exchanged.
I didn’t go through the full video, but the math behind it is… staggeringly boring for most people (sorry, I can’t sugar coat it), but functionally, the use of ECDH for TLS 1.2+ creates perfect forward secrecy (meaning the session can’t be replayed and deciphered).
ALL THAT TO SAY: is that the handshake is done mostly in the clear, but once the Public Key and cipher suite selections are made, so long as the cipher suites the client uses aren’t all deprecated or weak, the rest of the transmissions can be encrypted properly.
One of the biggest and most important things to do when setting up your network (from the router perspective) is to use an encrypting DNS to reduce or prevent leakage. Your ISP will be involved up to that point, but once you hand-off to the encrypting DNS, you can set up TLS sessions a lot more securely because then, even the DNS calls to your VPN for handshaking are encrypted from your ISP.
did you read that?
it literally says that police didn’t go after users.
Keine Konsequenzen für die meisten Nutzer
there are a lot of reports of usenet-server owners and some about usenet-uploaders but not a single report that says that users are affected.
That article does not make the claim you are trying to prove. In fact it points out specifically that board users were not targetable and that the storage systems were destroyed to protect anominity
so, it didn’t happen in germany 10 years ago like you claimed?
your original claim is also bullshit. usenet servers and DDL servers definitely don’t log your ips, which is evident by the fact that you can use most accs from multiple IPs at the same time.
so basically everything you said is wrong and the link you claimed to be evidence disputes everything you said…