Re: [Openvpn-devel] server support for UV_ variables still not present in 2.3.6?

[Gert Doering]

Hi,

On Tue, Mar 03, 2015 at 08:54:08AM +1300, Jason Haar wrote:
> Back in Aug 2014, I needed the server to support exporting the UV_*
> variables the client sets into external programs the server calls on
> client-connect, so was told to try out openvpn-2.3_git - which had that
> missing code. So I did a clone of that and off I went
> 
> I've been happily running on that for some time now - but just tried out
> 2.3.6 - and discovered that support still wasn't in there!
> 
> Was it dropped for some reason, or was/is 2.3_git not a true
> representation of what ended up in the official 2.3 series? The missing
> code was in src/openvpn/misc.c

2.3_git is a bit misleading, this is what will be 2.*4* - it was forked
off 2.3.0, and after that, 2.3.x only got bugfixes and "long term 
compatibility / stability" changes, while git master = 2.3_git got the
big new features.

This one in particular sounds harmless but the actual code change is 
fairly invasive so we decided that it does not belong into 2.3.x (the
client side improvements, like IV_SSL_VERSION or whatever it's called,
went into 2.3.x :-)).

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


pgp_W2WHtPp8H.pgp
Description: PGP signature

[Openvpn-devel] server support for UV_ variables still not present in 2.3.6?

[Jason Haar]

Hi there

Back in Aug 2014, I needed the server to support exporting the UV_*
variables the client sets into external programs the server calls on
client-connect, so was told to try out openvpn-2.3_git - which had that
missing code. So I did a clone of that and off I went

I've been happily running on that for some time now - but just tried out
2.3.6 - and discovered that support still wasn't in there!

Was it dropped for some reason, or was/is 2.3_git not a true
representation of what ended up in the official 2.3 series? The missing
code was in src/openvpn/misc.c

Thanks

-- 
Cheers

Jason Haar
Corporate Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

[Openvpn-devel] [PATCH] Fast recovery when host is in unreachable network

[Lev Stipakov]

When client connects to the server which is in unreachable network (for
example hostname got resolved into ipv6 address and client has no ipv6),
throw SIGUSR1 and connect to the next server without waiting 60 seconds
for "TLS key negotiation failed".
---
 src/openvpn/forward.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index a3323e9..8eb8434 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -1090,6 +1090,7 @@ void
 process_outgoing_link (struct context *c)
 {
   struct gc_arena gc = gc_new ();
+  int error_code = 0;

   perf_push (PERF_PROC_OUT_LINK);

@@ -1177,6 +1178,7 @@ process_outgoing_link (struct context *c)
}

   /* Check return status */
+  error_code = openvpn_errno();
   check_status (size, "write", c->c2.link_socket, NULL);

   if (size > 0)
@@ -1193,6 +1195,14 @@ process_outgoing_link (struct context *c)
   /* if not a ping/control message, indicate activity regarding --inactive 
parameter */
   if (c->c2.buf.len > 0 )
 register_activity (c, size);
+
+  /* for unreachable network and "connecting" state switch to the next 
host */
+  if (size < 0 && ENETUNREACH == error_code && 
!tls_initial_packet_received (c->c2.tls_multi)
+ && c->options.mode == MODE_POINT_TO_POINT)
+   {
+ msg (M_INFO, "Network unreachable, restarting");
+ register_signal (c, SIGUSR1, "network-unreachable");
+   }
 }
   else
 {
-- 
1.9.1

[Openvpn-devel] [PATCH] Client-side handling of OCC_SERVER_EXIT

[Lev Stipakov]

When client receives OCC_SERVER_EXIT, it fires SIGUSR1 and switches to
the next server. Next server is defined as same remote with different IP
address if remote resolves into multiple addresses or next remote
otherwise.

This is a client-side only verion of "Notify clients about server's
exit/restart" patch.
---
 src/openvpn/occ.c | 7 +++
 src/openvpn/occ.h | 5 +
 2 files changed, 12 insertions(+)

diff --git a/src/openvpn/occ.c b/src/openvpn/occ.c
index ff48706..e8652de 100644
--- a/src/openvpn/occ.c
+++ b/src/openvpn/occ.c
@@ -390,6 +390,13 @@ process_received_occ_msg (struct context *c)
   c->sig->signal_received = SIGTERM;
   c->sig->signal_text = "remote-exit";
   break;
+
+case OCC_SERVER_EXIT:
+  msg (D_LOW, "RECEIVED OCC_SERVER_EXIT");
+  c->sig->signal_received = SIGUSR1;
+  c->sig->signal_text = "remote-server-exit";
+  c->options.no_advance = false;
+  break;
 }
   c->c2.buf.len = 0; /* don't pass packet on */
 }
diff --git a/src/openvpn/occ.h b/src/openvpn/occ.h
index 5d88cc9..8856c55 100644
--- a/src/openvpn/occ.h
+++ b/src/openvpn/occ.h
@@ -70,6 +70,11 @@
 #define OCC_EXIT   6

 /*
+ * Notifies clients that server is exiting/restarting
+ */
+#define OCC_SERVER_EXIT7
+
+/*
  * Used to conduct a load test command sequence
  * of UDP connection for empirical MTU measurement.
  */
-- 
1.9.1

[Openvpn-devel] [PATCH v2] Notify clients about server's exit/restart

[Lev Stipakov]

When server exits / restarts (gets SIGUSR1, SIGTERM, SIGHUP, SIGINT) and
explicit-exit-notify is set, server broadcasts new OCC_SERVER_EXIT command
to all clients and reschedules received signal in 2 secs.

When client receives OCC_SERVER_EXIT, it fires SIGUSR1 and switches to
the next server. Next server is defined as same remote with different IP address
if remote resolves into multiple addresses or next remote otherwise.

v2:
 - take into use explicit-exit-notify on the server side
 - OCC_SHUTTING_DOWN renamed to OCC_SERVER_EXIT
 - minor code prettifying

---
 src/openvpn/multi.c   | 66 +++
 src/openvpn/multi.h   | 14 ++-
 src/openvpn/occ.c |  8 +++
 src/openvpn/occ.h |  6 +
 src/openvpn/options.c |  7 ++
 src/openvpn/options.h |  3 ++-
 6 files changed, 93 insertions(+), 11 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 4412491..b0d0e08 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -396,6 +396,8 @@ multi_init (struct multi_context *m, struct context *t, 
bool tcp_mode, int threa
 t->options.stale_routes_check_interval, 
t->options.stale_routes_ageing_time);
   event_timeout_init (>stale_routes_check_et, 
t->options.stale_routes_check_interval, 0);
 }
+
+  m->deferred_shutdown_signal.signal_received = 0;
 }

 const char *
@@ -603,6 +605,25 @@ multi_close_instance (struct multi_context *m,
   perf_pop ();
 }

+void
+multi_broadcast_server_exit (struct multi_context *m)
+{
+  msg (D_LOW, "multi_broadcast_server_exit");
+
+  struct gc_arena gc = gc_new ();
+  struct buffer buf = alloc_buf_gc (BUF_SIZE (>top.c2.frame), );
+
+  buf_init (, FRAME_HEADROOM (>top.c2.frame));
+  buf_safe (, MAX_RW_SIZE_TUN (>top.c2.frame));
+  buf_write (, occ_magic, OCC_STRING_SIZE);
+
+  buf_write_u8 (, OCC_SERVER_EXIT);
+
+  multi_bcast (m, , NULL, NULL);
+
+  gc_free ();
+}
+
 /*
  * Called on shutdown or restart.
  */
@@ -1952,7 +1973,7 @@ multi_unicast (struct multi_context *m,
 /*
  * Broadcast a packet to all clients.
  */
-static void
+void
 multi_bcast (struct multi_context *m,
 const struct buffer *buf,
 const struct multi_instance *sender_instance,
@@ -2571,10 +2592,18 @@ multi_process_timeout (struct multi_context *m, const 
unsigned int mpp_flags)
   /* instance marked for wakeup? */
   if (m->earliest_wakeup)
 {
-  set_prefix (m->earliest_wakeup);
-  ret = multi_process_post (m, m->earliest_wakeup, mpp_flags);
+  if (m->earliest_wakeup == (struct 
multi_instance*)>deferred_shutdown_signal)
+   {
+ schedule_remove_entry(m->schedule, (struct schedule_entry*) 
>deferred_shutdown_signal);
+ throw_signal(m->deferred_shutdown_signal.signal_received);
+   }
+  else
+   {
+ set_prefix (m->earliest_wakeup);
+ ret = multi_process_post (m, m->earliest_wakeup, mpp_flags);
+ clear_prefix ();
+   }
   m->earliest_wakeup = NULL;
-  clear_prefix ();
 }
   return ret;
 }
@@ -2699,6 +2728,12 @@ multi_top_free (struct multi_context *m)
   free_context_buffers (m->top.c2.buffers);
 }

+bool
+is_exit_restart(int sig)
+{
+  return (sig == SIGUSR1 || sig == SIGTERM || sig == SIGHUP || sig == SIGINT);
+}
+
 /*
  * Return true if event loop should break,
  * false if it should continue.
@@ -2714,6 +2749,29 @@ multi_process_signal (struct multi_context *m)
   m->top.sig->signal_received = 0;
   return false;
 }
+  else if (proto_is_dgram(m->top.options.ce.proto) &&
+  is_exit_restart(m->top.sig->signal_received) &&
+  (m->deferred_shutdown_signal.signal_received == 0) &&
+  m->top.options.ce.explicit_exit_notification)
+{
+  /* broadcast OCC_SERVER_EXIT to clients */
+  multi_broadcast_server_exit(m);
+
+  /* schedule signal */
+  openvpn_gettimeofday (>deferred_shutdown_signal.wakeup, NULL);
+  struct timeval tv;
+  tv.tv_sec = 2;
+  tv.tv_usec = 0;
+  tv_add (>deferred_shutdown_signal.wakeup, );
+
+  m->deferred_shutdown_signal.signal_received = 
m->top.sig->signal_received;
+
+  schedule_add_entry (m->schedule, (struct schedule_entry *) 
>deferred_shutdown_signal,
+ >deferred_shutdown_signal.wakeup, 
compute_wakeup_sigma (>deferred_shutdown_signal.wakeup));
+
+  m->top.sig->signal_received = 0;
+  return false;
+  }
   return true;
 }

