Re: Shadow TCP stacks

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Joachim Schipper-2
<moved to misc@; it's still not on-topic, but this message may be
somewhat interesting>

On Fri, Oct 10, 2014 at 07:31:50PM -0400, Ian Grant wrote:
> I want to try to implement some form of concealed port knocking in
> OpenBSD, along the lines of Martin Kirsch:
>
>     https://gnunet.org/sites/default/files/ma_kirsch_2014_0.pdf

Looking through the abstract and introduction, that's just port
knocking. As the paper points out, "Port knocking is a well-known
technique to hide TCP servers from port scanners".

(The thesis does aim at security against a global eavesdropper, which is
not traditionally a goal of port knocking; and the implementation does
try hard to work with existing software, which is nice.

I don't think port knocking is actually useful - see below - but this
does look like a competent execution of its concept.)

> The application is electronic democracy. I want to demonstrate how it
> is possible to do secure comms. over untrusted networks and hardware.

But it *isn't* possible to do secure comms from/to compromised hardware;
that is what "compromised" means.

Note that the thesis above merely aims at cryptographic port knocking; a
global adversary can still just read the unencrypted traffic. The thesis
also requires a pre-shared key; if you have a PSK, why not use real
crypto (e.g. a VPN) instead?

Also, note that securely pre-sharing keys is a pain even in a small
group of friends; there is no way you can scale that to "every human in
the world".

> I hope to be able do this by carrying out a global referendum. See
>
>      http://livelogic.blogspot.com/2014/10/the-foundation-parts-iii-iii.html

A very quick read shows that you want to do, roughly, electronic voting.
A number of proposals exists to achieve secure (or verifiable)
electronic voting; I believe you should be able to find fairly
accessible introductions to the cryptographic scheme proposed by Ron
Rivest (of RSA fame).

No proposal that I'm aware of even contemplates using compromised
hardware, though, and all proposals assume a functioning census.

> My plan is to use a virtual interface which magically shows behind the
> physical interface when connections are made with the right ISN key in
> the SYN packet. If the ISN is not one of the 'knocks' then the
> connection sees the ordinary physical interface.
>
> Then I want to make a connection between applications and the TCP
> stack so that the knocks can be determined only by data from within
> the VPN. Then the knocks will vary non-deterministically. To bootstrap
> into the VPN a machine will need a direct trusted connection to
> another machine which is already in the VPN, and which can send it the
> initial knock key sequence which will allow it to handshake into the
> VPN, and thereafter have a connection.
>
> The VPN will be tunneled over TCP and/or IP datagram connections.
> Within the VPN the routing and representation of data within real TCP
> network packets will also vary non-deterministically according to data
> passed over the VPN.
>
> The VPN will be used for trusted core protocols for authentication,
> key-exchange and verification. So it need not carry such high volumes
> of traffic The bulk of data will be carried over the exposed network.
>
> If anyone here has a better idea, or any other useful advice (even if
> it's "this has already been done!" or "It won't work," but please
> explain exactly why.) or pointers: I am new to this game: I have never
> seriously looked at network protocol driver code in OpenBSD or any
> other OS.

This is way too large; start with something *much* smaller. Very smart
people have been working on the kind of things you're thinking about for
decades; you're not going to solve this in a weekend, or in just a
hundred lifetimes.

Some things that you may find interesting:
 - http://curvecp.org/: djb's "encrypt the whole internet" scheme. One
   useful first contribution might be to get the efficiency measurements
   that http://curvecp.org/efficiency.html promises; this is not easy.
 - Tor is the most realistic choice for internet anonymity at the
   moment; there are plenty of issues with it, but it's something.
   Consider setting up a tor node; do not set up an exit node without
   consulting an appropriate legal professional.
 - the global poor are getting more and more access to mobile
   (dumb-)phones; consider things like
   http://en.wikipedia.org/wiki/M-Pesa. It has been very hard for the
   open source world to do much of anything in this area, since (a) it's
   desperately uncool and (b) telecom companies are hesitant to allow
   any arbitrary code on their devices. Nonetheless, some (extremely
   ambitious) projects might be worthwhile:
     + try turning Karsten Nohl's research into something like Cydia, a
     platform for rooting SIM cards and installing custom applications
     on them. Again, consult a legal professional; this is definitely
     not legal everywhere.
     + create an e-voting application and bring it to market with the
     telecom operators' approval. This has probably been tried. (Again,
     there is a political dimension to this, which I'll hint at by
     saying "informed voter".)
     + investigate this area more - I'm not even remotely competent.
 - Estonia is running some interesting experiments, notably
   http://e-estonia.com/e-residents/become-e-resident/. Do note
   http://en.wikipedia.org/wiki/Electronic_voting_in_Estonia ("computer
   security experts (...) have voiced sharp criticism").

