I am usually 100% in agreement with your arguments and explanations but

Microsoft not enabling this RFC by default due to security concerns of TimeStamps does not explain why Microsoft Windows Will enable Timestamps
if asked to by the originator of the Link??

So any Linux user accessing a Microsoft Server would likely be using TimeStamps.

Although I do agree the majority of cases would be Windows accessing Windows.

I am usually 100% in agreement with your arguments and explanations but

Microsoft not enabling this RFC by default due to security concerns of TimeStamps does not explain why Microsoft Windows Will enable Timestamps
if asked to by the originator of the Link??

So any Linux user accessing a Microsoft Server would likely be using TimeStamps.

Although I do agree the majority of cases would be Windows accessing Windows.

The default configuration is to use timestamps or scaling if the other end initiates a connection, but not when initiating a connection.
Changing it to 3 forces the options to be used all the time.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

... Mac and Linux has it default you said, right?

Not every network administrator, and not everyone with responsibility for a secure server, thinks that RFC1323 is universally a good thing: see http://www.forensicswiki.org/wiki/TCP_timestamps.

Would you like your bank's IT manager to reveal their security status on the web? ...

?

OK... So uptime is an indicator of "security status"?!

In the Linux world, apart from kernel updates, no reboot is needed so you can have continuous uptime for as long as the hardware and continuous power allow. (There's also kexec so that you can even swap kernels on a live system with no reboot at all!...) So no reliable clue there about what updates may or may not have been applied.

RFC1323 has been around for a very long time. I can't help but think that any real security concerns or exploits would have been covered by now.

In any case for the Windows defaults, the uptime can be still determined by just firing off a few spoofed packets with timestamps. Or even just add timestamps to a legitimate packet stream from a man-in-the-middle (or proxy) attack...


So, is there any negative performance penalty other than the overhead of a few extra bits in the data packets?

Anything definite for the reasoning behind the Microsoft Windows approach?

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

O.K. I admit I am scared of thinking of running the Optimiser, as I do not know what I am doing, is there an idiots guide of how to do it as I keep on getting http errors mainly on my AP's and they take about 2 hours running time to download. Thank you in advance if there is one

---

O.K. I admit I am scared of thinking of running the Optimiser, as I do not know what I am doing, is there an idiots guide of how to do it as I keep on getting http errors mainly on my AP's and they take about 2 hours running time to download. Thank you in advance if there is one

In the very First Post are good instructions...Follow them closely.

---

I Desire Peace and Justice, Jim Scott (Mod-Ret.)

O.K. I admit I am scared of thinking of running the Optimiser, as I do not know what I am doing, is there an idiots guide of how to do it as I keep on getting http errors mainly on my AP's and they take about 2 hours running time to download. Thank you in advance if there is one

From Richard H

"Open a command prompt as administrator,

REG ADD "HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters" /v "Tcp1323Opts" /t REG_DWORD /d 3 /f

Exit the command pronpt.

And make sure to reboot afterwards."

---

Grant
Darwin NT

Do I use the TCP or how to I do a command prompt?

---

Do I use the TCP or how to I do a command prompt?

Personally, I'd recommend the command prompt route.

You have two computers - one Windows XP, the other Windows 7. These steps will work on both, but note there is one extra instruction for Windows 7.

1) Open a command prompt:
Click on the Start button
Click 'All Programs'
Scroll down (if needed) to the 'Accessories' group, and click it.
'Command Prompt' should be visible...
On the Windows 7 machine, right-click on Command Prompt and select 'Run as administrator' - click 'Yes' for user account control. On the XP machine, just click the Command Prompt as normal.
You'll get what's often described as a black box on screen.

2) Run the command:
This is the text you need. Don't even attempt to type it: highlight it all here with your mouse, right click it, and choose 'Copy'.

REG ADD "HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters" /v "Tcp1323Opts" /t REG_DWORD /d 3 /f

Go back to the black box. Click on the miniature black box in the extreme top-left corner (the one with C:\... just visible in tiny print)
A menu should appear: go down to 'Edit' and select 'Paste'.
Press 'Enter' or the return key.
You should see "The operation completed successfully". That's all you need.
Close the command prompt window (the black box) with the corner 'X', or by typing 'exit'.

Restart you computer whenever it's convenient. You should see fewer downloads backing off and waiting to retry - though this isn't a total protection against all problems, and won't make any difference to the download speed while the transfers are actually running.

Let us know how you got on, and how easy it was to follow the instructions - they're a dummy run for the sticky I still intend to write.

Can someone tell me more about the security issue with timestamps?

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

Having trouble getting the administrator it will not allow be, all I get if I then post it is Access is denied

---

My XP machine no problem it allowed me to do it yet my Windows 7 I am classified as an Administrator but will not allow me to do it

---

Having trouble getting the administrator it will not allow be, all I get if I then post it is Access is denied

When you open the command window, what is the final line displayed?

If I open it normally, mine says

C:\Users\Richard Haselgrove>_

Even though I'm an administrator for the computer, that still isn't enough: you still need to do that right-click and 'Run as administrator', and click 'yes' in the UAC dialog, to get full administrator (super-user) rights.

If you negotiate that, the last line in the command window should be

C:\Windows\system32>_

(and yes, I'm reading that from a 64-bit Windows 7 computer)

I seem not to be able to click on run as admin I have a shield to the right my first line is my name I cannot seem to get the UAC dialog box up so there is no last line

---

Is it disabled?
You should be able to click this option anyway unless its shown grayed...
The shield is just an icon to show that this option will use elevated rights.

---

just cannot seem to click on it

---

just cannot seem to click on it

It should look something like this?



Edit - you click with the right mouse button to get that menu of options, then click with the normal button on the words 'Run as administrator'.

That is what I get but nothing happens when I click on it no User thing so I will probably wait until my brother comes down, he has a software degree and will see how to fix it Thanks

---

Can someone tell me more about the security issue with timestamps?

Sorry, parked this in the rush, and never came back to it.

In a word, no. As with many subjects on the internet, when you search for it, you find vastly more pananoid or ignorant questions than you find answers. I don't pretend that my original comment was rigorous, or even necessarily accurate - I was just attempting to provide some counter-examples, to suggest that reporting RFC1323 to Microsoft as if the non-default implementation was a bug was perhaps wide of the mark.

The security implication I'd picked up in my reading/research was that some *server operators* - i.e. nothing of what follows is of any concern to home users - were worried that 'black hats' could deduce from the time stamps on TCP packets how long it had been since the server was last rebooted, or even how long since security patches had been applied. If attackers knew or could deduce that a particular security patch was missing, they might be able to use the exploit the patch was designed to block, and get into the server that way.

Apart from not applying to us (if anyone should worry, it's the boyz in the lab), further thinking and reading suggests to me that the theory is bullshit. It seems to rely on there being some connection between 'timestamps' in the RFC1323/TCP sense, and timestamps like your works clocking-in and clocking-out card - in other words, wall-clock time.

If you read s4.2.2 Timestamp Clock on page 19-20 of http://www.ietf.org/rfc/rfc1323.txt, you'll see that no such correlation is required or even implied. A TCP timestamp is simply a number, which steadily increases. It has no particular starting point, and no particular rate of increase. They do suggest it should increase neither 'too fast' nor 'too slow' - but say 'the maximum acceptable clock frequency is one tick every 59 nanoseconds'. The 'goldilocks' speed (they seem to imply, writing 20 years ago) is a clock which ticks about once every millisecond: at that speed, the numbers are recycled and cease to have any meaning every 24.8 days.

Overall, I'm sure there are better ways of hacking into a server - like bribing the cleaners to collect any post-it notes with passwords written on them.

Richard,

Thanks for a good answer. So more a case of paranoia over substance. Pre-Linux-2.1 is an awful long time ago for the defaults (timestamps on) not to have been very thoroughly tested by the big bad world!

Which still leaves the question of why timestamps available but defaulted to off for Windows. I can't believe it's any concern for the small overhead vs benefit. To be worried about deducing uptime seems overly paranoid. Curious...


Happy fun crunchin',

Regards,
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

A follow on question:

I switched back to running BOINC 6.10.60 because 1) my downloads were hanging which 2) kicked in the ridiculously long project backoff times in BOINC 7.X.X. The hangups have been largely eliminated by adopting the TCP fix. My transfer rates are glacial, but downloads are now consistent. For those of you running the newer BOINC Windows versions, does the TCP fix help with your backoff situation?

---

Join the PACK!