Re: [Openvpn-devel] tls-version-min in Openvpn-devel Digest, Vol 95, Issue 27

[Timothe Litt]

On 21-Apr-14 23:59, openvpn-devel-requ...@lists.sourceforge.net wrote:

Message: 4 Date: Mon, 21 Apr 2014 13:49:46 +0200 From: Gert Doering <g...@greenie.muc.de> Subject: Re: [Openvpn-devel] [PATCH 4/4] When tls-version-min is unspecified, revert to original versioning approach. To: Arne Schwabe <a...@rfc2549.org> Cc: openvpn-devel@lists.sourceforge.net Message-ID: <20140421114946.gv16...@greenie.muc.de> Content-Type: text/plain; charset="us-ascii" Hi, On Mon, Apr 21, 2014 at 01:11:05PM +0200, Arne Schwabe wrote:

>Yes. But with this patch it is always turned off, keeping OpenVPN in 99%
>of installations in TLS 1.0. Is there any other known case where it
>breaks aside from the Tomato OpenVPN client?

http://community.openvpn.net/openvpn/ticket/385

this is the only case I know - and I blaim the openssl library on the
server side (ARM).  So for me, "default-on with a way to turn it off" would
be sufficient.  But I assume James has much more visibility...

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

FYI, I reported this in Trac #385.









Here is my current work-around (same as posted on trac)

diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index 0b63e26..0785ce4 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -98,10 +98,10 @@ tls_ctx_server_new(struct tls_root_ctx *ctx)
 {
   ASSERT(NULL != ctx);

-  ctx->ctx = SSL_CTX_new (SSLv23_server_method ());
+  ctx->ctx = SSL_CTX_new (TLSv1_server_method ());

   if (ctx->ctx == NULL)
-    msg (M_SSLERR, "SSL_CTX_new SSLv23_server_method");
+    msg (M_SSLERR, "SSL_CTX_new TLSv1_server_method");
 }

 void
@@ -109,10 +109,10 @@ tls_ctx_client_new(struct tls_root_ctx *ctx)
 {
   ASSERT(NULL != ctx);

-  ctx->ctx = SSL_CTX_new (SSLv23_client_method ());
+  ctx->ctx = SSL_CTX_new (TLSv1_client_method ());

   if (ctx->ctx == NULL)
-    msg (M_SSLERR, "SSL_CTX_new SSLv23_client_method");
+    msg (M_SSLERR, "SSL_CTX_new TLSv1_client_method");
 }

 void



Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

This communication may not represent my employer's views,
if any, on the matters discussed.

On OpenVPN users today, there was a report of (superficially) the same symptom on linux x86_64; I pointed the reporter to the thread and asked for some more details. If truly the same problem, it would rule out the 'ARM -only' theory. I have built the ARM OpenSSL library for my distribution (Debian - as patched by them) from source, and when I get a chance will see if I can get any closer to root cause with GDB. I'm not an OpenSSL internals expert, but it's just code. We'll see. Note that my work-around (in #385) is a lot less intrusive than the disabling patches that have been posted here recently; at least in my case all that's required is to change the SSL_CTX_new init method to TLSv1. Also, the server is trying to send a plaintext error message, but the length is apparently wrong as seen by the client. It would be helpful if we could get the server to log the actual error..

smime.p7s
Description: S/MIME Cryptographic Signature