diff --git a/src/openvpn/multi.h b/src/openvpn/multi.h
index 32b89d2..d968626 100644
--- a/src/openvpn/multi.h
+++ b/src/openvpn/multi.h
@@ -57,6 +57,13 @@ struct multi_reap
 };


+struct deferred_signal_schedule_entry
+{
+  struct schedule_entry se;
+  int signal_received;
+  struct timeval wakeup;
+};
+
 /**
  * Server-mode state structure for one single VPN tunnel.
  *
@@ -172,6 +179,8 @@ struct multi_context {
* Timer object for stale route check
*/
   struct event_timeout stale_routes_check_et;
+
+  struct deferred_signal_schedule_entry 

Re: [Openvpn-devel] Add support for Keying Material Exporter [RFC 5705]

[daniel kubec]

Greetings Steffan, David and Gert

Thank you very much for your comments.

1) log level switched to D_TLS_DEBUG_MED
2) ekm_size removed, ekm_size != 0 condition is used instead.
3) changed to: exported_keying_material
4) minimum set to 16 bytes and maximum set to 4095 bytes.

Added 2 patches related to [RFC-5705] (code + docs).

Regards

Daniel

On 25 February 2015 at 23:39, Steffan Karger  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 23-02-15 17:28, David Sommerseth wrote:
>> On 23/02/15 17:18, Gert Doering wrote:
>>> On Mon, Feb 23, 2015 at 04:51:34PM +0100, Daniel Kubec wrote:
 Keying Material Exporter [RFC 5705] Patch rebased to actual
 master branch.
>>
>>> There definitely needs to be much(!) more documentation about
>>> this, maybe an extra .txt file under doc/ - I still(!) have *no*
>>> idea what this is useful for, or how to use it, so right now this
>>> is "extra code complexity with no well-explained gain" to me.
>>
>>> I understand that David understands this, but we really really
>>> need to have documentation understandable to non-crypto-geeks
>>> about it before it can go in.
>>
>> Fair enough.
>>
>> Daniel, would it be possible to add some docs and possibly a very
>> simple tool + plugin which could be used to demonstrate this
>> feature?  API docs should go into the docs/ sub-folder and the demo
>> code into sample/sample-plugins/.
>>
>> I suggest this comes as a separate patch, for patch
>> maintainability. Will probably be a good idea to even split docs
>> and demo/sample code into separate patches too?   (I'm not too keen
>> on big patches doing several things)
>
> Agreed that a bit more documentation would make this patch a lot more
> useful.
>
> - From a crypto perspective I think the codes is good. I do have a few
> practicals nits though:
>
> 1) Instead of using just M_DEBUG in dmsg(), please add a log level.
> Since you are printing derived key material, I think a rather high log
> level like D_TLS_DEBUG, or perhaps D_TLS_DEBUG_MED would make sense.
>
> 2) ekm_used in struct tls_options is equivalent to (ekm_size > 0). You
> could just get rid of this extra variable.
>
> 3) tls_binding_key might not be the best env var name. That name hints
> at the use case you have in mind for this mechanisms, but it does not
> cover all use cases, nor does it easily match to the
> 'keying-material-exporter' name of the option you introduce. Something
> like 'exported_keying_material' might me more appropriate.
>
> 4) We might want to enforce a minimum length for the exported keying
> material. How about 128 bits / 16 bytes? Just to prevent a user making
> a typo from ending up with ridiculously small keys.
>
> - -Steffan
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJU7k8PAAoJEJgCyj0AftKIWBUIAJPG7+nbNS9dRbwDzOA8NpBU
> d0ueiNskJ5gGTfeUoRZwPK/wSlxPtRP0j1wKg7ltwJOvgJM7MCewI2KNxobPE/BF
> PptAzH8PU2X8YHMRhbgfcER4CyvTlg/KUW5PEieL7c1zAjq5pkQJMqTNIToq51Wo
> bUmQOEdtPuY5J3PF/06NpnKr9ZigM2FiIpx+M+GOietav8MX7a4OrGQVPnaZQo6E
> rtwCfhVTAxeaitRsWiJjuvg5tJOCqbs7uC8imjNNM6kCZzSpfJkC1nDDP6g+JAOa
> mTKgrbKS1HWYDlsE8kaSg8LLADWFix8Q2lTtGeXGUlbITtHYEE2n3DEAXqtgr4I=
> =vOYB
> -END PGP SIGNATURE-
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel


openvpn-rfc5705.patch
Description: Binary data


openvpn-rfc5705-doc.patch
Description: Binary data