[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Thunderbird & Gmail



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