On 9/3/19 4:45 PM, David Miller wrote:
> At least our problematic code, unlike your patch, compiles.
I obviously compiled and tested the code before sending along and this should be
easy to understand. Even I published the results in the link that I mentioned in
the initial message. Now I'm not s
On 9/3/19 10:17 AM, Eric Dumazet wrote:
> Do you have a real program showing us how this clock skew can be used
> practically ?
This is a well studied issue. You can take a look at this presentation as an
example:
http://caia.swin.edu.au/talks/CAIA-TALK-080728A.pdf
> You will have to convince
On 9/3/19 9:59 AM, Eric Dumazet wrote:
> You could add a random delay to all SYN packets, if you believe your host has
> clock skews.
And by the way adding delays has its own performance penalties.
On 9/3/19 9:59 AM, Eric Dumazet wrote:
>
> You could add a random delay to all SYN packets, if you believe your host has
> clock skews.
In theory yes, but again do you know any practical example with tested
applications and the list of the rules? I'm interested to see an actual example
that s
On 9/3/19 1:41 AM, Eric Dumazet wrote:
> Clock skew seems quite secondary. Some firewall rules should prevent this
> kind of attacks ?
Can you provide any reference to somewhere that explains these firewall rules
and how to exactly use them to prevent this specific type of attack?
This patch addresses the privacy issue of TCP ISN generation in Linux
kernel. Currently an adversary can deanonymize a user behind an anonymity
network by inducing a load pattern on the target machine and correlating
its clock skew with the pattern. Since the kernel adds a clock-based
counter to ge
This patch addresses the privacy issue of TCP ISN generation in Linux
kernel. Currently an adversary can deanonymize a user behind an anonymity
network by inducing a load pattern on the target machine and correlating
its clock skew with the pattern. Since the kernel adds a clock-based
counter to ge
