Re: Shadow TCP stacks
* Ian Grant ian.a.n.gr...@googlemail.com [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, h...@bsws.de, henn...@openbsd.org 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/
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]
Re: Shadow TCP stacks
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: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] 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]
Re: Shadow TCP stacks
On 20 October 2014 14:13, Worik Stanton worik.stan...@gmail.com wrote: 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! Can throw in some real-world experience here - worked on a project in Malaysia that was doing near-realtime (no more than 5 minutes lag) analytics of cellular and data traffic on that country's largest cellular network. The kit fit in less than five 42U racks, including dev/test kit, and four of those racks were an inefficiently-used Netezza appliance. It wasn't even that expensive - private industry budget. John
Re: Shadow TCP stacks
On Mon, Oct 20, 2014 at 6:18 PM, john slee indig...@oldcorollas.org wrote: On 20 October 2014 14:13, Worik Stanton worik.stan...@gmail.com wrote: 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! Can throw in some real-world experience here - worked on a project in Malaysia that was doing near-realtime (no more than 5 minutes lag) analytics of cellular and data traffic on that country's largest cellular network. The kit fit in less than five 42U racks, including dev/test kit, and four of those racks were an inefficiently-used Netezza appliance. It wasn't even that expensive - private industry budget. There's analysis, and there's analysis. None of this is particularly interesting without knowledge of what depth of analysis was being done. I doubt they were looking for steganographic transport encoding in audio and image data, for example. And I said before, using WiFi cells, they simply won't have access to all the traffic without snooping all the WiFi cells. And they would have a hard time dealing with USBstickNet traffic. high-latency, but massive bandwidth :-) Ian
Re: Shadow TCP stacks
On 20-10-2014 20:46, Ian Grant wrote: There's analysis, and there's analysis. None of this is particularly interesting without knowledge of what depth of analysis was being done. Yes it is. Because filters can be made to alert you of odd traffic. And certainly a tcp syn to an http port which after the connection is established you start seeing a lot of vpn traffic. Or even they can specifically try to target the PSK in the ISN. There are lot's of things with this port knocking that they can look into, easily. I doubt they were looking for steganographic transport encoding in audio and image data, for example. Which has nothing to do with your proposal. And even so, I believe you couldn't make a vpn for real world traffic masquerade inside audio or video data. Hell, I don't even think that steganography work that well. But that's another matter entirely. And I said before, using WiFi cells, they simply won't have access to all the traffic without snooping all the WiFi cells. And they would have a hard time dealing with USBstickNet traffic. high-latency, but massive bandwidth:-) Both do not have anything to do with your proposal. But I don't see why the 4G antennas couldn't have NSA or (insert your country agency name here) hardware to see every wireless network in their range. Which clients connect to them, and other things that the great unencrypted world of 802.11 management frames do for you. And since you need much more antennas for 4G in a crowded city, I bet they could cover effectively a very large area, if not the entire city. As for the USB, did you heard of badusb? It's bad. They specifically tell you not to share any stick with anyone because all that needs is one computer infected and your stick firmware becomes your worst enemy. I already said you and will say again. Want to help? Improve or implement strong cryptography properly. It's the only thing that can save us in the long term. Cheers [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Shadow TCP stacks
On Mon, Oct 20, 2014 at 8:33 AM, Giancarlo Razzolini grazzol...@gmail.com wrote: 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. How else can one protect a system from DoS attacks, other than by concealing it some way? And what is cryptography if it's not concealing the meaning of a communication in some way? 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. Sure they can see it, but that's not going to tell them where it went next. So they can analyse all the traffic and what they learn from that won't be worth knowing half an hour later. I live in Bolivia, and I want to implement something like this here, so that the Bolivian government can have secure communications within Bolivia, and across her borders. 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. I can make and a maintain any modifications to OpenBSD that I please. Ian
Re: Shadow TCP stacks
On 20-10-2014 21:52, Ian Grant wrote: How else can one protect a system from DoS attacks, other than by concealing it some way? And what is cryptography if it's not concealing the meaning of a communication in some way? Oh my. DoS can be mitigated. You could never protect a system. Even if there isn't any port open, they can flood you uplink, even if you stop sending FIN or ACK. There is UDP. Cryptography is not just concealment. It's integrity. It's authentication (in some cases). So it's the only way to be sure your message wasn't modified because the math behind it is solid. Sure they can see it, but that's not going to tell them where it went next. So they can analyse all the traffic and what they learn from that won't be worth knowing half an hour later. Man, real time traffic analysis. We told you so many times. They'll learn it right away. Because they can see ALL traffic in real time. Simple as that. I live in Bolivia, and I want to implement something like this here, so that the Bolivian government can have secure communications within Bolivia, and across her borders. I live in Brazil. And I'm aware of the situation of many countries in South America, ours included. If you want that, please tell them to use known and proven cryptography solutions such as Tor, IPSEC, Off the record messaging, etc. Do not reinvent the wheel, because it will only make their traffic stand out even further. I can make and a maintain any modifications to OpenBSD that I please. Of course you can. But if you go along these lines of reinventing the wheel and security through obscurity you'll never get your contributions into it. Cheers [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Shadow TCP stacks
On Mon, Oct 20, 2014 at 8:01 PM, Giancarlo Razzolini grazzol...@gmail.com wrote: On 20-10-2014 21:52, Ian Grant wrote: How else can one protect a system from DoS attacks, other than by concealing it some way? And what is cryptography if it's not concealing the meaning of a communication in some way? Oh my. DoS can be mitigated. You could never protect a system. Even if there isn't any port open, they can flood you uplink, even if you stop sending FIN or ACK. There is UDP. Cryptography is not just concealment. It's integrity. It's authentication (in some cases). So it's the only way to be sure your message wasn't modified because the math behind it is solid. Sure they can see it, but that's not going to tell them where it went next. So they can analyse all the traffic and what they learn from that won't be worth knowing half an hour later. Man, real time traffic analysis. We told you so many times. They'll learn it right away. Because they can see ALL traffic in real time. Simple as that. You don't read what I write. I said the info won't be worth having half an hour later. Because the service access point will have moved. I didn't dispute the real-timeness of the traffic analysis. I live in Bolivia, and I want to implement something like this here, so that the Bolivian government can have secure communications within Bolivia, and across her borders. I live in Brazil. And I'm aware of the situation of many countries in South America, ours included. If you want that, please tell them to use known and proven cryptography solutions such as Tor, IPSEC, Off the record messaging, etc. Do not reinvent the wheel, because it will only make their traffic stand out even further. Thanks for your advice but I will do exactly what I think is the right thing to do. I can make and a maintain any modifications to OpenBSD that I please. Of course you can. But if you go along these lines of reinventing the wheel and security through obscurity you'll never get your contributions into it. I am not trying to become an OpenBSD developer. I just want to use for a real project. Ian
Re: Shadow TCP stacks
You are off-topic for this mailing list. Please go discuss it elsewhere.
Re: Shadow TCP stacks
On Sun, Oct 19, 2014 at 1:40 AM, Giancarlo Razzolini grazzol...@gmail.com 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
Re: Shadow TCP stacks
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? worik.stan...@gmail.com 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]
Re: Shadow TCP stacks
On 17-10-2014 15:59, Ian Grant wrote: On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert bret.lamb...@gmail.com 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]
Re: Shadow TCP stacks
On Thu, Oct 16, 2014 at 02:48:22PM +0200, Martin Schr??der wrote: 2014-10-16 13:16 GMT+02:00 Kevin Chadwick ma1l1i...@yahoo.co.uk: 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.
Re: Shadow TCP stacks
2014-10-17 10:24 GMT+02:00 Bret Lambert bret.lamb...@gmail.com: 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.
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 12:56:48PM +0200, Martin Schr??der wrote: 2014-10-17 10:24 GMT+02:00 Bret Lambert bret.lamb...@gmail.com: 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'.
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert bret.lamb...@gmail.com 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 ma1l1i...@yahoo.co.uk: 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
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 9:13 AM, Ian Grant ian.a.n.gr...@googlemail.com wrote: On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert bret.lamb...@gmail.com 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 ma1l1i...@yahoo.co.uk: 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.
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 12:13:55PM -0400, Ian Grant wrote: On Fri, Oct 17, 2014 at 4:24 AM, Bret Lambert bret.lamb...@gmail.com 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 ma1l1i...@yahoo.co.uk: 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.
Re: Shadow TCP stacks
2014-10-17 20:49 GMT+02:00 Bret Lambert bret.lamb...@gmail.com: 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
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert bret.lamb...@gmail.com 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
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 02:59:26PM -0400, Ian Grant wrote: On Fri, Oct 17, 2014 at 2:49 PM, Bret Lambert bret.lamb...@gmail.com 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.
Re: Shadow TCP stacks
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)?
Re: Shadow TCP stacks
2014-10-16 13:16 GMT+02:00 Kevin Chadwick ma1l1i...@yahoo.co.uk: 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
Re: [Bulk] Re: Shadow TCP stacks
On Wed, Oct 15, 2014 at 4:47 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk 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
Re: [Bulk] Re: Shadow TCP stacks
2014-10-16 2:22 GMT+02:00 Ian Grant ian.a.n.gr...@googlemail.com: 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
Re: Shadow TCP stacks
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'
