Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[adrelanos]

Jacob Appelbaum:
> adrelanos:
>> Jacob Appelbaum:
>>> adrelanos:
>
> We already fail this test, no?

 Not necessarily. This is a difficult question.

>>>
>>> Tor does not hide that you are using Tor
>>
>> Yes, but... While making this point up, I saw pluggable transports as a
>> tool which can be thrown into the mix and make this a non-issue.
> 
> I don't think so - I also this this is non-trivial.

I know. It's absolutely non-trivial. From my distro packager perspective
pluggable transports are just some magic boxes to throw into the mix,
which get a job done. Great minds do all the thinking and coding.

> Some pluggable
> transports may seek to obfuscate traffic or to morph it. However, they
> do not claim to hide that you are using Tor *in all cases* but rather in
> very specific cases. An example threat model includes a DPI device with
> limited time to make a classification choice - so the hiding is very
> specific to functionality and generally does not take into account
> endless data retention with retroactive policing.

Ok.

>>
>> (In theory obfsproxy and alike tools can hide the fact that someone is
>> using Tor, which will be required against trying-hard-censurers so or
>> so. This assumes, that pluggable transports will win the arms race
>> against censors.)
> 
> Perhaps for a time but again - rarely is anyone thinking about say, the
> one, five or ten year logging of full packets.

Yes.

>>
>>> and using Tails or Whonix is an
>>> example of a system only emitting Tor traffic.
>>
>> The plan is...
>>
>> Whonix:
>> When using VMs (as most people do), there is still a host operating
>> system people start first - so there is not only Tor traffic. Tor usage
>> can be hidden by using pluggable transports.
> 
> I would be very careful with that claim. It might be hidden and it might
> just be that no one is looking.

Yes, I wouldn't claim that in documentation, of course. When I said "Tor
usage can be hidden by using pluggable transports." in this very
context, I assume, that this magic box is working well. It's very clear
to me, that this is a very strong assumption and that this involves a
lot work done by other people creating that magic box. (If we wouldn't
make that assumption, we probable wouldn't have to talk about
fingerprinting issues.)

It's all about censorship circumvention. I thought, when we assume that
this magic box works reasonable well, it would be a pity if we now added
something which could render the achievements by pluggable transports
useless.

>>
>> Tails:
>> When this becomes an issue, there are two workarounds:
>> - running Tails in a VM (naturally requires starting a non-Tails os
>> beforehand) using pluggable transports to hide Tor usage
>> - booting a second computer with a non-Tails operating system behind the
>> same router, wait a bit, run Tails using pluggable transports to hide
>> Tor usage
>>
>> And one possible fix: boot the amnesic system, simulate "this is Debian"
>> (or other mainstream distro) by running it untorified in chroot or in a
>> VM; fire up Tor using pluggable transports to hide Tor usage.
>>
>> The point I wanted to make is, I can very well imagine, not to fail this
>> test, i.e. pretending to be a mainstream distribution, having non-Tor
>> traffic and obfuscating Tor traffic using pluggable transports. Perhaps
>> it can be prevented, that tlsdate introduces new operating system
>> fingerprinting possibilities for ISPs.
>>
> 
> That's my point - I don't believe that tlsdate introduces anything more
> than what any OpenSSL TLS connection would introduce. The main
> difference is the host and *that* is currently a set of *extremely*
> popular hosts, way way more popular than Tor nodes or some random bridge
> or something. Yes, we could use obfsproxy in the mix but that is punting
> and a side step.

Ok.

>>> It depends on your threat
>>> model but generally, we'd just making up "someone could" as a network
>>> distinguisher.
>>
>> Yes.
>>
>>> I assert that someone could watch - see no traffic except
>>> encrypted traffic, decide it is Tor and then decide you're running Tails
>>> or Whonix.
>>
>> I tried to picture solutions to that above.
>>
> 
> That doesn't solve the fingerprinting issues - attackers can classify
> the number of users with different machines behind a NAT and often do so.

Well, I failed to describe what I meant with 100% accuracy due to my
skills. I cut it here so you don't have to read so much. Just that: our
opinions here don't differ at all and I got educated. You understand
this topic better than me, the important point "it would be a pity if we
now added something which could render the achievements by pluggable
transports useless" has been considered, thank you for that.

Best,
adrelanos
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

Maxim Kammerer:
> On Thu, Apr 18, 2013 at 1:18 AM, Jacob Appelbaum  wrote:
>> Whenever a less friendly person gives me a hard time about the obvious
>> futility of tlsdate, I think:
>>
>> "Let me know how your ntp replacement project goes and I'll gladly use
>> it when my shitty one trick pony isn't beating the pants off of your arm
>> chair hacking."
>>
>> I'd say I'm kidding but really, we need a secure network time client and
>> we need one badly. If we don't have one, we can't hold certain
>> assumptions to be correct and entire systems can be broken. There is
>> also the attack surface and architecture of other ntp/ntp-like clients.
> 
> There are now apparently enough openly accessible and stable
> authenticated NTP servers around to rely on them in a distro. The
> problem is that authenticated NTP protocol (more precisely, its
> asymmetric crypto Autokey variant) does not support NAT traversal in
> either the server *or* the client, since both IP addresses are signed.
> I guess the reason is that NTP has no clear distinction between client
> and server.
> 

There are a lot of issues with ntp - my favorite is that a basic (eg:
shipping with OS X) ntp client will hit the default Apple NTP servers.
These servers may be queried by external third parties and the
information returned is enough to attack any client who is using the
server. The information returned includes the client ip, the udp source
port, the udp destination and of course, the attacker knows the server
ip. This means that an attacker may now send packets as the server -
thus the attacker can even attack ntp clients behind a nat or a stateful
firewall. UDP is part of the problem, the lack of the client/server
authentication is another part of the problem, the fact that the ntp
clients aren't written with security in mind is yet another problem.

This says nothing of an attacker who controls the network path - such an
attacker has an even larger number of attacks and ntp falls over for
nearly all of them. The entire idea of a False Ticker relies on the
notion that you have some path to some honest ntp server, so you can
have some phase locked loops and determine which of the set is wrong or
bad. Good luck without authentication, integrity, confidentiality in
syncing that clock...

So again, I understand you don't like my hack and I'd just like to be
clear - we can't use the current ntp tools to safely, securely or
anonymously set our clock in nearly any use case. I'm working on
alternative ways to do it and I'm using IETF compliant protocols on the
network to ensure that it is actually more than a silly hack that only
works for a while.

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

adrelanos:
> Jacob Appelbaum:
>> adrelanos:

 We already fail this test, no?
>>>
>>> Not necessarily. This is a difficult question.
>>>
>>
>> Tor does not hide that you are using Tor
> 
> Yes, but... While making this point up, I saw pluggable transports as a
> tool which can be thrown into the mix and make this a non-issue.

I don't think so - I also this this is non-trivial. Some pluggable
transports may seek to obfuscate traffic or to morph it. However, they
do not claim to hide that you are using Tor *in all cases* but rather in
very specific cases. An example threat model includes a DPI device with
limited time to make a classification choice - so the hiding is very
specific to functionality and generally does not take into account
endless data retention with retroactive policing.

> 
> (In theory obfsproxy and alike tools can hide the fact that someone is
> using Tor, which will be required against trying-hard-censurers so or
> so. This assumes, that pluggable transports will win the arms race
> against censors.)

Perhaps for a time but again - rarely is anyone thinking about say, the
one, five or ten year logging of full packets.

> 
>> and using Tails or Whonix is an
>> example of a system only emitting Tor traffic.
> 
> The plan is...
> 
> Whonix:
> When using VMs (as most people do), there is still a host operating
> system people start first - so there is not only Tor traffic. Tor usage
> can be hidden by using pluggable transports.

I would be very careful with that claim. It might be hidden and it might
just be that no one is looking.

> 
> Tails:
> When this becomes an issue, there are two workarounds:
> - running Tails in a VM (naturally requires starting a non-Tails os
> beforehand) using pluggable transports to hide Tor usage
> - booting a second computer with a non-Tails operating system behind the
> same router, wait a bit, run Tails using pluggable transports to hide
> Tor usage
> 
> And one possible fix: boot the amnesic system, simulate "this is Debian"
> (or other mainstream distro) by running it untorified in chroot or in a
> VM; fire up Tor using pluggable transports to hide Tor usage.
> 
> The point I wanted to make is, I can very well imagine, not to fail this
> test, i.e. pretending to be a mainstream distribution, having non-Tor
> traffic and obfuscating Tor traffic using pluggable transports. Perhaps
> it can be prevented, that tlsdate introduces new operating system
> fingerprinting possibilities for ISPs.
> 

That's my point - I don't believe that tlsdate introduces anything more
than what any OpenSSL TLS connection would introduce. The main
difference is the host and *that* is currently a set of *extremely*
popular hosts, way way more popular than Tor nodes or some random bridge
or something. Yes, we could use obfsproxy in the mix but that is punting
and a side step.

>> It depends on your threat
>> model but generally, we'd just making up "someone could" as a network
>> distinguisher.
> 
> Yes.
> 
>> I assert that someone could watch - see no traffic except
>> encrypted traffic, decide it is Tor and then decide you're running Tails
>> or Whonix.
> 
> I tried to picture solutions to that above.
> 

That doesn't solve the fingerprinting issues - attackers can classify
the number of users with different machines behind a NAT and often do so.

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Maxim Kammerer]

On Thu, Apr 18, 2013 at 1:18 AM, Jacob Appelbaum  wrote:
> Whenever a less friendly person gives me a hard time about the obvious
> futility of tlsdate, I think:
>
> "Let me know how your ntp replacement project goes and I'll gladly use
> it when my shitty one trick pony isn't beating the pants off of your arm
> chair hacking."
>
> I'd say I'm kidding but really, we need a secure network time client and
> we need one badly. If we don't have one, we can't hold certain
> assumptions to be correct and entire systems can be broken. There is
> also the attack surface and architecture of other ntp/ntp-like clients.

There are now apparently enough openly accessible and stable
authenticated NTP servers around to rely on them in a distro. The
problem is that authenticated NTP protocol (more precisely, its
asymmetric crypto Autokey variant) does not support NAT traversal in
either the server *or* the client, since both IP addresses are signed.
I guess the reason is that NTP has no clear distinction between client
and server.

--
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] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

adrelanos:
> Jacob Appelbaum:
>> Elly Fong-Jones:
>>> On Tue, Apr 16, 2013 at 01:03:27PM +0200, intrigeri wrote:
 Hi Jacob and Elly,

 Thanks for your answers! See more questions bellow.

 Jacob Appelbaum wrote (11 Apr 2013 06:56:18 GMT) :
> Basically - tlsdate in Tails would be a minor set of users compared to
> the much larger user base of ChromeOS.

 Sure.

 I doubt we can blend in this "anonymity" set, though: unless Tails
 wants to forever copy the set of hosts ChromeOS queries (which I don't
 think we would want to rely upon on the long run), then Tails' use of
 tlsdate will probably be fingerprintable at least by the ISP if the
 connections are made in the clear, so we probably would want to run
 tlsdate over Tor anyway.
>>>
>>> Even if not, there are other easyish ways to distinguish a Chrome OS
> device,
>>> such as the autoupdate behavior.
> 
> Good point. Running tlsdate in the clear will therefore be
> fingerprintable and subsequently the whole client could get blocked in
> censored areas.
> 

How so?

> What could be the solution? I don't know. Can there be ever any network
> time sync solution which works in the clear?
> 

Yeah, a parasitic one? For example, I'd be happy to add a network
sniffer ( tlsdate-passive ) or a proxy for HTTPS connections
(tlsdate-clock-extraction-proxy) that just looks for tls sessions,
extracts the server time and generates no traffic at all.

> If many distributions jump on the tlsdate train by shipping tlsddate by
> default, that may help?

I feel like we're over thinking it - even in the most harsh networks, we
rarely see full https blocking endlessly. The fact is that we could
probably even set our clocks against a tls mitm device ( I do so against
captive portals somteimes ) and it would still work well enough. In the
cases when https is really blocked entirely, I believe that we can
instruct tlsdate to try to look up other services (eg: randomly pick an
alexa top domain, do an mx query or connect to pop.example.com or
imap.example.com to start a tls connection).

Again, another feature request - it is a property of tls, so we can use
things other than webservers.

For what it is worth, in Egypt, ntp was busted when the network went
down unless you had a local ntp server; the same was true for most services.

> 
>>From ntp* manpage:
> "ntpd adjusts the clock in small steps so that the timescale is
> effectively continuous and without discontinuities"
> 
> I haven't had any issues without that feature and therefore don't miss
> it. My speculation is, that mainstream distributions may care more.
> 

adjtime is a reasonable feature enhancement. It is in the queue. I've
been working on porting tlsdate to a few other platforms over that
feature though. I'd like to have a hardened parasitic network time
client before I worry about how it doesn't optimally update the clock.

>> I assume over time one would be able to distinguish it - though we
>> mostly care about getting a correct clock and then if someone tries to
>> guess our OS, we might be fine with them then filtering us or trying to
>> attack us. However, if we haven't set our clock correctly, we might have
>> some issues with actual attacks like replaying a consensus, etc.
> 
> This is a difficult topic, I hate being a nitpicker, don't have all the
> answers, but must say...
> 
> Distinguishing the operating system should be prevented if somehow
> possible: otherwise achievements made by pluggable transports wouldn't
> last long.

We already fail this test, no? Hell, who is even testing for that except
potential censors?

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

adrelanos:
>>
>> We already fail this test, no?
> 
> Not necessarily. This is a difficult question.
> 

Tor does not hide that you are using Tor and using Tails or Whonix is an
example of a system only emitting Tor traffic. It depends on your threat
model but generally, we'd just making up "someone could" as a network
distinguisher. I assert that someone could watch - see no traffic except
encrypted traffic, decide it is Tor and then decide you're running Tails
or Whonix.

Also, the way these systems do TLS handshakes will reveal your current
clock as well as other details - such as if you're using Whonix or Tails
(if one caches the consensus, and the other doesn't).

> Tails:
> (For your ISP or local network administrator)
> https://tails.boum.org/doc/about/fingerprint/index.en.html
> 
> Whonix (since interested in this topic as well):
> https://sourceforge.net/p/whonix/wiki/Fingerprint/#for-your-isp-or-local-network-administrator
> 
> My point is, even if the answer is at the moment "we fail that test",
> it's hopefully "possible to fix" as well. And, we should try to prevent
> adding new factors, which could worsen the current status, if that
> appears (already) attractive and doable.

Well, TLS is the default transport and so, I think TLS is the best way
to get time information. We're not really going to stick out any more
than the rest of the TLS traffic - in fact, we might even stick out less
because we have a valid cert and it isn't Tor, it's a shared network
time program. I admit, it can probably be fingerprinted but I think that
fingerprinting it won't look much different from the rest of the TLS
traffic - it will look lets say, less sketchy?

> 
> Of course, the already existing (or new) operating system fingerprinting
> by ISP issues could still get fixed when they get real world issues. For
> example, Tails could mimic a mainstream operating system, by running one
> untorified in a VM or chroot; and letting pluggable transports doing the
> obfuscation for Tor traffic.
> 

I'd be curious what snoopy says about any of the systems?

  http://www.sensepost.com/blog/7557.html

>> Hell, who is even testing for that except
>> potential censors?
> 
> Potential censors, yes. Other, I don't have an answer.

Well, if we want to red team it, we should set up some parameters and go
for it?

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

intrigeri:
> Hi,
> 
> adrelanos wrote (17 Apr 2013 19:33:23 GMT) :
>> Why not build the required features into Tor itself?
> 
> (Let's assume this is no rhetorical question.)
> 
> My best guess is that nobody had 1. enough interest in this topic; 2.
> the right set of skills; 3. enough free time. In my experience, this
> is a correct answer to most "why not?" questions about wishlist
> tickets in the free software world.

I have a proposal that is half written on the topic. Once I write the
proposal, I will probably build it into Tor if no one else beats me to
it. It will however require a bit of work as we don't want to keep such
time setting capabilities forever, etc.

> 
> Please don't refrain yourself from doing as much of the work as you
> can (write a proposal, discuss it, implement it) and from finding
> someone else to do the rest. I, for one, will be very grateful if
> this happens.
> 

Sure. Of course.

However - the goal here is to for tlsdate to work everywhere - it will
work anywhere where openssl works and that is even more places than Tor,
sadly. I also want it to be used by groups that are not Tor - even if
tor could set the time in this way, I'd want a way to check that
confirms it. Trust but verify, right?

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[adrelanos]

Jacob Appelbaum:
> adrelanos:
>>>
>>> We already fail this test, no?
>>
>> Not necessarily. This is a difficult question.
>>
> 
> Tor does not hide that you are using Tor

Yes, but... While making this point up, I saw pluggable transports as a
tool which can be thrown into the mix and make this a non-issue.

(In theory obfsproxy and alike tools can hide the fact that someone is
using Tor, which will be required against trying-hard-censurers so or
so. This assumes, that pluggable transports will win the arms race
against censors.)

> and using Tails or Whonix is an
> example of a system only emitting Tor traffic.

The plan is...

Whonix:
When using VMs (as most people do), there is still a host operating
system people start first - so there is not only Tor traffic. Tor usage
can be hidden by using pluggable transports.

Tails:
When this becomes an issue, there are two workarounds:
- running Tails in a VM (naturally requires starting a non-Tails os
beforehand) using pluggable transports to hide Tor usage
- booting a second computer with a non-Tails operating system behind the
same router, wait a bit, run Tails using pluggable transports to hide
Tor usage

And one possible fix: boot the amnesic system, simulate "this is Debian"
(or other mainstream distro) by running it untorified in chroot or in a
VM; fire up Tor using pluggable transports to hide Tor usage.

The point I wanted to make is, I can very well imagine, not to fail this
test, i.e. pretending to be a mainstream distribution, having non-Tor
traffic and obfuscating Tor traffic using pluggable transports. Perhaps
it can be prevented, that tlsdate introduces new operating system
fingerprinting possibilities for ISPs.

> It depends on your threat
> model but generally, we'd just making up "someone could" as a network
> distinguisher.

Yes.

> I assert that someone could watch - see no traffic except
> encrypted traffic, decide it is Tor and then decide you're running Tails
> or Whonix.

I tried to picture solutions to that above.


___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[adrelanos]

Jacob Appelbaum:
> adrelanos:
>> Jacob Appelbaum:
>>> Elly Fong-Jones:
 On Tue, Apr 16, 2013 at 01:03:27PM +0200, intrigeri wrote:
> Hi Jacob and Elly,
>
> Thanks for your answers! See more questions bellow.
>
> Jacob Appelbaum wrote (11 Apr 2013 06:56:18 GMT) :
>> Basically - tlsdate in Tails would be a minor set of users compared to
>> the much larger user base of ChromeOS.
>
> Sure.
>
> I doubt we can blend in this "anonymity" set, though: unless Tails
> wants to forever copy the set of hosts ChromeOS queries (which I don't
> think we would want to rely upon on the long run), then Tails' use of
> tlsdate will probably be fingerprintable at least by the ISP if the
> connections are made in the clear, so we probably would want to run
> tlsdate over Tor anyway.

 Even if not, there are other easyish ways to distinguish a Chrome OS
>> device,
 such as the autoupdate behavior.
>>
>> Good point. Running tlsdate in the clear will therefore be
>> fingerprintable and subsequently the whole client could get blocked in
>> censored areas.
>>
> 
> How so?
> 
>> What could be the solution? I don't know. Can there be ever any network
>> time sync solution which works in the clear?
>>
> 
> Yeah, a parasitic one? For example, I'd be happy to add a network
> sniffer ( tlsdate-passive ) or a proxy for HTTPS connections
> (tlsdate-clock-extraction-proxy) that just looks for tls sessions,
> extracts the server time and generates no traffic at all.
> 
>> If many distributions jump on the tlsdate train by shipping tlsddate by
>> default, that may help?
> 
> I feel like we're over thinking it - even in the most harsh networks, we
> rarely see full https blocking endlessly. The fact is that we could
> probably even set our clocks against a tls mitm device ( I do so against
> captive portals somteimes ) and it would still work well enough. In the
> cases when https is really blocked entirely, I believe that we can
> instruct tlsdate to try to look up other services (eg: randomly pick an
> alexa top domain, do an mx query or connect to pop.example.com or
> imap.example.com to start a tls connection).
> 
> Again, another feature request - it is a property of tls, so we can use
> things other than webservers.
> 
> For what it is worth, in Egypt, ntp was busted when the network went
> down unless you had a local ntp server; the same was true for most services.
> 
>>
>> >From ntp* manpage:
>> "ntpd adjusts the clock in small steps so that the timescale is
>> effectively continuous and without discontinuities"
>>
>> I haven't had any issues without that feature and therefore don't miss
>> it. My speculation is, that mainstream distributions may care more.
>>
> 
> adjtime is a reasonable feature enhancement. It is in the queue. I've
> been working on porting tlsdate to a few other platforms over that
> feature though. I'd like to have a hardened parasitic network time
> client before I worry about how it doesn't optimally update the clock.
> 
>>> I assume over time one would be able to distinguish it - though we
>>> mostly care about getting a correct clock and then if someone tries to
>>> guess our OS, we might be fine with them then filtering us or trying to
>>> attack us. However, if we haven't set our clock correctly, we might have
>>> some issues with actual attacks like replaying a consensus, etc.
>>
>> This is a difficult topic, I hate being a nitpicker, don't have all the
>> answers, but must say...
>>
>> Distinguishing the operating system should be prevented if somehow
>> possible: otherwise achievements made by pluggable transports wouldn't
>> last long.
> 
> We already fail this test, no?

Not necessarily. This is a difficult question.

Tails:
(For your ISP or local network administrator)
https://tails.boum.org/doc/about/fingerprint/index.en.html

Whonix (since interested in this topic as well):
https://sourceforge.net/p/whonix/wiki/Fingerprint/#for-your-isp-or-local-network-administrator

My point is, even if the answer is at the moment "we fail that test",
it's hopefully "possible to fix" as well. And, we should try to prevent
adding new factors, which could worsen the current status, if that
appears (already) attractive and doable.

Of course, the already existing (or new) operating system fingerprinting
by ISP issues could still get fixed when they get real world issues. For
example, Tails could mimic a mainstream operating system, by running one
untorified in a VM or chroot; and letting pluggable transports doing the
obfuscation for Tor traffic.

> Hell, who is even testing for that except
> potential censors?

Potential censors, yes. Other, I don't have an answer.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[adrelanos]

Jacob Appelbaum:
> Elly Fong-Jones:
>> On Tue, Apr 16, 2013 at 01:03:27PM +0200, intrigeri wrote:
>>> Hi Jacob and Elly,
>>>
>>> Thanks for your answers! See more questions bellow.
>>>
>>> Jacob Appelbaum wrote (11 Apr 2013 06:56:18 GMT) :
 Basically - tlsdate in Tails would be a minor set of users compared to
 the much larger user base of ChromeOS.
>>>
>>> Sure.
>>>
>>> I doubt we can blend in this "anonymity" set, though: unless Tails
>>> wants to forever copy the set of hosts ChromeOS queries (which I don't
>>> think we would want to rely upon on the long run), then Tails' use of
>>> tlsdate will probably be fingerprintable at least by the ISP if the
>>> connections are made in the clear, so we probably would want to run
>>> tlsdate over Tor anyway.
>>
>> Even if not, there are other easyish ways to distinguish a Chrome OS
device,
>> such as the autoupdate behavior.

Good point. Running tlsdate in the clear will therefore be
fingerprintable and subsequently the whole client could get blocked in
censored areas.

What could be the solution? I don't know. Can there be ever any network
time sync solution which works in the clear?

If many distributions jump on the tlsdate train by shipping tlsdate by
default, that may help?

>From ntp* manpage:
"ntpd adjusts the clock in small steps so that the timescale is
effectively continuous and without discontinuities"

I haven't had any issues without that feature and therefore don't miss
it. My speculation is, that mainstream distributions may care more.

> I assume over time one would be able to distinguish it - though we
> mostly care about getting a correct clock and then if someone tries to
> guess our OS, we might be fine with them then filtering us or trying to
> attack us. However, if we haven't set our clock correctly, we might have
> some issues with actual attacks like replaying a consensus, etc.

This is a difficult topic, I hate being a nitpicker, don't have all the
answers, but must say...

Distinguishing the operating system should be prevented if somehow
possible: otherwise achievements made by pluggable transports wouldn't
last long.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[intrigeri]

Hi,

adrelanos wrote (17 Apr 2013 19:33:23 GMT) :
> Why not build the required features into Tor itself?

(Let's assume this is no rhetorical question.)

My best guess is that nobody had 1. enough interest in this topic; 2.
the right set of skills; 3. enough free time. In my experience, this
is a correct answer to most "why not?" questions about wishlist
tickets in the free software world.

Please don't refrain yourself from doing as much of the work as you
can (write a proposal, discuss it, implement it) and from finding
someone else to do the rest. I, for one, will be very grateful if
this happens.

[1] https://lists.torproject.org/pipermail/tor-talk/2011-January/008551.html

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

intrigeri:
> Hi,
> 
> Jacob Appelbaum wrote (17 Apr 2013 08:58:32 GMT) :
>> What version of htpdate are you shipping currently?
> 
> This is documented there:
> https://tails.boum.org/contribute/design/Time_syncing/#index2h2
> 

OK, so the perl version initially made me a lot less concerned - that C
code isn't the safest. Though in the perl version, I think most of the C
problems are missing - I'd wager a few general issues might remain. I'd
like to see the user switching code - do have it handy?

All the best,
Jacob

___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

intrigeri:
> Jacob, are you interested in implementing something like our current
> multiple pool -based approach [2], or something else with similar
> security properties?

What version of htpdate are you shipping currently? I've just been
reading the source for htpdate-1.0.4 - is that the right version? I
didn't find an htpdate package in Debian, where is the version Tails
uses? Is it the perl version? Or perhaps htpdate-1.0.5?

My initial thoughts from reading 1.0.4 very quickly are:

  It is written for HTTP services only
I thought surely that it used TLS, am I auditing the wrong version?
It is trivial to fingerprint
  It isn't written with defense in depth as a solid programming paradigm
  It looks like it might leak DNS (which in Tails probably won't matter)
  It has a static and easy to fingerprint user-agent:
'User-Agent: htpdate/"VERSION"'
  If called with long urls/host names:
the HTTP HEAD request will be truncated
  It has a hand rolled HTTP parser
  It assumes no day light savings time
Is this absolutely certain?
  It doesn't appear to be optimized for speed
it creates and initializes data structures while parsing HTTP
  It has an interesting way of doing rtt calculation:
"rtt * 1e-6"
  It may use adjtime which is kinder and gentler
it also uses settimeofday()
htpdate_adjtimex() is a reasonably interesting idea
  It does basically everything setting euid/guid as 0
it doesn't really privsep
  It runs as root by default
why not ensure that an unprived user/group is required?
the code allows for dropping to user:group root:root
  The priv dropping code is not safe:
  641 »·if ( sw_uid ) seteuid( sw_uid );
  642 »·if ( sw_gid ) setegid( sw_gid );
  The programmer is funny:
  750 »·if ( goodtimes )

I didn't see anything obviously exploitable but I did see that if some
things fail to happen... all bets are off about things like not being
root and there are no checks to catch such failures.

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[intrigeri]

Hi,

Jacob Appelbaum wrote (17 Apr 2013 08:58:32 GMT) :
> What version of htpdate are you shipping currently?

This is documented there:
https://tails.boum.org/contribute/design/Time_syncing/#index2h2

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

Hi,

intrigeri:
> Hi Jacob and Elly,
> 
> Thanks for your answers! See more questions bellow.
> 
> Jacob Appelbaum wrote (11 Apr 2013 06:56:18 GMT) :
>> Basically - tlsdate in Tails would be a minor set of users compared to
>> the much larger user base of ChromeOS.
> 
> Sure.
> 
> I doubt we can blend in this "anonymity" set, though: unless Tails
> wants to forever copy the set of hosts ChromeOS queries (which I don't
> think we would want to rely upon on the long run), then Tails' use of
> tlsdate will probably be fingerprintable at least by the ISP if the
> connections are made in the clear, so we probably would want to run
> tlsdate over Tor anyway.

I mean, I guess? It looks like a vanilla OpenSSL client connection to a
TLS service - it can be *any* TLS service - so you could pick domain
names at random and connect to their mx records, their pop/imap or
www/https ports, etc.

The list of hosts is the least interesting way to fingerprint it, I
guess is my thought - so we could try to make sure that tlsdate always
has the same cipher-suites for tlsdate on Tails and ChromeOS. Then the
main difference would be the host name - I suspect though that both will
vary and in any case, such variance isn't a bad thing per se.

I guess I sorta feel like this is being over thought.

> 
> So, I'm now considering this (tlsdate over Tor) to replace our use of
> htpdate, and not to replace our initial time guess based on the Tor
> consensus [1].

I'm happy to hear that. Proxy support works today - so we could easily
ship a tlsdated.conf in git master for tails. Send me one and I'll merge
it; perhaps even as the default?

> 
> [1] https://tails.boum.org/contribute/design/Time_syncing/#index3h1
> 

I think tordate should be integrated into tlsdate's timewarp feature -
that is - we may already slam the clock forward to the compile time for
tlsdate. We could also tell it where there might be a consensus and slam
it a second time as long as it is newer than the compile date.

I could either write a simple user tool that is basically the most
simple tordate like function inside of tlsdate, or I could spawn a
process that calls tordate with some arguments, or I could write a new
tordate like program (eg: tlsdate-tor-consensus-date-parser).

If I were to reinvent the wheel without having read any of tordate's
source, I would:

  open the consensus or the cached-microdescs
   parse the absolute minimum time
  stat the respective file to see the last possible atime/mtime/ctime
  pick the later time of the two
  jump the clock forward again

I suspect that we'd also want to make sure that the consensus on disk
did verify and check out - I wouldn't want to trust it blindly until I
carefully checked out how those files are created.

I realize that Tails doesn't start with a consensus and I consider this
to be a bug. If I use persistence for example, I would like a consensus
cached so that I might have the protection of Guard nodes as well as a
forward moving clock, as an example.

>> I'd like to settle on a list of hosts that it uses by default which may
>> include a Google host or not. I haven't yet decided.
> 
> OK.
> 
> Jacob, are you interested in implementing something like our current
> multiple pool -based approach [2], or something else with similar
> security properties?

We support multiple hosts in the configuration file. I'd be happy to
take a default config that sets against any set of hosts you'd like, I
bet. Would that satisfy your desire for a pool? I'm also happy to start
working on the TLSDATEPOOL idea that I've written up in the git repo.

I think though that it makes more sense to pick the top set of hosts
from the alexa top 1000, pick a host randomly and try a tls connection.
This gives us some entropy as the list changes, it also gives us the
ability to blend in with the overall large amount of traffic to those
sites and the list is largely neutrally collected without revealing much
about us.

> If Tails wants to move to tlsdate some day,

I don't mean to sound frustrated but really, what is the core set of
features that you would want added that would allow you to replace
htpdate? Do you want me to add an HTTP date parser helper or what? :)

> I guess a prerequisite would be not to lose the nice security
> properties this approach currently gives us.

I see that you'd like both multiple hosts by default and a way to pick
from a set, effectively to create a consensus. I generally think this is
a fine idea but really, I question the security properties if you're
worried about fingerprinting. If you're using it over Tor, I feel like
the fingerprinting is not worth serious consideration. If you're not, I
feel like a set of three host pools is extremely revealing. So in that
sense, if you want to settle for that - yeah, a consensus is a possible
enhancement I'd consider.

I'd like it even more if we pick a few different keys/root chains, burn
those into tlsdate, and add other stuff like DANE, convergence, CT, a
loo

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

Elly Fong-Jones:
> On Tue, Apr 16, 2013 at 01:03:27PM +0200, intrigeri wrote:
>> Hi Jacob and Elly,
>>
>> Thanks for your answers! See more questions bellow.
>>
>> Jacob Appelbaum wrote (11 Apr 2013 06:56:18 GMT) :
>>> Basically - tlsdate in Tails would be a minor set of users compared to
>>> the much larger user base of ChromeOS.
>>
>> Sure.
>>
>> I doubt we can blend in this "anonymity" set, though: unless Tails
>> wants to forever copy the set of hosts ChromeOS queries (which I don't
>> think we would want to rely upon on the long run), then Tails' use of
>> tlsdate will probably be fingerprintable at least by the ISP if the
>> connections are made in the clear, so we probably would want to run
>> tlsdate over Tor anyway.
> 
> Even if not, there are other easyish ways to distinguish a Chrome OS device,
> such as the autoupdate behavior.
> 

I assume over time one would be able to distinguish it - though we
mostly care about getting a correct clock and then if someone tries to
guess our OS, we might be fine with them then filtering us or trying to
attack us. However, if we haven't set our clock correctly, we might have
some issues with actual attacks like replaying a consensus, etc.

>> So, I'm now considering this (tlsdate over Tor) to replace our use of
>> htpdate, and not to replace our initial time guess based on the Tor
>> consensus [1].
>>
>> [1] https://tails.boum.org/contribute/design/Time_syncing/#index3h1
>>
>>> I'd like to settle on a list of hosts that it uses by default which may
>>> include a Google host or not. I haven't yet decided.
>>
>> OK.
>>
>> Jacob, are you interested in implementing something like our current
>> multiple pool -based approach [2], or something else with similar
>> security properties? If Tails wants to move to tlsdate some day,
>> I guess a prerequisite would be not to lose the nice security
>> properties this approach currently gives us.
>>
>> [2] https://tails.boum.org/contribute/design/Time_syncing/#index4h2
>>
>> Elly Fong-Jones wrote (08 Apr 2013 03:06:02 GMT) :
>>> The (slightly outdated now) time-sources design doc is here:
>>> 
>>
>> Elly, is this design doc correct that tlsdate queries
>> clients3.google.com only in ChromeOS?
> 
> Correct.
> 

Do you happen to have a pcap of tlsdate on a recent ChromeOS device
doing a handshake? I wouldn't mind considering it a design goal that all
Tails tlsdate builds should have matching cipher suites. With some other
hackery we can probably make it identical for the data in a given
tlsdate flow.

>> (Given you implemented the multi-host feature, I'd be surprised that
>> you don't use it, but I could not find what /etc/tlsdate/tlsdated.conf
>> ChromeOS is using, so I don't know.)
> 
> We are supposed to be using it, but are not yet. Open bug :)
> 

If we made that set of hosts the default set of hosts - would anyone
mind? :)

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Elly Fong-Jones]

On Tue, Apr 16, 2013 at 01:03:27PM +0200, intrigeri wrote:
> Hi Jacob and Elly,
> 
> Thanks for your answers! See more questions bellow.
> 
> Jacob Appelbaum wrote (11 Apr 2013 06:56:18 GMT) :
> > Basically - tlsdate in Tails would be a minor set of users compared to
> > the much larger user base of ChromeOS.
> 
> Sure.
> 
> I doubt we can blend in this "anonymity" set, though: unless Tails
> wants to forever copy the set of hosts ChromeOS queries (which I don't
> think we would want to rely upon on the long run), then Tails' use of
> tlsdate will probably be fingerprintable at least by the ISP if the
> connections are made in the clear, so we probably would want to run
> tlsdate over Tor anyway.

Even if not, there are other easyish ways to distinguish a Chrome OS device,
such as the autoupdate behavior.

> So, I'm now considering this (tlsdate over Tor) to replace our use of
> htpdate, and not to replace our initial time guess based on the Tor
> consensus [1].
> 
> [1] https://tails.boum.org/contribute/design/Time_syncing/#index3h1
> 
> > I'd like to settle on a list of hosts that it uses by default which may
> > include a Google host or not. I haven't yet decided.
> 
> OK.
> 
> Jacob, are you interested in implementing something like our current
> multiple pool -based approach [2], or something else with similar
> security properties? If Tails wants to move to tlsdate some day,
> I guess a prerequisite would be not to lose the nice security
> properties this approach currently gives us.
>
> [2] https://tails.boum.org/contribute/design/Time_syncing/#index4h2
> 
> Elly Fong-Jones wrote (08 Apr 2013 03:06:02 GMT) :
> > The (slightly outdated now) time-sources design doc is here:
> > 
> 
> Elly, is this design doc correct that tlsdate queries
> clients3.google.com only in ChromeOS?

Correct.

> (Given you implemented the multi-host feature, I'd be surprised that
> you don't use it, but I could not find what /etc/tlsdate/tlsdated.conf
> ChromeOS is using, so I don't know.)

We are supposed to be using it, but are not yet. Open bug :)

> Cheers,
> --
>   intrigeri
>   | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
>   | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

-- elly


signature.asc
Description: Digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[intrigeri]

Hi Jacob and Elly,

Thanks for your answers! See more questions bellow.

Jacob Appelbaum wrote (11 Apr 2013 06:56:18 GMT) :
> Basically - tlsdate in Tails would be a minor set of users compared to
> the much larger user base of ChromeOS.

Sure.

I doubt we can blend in this "anonymity" set, though: unless Tails
wants to forever copy the set of hosts ChromeOS queries (which I don't
think we would want to rely upon on the long run), then Tails' use of
tlsdate will probably be fingerprintable at least by the ISP if the
connections are made in the clear, so we probably would want to run
tlsdate over Tor anyway.

So, I'm now considering this (tlsdate over Tor) to replace our use of
htpdate, and not to replace our initial time guess based on the Tor
consensus [1].

[1] https://tails.boum.org/contribute/design/Time_syncing/#index3h1

> I'd like to settle on a list of hosts that it uses by default which may
> include a Google host or not. I haven't yet decided.

OK.

Jacob, are you interested in implementing something like our current
multiple pool -based approach [2], or something else with similar
security properties? If Tails wants to move to tlsdate some day,
I guess a prerequisite would be not to lose the nice security
properties this approach currently gives us.

[2] https://tails.boum.org/contribute/design/Time_syncing/#index4h2

Elly Fong-Jones wrote (08 Apr 2013 03:06:02 GMT) :
> The (slightly outdated now) time-sources design doc is here:
> 

Elly, is this design doc correct that tlsdate queries
clients3.google.com only in ChromeOS?

(Given you implemented the multi-host feature, I'd be surprised that
you don't use it, but I could not find what /etc/tlsdate/tlsdated.conf
ChromeOS is using, so I don't know.)

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

Maxim Kammerer:
> On Fri, Jul 20, 2012 at 3:07 AM, Jacob Appelbaum  wrote:
>> Allow me to be very explicit: it is harder to parse an HTTP Date header
>> than properly than casting a 32bit integer and flipping their order. The
>> attack surface is very small and easy to audit.
> 
> Just discovered that tlsdated in tlsdate-0.0.6 is dying with a
> segmentation fault after a while. Not surprised after seeing the code
> — my experimentation with this gimmick is finally over. Turns out that
> “throw something together and wait for patches” is not a sound
> development approach.
> 

tlsdated isn't tlsdate - it launches various helper programs. How is it
crashing?

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

Elly Jones:
> On Fri, Apr 12, 2013 at 02:43:13PM +0300, Maxim Kammerer wrote:
>> On Fri, Jul 20, 2012 at 3:07 AM, Jacob Appelbaum  wrote:
>>> Allow me to be very explicit: it is harder to parse an HTTP Date header
>>> than properly than casting a 32bit integer and flipping their order. The
>>> attack surface is very small and easy to audit.
>>
>> Just discovered that tlsdated in tlsdate-0.0.6 is dying with a
>> segmentation fault after a while. Not surprised after seeing the code
>> ? my experimentation with this gimmick is finally over. Turns out that
>> ?throw something together and wait for patches? is not a sound
>> development approach.
> 
> Did you get a stack trace?
> 

Not that I've seen - Maxim is often extremely harsh - don't take it
personally.

> Also, yes, tlsdated is not very well-written. I wrote it in a great hurry and
> now don't really have time to undo the worst of the hacks :(. Patches 
> gratefully
> accepted.

I haven't really touched it as I consider you to generally be the owner
of that part of the code. What specifically do you think we should re-write?

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Matthew Finkel]

I don't really understand your reservation about this project. It's reasonable
to want authenticated time to a non-webserver of ones choice. Depending on
your environment, tlsdate is complementary to the various other
programs. You can (and will) use whatever you decide fits your needs,
but please don't disparage a valid project because it segfaults "after a
while". It's a work-in-progress, better to contribute useful information
than complain.

On Fri, Apr 12, 2013 at 02:43:13PM +0300, Maxim Kammerer wrote:
> On Fri, Jul 20, 2012 at 3:07 AM, Jacob Appelbaum  wrote:
> > Allow me to be very explicit: it is harder to parse an HTTP Date header
> > than properly than casting a 32bit integer and flipping their order. The
> > attack surface is very small and easy to audit.
> 
> Just discovered that tlsdated in tlsdate-0.0.6 is dying with a
> segmentation fault after a while. Not surprised after seeing the code
> — my experimentation with this gimmick is finally over. Turns out that
> “throw something together and wait for patches” is not a sound
> development approach.
> 
> --
> Maxim Kammerer
> Liberté Linux: http://dee.su/liberte
> ___
> tor-talk mailing list
> tor-t...@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Elly Jones]

On Fri, Apr 12, 2013 at 02:43:13PM +0300, Maxim Kammerer wrote:
> On Fri, Jul 20, 2012 at 3:07 AM, Jacob Appelbaum  wrote:
> > Allow me to be very explicit: it is harder to parse an HTTP Date header
> > than properly than casting a 32bit integer and flipping their order. The
> > attack surface is very small and easy to audit.
> 
> Just discovered that tlsdated in tlsdate-0.0.6 is dying with a
> segmentation fault after a while. Not surprised after seeing the code
> ? my experimentation with this gimmick is finally over. Turns out that
> ?throw something together and wait for patches? is not a sound
> development approach.

Did you get a stack trace?

Also, yes, tlsdated is not very well-written. I wrote it in a great hurry and
now don't really have time to undo the worst of the hacks :(. Patches gratefully
accepted.

-- elly


signature.asc
Description: Digital signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Elly Jones]

On Fri, Apr 12, 2013 at 02:43:13PM +0300, Maxim Kammerer wrote:
> On Fri, Jul 20, 2012 at 3:07 AM, Jacob Appelbaum  wrote:
> > Allow me to be very explicit: it is harder to parse an HTTP Date header
> > than properly than casting a 32bit integer and flipping their order. The
> > attack surface is very small and easy to audit.
> 
> Just discovered that tlsdated in tlsdate-0.0.6 is dying with a
> segmentation fault after a while. Not surprised after seeing the code
> — my experimentation with this gimmick is finally over. Turns out that
> “throw something together and wait for patches” is not a sound
> development approach.

Did you get a stack trace?

Also, yes, tlsdated is not very well-written. I wrote it in a great hurry and
now don't really have time to undo the worst of the hacks :(. Patches gratefully
accepted.

-- elly 
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Maxim Kammerer]

On Fri, Jul 20, 2012 at 3:07 AM, Jacob Appelbaum  wrote:
> Allow me to be very explicit: it is harder to parse an HTTP Date header
> than properly than casting a 32bit integer and flipping their order. The
> attack surface is very small and easy to audit.

Just discovered that tlsdated in tlsdate-0.0.6 is dying with a
segmentation fault after a while. Not surprised after seeing the code
— my experimentation with this gimmick is finally over. Turns out that
“throw something together and wait for patches” is not a sound
development approach.

--
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] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

intrigeri:
> Hi,
> 
> Jacob Appelbaum wrote (19 Jul 2012 23:48:48 GMT) :
>> intrigeri:
>>> So, Jake tells me that ChromeOS will use tlsdate by default, and that
>>> this should solve the fingerprinting issue. Therefore, I assume this
>>> implicitly answer the (half-rhetorical, I admit) question I asked in
>>> March, and I assume there is indeed some fingerprinting issue. So, in
>>> the following I'll assume it's relatively easy, for a close network
>>> adversary (say, my ISP) to detect that I'm using tlsdate.
>>>
> 
>> It isn't shipping yet, so we'll see what happens.
> 
> I'm told ChromeOS ships it nowadays, so I'm excited at the idea to
> learn more about it, so that we can move forward a bit about the
> fingerprinting issue.

It does indeed - their network time document is here:

 
https://docs.google.com/a/chromium.org/document/d/1ylaCHabUIHoKRJQWhBxqQ5Vck270fX7XCWBdiJofHbU/edit

> 
> I was not able to find any authoritative information about how they
> run it. Their time sources [1] design doc is quite clearly outdated.
> Where can I find up-to-date information on this topic? I assume one of
> the dozens of Chromius Git repositories [2], but which one?
> 
> [1] http://www.chromium.org/developers/design-documents/time-sources
> [2] http://git.chromium.org/gitweb/
> 

Basically - tlsdate in Tails would be a minor set of users compared to
the much larger user base of ChromeOS.

I've also just updated the INSTALL file to document the different places
that git-master of tlsdate works:

  Debian Gnu/Linux 6.0.7
  Ubuntu 11.04, 12.04, 12.10
  CentOS 6.2, 6.3
  Fedora 17, 18
  RedHat Enterprise Server 6.4
  OpenSUSE 11.2, 12.3
  FreeBSD 10-CURRENT
  Mac OS X 10.8.2, 10.8.3
  ChromeOS 26.0.x.x, 27.0.x.x (tlsdate is part of the ChromeOS TCB!)

I'd like to settle on a list of hosts that it uses by default which may
include a Google host or not. I haven't yet decided.

All the best,
Jacob
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[intrigeri]

Hi,

Jacob Appelbaum wrote (19 Jul 2012 23:48:48 GMT) :
> intrigeri:
>> So, Jake tells me that ChromeOS will use tlsdate by default, and that
>> this should solve the fingerprinting issue. Therefore, I assume this
>> implicitly answer the (half-rhetorical, I admit) question I asked in
>> March, and I assume there is indeed some fingerprinting issue. So, in
>> the following I'll assume it's relatively easy, for a close network
>> adversary (say, my ISP) to detect that I'm using tlsdate.
>> 

> It isn't shipping yet, so we'll see what happens.

I'm told ChromeOS ships it nowadays, so I'm excited at the idea to
learn more about it, so that we can move forward a bit about the
fingerprinting issue.

I was not able to find any authoritative information about how they
run it. Their time sources [1] design doc is quite clearly outdated.
Where can I find up-to-date information on this topic? I assume one of
the dozens of Chromius Git repositories [2], but which one?

[1] http://www.chromium.org/developers/design-documents/time-sources
[2] http://git.chromium.org/gitweb/

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[adrelanos]

intrigeri:
> There are a few pieces of software called htpdate, and the one Tails
> uses only connects to HTTPS servers, and delegates to wget the X.509
> certificates validation:
> https://tails.boum.org/contribute/design/Time_syncing/#index3h2

Unfortunately wget (nor any other command line downloader) doesn't
support to pin the certificate of the website.
https://lists.gnu.org/archive/html/bug-wget/2012-07/msg7.html

So it still depend on the flawed root CA system.

(Don't take this too harsh. Although there is space for improvement I
seriously consider adding tails_htp to aos. Thanks to the distributed
trust model, I think it's currently the safest method.)

> In addition, the pal/foe/neutral pool system Tails uses gives *some*
> protection against untrustworthy sources of time information, which
> limits what one can do with only a few illegitimate X.509 certificates
> they got from a "trusted" CA:
> https://tails.boum.org/contribute/design/Time_syncing/#index4h2

If I understand correctly, you pick three random servers. One from each
pool. And then build the mediate of the three.

What's the point of asking the foe pool? (Servers which generally do not
care about privacy.)

Why doesn't tails_htp ask more than three servers for the time and build
the mediate? Like 6, 9 or 12.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[adrelanos]

intrigeri:
> Hi,
> 
> adrelanos wrote (18 Jul 2012 18:37:18 GMT) :
>> To make our life even worse... Sorry... But not using NTP and only
>> emmiting Tor traffic is also pretty clearly Tails. Because that puts
>> you in the group of users "Uses Tor, nothing else, but does not use
>> NTP? How many people act like this?". So you should at least emmit
>> a fake NTP query (when others that usuaally do) and drop it.
> 
> This is indeed true for a non-shared public IP, and is mitigated to
> some degree when sharing an IP (e.g. behind home router NAT,
> concurrently with others non-Tails systems).

Yes.

> Looks like we'll need to think a bit more what kind of fingerprinting
> resistance a system like Tails can reasonably pretend to at this scale.

Don't give up too early. Man ntpdate says there is "-q Query only -
don't set the clock.". That's perfect for a fake NTP query.

I just haven't found out how to tell ntpd to do the same. That is
required for a good fake.
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[intrigeri]

Hi,

Jacob Appelbaum wrote (19 Jul 2012 23:48:48 GMT) :
> The key difference with htpdate is that one has a cryptographic
> signature. I'll take a subset of possible MITM attackers over fully
> trusting something that anyone could MITM.

I think this is wrong in the context of Tails.

There are a few pieces of software called htpdate, and the one Tails
uses only connects to HTTPS servers, and delegates to wget the X.509
certificates validation:
https://tails.boum.org/contribute/design/Time_syncing/#index3h2

In addition, the pal/foe/neutral pool system Tails uses gives *some*
protection against untrustworthy sources of time information, which
limits what one can do with only a few illegitimate X.509 certificates
they got from a "trusted" CA:
https://tails.boum.org/contribute/design/Time_syncing/#index4h2

Thanks a lot for your detailed answer!
I'll think about the rest later.

Cheers,
-- 
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[intrigeri]

Hi,

adrelanos wrote (18 Jul 2012 18:37:18 GMT) :
> To make our life even worse... Sorry... But not using NTP and only
> emmiting Tor traffic is also pretty clearly Tails. Because that puts
> you in the group of users "Uses Tor, nothing else, but does not use
> NTP? How many people act like this?". So you should at least emmit
> a fake NTP query (when others that usuaally do) and drop it.

This is indeed true for a non-shared public IP, and is mitigated to
some degree when sharing an IP (e.g. behind home router NAT,
concurrently with others non-Tails systems).

Looks like we'll need to think a bit more what kind of fingerprinting
resistance a system like Tails can reasonably pretend to at this scale.

(I'm re-adding the Cc to tails-dev, that was lost at some point.
Please don't drop it again.)

Cheers!
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

Maxim Kammerer:
> On Wed, Jul 18, 2012 at 7:31 AM, intrigeri  wrote:
>> Thoughts?
> 
> After pondering about extending tlsdate for a while, I see no reason
> to use tlsdate instead of htpdate at the moment (or, possibly, ever).
> There is a difference between thinking of and experimenting with a
> gimmick, and using it as a replacement for a robust method of time
> setting.
> 

Huh, you think that setting your clock where *everyone* can *always*
MITM your time is somehow better? Fascinating!

> Motivation behind tlsdate is incorrect:
> 1. Extracting the HTTP Date: header is not a “nightmare” — it is easy,
> standards-compliant, and safe.

Allow me to be very explicit: it is harder to parse an HTTP Date header
than properly than casting a 32bit integer and flipping their order. The
attack surface is very small and easy to audit.

> If anything, TLS is much harder to get
> right (see issue #16 on GitHub, for instance — tlsdate is currently
> susceptible to a MITM attack).

It's a work in progress, of course. I use it with a pinned CA, so in
such a case, users are not vulnerable to a MITM attack unless one can
get certs from that specific CA.

With that said, I have a branch to add CN/SAN checking but it makes
little sense when one use case is pre-DNSSEC bootstrapping. Rarely do
certificates contain the IP address of the host, so what we care about
is an assertion of trust by a given authority. That use case would
suggest a pinned CA anyway, so perhaps it would make sense to just add a
few new options to tackle that use case.

I'm not totally sure but I think getting a CA signature for a specific
CA is harder than any CA. I agree that using it where it trusts *any* CA
allows *any* CA to assert things. That doesn't really change with CN/SAN
checking. Practically, it makes it harder for an attacker but
theoretically, we're still relying on the CA playing nice. Pinning
removes that gamble, which seems better all around.

> 2. The latency due to receiving HTTP headers is negligible when
> compared to the latency of a TLS handshake.

Do you have some data about that? The TLS ServerHello is generally the
first thing sent to the client. I'd expect the timing to be very similar

> 3. Nothing is gained by restricting the application layer to TLS — the
> reverse is true, since, e.g., using HTTP instead of HTTPS to reduce
> latency is not possible anymore.

Nothing? That seems a little... technically incorrect. Users gain a
cryptographic signature - which is the goal here - to use time to trust
signatures, we might want to start with signatures that don't require
time. That raises the bar against an attacker and with a pinned CA, it
means that the attacker has to own CA or find another vulnerability in
TLS itself.

Furthermore, in the TODO, I suggest that we should offer an option to
confirm the date by comparing it with HTTP over SSL/TLS - then we can at
least say that our HTTP date has some kind of integrity protection. The
goal isn't to have millisecond accurate clocks, it's to validate
cryptographic signatures that have hour or year long windows.

> 4. tlsdate either leaks local clock in ClientHello, or is not
> standards-compliant (currently, it leaks the local clock); the user
> cannot disable TLS to avoid that.

Yes, another known issue - so does Tor - what's your point? It's turtles
all the way down, right?

I'll gladly add an option to break the standard, if a user wishes to use it.

> 
> Additionally, tlsdate lacks important features:
> 6. It cannot run as a daemon with clock skewing and hosts rotation.

That isn't the goal of tlsdate but it is something that could be easily
added. Support for a list of hosts would be a fine addition, I'm not
sure that a daemon mode makes a lot of sense. With the accuracy levels
we're discussing, an hourly cronjob would be fine as well.

> 7. There is no explicit proxy support.
> 

It appears to work fine with `usewithtor` but I'd gladly take a
SOCKS4a/SOCKS5 patch.

> Once / if these features are implemented, tlsdate will only provide
> part of the functionality of htpdate (since TLS is forced), and will
> not have any advantages over it (perhaps besides the possibility of
> using non-HTTP(S) servers).

Are you one of the authors of htpdate or something? :-)

I'll gladly mirror the functionality of htpdate but the primary goal is
to solve a few problems that htpdate does not aim to solve. I think
these two tools are complementary but with very different goals -
htpdate is like rdate without any kind of security properties and
tlsdate is like rdate with the possibility of some security properties.

Lots of work to be done, of course.

> 
> I also wonder whether Chrome OS's usage of tlsdate is confirmed by
> Google, or this information comes from a single pull request on
> GitHub. In any case, I suspect that Chrome OS developers did not
> properly explore the available time setting options.
> 

I've emailed with them, so no, it's not just a github pull request.

However, I assu

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Jacob Appelbaum]

Hey hey,

intrigeri:
> Hi,
> 
> intrigeri wrote (25 Mar 2012 23:02:55 GMT) :
>> Jacob Appelbaum wrote (20 Feb 2012 20:30:08 GMT) :
>>> For a while I've been interested in secure network time that would
>>> be useful for Tor users. Tor users generally need accuracy to the
>>> hour in the local system clock.
> 
>> Thank you for tackling this problem.
> 
> ... and thank you for going on with it!
> 
>>> As a result, I've also written another tool, tlsdate[1], that
>>> I regularly use for setting my own clock.
> 
>> What network fingerprint does tlsdate currently display if I run it
>> in the clear, without forwarding its traffic through Tor?
> 
> Jake asked me to have another look at tlsdate, which was uploaded to
> Debian, so here it goes :)
> 
> (It's pretty clear I lack much of the background and intended usecase,
> so please correct whatever is wrong in what follows!)
> 
> So, Jake tells me that ChromeOS will use tlsdate by default, and that
> this should solve the fingerprinting issue. Therefore, I assume this
> implicitly answer the (half-rhetorical, I admit) question I asked in
> March, and I assume there is indeed some fingerprinting issue. So, in
> the following I'll assume it's relatively easy, for a close network
> adversary (say, my ISP) to detect that I'm using tlsdate.
> 

It isn't shipping yet, so we'll see what happens.

>>From what I remember from our past attempts to discuss this on IRC,
> I assume the intended usecase for Tails is to run tlsdate in the clear
> (that is, without going through Tor) so that the clock is set before
> Tor is started.

There are a few use cases - the first is to use it with the -t option -
this at least will skip the clock forward to a recent build time. So if
previously, the clock was in 1970, you're at least now in the same
decade as the tails release. Probably the same year and likely, with a
few releases a year, the same month. That has no network access at all.

The next use case is to use it over Tor - I haven't added direct proxy
support yet but I'll do so when it becomes a blocking issue. As it
stands now, you can easily just `usewithtor tlsdate` and it will work
fine. This gives you the ability to securely set your clock over Tor.

Another use case is to fire it up against any SSL/TLS enabled server,
including the Tor relay you were going to use anyway, and attempt to use
it as a time source. If you use a Tor relay, tlsdate currently lacks a
way to verify the key for that relay - so it's a leap of faith, rather
than a leap of cryptographic something or other. But at the very least,
you no longer need to involve any third party that you weren't already
going to connect to - it isn't more secure, it's just a cute hack.

The most common way for me to use tlsdate is to connect to a popular TLS
server and if I trust the CA, which can be pinned to a *single* CA that
isn't part of the traditional cartel, I can easily trust it. Generally,
I find that this works fine.

> 
> If so, from the PoV of a close network adversary, if Tails starts to
> use tlsdate in the clear, as a Tails user, then I'm part of the set of
> people who run tlsdate and start Tor soon after, and in the current
> state of things, this set would almost exactly match the set of
> Tails users.
> 

That might be true - that's a good reason to add Tor tls fingerprint
verification to tlsdate - however, I'd take this fingerprinting risk
over a older consensus or Tor simply not working at all.

> The fact that ChromeOS uses tlsdate forces this kind of adversaries to
> detect "tlsdate followed by Tor", instead of merely detecting tlsdate
> alone, in order to detect Tails users. (Looks like we have to convince
> Google to run Tor by default on ChromeOS? :)
> 

Tor has been ported to ChromeOS as far as I know - I have talked with
them about adding a guest mode that uses Tor.

> Therefore, I'm not convinced tlsdate in the clear would be any better,
> on the fingerprinting side of things, than the "htpdate in the clear"
> system we eventually managed to escape in Tails 0.9 and later.
> Which means it looks quite worse, fingerprinting-wise, than what we
> currently ship.
> 

The key difference with htpdate is that one has a cryptographic
signature. I'll take a subset of possible MITM attackers over fully
trusting something that anyone could MITM.

Furthermore, I think that you're making a trade-off between
fingerprinting on the network, which Tor does not even try to address by
default, and the ability for someone to try to use Tor with an incorrect
clock, something that explicitly doesn't work in the Tor design.

In an ideal world, Tor will learn the clock anonymously and not care
about the system time. We're not there yet; patches are always welcome!

> Thoughts?
> 
> (Seriously, please prove me wrong, my life would be easier as
> a result :)
> 

I generally think that shipping tlsdate makes sense, especially if Tor
is already running as you can then keep clocks securely in sync. It may
not make sense for

Re: [Tails-dev] [tor-talk] secure and simple network time (hack)

[Maxim Kammerer]

On Wed, Jul 18, 2012 at 7:31 AM, intrigeri  wrote:
> Thoughts?

After pondering about extending tlsdate for a while, I see no reason
to use tlsdate instead of htpdate at the moment (or, possibly, ever).
There is a difference between thinking of and experimenting with a
gimmick, and using it as a replacement for a robust method of time
setting.

Motivation behind tlsdate is incorrect:
1. Extracting the HTTP Date: header is not a “nightmare” — it is easy,
standards-compliant, and safe. If anything, TLS is much harder to get
right (see issue #16 on GitHub, for instance — tlsdate is currently
susceptible to a MITM attack).
2. The latency due to receiving HTTP headers is negligible when
compared to the latency of a TLS handshake.
3. Nothing is gained by restricting the application layer to TLS — the
reverse is true, since, e.g., using HTTP instead of HTTPS to reduce
latency is not possible anymore.
4. tlsdate either leaks local clock in ClientHello, or is not
standards-compliant (currently, it leaks the local clock); the user
cannot disable TLS to avoid that.

Additionally, tlsdate lacks important features:
6. It cannot run as a daemon with clock skewing and hosts rotation.
7. There is no explicit proxy support.

Once / if these features are implemented, tlsdate will only provide
part of the functionality of htpdate (since TLS is forced), and will
not have any advantages over it (perhaps besides the possibility of
using non-HTTP(S) servers).

I also wonder whether Chrome OS's usage of tlsdate is confirmed by
Google, or this information comes from a single pull request on
GitHub. In any case, I suspect that Chrome OS developers did not
properly explore the available time setting options.

-- 
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] [tor-talk] secure and simple network time (hack)

[intrigeri]

Hi,

intrigeri wrote (25 Mar 2012 23:02:55 GMT) :
> Jacob Appelbaum wrote (20 Feb 2012 20:30:08 GMT) :
>> For a while I've been interested in secure network time that would
>> be useful for Tor users. Tor users generally need accuracy to the
>> hour in the local system clock.

> Thank you for tackling this problem.

... and thank you for going on with it!

>> As a result, I've also written another tool, tlsdate[1], that
>> I regularly use for setting my own clock.

> What network fingerprint does tlsdate currently display if I run it
> in the clear, without forwarding its traffic through Tor?

Jake asked me to have another look at tlsdate, which was uploaded to
Debian, so here it goes :)

(It's pretty clear I lack much of the background and intended usecase,
so please correct whatever is wrong in what follows!)

So, Jake tells me that ChromeOS will use tlsdate by default, and that
this should solve the fingerprinting issue. Therefore, I assume this
implicitly answer the (half-rhetorical, I admit) question I asked in
March, and I assume there is indeed some fingerprinting issue. So, in
the following I'll assume it's relatively easy, for a close network
adversary (say, my ISP) to detect that I'm using tlsdate.

>From what I remember from our past attempts to discuss this on IRC,
I assume the intended usecase for Tails is to run tlsdate in the clear
(that is, without going through Tor) so that the clock is set before
Tor is started.

If so, from the PoV of a close network adversary, if Tails starts to
use tlsdate in the clear, as a Tails user, then I'm part of the set of
people who run tlsdate and start Tor soon after, and in the current
state of things, this set would almost exactly match the set of
Tails users.

The fact that ChromeOS uses tlsdate forces this kind of adversaries to
detect "tlsdate followed by Tor", instead of merely detecting tlsdate
alone, in order to detect Tails users. (Looks like we have to convince
Google to run Tor by default on ChromeOS? :)

Therefore, I'm not convinced tlsdate in the clear would be any better,
on the fingerprinting side of things, than the "htpdate in the clear"
system we eventually managed to escape in Tails 0.9 and later.
Which means it looks quite worse, fingerprinting-wise, than what we
currently ship.

Thoughts?

(Seriously, please prove me wrong, my life would be easier as
a result :)

Cheers,
--
  intrigeri
  | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
  | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev