Obfuscated TCP

Windows Firefox installer

2008-10-20T18:56:00.000-07:00

Thanks to Arthur Casals, we have a Windows installer! See the Firefox page for the link.

This version only supports TLS transport however, in order to keep the build issues sane! The TLS only Firefox patch is quite small and I'll try to push it upstream at some point. However, Chrome is keeping me busy at the moment.

We hit Slashdot

2008-10-09T15:55:00.000-07:00

We hit Slashdot on Tuesday, the craze is dying down now.

I think I learn two things:

The introduction video was a bit crappy and several people, rightly, said so. However, the general level of misunderstanding was substantially reduced, so it worked I guess
I should be provided a transcript of the video or, at least, a non-video replacement for it. I've now done this.

TLS transport support

TLS transport support is here, yay! Well, it's just hitting the site now. In short, you can configure the DNS advert to say "Actually, connect with HTTPS on port x". Firefox will see this and, even when the user entered "http://", will use HTTPS and ignore any certificate problems.

This makes server support easy, it's just HTTPS. Performance isn't so great, but, well, there you go. Port 443 also works better with firewalls.

The documentation and git trees are up to date. I'll be uploading the Firefox build (64-bit Linux) in just a second.

ABI break, wire break

2008-10-06T18:12:00.000-07:00

I've switched the default cipher from Salsa20 to Salsa20/8. I had always intended to do this, it was just a question of getting a good implementation of Salsa20/8 first.

However, this entails an ABI and wire protocol break. Hopefully there won't be many more of these. So I've uploaded new tarballs for Firefox and libobstcp. Also, there's now a tarball for Firefox built on IA32 Linux (currently untested).

Testing needed

2008-10-03T11:35:00.000-07:00

Ok, all the documentation on the site has been updated. There is now new code (using DNS adverts), a new video introduction, new Firefox patches etc.

Please, if you have any time, goto the code site, act dumb, watch the video and follow the instructions, either as just a user, or as a webmaster too.

Tell me what doesn't work and what doesn't make sense.

Cheers

DNS support

2008-09-30T19:46:00.000-07:00

It's been a couple of weeks since I worked on ObsTCP. There has been some public key signature work and family matters in between.

However, I did have a stonking good idea today (with partial credit to djb).

Previously I intended to encode adverts in a DNS TXT record under a special name. This would mean writing a custom resolver to handle this and doubling the number of DNS lookups for each host.

However, if I encode the advert in a CNAME, I don't need either.

Consider www.example.com, a CNAME for opa12354zbcdefghijkl12345.example.com. When one performs a lookup for an A record for www.example.com, the server will return the A record opa...example.com and the CNAME record for www. By encoding the advert in the CNAME, we don't need an additional request.

Also, the CNAME chain is returned by gethostbyname (but not getaddrinfo), thus we can use the standard libc resolver too.

I'm very happy with this. I'm patching up Firefox now to use gethostbyname and to parse adverts from DNS.

New release: 0.2

2008-09-11T14:58:00.000-07:00

Another week, another release. This week brings lots of rewriting of the core to be cleaner and Apache support.

See the project page for details. Remember that, if you're installing 0.2 you should download a new Firefox, repatch lighttpd etc. Also, when you make install, if you have processes linked against a shared library that you override, they'll probably crash.

Obfuscated TCP (take 3) ready for alpha testing

2008-09-03T18:37:00.000-07:00

Well, after rewriting it again, the new design is ready for testing!

Not all of the old pages have been updated, but most have. Start at http://code.google.com/p/obstcp/wiki/Testing.

This time it doesn't involve any kernel patching. You just install the core library, download a patched Firefox binary, install a Firefox extension and you're done!

I'll be working on some more documentation tonight / tomorrow.

