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
From: Cyrus Sh
Date: Tue, 3 Sep 2019 10:27:41 -0600
> It's up to you whether to want to keep using a problematic code that
> may endanger users or want to do something about it since we won't
> insist on having a patch accepted.
At least our problematic code, unlike your patch, compiles.
From: Cyrus Sh
Date: Tue, 3 Sep 2019 10:06:03 -0600
> 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 lis
On 9/3/19 6:27 PM, Cyrus Sh wrote:
>
>
> 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/tal
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 6:06 PM, Cyrus Sh wrote:
>
>
> 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 ru
On 9/3/19 6:12 PM, Cyrus Sh wrote:
>
>
> 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.
>
You understand your patch has been reje
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 5:39 PM, Cyrus Sh wrote:
>
>
> 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
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?
Hi Cyrus,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc7 next-20190902]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Cyru
On 9/3/19 7:06 AM, Cyrus Sh wrote:
> 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. Sin
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
14 matches
Mail list logo
