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

Frank O'Connor francisoconnor3 at bigpond.com
Fri Dec 23 14:31:32 AEDT 2016


> On 23 Dec 2016, at 12:14 pm, David Lochrin <dlochrin at key.net.au> wrote:
> 
> 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?

You’re confusing ‘hops’ with traditional IP hops … the point at which the transaction/data passes through a route ron its way to the ultimate network destination

Situation with a 'three hop’ VPN …  For Hop 1 a tunnelled socket established with client, encrypted and transmitted to Server 1. Once there it is decrypted and another tunnelled socket established with Server 2 (in another jurisdiction) for Hop 2, there it is  encrypted and transmitted to Server 3 (in yet another jurisdiction) for Hop 3 … which then on-sends the data/data request.

In other words … you’re messing with three separate jurisdciations, three separate geographic locations, from  any one of possibly hundreds of dynamically assigned load balanced servers in different server farms, most of which will be clearing their logs dynamically an regularly once they no longer serve a network or billing purpose.

Hard to get transaction information out of that little miasma.

> 
> 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!

The standards for encryption and keys vary widely across VPN servers - and many use non-open standard key allocation and keys.

> 
> 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 (?).

Mmmm …

> 
> 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.

I’m not saying it would be impossible. If the agency/authority had the reach, expertise, resources and manpower to monitor all of the possible server combinations, across all of the geographic political boundaries on the planet, if they had a ‘presence’ everywhere, if they had effectively unlimited IT resources to devote to the problem of  decrypting and analysing the data streams, or alternatively if they didn’t mind going to the client’s physical point of origin and physically analysing the traffic/logs/contents of stored data of everyone who established a secure socket (on whatever range of ports data is encrypted … and nowadays that range is increasing) … the contents and metadata of said transaction would be effectively concealed.

Finally … you said:
> 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.

I think you’ll find that with TCP, UDP and ICMP  … all of the different packet types transmitted over TCP/IP … packet handling under TCP/IP is all stateless. Bottom line TCP/IP was set up at its creation as a really low maintenance network protocol. Its creators realised that the useful bits of network traffic were the requests for and the sending/receipt of data … so they saw no reason to maintain state between client and server once those transactions had been completed.

This is why it was necessary to invent little numbers like Cookies (which only imitate maintaining state between client and server by storing session/transaction/preference information on the client that can be uploaded when connections are re-established). TCP/IP doesn’t maintain connections for any complicated transaction on the Internet, and the only way it can actually be done/faked is at application level by proprietary protocols - cut in client-server side JAVA, Javascript, VBScript or whatever - embedded in the data stream. And even then it’s a bit of a kludge - compared to, for example, IBM’s X500 and other more much much high maintenance and complex protocols.

Just my 2 cents worth …




More information about the Link mailing list