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
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
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
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.
On 19 August 2014 21:36, Alexander Holler hol...@ahsoftware.de 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
Am 20.08.2014 10:24, schrieb Hagen Paul Pfeifer:
On 19 August 2014 21:36, Alexander Holler hol...@ahsoftware.de 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
On 20 August 2014 11:07, Alexander Holler hol...@ahsoftware.de 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
Am 20.08.2014 11:28, schrieb Hagen Paul Pfeifer:
On 20 August 2014 11:07, Alexander Holler hol...@ahsoftware.de 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
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 hol...@ahsoftware.de 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
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 ?
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
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
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
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
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
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
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
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
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 would
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 this
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 ensure
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
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 hole. It
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 some
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, 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 forward
> ... 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
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
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
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
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,
From: Christian Grothoff groth...@in.tum.de
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
On 12/11/2013 09:01 PM, David Miller wrote:
From: Christian Grothoff groth...@in.tum.de
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
On Wed, 11 Dec 2013 21:19:00 +0100
Christian Grothoff groth...@in.tum.de wrote:
On 12/11/2013 09:01 PM, David Miller wrote:
From: Christian Grothoff groth...@in.tum.de
Date: Tue, 10 Dec 2013 19:35:36 +0100
Only NAT implementations that change the SQN are not supported
(those should be
On 12/11/2013 09:26 PM, Stephen Hemminger wrote:
On Wed, 11 Dec 2013 21:19:00 +0100
Christian Grothoff groth...@in.tum.de wrote:
On 12/11/2013 09:01 PM, David Miller wrote:
From: Christian Grothoff groth...@in.tum.de
Date: Tue, 10 Dec 2013 19:35:36 +0100
Only NAT implementations that
Stephen Hemminger step...@networkplumber.org 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:
On 12/11/2013 10:25 PM, Andi Kleen wrote:
Stephen Hemminger step...@networkplumber.org 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
... 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 from
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
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
44 matches
Mail list logo
