Re: [Openvpn-devel] [PATCH v3] Floating: Add support for floating in TLS mode

[Gert Doering]

Hi,

On Fri, Jan 03, 2014 at 02:28:51PM +0100, Arne Schwabe wrote:
> > 2) What you mean by "hack"? Do you mean new packet format or something else?
> The byte juggling the compress does.

Actually the "compress byte swap hack" is for the de-crypted material,
while *this* discussion is concernced about the encrypted material, which
is also unaligned and also wants a byte swap hack :-)

What I'd like to see is a definition of the new data frame format from
James (with and without session ID), and then we can go and hack that in
- but before we agree on the frame format, we don't really know what to
implement.

Meeting topic... (Samuli, are you listening?).

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpFDMooLgVTA.pgp
Description: PGP signature

Re: [Openvpn-devel] [PATCH v3] Floating: Add support for floating in TLS mode

[Arne Schwabe]

Am 03.01.14 12:58, schrieb Lev Stipakov:
> Hi Arne,
>
> I am researching how "session id" can be added to packet. Could you please 
> clarify the statement "If we choose the session id to be 3 or 7 byte we 
> would not need the "hack" for the packets with
> session id." ?
>
> I am currently at very beginning, so questions might look odd.
>
> 1) "3 or 7" - does it mean byte's ordinal number in packet or length of 
> session id in bytes?
One header byte +3 byte or +7 byte = 32 bit aligment.
>
> 2) What you mean by "hack"? Do you mean new packet format or something else?
The byte juggling the compress does.
> 3) I am trying to comprehend protocol format reading 
> http://openvpn.net/index.php/open-source/documentation/security-
> overview.html and looking at wireshark capture results. Where exactly 
> session id field should be placed?
Not yet decided :)

Arne

Re: [Openvpn-devel] [PATCH v3] Floating: Add support for floating in TLS mode

[Andre Valentin]

Hi!

On 30.12.2013 18:31, Arne Schwabe wrote:

For negoating the packet format the client would submit something like
IV_CLNT_SUPPORT 1 or similar (look at the IV_SNAPPY, IV_LZO for
compression) to tell the server the supported format and the server
would push a packet-format 1 or something similar like that. For a first
prototype implementation having only the packet-format 1 is probably
good enough.


I'm sorry, but this a bit too much for me to help in this case. If support
for testing is needed, I will do that!

--
With kind regards,
André Valentin
Projektkoordination / Systemadministration

MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
Fon: +49 (521) 95945-0 | Fax -18
URL: http://www.marcant.net | http://www.global-m2m.com

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238
___
CONFIDENTIALITY NOTICE
The contents of this email are confidential to the ordinary user of the
email address to which it was addressed and may also be privileged. If
you are not the addressee of this email you may not copy, forward,
disclose or otherwise use it or any part of it in any form whatsoever.
If you have received this email in error please email the sender by
replying to this message.

Re: [Openvpn-devel] [PATCH v3] Floating: Add support for floating in TLS mode

[Lev Stipakov]

Hi Arne,

I am researching how "session id" can be added to packet. Could you please 
clarify the statement "If we choose the session id to be 3 or 7 byte we 
would not need the "hack" for the packets with
session id." ?

I am currently at very beginning, so questions might look odd.

1) "3 or 7" - does it mean byte's ordinal number in packet or length of 
session id in bytes?

2) What you mean by "hack"? Do you mean new packet format or something else?

3) I am trying to comprehend protocol format reading 
http://openvpn.net/index.php/open-source/documentation/security-
overview.html and looking at wireshark capture results. Where exactly 
session id field should be placed?

-Lev

Re: [Openvpn-devel] [PATCH v3] Floating: Add support for floating in TLS mode

[Heikki Hannikainen]

On Mon, Dec 23, 2013 at 4:43 PM, André Valentin  wrote:
> On 23.12.2013 12:32, Gert Doering wrote:
>> We've discussed the patch on the Munich Hackathon, and we intend to do
>> it in a different way.  James wants to change the packet format for
>> data packets anyway (due to bad alignment in the current packet format),
>> and the new format would have the option to send the session ID in the
>> data packet as well, like "normally it's not sent, but if we have't heard
>> from the server longer than  time units, send a session ID so that
>> hmac-float will work".
>
> Of course, this is a better idea and should have less problems with scaling.
> But there should be an option for the client to always send the session id,
> so that there are no timeouts if the user decides to do so.

+1 to that - it'd be really neat if floating would work seamlessly
without timeouts + retransmissions. It'd be very useful on mobile
devices, which often get hit by NAT timeouts on UDP (around 30 or 60
seconds typically), switches between WIFI and 3G, and keepalive pings
with tight timers (sub-30-second range) consume a lot of battery.

The regular SSL session ID is maybe a bit long to be sent with each
and every packet, though.

Which other enhancements to the packet format are necessary? I
gathered that the encrypted data needs to be aligned for AES-NI to
work, which probably means that either the packet headers need to be
padded so that the data starts on a nice word boundary, or that the
data packet needs to begin with the encrypted data and all the headers
need to be placed in the end of the packet. Right?

And then some backwards compatibility in the handshake - it'd be good
if old clients could optionally be allowed on new servers using the
new packet format.

>> This code has not been written yet, though, and we have no specific
>> timelines when it will happen.
> So what does this mean for my work and the current format? Is there still
> a possibility that it will be integrated for the 'old packet format'?

We could also start working on the new packet format, do a prototype
if you'd like. Just need to figure out what the exact requirements
would be.

 - Hessu

Re: [Openvpn-devel] [PATCH v3] Floating: Add support for floating in TLS mode

[André Valentin]

Hi!

On 23.12.2013 12:32, Gert Doering wrote:
> We've discussed the patch on the Munich Hackathon, and we intend to do
> it in a different way.  James wants to change the packet format for
> data packets anyway (due to bad alignment in the current packet format),
> and the new format would have the option to send the session ID in the
> data packet as well, like "normally it's not sent, but if we have't heard
> from the server longer than  time units, send a session ID so that
> hmac-float will work".
Of course, this is a better idea and should have less problems with scaling.
But there should be an option for the client to always send the session id,
so that there are no timeouts if the user decides to do so.

> This code has not been written yet, though, and we have no specific 
> timelines when it will happen.
So what does this mean for my work and the current format? Is there still
a possibility that it will be integrated for the 'old packet format'?

André

--
With kind regards,
André Valentin
Projektkoordination / Systemadministration

MarcanT GmbH, Ravensberger Str. 10 G, D - 33602 Bielefeld
Fon: +49 (521) 95945-0 | Fax -18
URL: http://www.marcant.net | http://www.global-m2m.com

Geschäftsführer: Thorsten Hojas
Handelsregister: AG Bielefeld, HRB 35827 USt-ID Nr.: DE 190203238

[Openvpn-devel] [PATCH v3] Floating: Add support for floating in TLS mode

[Andre Valentin]

Hi!

This updates my floating patch to current trunk. I tested it for over 2 weeks 
now.
Please review!

André



--- Begin Message ---
>From bab19ca1b1f1b89dca00ca18e258dbe1dacf4891 Mon Sep 17 00:00:00 2001
From: avalentin 
List-Post: openvpn-devel@lists.sourceforge.net
Date: Tue, 17 Dec 2013 21:51:25 +
Subject: [PATCH] Floating: Add support for floating in TLS mode
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Add support for floating in tls mode using the HMAC of a packet. It costs
a roundtrip through the client list. Because it is bases on the HMAC, it
shoudl be secure. The HMAC calculation is very fast, (~700k/s), so this
won't be a problem for medium size servers.


URL: https://community.openvpn.net/openvpn/ticket/49
Signed-off-by: André Valentin 
---
 src/openvpn/crypto.c  |   55 
 src/openvpn/crypto.h  |4 ++
 src/openvpn/mudp.c|  112 +
 src/openvpn/mudp.h|   18 
 src/openvpn/options.c |3 ++
 src/openvpn/perf.h|2 +
 src/openvpn/ssl.c |   28 +
 src/openvpn/ssl.h |6 +++
 8 files changed, 228 insertions(+)

diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
index c4c356d..6446eee 100644
--- a/src/openvpn/crypto.c
+++ b/src/openvpn/crypto.c
@@ -389,6 +389,61 @@ openvpn_decrypt (struct buffer *buf, struct buffer work,
 }

 /*
+ * This verifies if a packet and its HMAC fit to a crypto context.
+ *
+ * On success true is returned.
+ */
+bool
+crypto_test_hmac (struct buffer *buf,
+  const struct crypto_options *opt)
+{
+  struct gc_arena gc;
+  gc_init ();
+  int offset = 1;
+
+  if (buf->len > 0 && opt->key_ctx_bi)
+{
+  struct key_ctx *ctx = >key_ctx_bi->decrypt;
+
+  /* Verify the HMAC */
+  if (ctx->hmac)
+{
+  int hmac_len;
+  uint8_t local_hmac[MAX_HMAC_KEY_LENGTH]; /* HMAC of ciphertext 
computed locally */
+
+  hmac_ctx_reset(ctx->hmac);
+
+  /* Assume the length of the input HMAC */
+  hmac_len = hmac_ctx_size (ctx->hmac);
+
+  /* Authentication fails if insufficient data in packet for HMAC */
+  if ((buf->len - offset) < hmac_len) 
+{
+  gc_free ();
+  return false;
+}
+
+  hmac_ctx_update (ctx->hmac, BPTR (buf) + offset + hmac_len, BLEN 
(buf) - offset - hmac_len);
+  hmac_ctx_final (ctx->hmac, local_hmac);
+
+  /* Compare locally computed HMAC with packet HMAC */
+  if (memcmp (local_hmac, BPTR (buf) + offset, hmac_len))
+{
+  gc_free ();
+  return false;
+}
+
+  gc_free ();
+  return true;
+}
+}
+
+  gc_free ();
+  return false;
+}
+
+
+/*
  * How many bytes will we add to frame buffer for a given
  * set of crypto options?
  */
diff --git a/src/openvpn/crypto.h b/src/openvpn/crypto.h
index 3b4b88e..296519a 100644
--- a/src/openvpn/crypto.h
+++ b/src/openvpn/crypto.h
@@ -279,6 +279,10 @@ bool openvpn_decrypt (struct buffer *buf, struct buffer 
work,
  const struct crypto_options *opt,
  const struct frame* frame);

+
+bool crypto_test_hmac (struct buffer *buf,
+   const struct crypto_options *opt);
+   
 /** @} name Functions for performing security operations on data channel 
packets */

 void crypto_adjust_frame_parameters(struct frame *frame,
diff --git a/src/openvpn/mudp.c b/src/openvpn/mudp.c
index 3468dab..834d386 100644
--- a/src/openvpn/mudp.c
+++ b/src/openvpn/mudp.c
@@ -63,6 +63,12 @@ multi_get_create_instance_udp (struct multi_context *m)
{
  mi = (struct multi_instance *) he->value;
}
+  else if (multi_find_instance_udp (m,  mi, real))
+{
+  /* found instance */
+  msg (D_MULTI_LOW, "MULTI: Floated with HMAC authentication to a new 
client address: %s", 
+   print_link_socket_actual (>top.c2.from, ));
+}
   else
{
  if (!m->top.c2.tls_auth_standalone
@@ -111,6 +117,112 @@ multi_get_create_instance_udp (struct multi_context *m)
 }

 /*
+ * Find a client instance based on the HMAC, if auth is used. The function 
+ * iterates over all peers to find a fitting instance. The found instance is
+ * updated with the current peer address.
+ * If the instance doesn't exist, return false.
+ */
+bool
+multi_find_instance_udp (struct multi_context *m,  struct multi_instance *mi, 
+ struct mroute_addr real)
+{
+  struct gc_arena gc = gc_new ();
+  struct hash *hash = m->hash;
+  struct hash_element *he;
+  const uint32_t hv = hash_value (hash, );
+  struct hash_bucket *bucket = hash_bucket (hash, hv);
+  struct hash_iterator hi;
+  struct mroute_addr real_old;
+  int op;
+  uint8_t c;
+  
+  perf_push (PERF_MULTI_FIND_INSTANCE);
+  
+  /* try to