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