Re: [Openvpn-devel] man page and options.c contradict

[Gert Doering]

Hi,

On Thu, Oct 23, 2014 at 02:04:10PM -0600, Reinoud Koornstra wrote:
> In my understanding, there is no client or server in p2p mode. 

True, as far as the OpenVPN protocol is concerned.

False, as far as TCP is concerned, because you MUST have a client and a
server in TCP - it's not a symmetric protocol (unlike UDP).

So, OpenVPN in peer-to-peer mode will need --tcp-client on one side and
--tcp-server on the other (it doesn't matter which one is which, as
as soon as the TCP connection is up, it's "peer to peer" inside)

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


pgpx_tS8idRDG.pgp
Description: PGP signature

Re: [Openvpn-devel] man page and options.c contradict

[Reinoud Koornstra]

In my understanding, there is no client or server in p2p mode. In this case
you're trying to establish a secure connection between two gateways using
openvpn like a tunnel. Is my understanding wrong about this? Besides this,
I still stumble upon the issue of specifying just tcp in the remote
section, options.c doesn't allow you to do it.
Or am I missing a part where it doesn't allow this in MODE-POINT-TO-POINT?
On Oct 23, 2014 1:28 PM, "Gert Doering"  wrote:

> Hi,
>
> On Thu, Oct 23, 2014 at 01:24:45PM -0600, Reinoud Koornstra wrote:
> > The idea in my case is to have a point-to-point connection where both
> hosts
> > listen on port 443 tcp instead of port 1194 udp to setup the
> point-to-point
> > connection.
>
> If both listen, who calls out?  In TCP mode, you need to decide who opens
> the tcp session (tcp-client) and who listens (tcp-server).
>
> In UDP mode, the socket is not "connected" so you can just send packets
> when you feel like it, without having to establish a connection first.
>
> 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-35655025
> g...@net.informatik.tu-muenchen.de
>

Re: [Openvpn-devel] man page and options.c contradict

[Gert Doering]

Hi,

On Thu, Oct 23, 2014 at 01:24:45PM -0600, Reinoud Koornstra wrote:
> The idea in my case is to have a point-to-point connection where both hosts
> listen on port 443 tcp instead of port 1194 udp to setup the point-to-point
> connection.

If both listen, who calls out?  In TCP mode, you need to decide who opens
the tcp session (tcp-client) and who listens (tcp-server).

In UDP mode, the socket is not "connected" so you can just send packets
when you feel like it, without having to establish a connection first.

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


pgpQG83TADXbV.pgp
Description: PGP signature

[Openvpn-devel] man page and options.c contradict

[Reinoud Koornstra]

Hello Everyone,

I read the manpage here: doc/openvpn.8


remote 198.19.34.56 443 tcp


However, when you configure this in your configuration file, you cannot do
this:

in src/openvpn/options.c:

  /*
   * If "proto tcp" is specified, make sure we know whether it is
   * tcp-client or tcp-server.
   */
  if (ce->proto == PROTO_TCPv4)
msg (M_USAGE, "--proto tcp is ambiguous in this context.  Please
specify --proto tcp-server or --proto tcp-client");
  if (ce->proto == PROTO_TCPv6)
msg (M_USAGE, "--proto tcp6 is ambiguous in this context.  Please
specify --proto tcp6-server or --proto tcp6-client");


So the man page isn't correct?
The only thing I can reliably use in p2p mode is remote host 1194 udp
If I fill out a different port.
The idea in my case is to have a point-to-point connection where both hosts
listen on port 443 tcp instead of port 1194 udp to setup the point-to-point
connection.
Thanks,

Reinoud.

Re: [Openvpn-devel] session-id implementation

[Lev Stipakov]

Hi Steffan,

Patch attached.

-Lev

2014-10-23 10:52 GMT+03:00 Steffan Karger :
> Hi Lev,
>
> On 10/21/2014 09:33 AM, Lev Stipakov wrote:
>>
>> Thanks for your comments. I have fixed (1) and (2) - well, reusing
>> existing code in (2) has fixed also (1).
>
> Thanks! Do you have the patch somewhere for us to look at?
>
>> Regarding (3) - I don't have much experience in crypto thing, so it
>> would be nice if someone suggests if we should use another alignment.
>
> >From later discussions I get the feeling the alignment was not crypto
> related.
>
> Also, alignment for crypto is very platform-specific. e.g. AES-NI
> instructions require 128-bit alignment for maximum speed. Though it
> depends on the crypto mode and implementation whether the data we supply
> it is directly used or not.
>
> The main accelerated crypto mode currently is AES-GCM, and that does not
> run the data through the crypto (but rather encrypts counters, and then
> XORs the result with the data). So I wouldn't worry too much about that
> for now.
>
> -Steffan
>
> --
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel



-- 
-Lev
diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
index c4c356d..2c827e2 100644
--- a/src/openvpn/crypto.c
+++ b/src/openvpn/crypto.c
@@ -220,6 +220,30 @@ err:
   return;
 }
 
+int verify_hmac(struct buffer *buf, struct key_ctx *ctx, int offset)
+{
+  uint8_t local_hmac[MAX_HMAC_KEY_LENGTH]; /* HMAC of ciphertext computed locally */
+  int hmac_len = 0;
+
+  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)
+return 0;
+
+  hmac_ctx_update (ctx->hmac, BPTR (buf) + hmac_len + offset,
+  	BLEN (buf) - hmac_len - offset);
+  hmac_ctx_final (ctx->hmac, local_hmac);
+
+  /* Compare locally computed HMAC with packet HMAC */
+  if (memcmp_constant_time (local_hmac, BPTR (buf) + offset, hmac_len) == 0)
+return hmac_len;
+
+  return 0;
+}
+
 /*
  * If (opt->flags & CO_USE_IV) is not NULL, we will read an IV from the packet.
  *
@@ -246,30 +270,13 @@ openvpn_decrypt (struct buffer *buf, struct buffer work,
   /* 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 < hmac_len)
-	CRYPT_ERROR ("missing authentication info");
-
-	  hmac_ctx_update (ctx->hmac, BPTR (buf) + hmac_len, BLEN (buf) - hmac_len);
-	  hmac_ctx_final (ctx->hmac, local_hmac);
-
-	  /* Compare locally computed HMAC with packet HMAC */
-	  if (memcmp_constant_time (local_hmac, BPTR (buf), hmac_len))
+	  int hmac_len = verify_hmac(buf, ctx, 0);
+	  if (hmac_len == 0)
 	CRYPT_ERROR ("packet HMAC authentication failed");
-
 	  ASSERT (buf_advance (buf, hmac_len));
 	}
 
   /* Decrypt packet ID + payload */
-
   if (ctx->cipher)
 	{
 	  const unsigned int mode = cipher_ctx_mode (ctx->cipher);
@@ -389,6 +396,28 @@ 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)
+{
+  if (buf->len > 0 && opt->key_ctx_bi)
+{
+  struct key_ctx *ctx = >key_ctx_bi->decrypt;
+
+  /* Verify the HMAC */
+  if (ctx->hmac)
+	{
+	  /* sizeof(uint32_t) comes from session_id (3 bytes) and opcode (1 byte) */
+	  return verify_hmac(buf, ctx, sizeof(uint32_t)) != 0;
+	}
+}
+  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..68cdf16 100644
--- a/src/openvpn/crypto.h
+++ b/src/openvpn/crypto.h
@@ -279,6 +279,9 @@ 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/init.c b/src/openvpn/init.c
index 3b72b96..fef7c1d 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1748,7 +1748,8 @@ pull_permission_mask (const struct context *c)
 | OPT_P_MESSAGES
 | OPT_P_EXPLICIT_NOTIFY
 | OPT_P_ECHO
-| OPT_P_PULL_MODE;
+| OPT_P_PULL_MODE
+| 

Re: [Openvpn-devel] session-id implementation

[Steffan Karger]

Hi Lev,

On 10/21/2014 09:33 AM, Lev Stipakov wrote:
> 
> Thanks for your comments. I have fixed (1) and (2) - well, reusing
> existing code in (2) has fixed also (1).

Thanks! Do you have the patch somewhere for us to look at?

> Regarding (3) - I don't have much experience in crypto thing, so it
> would be nice if someone suggests if we should use another alignment.

>From later discussions I get the feeling the alignment was not crypto
related.

Also, alignment for crypto is very platform-specific. e.g. AES-NI
instructions require 128-bit alignment for maximum speed. Though it
depends on the crypto mode and implementation whether the data we supply
it is directly used or not.

The main accelerated crypto mode currently is AES-GCM, and that does not
run the data through the crypto (but rather encrypts counters, and then
XORs the result with the data). So I wouldn't worry too much about that
for now.

-Steffan

Re: [Openvpn-devel] New OpenVPN bundles for Windows platform that incorporate OpenSSL 1.0.1j

[Samuli Seppänen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> Please surf to http://sourceforge.net/p/openvpn/mailman/openvpn-announce/ and 
> read the
post titled "[Openvpn-announce] New OpenVPN Windows installers (I004 and
I604) released" by Samuli.
>
> You'll see that OpenVPN needs to apply the latest security fixes from
OpenSSL.
>
> Lisa
>
There is also a Wiki page here:



- -- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRIorYACgkQwp2X7RmNIqPuKgCgp+Iv4JwX8ZXXkJGYbCyAJQ+F
104An05iMcfW+DB+cNHzY8whqqXrTUnB
=4QL4
-END PGP SIGNATURE-

Re: [Openvpn-devel] Are OpenVPN 2.3.4 I005 and I605 builit with OpenSSL 1.0.1j and "no-ssl3" flag?

[Gert Doering]

Hi,

On Thu, Oct 23, 2014 at 07:30:48AM +0200, Lisa Minogue wrote:
> I'm no expert of OpenVPN or OpenSSL and it be nice of you if you could tell 
> me whether the latest OpenVPN's installers for Microsoft Windows OS have been 
> built with "no-ssl3" flag in OpenSSL 1.0.1j.

No, they haven't.

Because it is not relevant for OpenVPN, as Steffan explained.

(OpenVPN gets build with default flags, as you can see when you look
into the build scripts in git)

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


pgp41mkTYR1EJ.pgp
Description: PGP signature

[Openvpn-devel] Are OpenVPN 2.3.4 I005 and I605 builit with OpenSSL 1.0.1j and "no-ssl3" flag?

[Lisa Minogue]

Hi Samuli

I'm no expert of OpenVPN or OpenSSL and it be nice of you if you could tell me 
whether the latest OpenVPN's installers for Microsoft Windows OS have been 
built with "no-ssl3" flag in OpenSSL 1.0.1j.

Regards.

Lisa
-
Mail.be, WebMail and Virtual Office
http://www.mail.be

Re: [Openvpn-devel] New OpenVPN bundles for Windows platform that incorporate OpenSSL 1.0.1j

[Lisa Minogue]

Please surf to http://sourceforge.net/p/openvpn/mailman/openvpn-announce/ and 
read the post titled "[Openvpn-announce] New OpenVPN Windows installers (I004 
and I604) released" by Samuli.

You'll see that OpenVPN needs to apply the latest security fixes from OpenSSL.

Lisa

> 
> From: Arne Schwabe 
> Sent: Fri Oct 17 15:37:37 CEST 2014
> To: Lisa Minogue , 
> Subject: Re: [Openvpn-devel] New OpenVPN bundles for Windows platform that 
> incorporate OpenSSL 1.0.1j
> 
> 
> Am 17.10.14 13:16, schrieb Lisa Minogue:
> > Hi Samuli
> >
> > I just wish to thank you in advance for preparing and compiling new OpenVPN 
> > bundles for Microsoft Windows OS that incorporate OpenSSL 1.0.1j.
> >
> >
> Just to comment on that. Since OpenVPN is not affected by Poodle, there
> is no urgent need for new OpenVPN bundles.
> 
> Arne

-
Mail.be, WebMail and Virtual Office
http://www.mail.be

Re: [Openvpn-devel] New OpenVPN bundles for Windows platform that incorporate OpenSSL 1.0.1j

[Lisa Minogue]

Please surf to http://sourceforge.net/p/openvpn/mailman/openvpn-announce/ and 
read the post titled "[Openvpn-announce] New OpenVPN Windows installers (I004 
and I604) released" by Samuli.

The answer you're looking for is there.

Lisa

> 
> From: Илья Шипицин 
> Sent: Fri Oct 17 21:59:04 CEST 2014
> To: Lisa Minogue 
> Subject: Re: [Openvpn-devel] New OpenVPN bundles for Windows platform that 
> incorporate OpenSSL 1.0.1j
> 
> 
> can you please describe carefully, how those vulnerabilities do affect 
> OpenVPN ?
> 
> 2014-10-17 20:21 GMT+06:00 Lisa Minogue :
> > Have you looked carefully into what security vulnerabilities OpenSSL 1.0.1j 
> > fixes, other than Poodle?
> >
> > Lisa
> >
> >> 
> >> From: Arne Schwabe 
> >> Sent: Fri Oct 17 15:37:37 CEST 2014
> >> To: Lisa Minogue , 
> >> Subject: Re: [Openvpn-devel] New OpenVPN bundles for Windows platform that 
> >> incorporate OpenSSL 1.0.1j
> >>
> >>
> >> Am 17.10.14 13:16, schrieb Lisa Minogue:
> >> > Hi Samuli
> >> >
> >> > I just wish to thank you in advance for preparing and compiling new 
> >> > OpenVPN bundles for Microsoft Windows OS that incorporate OpenSSL 1.0.1j.
> >> >
> >> >
> >> Just to comment on that. Since OpenVPN is not affected by Poodle, there
> >> is no urgent need for new OpenVPN bundles.
> >>
> >> Arne
> >
> > -
> > Mail.be, WebMail and Virtual Office
> > http://www.mail.be
> >
> > --
> > Comprehensive Server Monitoring with Site24x7.
> > Monitor 10 servers for $9/Month.
> > Get alerted through email, SMS, voice calls or mobile push notifications.
> > Take corrective actions from your mobile device.
> > http://p.sf.net/sfu/Zoho
> > ___
> > Openvpn-devel mailing list
> > Openvpn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openvpn-devel

-
Mail.be, WebMail and Virtual Office
http://www.mail.be