Am 20.08.2014 11:47, schrieb Alexander Holler:
Am 20.08.2014 11:28, schrieb Hagen Paul Pfeifer:
On 20 August 2014 11:07, Alexander Holler wrote:
For sure it could be better, but I'm already happy with the current
imperfect solution which I can use now and not some perfect solution
which
might
Am 20.08.2014 11:28, schrieb Hagen Paul Pfeifer:
On 20 August 2014 11:07, Alexander Holler wrote:
For sure it could be better, but I'm already happy with the current
imperfect solution which I can use now and not some perfect solution which
might be available in some years.
Alexander, to mak
On 20 August 2014 11:07, Alexander Holler wrote:
> For sure it could be better, but I'm already happy with the current
> imperfect solution which I can use now and not some perfect solution which
> might be available in some years.
Alexander, to make it clear: we cannot include mechanisms which
Am 20.08.2014 10:24, schrieb Hagen Paul Pfeifer:
On 19 August 2014 21:36, Alexander Holler wrote:
It doesn't have to work in every environment and it doesn't have to solve
all existing problems in the world. ;)
But it enables people to protect a bit more against malicious people or
government
On 19 August 2014 21:36, Alexander Holler wrote:
> It doesn't have to work in every environment and it doesn't have to solve
> all existing problems in the world. ;)
>
> But it enables people to protect a bit more against malicious people or
> governments.
>
> And it is really very easy to use. I
Am 12.12.2013 15:34, schrieb Eric Dumazet:
A bit late, but I've just stumbled over that feature which I do like a lot.
Very soon you'll need to support different secrets. You do not want all
clients share a common secret, do you ? How can a server change its
secret without disrupting clients ?
On Thu, Dec 12, 2013 at 04:46:37PM +0100, Hannes Frederic Sowa wrote:
> On Thu, Dec 12, 2013 at 06:34:24AM -0800, Eric Dumazet wrote:
> > With various proposals (like TCP minion), maybe its time to be able to
> > implement part of TCP stack in user land (Keep the mux inside the
> > kernel, and forw
On Thu, Dec 12, 2013 at 06:34:24AM -0800, Eric Dumazet wrote:
> With various proposals (like TCP minion), maybe its time to be able to
> implement part of TCP stack in user land (Keep the mux inside the
> kernel, and forward raw incoming packets to user land where all the
> crazy things can be done
On Thu, 2013-12-12 at 16:07 +0100, Christian Grothoff wrote:
> I'm already having fun with IETF and pTLDs right now, one war at a time
> ;-). I also figured it might be easier to have a reasonable working
> reference implementation first and then standardize. After all, with my
> recent draft so
On 12/12/2013 03:34 PM, Eric Dumazet wrote:
> On Thu, 2013-12-12 at 12:43 +0100, Christian Grothoff wrote:
>> On 12/12/2013 11:19 AM, Jacob Appelbaum wrote:
>>> I think that generally, I would prefer if the code didn't use MD5 but
>>> otherwise, I don't see any real risk of adding an exploitable ho
On Thu, 2013-12-12 at 12:43 +0100, Christian Grothoff wrote:
> On 12/12/2013 11:19 AM, Jacob Appelbaum wrote:
> > I think that generally, I would prefer if the code didn't use MD5 but
> > otherwise, I don't see any real risk of adding an exploitable hole. It
> > seems silly to disable it by default
Christian Grothoff:
> On 12/12/2013 11:19 AM, Jacob Appelbaum wrote:
>> I think that generally, I would prefer if the code didn't use MD5 but
>> otherwise, I don't see any real risk of adding an exploitable hole. It
>> seems silly to disable it by default though - ideally, I'd like a sysctl
>> to e
On 12/12/2013 11:19 AM, Jacob Appelbaum wrote:
> I think that generally, I would prefer if the code didn't use MD5 but
> otherwise, I don't see any real risk of adding an exploitable hole. It
> seems silly to disable it by default though - ideally, I'd like a sysctl
> to ensure that Tor could use t
Andi Kleen:
>> ... and then do the same for the first TCP packet with payload? And you
>
> That gets passed through by the firewall rule.
>
As an application developer, I find it very common for our users to have
difficulty synchronizing userspace program needs and firewall rules.
This option wou
> ... and then do the same for the first TCP packet with payload? And you
That gets passed through by the firewall rule.
> seriously would consider that "safer" or "less error prone", starting
Yes the risk of adding exploitable holes to the kernel is signficantly
lower.
-Andi
--
To unsubscribe
On 12/11/2013 10:25 PM, Andi Kleen wrote:
> Stephen Hemminger writes:
>>
>> The point is that doing it outside of TCP core is safer, less error prone
>> and more flexible.
>
> Or to put the question differently: what hooks would be needed to make
> this efficiently work in user space?
>
> It cou
Stephen Hemminger writes:
>
> The point is that doing it outside of TCP core is safer, less error prone
> and more flexible.
Or to put the question differently: what hooks would be needed to make
this efficiently work in user space?
It could be something like this: Firewall the port with forward
On 12/11/2013 09:26 PM, Stephen Hemminger wrote:
> On Wed, 11 Dec 2013 21:19:00 +0100
> Christian Grothoff wrote:
>
>> On 12/11/2013 09:01 PM, David Miller wrote:
>>> From: Christian Grothoff
>>> Date: Tue, 10 Dec 2013 19:35:36 +0100
>>>
Only NAT implementations that change the SQN are not
On Wed, 11 Dec 2013 21:19:00 +0100
Christian Grothoff wrote:
> On 12/11/2013 09:01 PM, David Miller wrote:
> > From: Christian Grothoff
> > Date: Tue, 10 Dec 2013 19:35:36 +0100
> >
> >> Only NAT implementations that change the SQN are not supported
> >> (those should be rare, but we have no ha
On 12/11/2013 09:01 PM, David Miller wrote:
> From: Christian Grothoff
> Date: Tue, 10 Dec 2013 19:35:36 +0100
>
>> Only NAT implementations that change the SQN are not supported
>> (those should be rare, but we have no hard data on this).
>
> Even Linux's netfilter can and does do this, it is a
From: Christian Grothoff
Date: Tue, 10 Dec 2013 19:35:36 +0100
> Only NAT implementations that change the SQN are not supported
> (those should be rare, but we have no hard data on this).
Even Linux's netfilter can and does do this, it is absolutely necessary
for tracking SIP and FTP protocols,
Hi!
We've written a patch to add support for a modern variant of silent TCP
port knocking to Linux, and hope to convince you to include it in the
kernel by default.
The motivation is simple: given security services that stockpile
undisclosed exploits, running TCP services on a visible port is ask
22 matches
Mail list logo
