Re: [Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
On Wed, Jun 13, 2012 at 08:03:46PM +0300, Maxim Kammerer wrote: > On Wed, Jun 13, 2012 at 4:46 PM, anonym wrote: > > Yup. I've opened bugs/claws_with_torsocks_leaks_hostname to track this > > issue. > > This is possibly not a bug with torsocks, but a result of its extended > functionality. [...] Thanks for your detailed analysis. :) -- Ague pgp7lBjnqMj0y.pgp Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
PS. From looking at tsocks sources, it doesn't touch gethostbyname(), whereas torsocks does translate this function. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
Hi,
On Wed, Jun 13, 2012 at 4:46 PM, anonym wrote:
> Yup. I've opened bugs/claws_with_torsocks_leaks_hostname to track this
> issue.
This is possibly not a bug with torsocks, but a result of its extended
functionality. Claws-Mail 3.8.0, when used with set_domain=0, uses its
get_domain_name() function (in compose.c) to retrieve the domain name.
get_domain_name() (commons/utils.c) calls gethostname() to retrieve
the current hostname, and then calls gethostbyname() to get the
canonical hostname. I couldn't find /etc/hosts in Tails' git, but I
guess that it contains something like:
127.0.0.1 localhost amnesia
When gethostbyname() is called on "amnesia", it will consider
"localhost" as the canonical name (h_name). tsocks doesn't change that
behavior. However, torsocks forwards gethostbyname() over Tor, fails
("amnesia" fails to resolve on an exit node), and then Claws-Mail's
get_domain_name() uses the original gethostname() result as a fallback
(and you should see perror("gethostbyname") on stderr). Note that
tsocks can also forward gethostbyname() via SOCKS, but it apparently
doesn't do that for "local" hostnames.
Feel free to explore the sample code below (emulating Claws-Mail's
behavior) with torsocks/tsocks:
#define _BSD_SOURCE
#include
#include
#include
int main() {
char s[256];
struct hostent *hp;
if (!gethostname(s, sizeof(s))) {
printf("hostname: %s\n", s);
if ((hp = gethostbyname(s)))
printf("h_name: %s\n", hp->h_name);
else
herror("gethostbyname");
}
else
perror("gethostname");
return 0;
}
--
Maxim Kammerer
Liberté Linux: http://dee.su/liberte
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
06/13/2012 03:01 PM, intrigeri:
>>> We have a regression here. EHLO/HELO messages leaks the hostname
>>> ('amnesia'), resulting in '*@amnesia' Message IDs, and 'amnesia' in
>>> the last Received field. I managed to track down the culprit: torsocks.
>>> We start claws-mail with torify, which uses torsocks over tsocks.
>>> Switching back to tsocks, like in 0.11 and previous releases, fixes the
>>> leak.
>
> The funny part being:
> at some point we started Claws Mail directly,
> relied on transparent torification,
> and it did not leak such information.
Yup. I've opened bugs/claws_with_torsocks_leaks_hostname to track this
issue.
>> If tsocks really is good enough, here is a quick and dirty hack,
>> hastly tested in the wild, no time for a proper patch:
>
> If that works, then I think it's the way to go.
Implemented.
The remaining tests passed (+ some casual testing since a new image was
built since the last tests) so I've uploaded the final 0.12 image (I'm
waiting for the mirrors to sync before I'll push testing -> master) and
pushed the tag. In other words, Tails 0.12 should go live in <2 hours.
Unfortunately I didn't do a pull this morning so a6b7c2d (which I
noticed 10 minutes ago, when I tried to push testing) didn't make it
into the release.
Cheers!
signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
>> We have a regression here. EHLO/HELO messages leaks the hostname
>> ('amnesia'), resulting in '*@amnesia' Message IDs, and 'amnesia' in
>> the last Received field. I managed to track down the culprit: torsocks.
>> We start claws-mail with torify, which uses torsocks over tsocks.
>> Switching back to tsocks, like in 0.11 and previous releases, fixes the
>> leak.
The funny part being:
at some point we started Claws Mail directly,
relied on transparent torification,
and it did not leak such information.
> If tsocks really is good enough, here is a quick and dirty hack,
> hastly tested in the wild, no time for a proper patch:
If that works, then I think it's the way to go.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
On Tue, Jun 12, 2012 at 07:21:36PM +0200, anonym wrote:
> > # Claws
> >
> > * Check that the profile works and is torified (specifically the
> > EHLO/HELO SMTP messages it sends). Send an email using Claws and a
> > non-anonymizing SMTP relay. Then check that email's headers once
> > received, especially the `Received:` and `Message-ID:` ones.
> > * Also check that the EHLO/HELO SMTP message is not leaking anything
> > with a packet sniffer: start Claws using the panel icon (which runs
> > `torify claws-mail`) to
> > avoid using the transparent proxy (which will confuse tcpdump).
> > Disable SSL/TLS for SMTP in Claws (so take precautions for not
> > leaking your password in plaintext by either changing it temporarily
> > or using a disposable account). Then run `sudo tcpdump -i lo -w
> > dump` to capture the packets before Tor encrypts it, and check the
> > dump for the HELO/EHLO message and verify that it only contains
> > `localhost`.
>
> We have a regression here. EHLO/HELO messages leaks the hostname
> ('amnesia'), resulting in '*@amnesia' Message IDs, and 'amnesia' in
> the last Received field. I managed to track down the culprit: torsocks.
> We start claws-mail with torify, which uses torsocks over tsocks.
> Switching back to tsocks, like in 0.11 and previous releases, fixes the
> leak.
If tsocks really is good enough, here is a quick and dirty hack, hastly
tested in the wild, no time for a proper patch:
1. Create `/usr/bin/torified-claws-mail` (perm 755) with:
#!/bin/sh
TSOCKS_CONF_FILE=/etc/tor/tor-tsocks.conf tsocks.distrib claws-mail
2. Update .desktop (applications and shortcut icon) to use
`torified-claws-mail`.
I have only gone so far to look upon /proc/$PID/maps to see that
libtsocks was indeed loaded. I don't know if that fixes the regression
or introduce others.
This is not the nicest, but we have in mind to ditch Claws soon enough.
--
Ague
pgpyYoxynyjiI.pgp
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] [urgent] Tails 0.12 test results (we've got a potential blocker)
Hi,
Today I've been testing (what I thought was) the final 0.12 build, but
beyond the usual minor annoyances that I've been reporting for a few
releases now there's a regression with Claws Mail (see below). I suppose
this could be called a blocker, but I'd like input on it. No matter what
this will probably delay the 0.12 release until tomorrow. Ah well...
> # Iceweasel
>
> * Does playing HTML5 videos work? In particular, (due to its
> popularity) do [youtube](http://www.youtube.com) videos work?
Like in 0.11, I cannot click the element placeholder to enable HTML5
youtube videos. I have to click the noscript toolbar button -> blocked
objects -> temporarily allow , to make it work. Which
is the correct one is non-obvious.
> # Tor enforcement
>
> * firewall: is IPv6 traffic blocked?
> - at a place with working IPv6: try connecting to a known-working
>IPv6-enabled server on its IPv6 address over TCP and icmp6.
Couldn't test.
> # Claws
>
> * Check that the profile works and is torified (specifically the
> EHLO/HELO SMTP messages it sends). Send an email using Claws and a
> non-anonymizing SMTP relay. Then check that email's headers once
> received, especially the `Received:` and `Message-ID:` ones.
> * Also check that the EHLO/HELO SMTP message is not leaking anything
> with a packet sniffer: start Claws using the panel icon (which runs
> `torify claws-mail`) to
> avoid using the transparent proxy (which will confuse tcpdump).
> Disable SSL/TLS for SMTP in Claws (so take precautions for not
> leaking your password in plaintext by either changing it temporarily
> or using a disposable account). Then run `sudo tcpdump -i lo -w
> dump` to capture the packets before Tor encrypts it, and check the
> dump for the HELO/EHLO message and verify that it only contains
> `localhost`.
We have a regression here. EHLO/HELO messages leaks the hostname
('amnesia'), resulting in '*@amnesia' Message IDs, and 'amnesia' in
the last Received field. I managed to track down the culprit: torsocks.
We start claws-mail with torify, which uses torsocks over tsocks.
Switching back to tsocks, like in 0.11 and previous releases, fixes the
leak.
Once an account has been created, the problem can be fixed by setting:
set_domain=1
domain=localhost
in accountrc. Unfortunately we get:
set_domain=0
domain=
no matter what's put in accountrc.tmpl ('set_domain' isn't supported in
templates, and 'domain' is only used in the wizard for guessing the
email address, the servers' hostnames etc.).
Should we call this a blocker? If so, since torsocks apparently behaves
worse than tsocks in this respect I believe the right course of action
is to revert 7f7cd4e (Merge branch 'feature/torsocks' into devel).
Otherwise, I'm unsure of how to make torsocks play nicely with Claws
Mail, but perhaps some one else has a better solution?
[1] todo/applications_audit/claws_mail/
> # Whisperback
>
> * can a bug report e-mail be sent?
Eventually, yes. I got this error quite a few times:
"Unable to create or to send the mail. [...] peer certificate is
invalid"
Hm? Also it seems that some of them were sent any way, despite the error.
> # erase memory on shutdown
>
> Testing that the needed files are really mapped in memory, and the
> erasing process actually works, involves slightly more complicated
> steps that are worth [[a dedicated page|test/erase_memory_on_shutdown]].
Bad results as expected.
The following tests has not been done yet:
> # USB Installer/Upgrader
>
> The installed or upgraded Tails medium shall be successfully booted
> after each of the following tests.
>
> * Test "Clone & Install":
> - onto a USB stick that has a MBR partition table, and no
> partition at all (regression test)
> - onto a USB stick that already has an old-fashioned hybrid cat'd
> Tails on it
> * Test "Clone & Upgrade" (onto a USB install containing an older
> Tails):
> - onto a USB stick that already has a old-fashioned cat'd hybrid
> Tails on it: should warn this action is not supported, and direct
> the user to the "Clone & Install" operation mode.
> * Test "Upgrade from ISO".
> - make sure to test that TailsData partitions survive upgrades.
> * Test "emergency shutdown on boot medium removal" feature, on Tails
> system installed by this installer.
>
> # Persistence
>
> * Turn off some persistence presets, reboot, and make sure they are
> not activated.
Cheers!
signature.asc
Description: OpenPGP digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