There are also many political dimension to this; that is even less
appropriate for misc@. Do consider concepts like "coercion", "buying
votes", "informed voter", etc.

(This was enough of a diversion; I'll shut up now, and my apologies to
anyone unhappy to receive this message.)

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: Shadow TCP stacks

Ian Grant
On Wed, Oct 15, 2014 at 4:47 PM, Kevin Chadwick <[hidden email]> wrote:
> On Sat, 11 Oct 2014 13:38:49 -0400
> Ian Grant wrote:
>
>> No, the "pre-shared keys" are communicated over the VPN, as are the
>> keys which encrypt the VPN's own data as it appears in the actual TCP
>> packets which carry the tunnel through which the VPN operates.
>
> Perhaps I have missed something but if you have a ssh tunnel or
> something then just put that in front of the service without increasing

Moved to misc.

Yes, you missed something: the point :-)

The idea is that the existence of this entire 'ultranet' is
undetectable by even someone snooping all national traffic. So a TCP
port 80 connection looks to the snooper _exactly_ like an HTTP
connection handshake. Only the ISN and the source address mark the
connection as 'ultra' and take it into a back room where it connects
to the real network. If the snooper tries to connecto to that port
they the same HTTP service that all the other muggles see.

Ian

Reply | Threaded
Open this post in threaded view
|

Re: [Bulk] Re: Shadow TCP stacks

Martin Schröder
2014-10-16 2:22 GMT+02:00 Ian Grant <[hidden email]>:

>> Perhaps I have missed something but if you have a ssh tunnel or
>> something then just put that in front of the service without increasing
>
> Moved to misc.
>
> Yes, you missed something: the point :-)
>
> The idea is that the existence of this entire 'ultranet' is
> undetectable by even someone snooping all national traffic. So a TCP
> port 80 connection looks to the snooper _exactly_ like an HTTP
> connection handshake. Only the ISN and the source address mark the

Or a service on a port is invisible unless a magic SYN packet appears.

Best
   Martin

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Kevin Chadwick-2
In reply to this post by Ian Grant
On Wed, 15 Oct 2014 20:22:56 -0400
Ian Grant wrote:

> Moved to misc.
>
> Yes, you missed something: the point :-)
>
> The idea is that the existence of this entire 'ultranet' is
> undetectable by even someone snooping all national traffic. So a TCP
> port 80 connection looks to the snooper _exactly_ like an HTTP
> connection handshake. Only the ISN and the source address mark the
> connection as 'ultra' and take it into a back room where it connects
> to the real network. If the snooper tries to connecto to that port
> they the same HTTP service that all the other muggles see.

I still don't see the benefit though but do see added complexity or
more code to audit.

Reducing DDOS against a visible SSH service maybe? Reduce password
attempts on your logs allowing them to go after targets that might
actually use passwords (port change also works there, I find)?

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Martin Schröder
2014-10-16 13:16 GMT+02:00 Kevin Chadwick <[hidden email]>:
> I still don't see the benefit though but do see added complexity or
> more code to audit.
>
> Reducing DDOS against a visible SSH service maybe? Reduce password
> attempts on your logs allowing them to go after targets that might
> actually use passwords (port change also works there, I find)?

The impossibility to scan for services - which the NSA/GHCQ/... do.

Best
   Martin

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Bret S. Lambert-2
On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote:
> 2014-10-16 13:16 GMT+02:00 Kevin Chadwick <[hidden email]>:
> > I still don't see the benefit though but do see added complexity or
> > more code to audit.
> >
> > Reducing DDOS against a visible SSH service maybe? Reduce password
> > attempts on your logs allowing them to go after targets that might
> > actually use passwords (port change also works there, I find)?
>
> The impossibility to scan for services - which the NSA/GHCQ/... do.

