Re: [Openvpn-devel] push route-ipv6 and metric

[Athanasios Douitsis]

19 Ιουν 2013, 11:04 μ.μ., ο/η Gert Doering  έγραψε:

> Hi,
> 
> On Wed, Jun 19, 2013 at 06:00:27PM +0300, Athanasios Douitsis wrote:
>> I noticed that issuing the following command in the server config:
>> 
>> push "route-ipv6 ::/0 2001:648:2000:ffae::1 15"
>> 
>> does indeed make a windows client install that route, but it ignores the
>> metric:
> 
> True.  There is no metric support for IPv6 routes today - half of it is
> "because most operating systems don't actually support route metrics"
> and the other half is "because I'm lazy and haven't found a problem
> that needed metrics, and couldn't be tackled in a more robust way".
> 
>> Fwiw, I was able to workaround this problem by pushing two /1 routes,
>> exactly like def1 does for IPv4. Like this:
>> 
>> push "route-ipv6 ::/1 2001:648:2000:ffae::1"
>> push "route-ipv6 8000::/1 2001:648:2000:ffae::1"
> 
> routing 2000::/3 is usually sufficient, as all globally routable IPv6
> space is in there.
> 
> 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


Hello Gert,

Heh, you're right :) Anyway, maybe the man page shouldn't mention the metric in 
the first place then. 

Thanks!,
Athanasios 

Re: [Openvpn-devel] push route-ipv6 and metric

[Gert Doering]

Hi,

On Wed, Jun 19, 2013 at 06:00:27PM +0300, Athanasios Douitsis wrote:
> I noticed that issuing the following command in the server config:
> 
> push "route-ipv6 ::/0 2001:648:2000:ffae::1 15"
> 
> does indeed make a windows client install that route, but it ignores the
> metric:

True.  There is no metric support for IPv6 routes today - half of it is
"because most operating systems don't actually support route metrics"
and the other half is "because I'm lazy and haven't found a problem
that needed metrics, and couldn't be tackled in a more robust way".

> Fwiw, I was able to workaround this problem by pushing two /1 routes,
> exactly like def1 does for IPv4. Like this:
> 
> push "route-ipv6 ::/1 2001:648:2000:ffae::1"
> push "route-ipv6 8000::/1 2001:648:2000:ffae::1"

routing 2000::/3 is usually sufficient, as all globally routable IPv6
space is in there.

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


pgpMJtIUynDkX.pgp
Description: PGP signature

[Openvpn-devel] push route-ipv6 and metric

[Athanasios Douitsis]

Hello,

I noticed that issuing the following command in the server config:

push "route-ipv6 ::/0 2001:648:2000:ffae::1 15"

does indeed make a windows client install that route, but it ignores the
metric:

add_route_ipv6(::/0 -> 2001:648:2000:ffae::1 metric 15) dev Local Area
Connection 3
C:\Windows\system32\netsh.exe interface ipv6 add route ::/0 Local Area
Connection 3 fe80::8 store=active

Issuing route print client-side confirms that suspicion.

 13 26::/0 fe80::208:7cff:fe63:e400
 14286   ::/0 fe80::8

(13 is my lan, 14 is the tun device. As you can see, metric is 286)

I suppose most people on this list should be aware of the problem. If you
desire so, I'd gladly file a bug request.

Fwiw, I was able to workaround this problem by pushing two /1 routes,
exactly like def1 does for IPv4. Like this:

push "route-ipv6 ::/1 2001:648:2000:ffae::1"
push "route-ipv6 8000::/1 2001:648:2000:ffae::1"

Apologies if this has been discussed before.

Kind regards to all,
-- 
Athanasios Douitsis

Re: [Openvpn-devel] OpenVPN Versioning

[James Yonan]

On 18/06/2013 01:41, Joachim Schipper wrote:

From: James Yonan :

On 14/06/2013 02:47, Joachim Schipper wrote:

>From James Yonan :

TLS Protocol


Since day 1, OpenVPN has used TLS 1.0 as a control channel and key
exchange mechanism.  But now we have TLS 1.1 and 1.2, each of which
addresses significant shortcomings in its predecessor.  Fortunately,
SSL/TLS already includes dynamic version negotiation.  So I've put
together a patch that leverages on this, by allowing OpenVPN client
and server to negotiate the TLS version and use the highest version
supported by both peers.  The patch also adds a new directive "tls-
version-min" that allows either client or server to specify a

minimum

required TLS version from the peer.



https://github.com/jamesyonan/openvpn/commit/6ee8faade224cc346d67a7f1

7
1
6df4012782999a


[snip: SSL negotiation. Thanks for the explanation; I agree that speaking
the highest supported protocol is good.]


I'm not sure what purpose the "or-highest" serves. Clients already

connect with the newest protocol supported by both client and server;
if you want to run a TLSv1.2-only network, just set min-version to 1.2
on the server. (...)