If you try it (sucessfully or otherwise) please tell me. Comments on the blog, comments on the site (http://code.google.com/p/obstcp), mailing list posts (http://groups.google.com/group/obstcp) or email (agl AT imperialviolet DOT org) all welcome.

And, of course, you should thank Google, who are still employing me as I write this. Although no support of the idea by Google, as a company, is implied.

2008-08-28T19:41:00.000-07:00

The firefox modifications to support Obfuscated TCP appear to be working. There's still a fair bit of work until they exist as an extension rather than a source patch however.

2008-08-26T16:30:00.000-07:00

I've written the new libobstcp, it's not in a final state yet (of course), but it's functional. The header file is included below, I'll release the source once there's a client side implementation (maybe as a Firefox extension).

The design is thus:I started writing the HTTP-in-HTTP encapsulation and discovered that it's really hideous. I don't think anything that feels so wrong can be a good design decision, so, here's the main point: it's using a different port number for obfuscation now.

The client finds out the alternative port number via an "advert" for the server. The advert can either be in the DNS, or can be remembered from previous (non-obfuscated) HTTP connections where the advert is returned by the server in an X-ObsTCP header. The advert is a small, base64 encoded string that contains the server's public key, obfuscated port number, and (optionally) the TLS port number.

This isn't specific to HTTP, the general idea is that the advert is a way of saying "This service is alternatively available over ObsTCP/TLS on these ports...". The advert is a tagged format, so there's room to extend it in the future. Planned extensions currently include integrety protection for the data stream using either packet signing in the kernel or MACs at the application layer (or both).

So, the major work at the moment is writing a Firefox extension to do this. Firefox is a big piece of code.

#ifndef LIBOBSTCP_H
#define LIBOBSTCP_H

#include <stdint.h>
#include <sys/uio.h>

// -----------------------------------------------------------------------------
// struct obstcp_keypair - a public/private key pair
// keyid: the 32-bit xor folding of the public key
// -----------------------------------------------------------------------------
struct obstcp_keypair {
  uint8_t private_key[32];
  uint8_t public_key[32];
  uint32_t keyid;
  struct obstcp_keypair *next;
};

struct obstcp_keys {
  struct obstcp_keypair *keys;
};

// -----------------------------------------------------------------------------
// Setup a keyset structure. This must be called before any other operations
// on the keyset.
// -----------------------------------------------------------------------------
void obstcp_keys_init(struct obstcp_keys *keys);
// -----------------------------------------------------------------------------
// Calculate the public key from a private key and prepend the key pair to the
// list of keys installed in the keyset. This becomes the default key
//
// returns: 1 on success, 0 on error, in which case errno is set:
//   ENOMEM: out of memory
//   ENOSPC: a key with the same keyid is already in the keyset
// -----------------------------------------------------------------------------
int obstcp_keys_key_add(struct obstcp_keys *keys, const uint8_t *private_key);
// -----------------------------------------------------------------------------
// Free all keys contained in the keyset
// -----------------------------------------------------------------------------
void obstcp_keys_free(struct obstcp_keys *keys);

// -----------------------------------------------------------------------------
// Keys for the variable arguments part of obstcp_advert_create and
// obstcp_advert_parse
// -----------------------------------------------------------------------------
enum {
  OBSTCP_ADVERT_END = 0,      // no argument
  OBSTCP_ADVERT_OBSPORT,      // takes an int giving the port
  OBSTCP_ADVERT_TLSPORT,      // takes an int giving the port
};

// -----------------------------------------------------------------------------
// Generate a base64 encoded obstcp "advert", this is the data that can be
// included in a DNS TXT record of via other side channels. It takes a variable
// argument list. The variable part of the argument list are a series of pairs
// where the first element of the pair is one of OBSTCP_ADVERT_* and the second
// depends on the value of the first, and may not even exist. The default key
// from the keyset is used for the public value.
//
// The variable list must be terminated with OBSTCP_ADVERT_END.
//
// output: a buffer to which the base64 encoded data is written
// length: number of bytes of space in @output
// returns: on success a value <= to @length is returned. This is the number of
//   bytes written. If @output was too small, a value > @length is returned.
//   This is the number of bytes that is required. Otherwise -1 is returned and
//   errno is set:
//
//   E2BIG: too many options were selected
//   EINVAL: an unknown or invalid pair was found in the arguments
//   ENOKEY: no default key was found in the keyset
// -----------------------------------------------------------------------------
int obstcp_advert_create(char *output, unsigned length,
                         const struct obstcp_keys *keys, ...);

// -----------------------------------------------------------------------------
// Parse a base64 encoded obstcp "advert". This can be used to extract the
// advertised obfuscated and TLS port numbers.
//
// The variable arguments come in pairs. The first of each pair is one of
// OBSTCP_ADVERT_* which are shared with obstcp_advert_create, above. However,
// since this is a parsing function, where, say, OBSTCP_ADVERT_OBSPORT is
// documented as having an int as its second element, for this function is
// would be a pointer to an int.
//
// The variable list must be terminated with OBSTCP_ADVERT_END.
//
// For elements which aren't found a special value is used to denote this. For
// port numbers, this value is 0.
//
// input: the base64 encoded banner
// length: the number of bytes in @input (not inc \n etc)
// returns: 1 on success, 0 on parse error.
// -----------------------------------------------------------------------------
int obstcp_advert_parse(const char *input, unsigned length, ...);

// -----------------------------------------------------------------------------
// This is the crypto context for a given direction of data
// -----------------------------------------------------------------------------
struct obstcp_half_connection {
  uint8_t  keystream[64];  // keystream bytes
  unsigned used;  // number of bytes of @keystream used
  uint32_t input[16];  // salsa20 context
};

// -----------------------------------------------------------------------------
// Server interfaces...
//
// These functions are designed to be used by the 'server' side of the
// connection. It's up to the user of this library to decide which side is the
// server, it doesn't have to correspond to the sockets API notion of a server,
// although it's expected that it usually will.

struct obstcp_server_ctx {
  const struct obstcp_keys *keys;
  union {
    struct {
      uint8_t buffer[386];
      unsigned read;
    } a;
    struct {
      struct obstcp_half_connection in;
      struct obstcp_half_connection out;
    } b;
  } u;

  int state;
  char frame_open, frame_valid;
};

// -----------------------------------------------------------------------------
// Setup a context structure. This must be called before any other operations
// on the context struture.
// -----------------------------------------------------------------------------
void obstcp_server_ctx_init(struct obstcp_server_ctx *ctx,
                            const struct obstcp_keys *keys);

// -----------------------------------------------------------------------------
// Read from a socket
// fd: the file descriptor to read from
// buffer: buffer to write data to
// len: number of bytes in @buffer
// ready: (output) on success, this is true if a MAC was successfully
//   calculated.
//
// Reading from a socket has two phases:
//   1) setup phase, before key agreement has completed. In this phase this
//      function with return -1 with errno set to EAGAIN until it has enough
//      data to complete key agreement.
//
//      If key agreement is successful, we move to phase two. Otherwise, we
//      return -1 and set errno to EPROTO.
//
//   2) In this phase we are reading application data from the socket. It may
//      be that the data is MAC protected. In this case, the read calls will
//      return positive byte counts, but *ready will be false on return. Once
//      the MAC has been read and checked *ready will be true. This means that
//      all the data since the last time ready returned true is valid and can
//      be processed. There cannot be > 16K of unready data.
//
//      Do not use this for application level framing since MAC may not be in
//      operation - in this case *ready is always set to true.
//
// Otherwise, this call returns like read(2) - i.e. 0 return means EOF etc. One
// exception is that this call will never return -1 with an errno of EINTR. The
// socket can be blocking or non-blocking.
//
// If you wish to know if key agreement has completed after calling this
// function, use obstcp_server_ready.
// -----------------------------------------------------------------------------
ssize_t obstcp_server_read(int fd, struct obstcp_server_ctx *ctx,
                           uint8_t *buffer, size_t len, char *ready);

// -----------------------------------------------------------------------------
// Returns true iff key agreement has completed.
// -----------------------------------------------------------------------------
int obstcp_server_ready(const struct obstcp_server_ctx *ctx);

// -----------------------------------------------------------------------------
// Write examples:
//
// Simple case: in this case, the application is writing blocks of data to a
// socket. It would normally use a series of write() calls. The socket is
// blocking.
//
// ssize_t write_data(int fd, uint8_t *data, size_t len) {
//   struct iovec[3] iov;
//
//   const unsigned n = obstcp_server_encrypt(ctx, data, data, len, 0);
//
//   switch (obstcp_server_ends(ctx, &iovec[0], &iovec[2])) {
//   case -1:
//     abort();
//   case 0:
//     return write(fd, data, n);
//   default:
//     iovec[1].iov_base = data;
//     iovec[1].iov_len = n;
//     return writev(fd, iovec, 3);
//   }
// }
//
// Note that, for non-blocking sockets it's up to the application to deal with
// feeding the data to the socket. However, obstcp_server_ends may be called
// repeatedly to get the same data.
// -----------------------------------------------------------------------------

// -----------------------------------------------------------------------------
// This library doesn't perform writing as such, instead call this function to
// encrypt the data in preparation for writing.
//
// output: encrypted data is written here (maybe equal to @buffer)
// buffer: data to be encrypted
// len: the length, in bytes, of @buffer and @output.
// frame_accum: if true, more data is next so don't close out the frame.
// returns: the number of bytes encrypted
//
// A frame can cover, at most, 16384 bytes, so if you repeatedly call this
// function with frame_accum true it may return less than @len bytes to denote
// that the frame is full.
//
// NB that the peer cannot process anything until a frame's worth of data has
// been processed. Thus, if this is the end of a message, and you expect the
// client to answer you, you must close out the frame.
//
// Before writing anything to a socket you must call obstcp_server_ends to get
// the prepended and appended data for the frame.
// -----------------------------------------------------------------------------
ssize_t obstcp_server_encrypt(struct obstcp_server_ctx *ctx,
                              uint8_t *output, const uint8_t *buffer, size_t len,
                              char frame_accum);

// -----------------------------------------------------------------------------
// The protocol may need to prepend and append data to a frame. Call this
// function to get that data. You pass it two iovec's: one to be sent at the
// beginning of the frame and one to be sent at the end.
//
// returns: -1 on error, or the number of iovecs with data.
//
// If this function returns -1 it means there has been a programming error on
// the part of the library user. Either you haven't closed out a frame or you
// haven't opened one. Aborting the process is reasonable in this case.
//
// Note that some connections may not having framing, thus this function may
// return 0. It's worth detecting this and falling back to a simple write()
// rather than a writev() in this case.
// -----------------------------------------------------------------------------
int obstcp_server_ends(struct obstcp_server_ctx *ctx, struct iovec *start,
                       struct iovec *end);

// -----------------------------------------------------------------------------

// -----------------------------------------------------------------------------
// Client interfaces...

struct obstcp_client_ctx {
  uint8_t buffer[386];
  unsigned n;

  struct obstcp_half_connection in;
  struct obstcp_half_connection out;

  int state;
  ssize_t frame_size;
  char frame_open;
};

// -----------------------------------------------------------------------------
// keys: a keyset for the client. Only the default key will be uesd.
// advert: a base64-encoded advert for the server. This can be obtained via TXT
//   records in DNS or any other side channel.
// len: length of @advert, in bytes.
// random: 16 random bytes, never to be reused
// returns: 1 on success, 0 on failure (in which case errno is set)
//
// Obviously, the advert can fail to parse, in which case errno is set to
// EINVAL.
// -----------------------------------------------------------------------------
int obstcp_client_ctx_init(struct obstcp_client_ctx *ctx, struct obstcp_keys *keys,
                           const char *advert, unsigned len,
                           const uint8_t *random);

// -----------------------------------------------------------------------------
// After connecting the socket you must call this function to get the banner
// that is to be sent to the server. This function must be called exactly once.
// To do otherwise will trigger an assertion failure. The banner returned in
// the iovec must be completed enqueued to the kernel's socket buffer before
// doing anything else with this context object.
// -----------------------------------------------------------------------------
void obstcp_client_banner(struct obstcp_client_ctx *ctx,
                          struct iovec *out);

// -----------------------------------------------------------------------------
// Same as the server version
// -----------------------------------------------------------------------------
ssize_t obstcp_client_read(int fd, struct obstcp_client_ctx *ctx,
                           uint8_t *buffer, size_t len, char *ready);

// -----------------------------------------------------------------------------
// Same as the server version
// -----------------------------------------------------------------------------
ssize_t obstcp_client_encrypt(struct obstcp_client_ctx *ctx,
                              uint8_t *output, const uint8_t *buffer, size_t len,
                              char frame_accum);

// -----------------------------------------------------------------------------
// Same as the server version
// -----------------------------------------------------------------------------
int obstcp_client_ends(struct obstcp_client_ctx *ctx, struct iovec *start,
                       struct iovec *end);

// -----------------------------------------------------------------------------

#endif  // LIBOBSTCP_H

2008-08-19T22:00:00.000-07:00

The current state of play:

I've made curve25519-donna constant time, and, at the request of DJB, I'll be making it public domain too. I've been told that a group has it working in 165us and I just can't even get close to that. I spent a day rewriting the field multiplication using SSE2, but that didn't help at all. Nevermind, that group aren't releasing their source it seems so they don't count :)
I'm working on getting djbdns's client library in a useful state in order to integrate into Firefox. (did you know that libresolv doesn't parse DNS packets for you? How useless!) So I spent today reviewing 1000s of lines of DJB's code and adding comments.

The point of (2) is that my current plans are revolving around these ideas:

Keeping the server's public key in a TXT record for _obs_80.example.com. Why TXT? Because it's better supported. Thus clients will need a real resolver library, hence my work on DJB's code.

However, this presents some problems, mostly in the face of transproxies: If we were to connect and write a NUL (to escape HTTP) and then start with encrypting the usual HTTP stream, a transproxy will probably barf. But users can't get around them! (I need to test this with Squid tomorrow).

So one solution is for the TXT record to be able to indicate a separate port number. However, a separate port is a real pain for some sites to setup. So we might need something different. I think that might be encapsulation like:

HEAD / HTTP/1.1
Host: example.com
X-ObsReq: a4bfdz33456sdfFdsFA...
X-TransProxyDetect: flowers

The X-ObsReq carries the encrypted request, so that we don't burn a RTT on the probe. The hope is that transproxies will remove the header that they don't understand (again, have to test with Squid). The server recognises the headers and replies with an encrypted reply in the expected case. However, if a transproxy removed the header, it sends a normal reply. Thus the client can detect the proxy and back off (sadly, probably forever).

Also, is the TXT requirement too much for some? Do we need cross session state as well to get the server keys to the client? (The idea here being that a server can advertise it's keys in an unencrypted reply and the client caches the key, on disk, for some time.)

Again, it's much more messy furthur up the stack, although we don't need kernel changes.

Comments welcome. Email or comments on the post.

(updated: before I go to sleep, it strikes me that a series of POSTs with uncachable replies may work better)

Sorry folks, I think Obfuscated TCP died

2008-08-15T11:07:00.000-07:00

Introduction: "Obfuscated TCP is a backwards-compatible modification to the TCP protocol which adds opportunistic encryption. It's designed to hamper and detect large-scale wiretapping and corruption of TCP traffic on the Internet" [1].

I'm afraid that the IETF wouldn't go for it. You can see the mailing list archives if you wish, but it's a lot of email.

In short, I requested an option in order to use as a switch at the application layer. (Thus, you would still be able to connect to an HTTP server and it could upgrade transparently.) This, it was felt, was a laying violation and the working group members didn't feel there was sufficient motivation to allow it.

Of course, I'm saddened that they didn't agree. I'm also a little relieved that it's done one way or another. Dealing with defending the draft morning, noon and night for days on end was shockingly draining.

Obfuscated TCP might regenerate, Time Lord like, but it will end up in a very different form if it does. Below is a list of possible futures. To be more complete, it includes options that I've already decided against. Also, it's in some sort of order, worse first. You'll also note that some of these are sacrificing the original, TCP wide goals for a specific HTTP target.

Ignore the IETF and just take the option number. This is a really nasty thing to do. I could probably do it, at least as far as getting the patch into the Linux mainline, but it would really hurt the chances of future adoption and the IETF would be mad at me.
Stuff the needed extensions in somewhere else in the header. This is possible, if icky. A SYN frame typically has 8 bytes unused (the ACK and the timestamp echo). The SYNACK is more troublesome, but I might be able to find somewhere. It would be a painful hack.
Go back to the first design: long options and all in kernel. Long options requires IETF permission again and I've already been bitten by that. Also, it's known that there's little support in the IETF for long options. Additionally, putting all the crypto in kernel is a nasty wort on the TCP stack. This was a bad design which I dismissed early on; it's still a bad design.
Concurrent SYNs. (Idea from Joe Touch) define a new default HTTP port and have web browsers race two connection opens, one to each port. If the old and the new both come back, close the old. I feel this is fairly ugly, probabilistic and wasteful.
Burn a round trip. This is the general advice of the IETF. It's also the TLS upgrade method suggested in RFC2817 (which went nowhere). The problem is that, if browsers started deploying this, it would cost a round trip everywhere. Amazon, Google etc would go balistic because they know how much latency matters. IETF members, sadly, don't. I, personally, couldn't support this.
Exploit connection history. The idea would be that browsers connect to a new site as they do now, but HTTP headers can advertise support. Then, for future connections to the same site, the browser can optimistically try an obfuscated request, wrapped in HTTP such that it only costs a RTT in the (hopefully rare) case that the optimism was unfounded. Problems here are that the interaction with pipelining is complicated, it's ugly and it doesn't work will with incremental deployment for a single site (if you have many servers). It doesn't, however, require TCP changes. Of anything, this seems like the least bad.

I'm going to take a few days to think about it. Comments are welcome: agl AT imperialviolet DOT org.

Special thanks also go to Dave McBride for his support of the project thus far. Also to my generous employer.

2008-08-13T14:05:00.001-07:00

The aforementioned curve25519 implementation has been released

2008-08-05T17:18:00.000-07:00

I promised a new release of libobstcp today, but it's not going to happen I'm afraid - maybe Thursday. However, you do get a new draft:

http://www.ietf.org/internet-drafts/draft-agl-tcpm-sadata-01.txt

Also, I've written an x86-64 version of curve25519. Previously, I had a C version that was under half the speed of djb's version. But djb's version was written in 32-bit asm, meaning that it couldn't link with 64-bit code. My 64-bit version is about 10% faster than djb's version. Source code coming soon.

2008-08-01T13:50:00.000-07:00

Things only appear to be quiet. In the backgroud, I've been madly working on TCP AO support, a new SYNACK payloads draft, getting design reviews etc.

And a thanks is in order to Dave McBride for being the only person (as far as I know) to actually test the epsilon1 release!

The plan, currently, is to move ahead with TCP AO support because the IETF draft isn't ready yet. The code is in libobstcp, but #ifdef'ed out.

So I'll be working on a smaller patch for 2.6.26 which just implements SYNACK payloads. The major blocking factor at the moment is getting the IETF to assign an options number.

The new draft and patch should be out Tuesday.

First testing release

2008-07-23T11:31:00.000-07:00

I've just put up the first testing release, which I'm not even calling an alpha:
http://code.google.com/p/obstcp/wiki/Testing. If you can patch and build a kernel, please try it out. I'll be hanging out on #obstcp on OFTC.net today.

2008-07-18T17:23:00.000-07:00

TCP-AO experimental patches

2008-07-15T13:00:00.000-07:00

2008-07-11T17:18:00.000-07:00

Today:

The userspace libobstcp is looking good. Current source is checked into the svn (http://code.google.com/p/obstcp)
Patched lighttpd to use libobstcp - pretty easy, although I cheated a little by patching its writev backend rather than the (more complex) aio-sendfile one.
Patched libevent's httpd to use libobstcp and wrote a very simple webserver using it which echos the obfuscation state of the connection
Finished up the SYNACK payload draft (for now, there will be changes in the future) - see last post
Working on setting up a firefox build so that I can patch libobstcp into Firefox. That'll be quite a task

2008-07-11T10:57:00.000-07:00

New draft: draft-agl-tcpm-sadata-00

That draft specifies the stack changes to enable the current, mostly userspace, ObsTCP. My experimental version of the kernel patch comes in at just 150 lines of additional code. Also, it's currently working between my laptop and my home computer through two NATs. The major omission, currently, is that the packets aren't signed. I'm hoping that TCP-AO will take care of that at some point in the future. For now, I'm moving ahead with encryption only.

2008-07-08T16:54:00.000-07:00

I like header files which tell you everything you need to know about the library. Here's the libobstcp one:


// -----------------------------------------------------------------------------                                                                              
// Perform global setup. This must be called exactly once for a given process.                                                                                
//
// private_key: If non-NULL, this must be a 32-byte private key. Otherwise, the                                                                               
//   private key is taken from /dev/urandom. The private key is free form                                                                                     
//   random data. It will be tweaked to be a valid private key.
// -----------------------------------------------------------------------------                                                                              
void obstcp_init(const void *private_key);

// -----------------------------------------------------------------------------                                                                              
// Write the current private key to the given buffer. Note that the private key                                                                               
// may not be exactly equal to the private key given to obstcp_init because not
// every random string is a valid private key.
//
// private_key: a 32-byte buffer
// -----------------------------------------------------------------------------                                                                              
void obstcp_private_key_get(void *private_key);                                                                                                               

// -----------------------------------------------------------------------------                                                                              
// Write the current public key to the given buffer                                                                                                           
//
// public_key: a 32-byte buffer
// -----------------------------------------------------------------------------                                                                              
void obstcp_public_key_get(void *public_key);                                                                                                                 

// -----------------------------------------------------------------------------                                                                              
// For a client connection:                                                                                                                                   
//   * Create an obstcp_ctx object, either on the stack or on the heap. This
//     must persist for the length of the connection.                                                                                                         
//   * Call obstcp_ctx_init_client with a socket, before connect()ing the
//     socket
//   * You must complete key exchange before the server can write to you.                                                                                     
//     This involves writing a small amount of data. If you use obstcp_write,                                                                                 
//     it will happen automatically. Otherwise you can call obstcp_kx_write to                                                                                
//     write the data. Once the kernel has accepted the data,
//     obstcp_kx_complete will return non-zero.
//   * Then use obstcp_read and obstcp_write just as you would use read and                                                                                   
//     write. If the server doesn't support obfuscation, these are just pass                                                                                  
//     through functions.
//
// For a server connection:                                                                                                                                   
//   * Create and bind a socket                                                                                                                               
//   * Call obstcp_setup_listening on the socket.                                                                                                             
//   * Accept a connection.
//   * Create an obstcp_ctx object, either on the stack or on the heap. This                                                                                  
//     must persist for the length of the connection.                                                                                                         
//   * Call obstcp_ctx_init_server on the *accepted* socket.
//   * Use obstcp_read and obstcp_write as you would use read and write. If                                                                                   
//     anything was unsupported or failed, these will just work in pass through                                                                               
//     mode.
// -----------------------------------------------------------------------------    

// -----------------------------------------------------------------------------                                                                              
// The per-connection state.                                                                                                                                  
//
// Multithreading: no two threads can be using the same obstcp_ctx at the same                                                                                
// time. It's up to the user to ensure this.                                                                                                                  
// -----------------------------------------------------------------------------                                                                              
struct obstcp_ctx {
  uint8_t  state;
  uint8_t  reason;
 
  uint32_t input[16];                                                                                                                                         
                                                                                                                                                              
  uint8_t  in_keystream[128];                                                                                                                                 
  unsigned in_used;                                                                                                                                           
  uint64_t in_seq;
 
  uint8_t  out_keystream[128];                                                                                                                                
  unsigned out_used;                                                                                                                                          
  uint64_t out_seq;
};
 
// -----------------------------------------------------------------------------                                                                              
// Setup a socket (after bind, but before listen) to enable obfuscation.                                                                                      
//
// Returns: non-zero if the kernel doesn't support obsfuscation. You can ignore                                                                               
//   this because everything else will drop into pass through mode in this                                                                                    
//   case.
// -----------------------------------------------------------------------------                                                                              
char obstcp_setup_listening(int fd);                                                                                                                          

// -----------------------------------------------------------------------------                                                                              
// Setup a context structure to start processing a new connection.                                                                                            
//
// fd: a file descriptor to a TCP socket, freshly accepted.
// -----------------------------------------------------------------------------
void obstcp_ctx_init_client(struct obstcp_ctx *ctx, int fd);

// -----------------------------------------------------------------------------
// Setup a server socket (after bind, but before listen) to support
// obfuscation.
// -----------------------------------------------------------------------------
void obstcp_ctx_init_server(struct obstcp_ctx *ctx, int fd);

// -----------------------------------------------------------------------------
// Read from the given file descriptor and decrypt. Note that, at the beginning
// of the connection, this function may return -1 and set errno to EAGAIN to
// reflect the fact that some network data is consumed by key setup. All other
// behaviour matches read(2).
// -----------------------------------------------------------------------------
ssize_t obstcp_read(struct obstcp_ctx *ctx, int fd, void *buf, size_t count);

// -----------------------------------------------------------------------------
// Encrypt the data to a buffer on the stack and write to the network. All
// other behaviour matches write(2)
// -----------------------------------------------------------------------------
ssize_t obstcp_write(struct obstcp_ctx *ctx, int fd, const void *buf,
                     size_t count);

// -----------------------------------------------------------------------------
// If obstcp_kx_complete returns zero, we still need to write data to complete
// the key exchange. To write as much as possible, call this function.
// Afterwards one can call obstcp_kx_complete to see if the exchange is
// complete.
// -----------------------------------------------------------------------------
void obstcp_kx_write(int fd, struct obstcp_ctx *ctx);

// -----------------------------------------------------------------------------
// Return non-zero iff key exchange has completed, or failed. Either way, the
// host doesn't need to read/write any more data for key exchange.
// -----------------------------------------------------------------------------
char obstcp_kx_complete(const struct obstcp_ctx *ctx);

#define OBSTCP_NOT_ESTABLISHED  0
#define OBSTCP_MAYBE            1
#define OBSTCP_ESTABLISHED      2
// -----------------------------------------------------------------------------
// Return if obfuscation is active on the given connection.
//
// Returns:
//   OBSTCP_NOT_ESTABLISHED: Connection is pass through mode. Call
//     obstcp_failure_reason to find out why
//   OBSTCP_MAYBE: (client side) Key exchange hasn't completed yet.
//   OBSTCP_ESTABLISHED: Key exchange complete. The connection will be
//     obfuscated
// -----------------------------------------------------------------------------
char obstcp_established(const struct obstcp_ctx *ctx);

#define OBSTCP_NO_KERNEL        0
#define OBSTCP_NOT_OFFERED      1
#define OBSTCP_KX_FAILURE       2
// -----------------------------------------------------------------------------
// If obstcp_established returned OBSTCP_NOT_ESTABLISHED, then one can call
// this function to find out what went wrong.
//
// Returns:
//   OBSTCP_NO_KERNEL: The kernel doesn't support obfuscation
//   OBSTCP_NOT_OFFERED: (server side) client didn't request obfuscation
//   OBSTCP_KX_FAILURE: key exchange failed (protocol error)
// -----------------------------------------------------------------------------
char obstcp_failure_reason(const struct obstcp_ctx *ctx);

A small change in direction

2008-07-08T11:05:00.000-07:00

I now believe that I was previously too quixotic about getting changes into TCP and I'm exploring a different approach for now. Previously, the kernel handled almost everything: key exchange (using long options), encryption and signing. Now I'm leaning towards a setup where the kernel provides a generic way to include a payload in SYNACK packets. This turns up in normal read() calls in userspace (if userspace has requested it). Now, the key exchange can be performed in userspace, as can the encryption and we end up with less TCP changes.Signing still needs to be performed in the kernel, however, as it needs to protect the whole packet (to stop RST attacks etc). For this, I'm hoping that the TCP-AO standard (which replaces TCP MD5) will suffice. Sadly, the TCP-AO draft authors are being very quiet.All in all, I don't expect a lot of movement until the fall IETF meeting, which I hope to attend.There will be kernel patches before then, however.

2008-07-01T10:14:00.000-07:00

Long options submitted to TCPM working group of the IETF for discussion:
http://www.ietf.org/mail-archive/web/tcpm/current/msg03677.html

2008-06-27T11:08:00.001-07:00

New draft replaces the old Jumbo options draft that I did: draft-eddy-tcp-loo-04.html

2008-06-24T16:37:00.000-07:00

I've posted some of the new patches to netdev - the kernel mailing list for such things:

2008-06-19T12:57:00.000-07:00

More motivation: