Shadow TCP stacks
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 The application is electronic democracy. I want to demonstrate how it is possible to do secure comms. over untrusted networks and hardware. 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 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. Thanks in advance, and best wishes, Ian
Re: Shadow TCP stacks
On Sat, Oct 11, 2014 at 5:45 AM, Joachim Schipper wrote: > somewhat interesting> Moved back to tech for just this message: I am going to implement this inBSD, so I would still appreciate pointers and helpful tech advice, but please don't CC the list, just mail me privately. To prevent a flame war, please don't refute anything on the list without giving carefully considered, clear reasons why I and everyone else should agree with you, otherwise I will be obliged to respond to the list because I won't leave a falsehood uncontested on a public forum. >> 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. That's why I used the term "untrusted": to make a distinction between the unknown status of security of the underlying media and "compromised" meaning definite knowledge that the hardware affects a compromise of privacy/integrity. > Note that the thesis above merely aims at cryptographic port knocking; a > global adversary can still just read the unencrypted traffic 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. This is not a common idea: that such a thing a thing is possible, so people should not be too quick to dismiss it solely on account of never having heard of the idea before. Dismiss it only when you have convinced yourself that it definitely won't work. Because otherwise you are rejecting something very valuable: perfectly secure communications. > Also, note that securely pre-sharing keys is a pain even in a small > group of friends; The purpose of the VPN is to provide this mechanism and make it automatic, that point should be fairly clear in my description. > there is no way you can scale that to "every human in > the world". No, and that is certainly not the plan. The verification of the voting is as I explain in that document: it is that each voter certifies the votes of three others, and because people know this, they know that their own vote is only represented if the others certified theirs. So the knowledge doesn't exist in any one person's mind, it only exists in the combined minds of all the people. And the same principle applies to the knowledge of the VPN keys: that knowledge will be shared between four independent orthogonal VPNs and that information will simply not exist, so could never be compromised. Please don't be too quick to dismiss this. The idea is not an obvious one, but people who can think about systems are typically better at grasping this sort of thing that people who who work with systems of formal proof which work by symbolic substitution. This is not something you can make obvious by symbolic substitution because it is based on human knowledge, not concrete representation in some language: that knowledge is the knowledge that "these really are three other independent VPNs that are providing the information I need to encrypt my traffic when it sending to this other machine.. >> 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. Well, now you _are_ aware of at least one: which is this one :-) And I am not the only one who believes that this is possible. Roger Schell (cc'ed), who was very influential in the development of the NSA's TCSEC wrote in https://www.acsac.org/invited-essay/essays/2001-schell.pdf: "The science of computer and network information security has for some time given us the ability to purchase an information system from a mortal enemy and then assess its ability to enforce a well defined security policy, gaining sufficient assurance to confidently use the system to protect against massive loss and grave damage, and this has been actually been put into practice. This astonishing capability is known as “verified protection”." >> 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
Re: Shadow TCP stacks
On Fri, Oct 10, 2014 at 7:31 PM, Ian Grant wrote: > I want to try to implement some form of concealed port knocking in > OpenBSD, along the lines of [Julian] Kirsch: Thanks to everyone that replied. You know who you aren't :-) Several people said I should look at adding (to pf) a new IOCTL and a pre-handshake TCP state with the PSK for given source and a new timeout for expiring PSKs. Then ordinary packet re-writes will do the re-routing. So that's what I'm doing. Someone also pointed out that all the VPN encryption key-management could be handled by iked. A lot of this awesome stuff in here is all new to me, it was 3.x that I last seriously used. I'm even more impressed with OpenBSD than I thought I was. More comments would be gratefully received. Also, can anyone lend me a hundred dollars, for ever? I will be literally on the streets (again!) in a few days otherwise. Thanks again Ian
Re: Shadow TCP stacks
On a related note, I want to implement services on bochs VM's and pass them from one physical host machine to another, so that the physical addresses are not fixed targets. I am a bit confused about the bochs host implementation of networking. What bochs hardware works best on OpenBSD? Has anyone managed to get a bochs emulation communicating of an OpenBSD gre tunnel? Ian
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 12:58 PM, Ian Grant wrote: > On a related note, I want to implement services on bochs VM's and pass > them from one physical host machine to another, so that the physical > addresses are not fixed targets. qemu looks a bit better than bochs. I am wondering about how to keep a series of consistent check-points in a distributed virtual machine network, so that in the event of a compromise the VMs could be rewound to the last consistent point. Another possibility is running servers in redundant pairs on different hosts. The whole thing also needs to be runnable over "USB stick net" in extremis. I don't know enough yet about how something like VDE is implemented. Any pointers? Ian
Re: Shadow TCP stacks
On Fri, Oct 17, 2014 at 5:56 PM, Ian Grant wrote: > The whole thing also needs to be runnable over "USB stick net" in extremis. And mobile WiFi as per "What they should be doing" on: http://livelogic.blogspot.com/
Re: Shadow TCP stacks
On Mon, Oct 20, 2014 at 8:10 PM, Theo de Raadt wrote: > You are off-topic for this mailing list. Please go discuss it > elsewhere. Theo, Does this include my questions on tech? I still want to do this, even of a hundred little pricks don't understand what it is. I think I can make a very tidy self-contained module to do it. I have given up on the idea of using the existing state tables. Pre-loading states will make for a messy patch. I am looking at doing it with a seperate table of pre-shared ISNs Ian
IPv6 packet refragmentation in pf(4)
This refers to the un-patched OpenBSD 5.5 source tree.
Whilst trying to understand the notion of "direction" of packet flow
in pf(4) I came across this potential problem:
In pf.conf(5) we have:
When forwarding reassembled IPv6 packets, pf refragments them with
the original maximum fragment size. This allows the sender to
determine the optimal fragment size by path MTU discovery.
The code that does this is pf_refragment6, and it is called from only
one place (from within sys/{net,netinet}), which is in pf.c, from the
function pf_test defined on line 6395--??. On lines 6731--6739 we
have:
#ifdef INET6
/* if reassembled packet passed, create new fragments */
if (pf_status.reass && action == PF_PASS && *m0 && fwdir == PF_FWD) {
struct m_tag*mtag;
if ((mtag = m_tag_find(*m0, PACKET_TAG_PF_REASSEMBLED, NULL)))
action = pf_refragment6(m0, mtag, fwdir);
}
#endif
But from pf.c, the fn pf_test is only ever called with fwdir == PF_OUT
and the only other places from which it is called are in if_bridge.c,
and they set fwdir to either PF_OUT or PF_IN (aliased as BRIDGE_OUT
and BRIDGE_IN respectively, when PF is enabled). Therefore fwdir ==
PF_FWD never holds, and so reassembled IPv6 packets are never
refragmented, contradicting the manual page pf.conf(5).
I can't offer any suggestions as to what the test should be, because I
don't yet understand the notion of direction in pf. But perhaps I'm
not the only one :-)
Ian
Re: Shadow TCP stacks
> And when you have more than words, please put it on a a > web site and do nothing more than tell people once. Still a lot of words, but code too, and an outline of a test framework that others may be interested in using. I would be happy to take into account any other ideas people might have about what to include in the test framework to make it useful for others. Anyone who has comments please don't cc this list, post them on the blog if you want them to be publicly available. http://livelogic.blogspot.com/2014/10/shadow-tcp-stacks-in-openbsd.html Ian
Re: IPv6 packet refragmentation in pf(4)
I beg your collective pardons. I didn't notice the netinet6 directory!
Old timer ...
Ian
On Sat, Oct 25, 2014 at 1:02 PM, Henning Brauer
wrote:
> * Ian Grant [2014-10-25 18:15]:
>> #ifdef INET6
>> /* if reassembled packet passed, create new fragments */
>> if (pf_status.reass && action == PF_PASS && *m0 && fwdir == PF_FWD) {
>> struct m_tag*mtag;
>>
>> if ((mtag = m_tag_find(*m0, PACKET_TAG_PF_REASSEMBLED, NULL)))
>> action = pf_refragment6(m0, mtag, fwdir);
>> }
>> #endif
>>
>> But from pf.c, the fn pf_test is only ever called with fwdir == PF_OUT
>> and the only other places from which it is called are in if_bridge.c,
>> and they set fwdir to either PF_OUT or PF_IN (aliased as BRIDGE_OUT
>> and BRIDGE_IN respectively, when PF is enabled). Therefore fwdir ==
>> PF_FWD never holds, and so reassembled IPv6 packets are never
>> refragmented, contradicting the manual page pf.conf(5).
>
> you need to improve your grepping skills :)
>
> netinet6/ip6_forward.c:348: pf_test(AF_INET6, PF_FWD, encif,
> &m, NULL) != PF_PASS) {
> netinet6/ip6_forward.c:459: if (pf_test(AF_INET6, PF_FWD, rt->rt_ifp, &m,
> NULL) != PF_PASS) {
>
> --
> 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/
>
