Thunderbird & Gmail

Gerardo Rodríguez grchapa at hotmail.com
Wed Oct 15 04:07:00 UTC 2008


Hi once again. I was wondering if tor with thunderbird send information 
to the pop3/smtp servers, this is what i found out. I had to use 
thundebird ver 1.5.* with torbutton 1.0.4, and used the WireShark to 
capture packets.

While retrieving the mail this two readings where constant:
_____________________________________________________________________________

Frame 10 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 2wire_2e:d4:89 (aa:aa:aa:2e:d4:89), Dst: 
Intel_94:e0:d3 (ff:ff:ff:94:e0:d3)
Internet Protocol, Src: 83.132.242.113 (83.132.242.113), Dst: 
192.168.1.70 (192.168.1.70)
Transmission Control Protocol, Src Port: mosaicsyssvc1 (1235), Dst Port: 
53328 (53328), Seq: 1, Ack: 1, Len: 0

No.     Time        Source                Destination           Protocol 
Info
11 9.437005    2wire_2e:d4:89        Broadcast             ARP      Who 
has 192.168.1.65?  Tell 192.168.1.254
_____________________________________________________________________________

&
_____________________________________________________________________________

No.     Time        Source                Destination           Protocol 
Info
12 10.373837   192.168.1.70          88.198.51.7           TCP      
43089 > etlservicemgr [PSH, ACK] Seq=1 Ack=1 Win=64949 Len=586

Frame 12 (640 bytes on wire, 640 bytes captured)
Ethernet II, Src: Intel_94:e0:d3 (ff:ff:ff:94:e0:d3), Dst: 
2wire_2e:d4:89 (aa:aa:aa:2e:d4:89)
Internet Protocol, Src: 192.168.1.70 (192.168.1.70), Dst: 88.198.51.7 
(88.198.51.7)
Transmission Control Protocol, Src Port: 43089 (43089), Dst Port: 
etlservicemgr (9001), Seq: 1, Ack: 1, Len: 586
Data (586 bytes)

0000  17 03 01 00 20 bc 7f 8b ef dc 1e 82 ca fa 53 e0   .... .........S.
etc.
_____________________________________________________________________________

And while sending mail this two:
_____________________________________________________________________________

No.     Time        Source                Destination           Protocol 
Info
23 3.306572    CompName             schatten.darksystem.net TCP      
florence > etlservicemgr [PSH, ACK] Seq=1 Ack=1 Win=64363 Len=586

Frame 23 (640 bytes on wire, 640 bytes captured)
Ethernet II, Src: CompName (ff:ff:ff:94:e0:d3), Dst: 192.168.1.254 
(aa:aa:aa:2e:d4:89)
Internet Protocol, Src: CompName (192.168.1.70), Dst: 
schatten.darksystem.net (88.198.51.7)
Transmission Control Protocol, Src Port: florence (1228), Dst Port: 
etlservicemgr (9001), Seq: 1, Ack: 1, Len: 586
Data (586 bytes)

0000  17 03 01 00 20 39 1e d3 cb fe 30 60 3f f2 5f 43   .... 9....0`?._C
etc.
_____________________________________________________________________________

&
_____________________________________________________________________________

No.     Time        Source                Destination           Protocol 
Info
24 3.532021    schatten.darksystem.net CompName             TCP      
etlservicemgr > florence [ACK] Seq=1 Ack=587 Win=65535 Len=0

Frame 24 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 192.168.1.254 (aa:aa:aa:2e:d4:89), Dst: CompName 
(ff:ff:ff:94:e0:d3)
Internet Protocol, Src: schatten.darksystem.net (88.198.51.7), Dst: 
CompName (192.168.1.70)
Transmission Control Protocol, Src Port: etlservicemgr (9001), Dst Port: 
florence (1228), Seq: 1, Ack: 587, Len: 0
_____________________________________________________________________________

Now:

aa:aa:aa:2e:d4:89   is the actual mac address of the adapter in my router
ff:ff:ff:94:e0:d3       is the actual mac address of the adapter in my pc
CompName          is the name of my pc (faked :-)

I´m not an expert in reading packets, but, this is a leak ain´t it?




Gerardo Rodríguez escribió:
> Thanks a lot, I´ll be running tests & I´ll post the results
>
> anonym escribió:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 08/10/08 01:09, Jonathan Addington wrote:
>>  
>>> With Wireshark you can filter by port.     
>> ..
>>  
>>> To address the above, filter by ports, and then by your IP inside the
>>> packet     
>>
>> Sure, filters make it easier finding stuff when you know what to look
>> for, but I'm not sure that's the case here. In an analysis like this we
>> are much more interested that which we had not anticipated. For example,
>> what if Thunderbird leaked DNS requests? Filtering away all but POP and
>> SMTP would then hide this for us.
>>
>> We're not dealing with huge amounts of packets here really, perhaps a
>> couple of hundreds of packets at most. That's a piece of cake to go
>> through and will make the analysis more complete and thorough. IMHO,
>> when dealing with these kinds of issues filtering comes in when that's
>> not a realistic option.
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.9 (GNU/Linux)
>>
>> iEYEARECAAYFAkjr/NAACgkQp8EswdDmSVjMrwCfT2aJ7j7Cko2HhYIItj35gmrK
>> VW4AoOjIfgtkSPrgghm9yusAz+137GSg
>> =xWB4
>> -----END PGP SIGNATURE-----
>>
>>
>>
>>   
>
>
>



More information about the tor-talk mailing list