[LINK] Brandis rushes to release telco metadata for civil proceedings

[David Lochrin]

On Friday 23 December 2016 10:49:34 Frank O'Connor wrote:

> The server at the other end takes over the TCP/IP application requests or data receipt (and remember TCP/IP is a stateless protocol … simply opening and closing connections to pass data) and repackages the results of same for transmission back to the user
> 
> And if you factor in ’double hop’ or even ‘triple hop’ VPN services …. where the connection is handled by two or three remote servers sequentially … and I can point you at any number of VPN services and servers that offer this extra level of security/tunnelling/concealment … you can factor in even grater levels of privacy.
> 
> The point is that the VPN server removes the initial IP address and origin identifying information as it reconstructs the packets so that it is effectively the client for the transaction, and then passes the network results back to the user at the other end of the data socket. And if that’s not concealing identity … then what is?

It's a while since I've been involved in network security, but this is my understanding.

First a nitpick... UDP is a stateless protocol but not TCP, however it's true TCP doesn't maintain any higher-level (application) state information.

The IPsec VPN protocol provides authentication and/or encryption.  A single-hop VPN packet carries the original source & destination IP addresses and also relies on public-private key pairs, so the local end could be raided to recover its private key and a recorded session then decrypted after the event.  (Presumably the other end's public key is generally available.)  I can't see how multiple hops would improve security because the last hop is surely the only one which needs to be cracked?

Alternatively, IPsec allows both ends to use a prearranged key, or keys might be created and destroyed on a per-session basis.  But that introduces the old recursive problem of securing key distribution!

SSH & SSL keys are created per-session and volatile, so the original user-data is difficult to recover by simply monitoring a session.  However these protocols still require one end to use a public-private key pair (?).

I think those considerations would apply to any VPN-type scheme, so it's really a question of how much money & time whatever authority is prepared to spend on recovering data.  Having the other end of the (first) VPN connection outside the jurisdiction would help.  But in the end, the target information still exists on some hard drive.

David L.