It's a good thing that traffic analysis isn't a thing, then. Otherwise
they'd be able to check if traffic purporting to go to port 80/443
doesn't look like HTTP traffic, or something.

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Martin Schröder
2014-10-17 10:24 GMT+02:00 Bret Lambert <[hidden email]>:
> On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote:
>> The impossibility to scan for services - which the NSA/GHCQ/... do.
>
> It's a good thing that traffic analysis isn't a thing, then. Otherwise
> they'd be able to check if traffic purporting to go to port 80/443
> doesn't look like HTTP traffic, or something.

That's not the scenario here. The scenario is defense against port scans.

You look like a fool who hasn't read the original paper.

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Bret S. Lambert-2
On Fri, Oct 17, 2014 at 12:56:48PM +0200, Martin Schr??der wrote:

> 2014-10-17 10:24 GMT+02:00 Bret Lambert <[hidden email]>:
> > On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote:
> >> The impossibility to scan for services - which the NSA/GHCQ/... do.
> >
> > It's a good thing that traffic analysis isn't a thing, then. Otherwise
> > they'd be able to check if traffic purporting to go to port 80/443
> > doesn't look like HTTP traffic, or something.
>
> That's not the scenario here. The scenario is defense against port scans.
>
> You look like a fool who hasn't read the original paper.
>

Quoting the OP a few emails back:

> The idea is that the existence of this entire 'ultranet' is
> undetectable by even someone snooping all national traffic. So a TCP
> port 80 connection looks to the snooper _exactly_ like an HTTP
> connection handshake. Only the ISN and the source address mark the
> connection as 'ultra' and take it into a back room where it connects
> to the real network.

Just sayin'.

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Ian Grant
In reply to this post by Bret S. Lambert-2
On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert <[hidden email]> wrote:
> On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote:
>> 2014-10-16 13:16 GMT+02:00 Kevin Chadwick <[hidden email]>:
>> The impossibility to scan for services - which the NSA/GHCQ/... do.
>
> It's a good thing that traffic analysis isn't a thing, then. Otherwise
> they'd be able to check if traffic purporting to go to port 80/443
> doesn't look like HTTP traffic, or something.

They don't have any clue which traffic to analyze though, so this
traffic is a needle in a haystack. Also, the VPN could be tunneled
over HTTP if necessary.

Ian

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

J Sisson
On Fri, Oct 17, 2014 at 9:13 AM, Ian Grant <[hidden email]> wrote:

> On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert <[hidden email]> wrote:
>> On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote:
>>> 2014-10-16 13:16 GMT+02:00 Kevin Chadwick <[hidden email]>:
>>> The impossibility to scan for services - which the NSA/GHCQ/... do.
>>
>> It's a good thing that traffic analysis isn't a thing, then. Otherwise
>> they'd be able to check if traffic purporting to go to port 80/443
>> doesn't look like HTTP traffic, or something.
>
> They don't have any clue which traffic to analyze though, so this
> traffic is a needle in a haystack. Also, the VPN could be tunneled
> over HTTP if necessary.
>
> Ian
>

Right.  Because the NSA/GHCQ don't have the resources to accomplish
such a goal.

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Bret S. Lambert-2
In reply to this post by Ian Grant
On Fri, Oct 17, 2014 at 12:13:55PM -0400, Ian Grant wrote:

> On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert <[hidden email]> wrote:
> > On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote:
> >> 2014-10-16 13:16 GMT+02:00 Kevin Chadwick <[hidden email]>:
> >> The impossibility to scan for services - which the NSA/GHCQ/... do.
> >
> > It's a good thing that traffic analysis isn't a thing, then. Otherwise
> > they'd be able to check if traffic purporting to go to port 80/443
> > doesn't look like HTTP traffic, or something.
>
> They don't have any clue which traffic to analyze though, so this
> traffic is a needle in a haystack.

Well, if, as Herr Schroeder seems to be implying, this is used to
avoid port scans, I'd look for traffic to/from address:port which
don't show up on scans.

> Also, the VPN could be tunneled
> over HTTP if necessary.

I know of at least one company which sells a product which doesn't
just read headers, but classifies traffic based upon behavior, e.g.,
"small request receives large response -> bulk transfer", or
"series of tiny packets which receive a single, larger response ->
interactive session". I assume nation-states have developed similar
capabilities.

The ability to use statistical methods to eavesdrop on encrypted
SIP sessions comes to mind as an example of traffic analysis as a
tool to defeat adversaries who are attempting to secure their
communications.

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Martin Schröder
2014-10-17 20:49 GMT+02:00 Bret Lambert <[hidden email]>:
> Well, if, as Herr Schroeder seems to be implying, this is used to
> avoid port scans, I'd look for traffic to/from address:port which
> don't show up on scans.

That's certainly possible but more expensive than "find all ssh servers".

Best
   Martin

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Ian Grant
In reply to this post by Bret S. Lambert-2
On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert <[hidden email]> wrote:
> Well, if, as Herr Schroeder seems to be implying, this is used to
> avoid port scans, I'd look for traffic to/from address:port which
> don't show up on scans.

That's why I want to hide it behind an ordinary service.

>> Also, the VPN could be tunneled
>> over HTTP if necessary.

> I know of at least one company which sells a product which doesn't
> just read headers, but classifies traffic based upon behavior, e.g.,
> "small request receives large response -> bulk transfer", or
> "series of tiny packets which receive a single, larger response ->
> interactive session". I assume nation-states have developed similar
> capabilities.

That's fine. But they have to analyze all the traffic. This is a
needle in a haystack.

> The ability to use statistical methods to eavesdrop on encrypted
> SIP sessions comes to mind as an example of traffic analysis as a
> tool to defeat adversaries who are attempting to secure their
> communications.

Again, a needle in a haystack.

Please read the OP before refuting stuff on the list. If you want to
argue, and you aren't sure of your argument, e-mail me off the list.
Otherwise it just adds to the general level of confusion, which is
already higher than I'd expected on this list.

Thanks,
Ian

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Bret S. Lambert-2
On Fri, Oct 17, 2014 at 02:59:26PM -0400, Ian Grant wrote:
> On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert <[hidden email]> wrote:
> > Well, if, as Herr Schroeder seems to be implying, this is used to
> > avoid port scans, I'd look for traffic to/from address:port which
> > don't show up on scans.
>
> That's why I want to hide it behind an ordinary service.

The point being, Herr Schroeder appears to be a man who would become
one of your users, and has apparently missed that step. A manual that
includes an advisory to do so would likely be a good idea.

>
> >> Also, the VPN could be tunneled
> >> over HTTP if necessary.
>
> > I know of at least one company which sells a product which doesn't
> > just read headers, but classifies traffic based upon behavior, e.g.,
> > "small request receives large response -> bulk transfer", or
> > "series of tiny packets which receive a single, larger response ->
> > interactive session". I assume nation-states have developed similar
> > capabilities.
>
> That's fine. But they have to analyze all the traffic. This is a
> needle in a haystack.

It's a good thing we don't know any nation-states that analyze all
the traffic, then. That would probably be bad.

>
> > The ability to use statistical methods to eavesdrop on encrypted
> > SIP sessions comes to mind as an example of traffic analysis as a
> > tool to defeat adversaries who are attempting to secure their
> > communications.
>
> Again, a needle in a haystack.

Assuming that your adversary is going into this blind, and hasn't been
given a list of interesting targets that includes your systems. States
also have access to human intelligence as well.

>
> Please read the OP before refuting stuff on the list. If you want to
> argue, and you aren't sure of your argument, e-mail me off the list.
> Otherwise it just adds to the general level of confusion, which is
> already higher than I'd expected on this list.

Quoting the original email you sent:

> If anyone here has a better idea, or any other useful advice (even if
> it's "this has already been done!" or "It won't work," but please
> explain exactly why.) or pointers

I'm not attempting to refute the validity of what you're attempting,
I'm pointing out things that probably should be taken into consideration
during implementation/deployment, which I think falls under the heading
of "useful advice". Whether or not it's useful is a judgement left to the
reader.

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Giancarlo Razzolini-3
In reply to this post by Ian Grant
On 17-10-2014 15:59, Ian Grant wrote:
> On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert <[hidden email]>
wrote:

>> Well, if, as Herr Schroeder seems to be implying, this is used to
>> avoid port scans, I'd look for traffic to/from address:port which
>> don't show up on scans.
> That's why I want to hide it behind an ordinary service.
>
>>> Also, the VPN could be tunneled
>>> over HTTP if necessary.
>> I know of at least one company which sells a product which doesn't
>> just read headers, but classifies traffic based upon behavior, e.g.,
>> "small request receives large response -> bulk transfer", or
>> "series of tiny packets which receive a single, larger response ->
>> interactive session". I assume nation-states have developed similar
>> capabilities.
> That's fine. But they have to analyze all the traffic. This is a
> needle in a haystack.
>
>> The ability to use statistical methods to eavesdrop on encrypted
>> SIP sessions comes to mind as an example of traffic analysis as a
>> tool to defeat adversaries who are attempting to secure their
>> communications.
> Again, a needle in a haystack.
>
> Please read the OP before refuting stuff on the list. If you want to
> argue, and you aren't sure of your argument, e-mail me off the list.
> Otherwise it just adds to the general level of confusion, which is
> already higher than I'd expected on this list.
>
> Thanks,
> Ian
>
Hi,

     I've read both the paper, your blog post and even your document
about the foundation. I must tell you, I found someone even more
paranoid than I am. But, there is the good paranoid and there is bad. Of
course everything in excess is bad, but man, you really get into it.
This tcp shadow stack would do no good in preventing people from
learning what you're doing. It's security through obscurity, even though
the authors of the paper try to say that it ain't. Believe me, this
would only scream on their filters. Hell, even someone capturing this
with tcpdump and analyzing it later would see something it's not right.
The answer to most of our privacy problems in today's internet is
cryptography. Better yet, properly implemented strong cryptography. I
believe that OpenBSD does that. But don't expect them to add a security
through obscurity layer to their kernel because I guess they wont.

Cheers

[demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Ian Grant
On Sun, Oct 19, 2014 at 1:40 AM, Giancarlo Razzolini
<[hidden email]> wrote:
> This tcp shadow stack would do no good in preventing
> people from learning what you're doing. It's security
> through obscurity, even though the authors of the paper try to say
> that it ain't.

On the contrary: it _will_ make it impossible for people to know what
_we_ are doing. This is not one system I'm talking about: it's
countless independent VPNs. No one person in the world will ever know
what _we_ are doing.

It's not security by obscurity, it's a one-time pre-shared key.

>  Believe me, this would only scream on their filters. Hell,
> even someone capturing this with tcpdump and analyzing it later
> would see something it's not right.

You think someone can analyse all the HTTP traffic in a country? So
what if they could? By the time they've analysed the dumps the service
won't be on that host anymore.

> The answer to most of our
> privacy problems in today's internet is cryptography. Better yet,
> properly implemented strong cryptography.

The issue I am addressing is not privacy. You would know that if you
had read the Foundation paper:

    http://livelogic.blogspot.com/2014/10/the-foundation-parts-iii-iii.html

> I believe that
> OpenBSD does that. But don't expect them to add
> a security through obscurity layer to their kernel because I
> guess they wont.

Well, "they" don't have a choice, because OpenBSD is open source, or
haven't you heard?

Ian

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Worik Stanton
On 20/10/14 12:01, Ian Grant wrote:
>>  Believe me, this would only scream on their filters. Hell,
>> > even someone capturing this with tcpdump and analyzing it later
>> > would see something it's not right.
> You think someone can analyse all the HTTP traffic in a country? So
> what if they could? By the time they've analysed the dumps the service
> won't be on that host anymore.
>

Jumping in...

Yes all traffic of a country can be analysed, fairly close to real time.
 With some basic statistics, smart sampling and a dedicated team
crafting cleaver algorithms...  That is what those big budgets are for!

Worik

--
Why is the legal status of chardonnay different to that of cannabis?
       [hidden email] 021-1680650, (03) 4821804
                          Aotearoa (New Zealand)
                             I voted for love

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Henning Brauer-4
In reply to this post by Ian Grant
* Ian Grant <[hidden email]> [2014-10-20 01:02]:
> On Sun, Oct 19, 2014 at 1:40 AM, Giancarlo Razzolini
> > I believe that
> > OpenBSD does that. But don't expect them to add
> > a security through obscurity layer to their kernel because I
> > guess they wont.
> Well, "they" don't have a choice, because OpenBSD is open source, or
> haven't you heard?

OpenBSD being open source does not imply that you decide what we
ship...

--
Henning Brauer, [hidden email], [hidden email]
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Giancarlo Razzolini-3
In reply to this post by Ian Grant
On 19-10-2014 21:01, Ian Grant wrote:
> On the contrary: it_will_  make it impossible for people to know what
> _we_  are doing. This is not one system I'm talking about: it's
> countless independent VPNs. No one person in the world will ever know
> what_we_  are doing.
Except perhaps for the nations with mass surveillance capabilities.
>
> It's not security by obscurity, it's a one-time pre-shared key.
Well, the need for a PSK doesn't change the fact that you're trying to
conceal something, but not making it inherently more secure.
>
> You think someone can analyse all the HTTP traffic in a country? So
> what if they could? By the time they've analysed the dumps the service
> won't be on that host anymore.
In what world do you live? Didn't you followed the news regarding Eduard
Snowden disclosures? Not only it is possible to analyze all HTTP traffic
on any given country, but it's also possible to analyze ALL traffic on
any given country. This is exactly what NSA is doing and perhaps others
also. Hell, even some companies such as akamai and others can see a
great chunk of the internet traffic.
>
> The issue I am addressing is not privacy. You would know that if you
> had read the Foundation paper:
>
>
http://livelogic.blogspot.com/2014/10/the-foundation-parts-iii-iii.html
Yes, you're not addressing *just* privacy. But your original post e-mail
subject of "shadow TCP stacks" is misleading.
> Well, "they" don't have a choice, because OpenBSD is open source, or
> haven't you heard?
Even if you did manage to create a nice patch, bug free, with great
security and all, I don't ever see this getting into the OpenBSD source
tree. And, as Henning, an OpenBSD developer, putted on a reply to you,
you don't get to decide what they put into their source code tree. As I
said before, focus on the proper development of good and strong
cryptography, and you'll sure see your contributions get into OpenBSD,
provided they are in the project's interest, of course.

Cheers

[demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]

Reply | Threaded
Open this post in threaded view
|

Re: Shadow TCP stacks

Justin Mayes
>On the contrary: it_will_  make it impossible for people to know what
> _we_  are doing. This is not one system I'm talking about: it's
> countless independent VPNs. No one person in the world will ever know
> what_we_  are doing.

'countless independent VPNs' + 'a one-time pre-shared key' = big trouble

My advice - Torproject.org
Currently the best math/crypto based solution to provide private service hosting and anonymous browsing. Open source, peer reviewed, thoroughly abused by smart people and so on. Tor also solves the very real metadata problem this paper does not even address.

Any code that makes it into the kernel introduces complexity must offset its long term cost with usefulness. I don't think this repackaged port knocking mess passes that test.

J

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Giancarlo Razzolini
Sent: Monday, October 20, 2014 7:34 AM
To: Ian Grant
Cc: Bret Lambert; OpenBSD general usage list
Subject: Re: Shadow TCP stacks

On 19-10-2014 21:01, Ian Grant wrote:
> On the contrary: it_will_  make it impossible for people to know what
> _we_  are doing. This is not one system I'm talking about: it's
> countless independent VPNs. No one person in the world will ever know
> what_we_  are doing.
Except perhaps for the nations with mass surveillance capabilities.
>
> It's not security by obscurity, it's a one-time pre-shared key.
Well, the need for a PSK doesn't change the fact that you're trying to conceal something, but not making it inherently more secure.
>
> You think someone can analyse all the HTTP traffic in a country? So
> what if they could? By the time they've analysed the dumps the service
> won't be on that host anymore.
In what world do you live? Didn't you followed the news regarding Eduard Snowden disclosures? Not only it is possible to analyze all HTTP traffic on any given country, but it's also possible to analyze ALL traffic on any given country. This is exactly what NSA is doing and perhaps others also. Hell, even some companies such as akamai and others can see a great chunk of the internet traffic.
>
> The issue I am addressing is not privacy. You would know that if you
> had read the Foundation paper:
>
>
http://livelogic.blogspot.com/2014/10/the-foundation-parts-iii-iii.html
Yes, you're not addressing *just* privacy. But your original post e-mail subject of "shadow TCP stacks" is misleading.
> Well, "they" don't have a choice, because OpenBSD is open source, or
> haven't you heard?
Even if you did manage to create a nice patch, bug free, with great security and all, I don't ever see this getting into the OpenBSD source tree. And, as Henning, an OpenBSD developer, putted on a reply to you, you don't get to decide what they put into their source code tree. As I said before, focus on the proper development of good and strong cryptography, and you'll sure see your contributions get into OpenBSD, provided they are in the project's interest, of course.

Cheers

[demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]

12