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

[David Lochrin]

On Friday 23 December 2016 14:31:32 Frank O'Connor wrote:

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

But all the local authority has to do is to crack encryption on the first (local) hop between client and server-1.  Do they care how much it's fiddled with after that?


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

Sure, but the only options are either symmetric or asymmetric (public key) encryption & decryption whichever way you do it.  There's nothing wrong with symmetric encryption per se.  Its weakness lies in the necessity to distribute a key of some sort which can be intercepted.  Of course you can encrypt the key distribution, but that requires another key...

I believe that was the undoing of the German Enigma machine used during the second krieg, an otherwise very fine piece of symmetric encryption; it wasn't just the the result of pure brilliance by Alan Turing as portrayed in the movie a little while ago.


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

Not true, I think - see above.


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

IP is the network-level (routing) protocol and TCP, UDP, etc. are session-level protocols.  Unlike UDP, TCP has to keep state information so it can piece together a complete TCP packet from datagrams which may be out of sequence, missing, etc.  And none of this (or encryption) has anything to do with application state, which must be maintained by individual applications, e.g. by browsers using cookies as you say.

David L.