Re: TCP timestamp starting value

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Thu, Jul 21, 2016 at 01:45:16PM +0200, Edgar Fuß wrote:
> JS> Wouldn't a better idea be to compute HASH(cookie,src,dst) + uptime for
> JS> some random cookie created at boot time? Essentially, you give each
> JS> target a unique monotonic time base, without leaking any data about the
> JS> perceived local time.
> EF> I thought about something like that, but then the peer would be able to 
> EF> tell when you booted (because the timebase changed). The elegance (or so 
> EF> I think) of using real time is that the peer can't tell a reboot from an 
> EF> intermediate network failure.  On the other hand, what's so bad about 
> EF> "leaking" information on my perception of UTC time?
> JS> You are assuming a clock is synchronised. It may or may not be.
> If it isn't, then its just a random offset, no? What's the problem with that
> compared to a fixed offset (1)?

A lot of protocols use the currennt time for various reasons. Knowing
the exact value might be a useful property for some attack vector.
That's why an unmasked time leak without good reason is not a good idea.
It is completely unnecessary in this context either.

> JS> Given that ntpdate is often run on boot as well, there are lots of 
> JS> environments where leaking the real time can be useful or where a reboot 
> JS> is just as visible.
> I don't get that. Could you re-phrase that (in german, if you prefer)?
> 
> Of course a reboot may be visible without inspecting TCP timestamps, but what 
> exactly is the concern (or are the concerns) of people objecting to using the 
> uptime for them?

ntpdate is often run on boot. That will often produce a trivally measurable
time difference. That means even using the "UTC" clock has visible skews
in it.

> JS> The cookie can be updated automatically every couple of hours.
> I'm afraid that could upset peers that get upset by timestamps jumping 
> backwards. Yes, they also jumps backwards if Linux crashes, but real word 
> boxes are probably more accomodated to this than to some (sensible) behaviour 
> of a niche OS like NetBSD.
> An attacker could also deduce from the offset changing just after an attack 
> that he crashed the machine.

While I can understand the desire the somewhat correlate the timestamps
of different connections on a short term time frame, any network stack 
that depends on them to remain stable over a long time is IMO plainly 
broken. Automatic reseeding for a time frame > 10min seems to be 
perfectly reasonable behavior. It's not about a niche OS, I even
question the validity of that argument. There is no standard
justification for the expectation here.

There are enough ways to easy tell a machine crashed that a changing
offset is hardly necessary.

> JS> The other issue remaining is that the real time is not monotonic.
> Err, what? MICROTIME(9) states "The system realtime clock is guaranteed to be 
> monotonically increasing at all times.  As such, all calls to these functions 
> are guaranteed to return a system time greater than or equal to the system 
> time returned in any previous calls".

Continue reading...