Re: [tor-talk] Retroactive traffic confirmation attacks on Tor through data retention records?

[Ondrej Mikle <ondrej.mikle@xxxxxxxxx>]

Yes, with data retention data, traffic confirmation over VPN can be done, too.
Think of VPN as "additional hop in circuit". Data retention is the precise
definition of global passive adversary (with one "bonus" - being able to look
into past).

In practice though, there's little to none cooperation among the states (so was
I told), thus the risk is relatively small unless you copy Eiffel Tower or
commit similar heinious crime ;-)

Ondrej

On 04/22/2012 12:08 AM, Phillip wrote:
> Just a quick question, might be stupid: if you were to run all of your
> traffic through a VPN, including tor, would the same considerations apply?
> 
> Or would they only apply to your VPN provider (provided that they keep
> records at all)...?
> 
> Phillip
> 
> 
>> MAC addresses are used by layer 2 protocols (see
>> https://en.wikipedia.org/wiki/OSI_model ).  Once an IP packet
>> traverses a layer 3 device (such as a router) the srcMac has been
>> changed to that of the router's egress interface.  Unless your ISP
>> provided your router, srcMac identifies only which router the packet
>> came from, not the particular client.
>>
>> Decent routers randomize source ports to prevent traffic correlation
>> (makes it harder to confirm that two streams from the same router came
>> from the same client).
>>
>> If you need deniability, don't use an ISP provided router, make sure
>> your router randomizes source ports, and have an open guest wifi
>> network (though obviously make sure the guest network can only access
>> the Internet, not your LAN).
>>
>> -Pascal
>>
>>
>> On 4/21/2012 1:05 PM, Ondrej Mikle wrote:
>>> If the ISP's records store [srcIP, srcPort, srcMac, dstIP, dstPort,
>>> size,
>>> startTime, endTime] for every TCP connection, then it's definitely
>>> doable; note
>>> that srcMac is MAC of client visible from ISP's side of the router to
>>> internet
>>> (so that clients behind NAT can be identified, though the srcPort
>>> gives that
>>> away, too).
>> _______________________________________________
>> tor-talk mailing list
>> tor-talk@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> 
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> 

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk