• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Killing Browser Fingerprinting

Murph

Well-Known Member

Thanks: 174
Messages: 297

I won't argue with the term security in first line. It is more a concern of privacy (which can have an impact on security also).
When there is the point reached that leaking the used OS could have negative effects (i.e. tailored attacks), argumentation with performance does not matter anymore.
You should assume that the tailored attacks will occur regardless of any precautions, as to do otherwise is security through obscurity. The state of the black art seems to routinely include anything and everything. If a tailored attack would be a problem for your system, it should not be on the net, not even briefly.

While I may have stopped publishing HINFO records in DNS rather a long time ago, I do not believe that knowledge of the OS should be considered to be a security problem in the current era. You should assume that the attacker does know precisely what OS you are running, and defend accordingly.
 

surv

New Member

Thanks: 7
Messages: 9

The window scale and timestamp options exist to improve TCP's performance and reliability. Read RFC 7323 for descriptions of the circumstances where window scaling and timestamps are beneficial. They are no less relevant for desktop systems. In the current era, desktop systems certainly can have the bandwidth to benefit from those features, combined with lower quality connectivity which can see round trip times rise under load. Selective ACKs improve performance and recovery from loss.

You gain no additional security by crippling your TCP stack in that manner. Those options are long established and do not have any negative impact on security. In a narrow set of circumstances, disabling those options is harmful to data integrity (high bandwidth combined with packet retransmission). Degrading the integrity of a protocol which software assumes to be reliable could be considered to weaken security.
Too categorical. I did not see anything dangerous. In https://wiki.freebsd.org/SystemTuning is about the benefits for gigabit satellite links. I have only 20Mbit DSL
 

surv

New Member

Thanks: 7
Messages: 9

By the way, from the same (RFC 7323):
"A naive implementation that derives the timestamp clock value directly from a system uptime clock may unintentionally leak this information to an attacker. This does not directly compromise any of the mechanisms described in this document. However, this may be valuable information to a potential attacker. It is therefore RECOMMENDED to generate a random, per-connection offset to be used with the clock source when generating the Timestamps option value"
As far as I understand FreeBSD does not use random per-connection offset?
 

Murph

Well-Known Member

Thanks: 174
Messages: 297

Too categorical. I did not see anything dangerous. In https://wiki.freebsd.org/SystemTuning is about the benefits for gigabit satellite links. I have only 20Mbit DSL
Window scale solves performance issues on links as slow as a T1 (1.5Mbit/s), when you encounter larger round trip times. You will certainly suffer from performance problems caused by disabling it on a 20Mbit/s link. For 100ms round trip times (e.g. typical transatlantic, coast to coast in the US, or longer European distances), TCP is limited to around 5Mbit/s without window scaling. Add in the typical 25-50ms that you can see from a DSL local link, and the problem only gets worse. A 64KB window hits its performance limit at around 25ms on a 20Mbit/s link, which pretty much makes it impossible to hit 20Mbit/s performance on a DSL without window scaling, and the problem will get significantly worse as the distance beyond the DSL link increases.

TCP window scaling has been an essential performance feature for a very long time. It was released as a standard back in 1992 (as RFC 1323, although had been experimentally around prior to then), and it has only become more important as the years passed. TCP itself is a very old protocol and hits some significant limitations on modern networks if you do not use a properly modernised implementation. Disabling the standard extensions turns it back into a 1980s protocol, when 1.5Mbit/s was a fast WAN link.

As far as gigabit links go, it can be needed on a gigabit LAN, never mind a satellite link.