Suppose a server admin wants to upgrade to TLS 1.2 over some transition
period, to allow time to upgrade existing clients in the field.



The overall goal here is to provide tools that allow a controlled
rollout of TLS 1.2 that doesn't break any clients during the rollout
period, and to upgrade to 1.2 in a way that doesn't create the
potential for MiTM version rollback attacks.


But no modern SSL protocol allows version rollback attacks: modern
implementations will always speak the highest supported/configured protocol
version between each other. (Only) SSLv2 allows rollback attacks, which is
why the only sane way to deal with SSLv2 in 2013 is to unconditionally
disable support.


Right, and the patch is able to unconditionally disable support for SSL 
2 and 3 since these were never supported by even the earliest versions 
of OpenVPN.



The switch(tls_version_min) needs a default case, just compile the

first case/default: unconditionally.

There is a default case already -- it's right under "case
TLS_VER_1_0:".


Yes, but that's #ifdef'ed. I'd be happier if the default case remained
present even if PolarSSL foolishly decides to drop TLSv1 support.


Agreed -- there shouldn't be any implicit assumption
that SSL lib might not implement TLS 1.0.

https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40


[snip: ciphersuites]

Negotiating ciphers might be fatal in some configurations that were a
bad idea to begin with. E.g. if you use OpenVPN with a static key and
--auth none (which is a bad idea!), adding this negotation could

allow

an attacker to set the cipher to none or, more dangerously, to a very
weak cipher like DES (provided it is mutually supported). An attacker
could then bruteforce the key and use his knowledge of 56 bits of the
key to attack stronger protocols like AES or 3DES. (Or do we only
negotiate in SSL mode? I must admit to being fuzzy on the non-SSL
mode.)


Static key mode has no negotiation.

Agreed that any negotiation model must have constraints placed on the
security of the negotiated cipher and HMAC digest.  You would probably
want to disable "cipher none" or "auth none" on the presumption that
users who want a cleartext tunnel would explicitly configure the client
and server for this.


Sure. Just disabling negotiations unless you have an SSL'd control channel
works fine against this.


One thing to keep in mind is that OpenVPN protocol negotiation occurs
over the already-negotiated TLS session, so it is immune to being
tampered with by a MiTM.  This is in contrast to SSL/TLS where a MiTM
can affect the negotiation.


As above, MiTM attackers cannot effect the negotiation step in SSL/TLS
protocols after SSLv2, except trivially (by causing the negotiation to fail, 
possibly a couple of protocol steps later, e.g. by dropping all packets.)


Aha, that's good to know.  Apparently browsers are still vulnerable to 
version rollback attacks due to compatibility fallback mechanisms, but 
that's great that SSL/TLS protocols are immune above SSL 3.  There's a 
good writeup on the subject here:


http://www.carbonwind.net/blog/post/Random-SSLTLS-101%E2%80%93SSLTLS-version-rollbacks-and-browsers.aspx

James

Re: [Openvpn-devel] OpenVPN Versioning

[James Yonan]

On 17/06/2013 01:58, Steffan Karger wrote:

On 06/14/2013 09:53 PM, James Yonan wrote:

To get the adaptive versioning behavior in OpenSSL, you have to use
SSLv23_server_method() or SSLv23_client_method() and then explicitly
disable the versions you don't want to consider, i.e. SSL_OP_NO_SSLv2,
SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1, etc.


Wow, so SSLv23_{client,server}_method() is the 'wildcard' you need to
dynamically negotiate the version. Yet it sounds like something
completely broken that should be avoided at all cost. OpenSSL keeps
amazing me.


It really shows OpenSSL's age, doesn't it?  But aside from the 
cruftiness, I wouldn't say that it's broken.  It's arguably a more 
flexible mechanism than PolarSSL because it allows you to cherry-pick 
the SSL/TLS versions you want to support, rather than just give a 
min/max range.



Does the change to key_state_ssl_init() do anything?


I had to add ssl_flags (containing tls-version-min parameter) to
key_state_ssl_init because that seems like the most appropriate place to
configure tls-version-min for PolarSSL.

For OpenSSL, tls_ctx_set_options is the right place to configure
tls-version-min.


The ssl_flags are already available through the tls session that is
passed as the fourth parameter. To make this a bit more clear, commit
b97e2c3 changed the type of session to struct tls session* (see
https://github.com/OpenVPN/openvpn/commit/b97e2c3c90afdbb1a24bc1357ec6b94d626defcd).


Right, I've rebased the patch against master and now use 
session->opt->ssl_flags


This simplifies the patch because now it's no longer necessary to pass 
ssl_flags to key_state_ssl_init


https://github.com/jamesyonan/openvpn/commit/03a5599202bdc3ba07983dc4efdae387fb8fb436

James