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