Changes between Initial Version and Version 1 of Ticket #385, comment 5
- Timestamp:
- 04/16/14 22:46:05 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #385, comment 5
initial v1 1 1 '''One bug found:''' 2 2 3 The version negotiation problem is caused by what looks like a partial reversed patch in the commit : the ssl context was being setup for v23 rather than TLS1.3 The version negotiation problem is caused by what looks like a partial reversed patch in the commit that you referenced: the ssl context was being setup for v23 rather than TLS1. 4 4 5 Here is a patch :5 Here is a patch that corrects the problem for me: 6 6 7 7 {{{ 8 8 9 9 diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c 10 index 0b63e26.. 2975cba10064410 index 0b63e26..0785ce4 100644 11 11 --- a/src/openvpn/ssl_openssl.c 12 12 +++ b/src/openvpn/ssl_openssl.c 13 @@ -98, 7 +98,7@@ tls_ctx_server_new(struct tls_root_ctx *ctx)13 @@ -98,10 +98,10 @@ tls_ctx_server_new(struct tls_root_ctx *ctx) 14 14 { 15 15 ASSERT(NULL != ctx); … … 19 19 20 20 if (ctx->ctx == NULL) 21 msg (M_SSLERR, "SSL_CTX_new SSLv23_server_method"); 22 @@ -109,7 +109,7 @@ tls_ctx_client_new(struct tls_root_ctx *ctx) 21 - msg (M_SSLERR, "SSL_CTX_new SSLv23_server_method"); 22 + msg (M_SSLERR, "SSL_CTX_new TLSv1_server_method"); 23 } 24 25 void 26 @@ -109,10 +109,10 @@ tls_ctx_client_new(struct tls_root_ctx *ctx) 23 27 { 24 28 ASSERT(NULL != ctx); … … 28 32 29 33 if (ctx->ctx == NULL) 30 msg (M_SSLERR, "SSL_CTX_new SSLv23_client_method"); 34 - msg (M_SSLERR, "SSL_CTX_new SSLv23_client_method"); 35 + msg (M_SSLERR, "SSL_CTX_new TLSv1_client_method"); 36 } 37 38 void 31 39 32 40 }}} 33 41 34 Don't know why the bogus change works elsewhere. But since we always reject v2 & v2, I don't see any harm in initializing for TLS.42 Don't know why the commit's change works in other environments but not here; since both SSL_CTX and the *_*_method functions belong to OpenSSL, it's probably their code. 35 43 36 I'll have a look at the cert name issue - that should be easier to find.44 Since we always reject v2 & v3 (using the options value), I don't see any harm in initializing for TLS - 'why' is of academic interest. Initializing for V23 should advertise V2 & V3 for compatibility and accept V2 and V3 client hellos, but then the options we select cause v2 and v3 to be rejected. So setting up to accept the V2/V3 hellos doesn't buy us anything - we know it has to be OpenVPN on the other end. So we might as well work-around the issue on the OpenVPN side. 37 45 46 I've looked at the cert name issue - see the next comment. 38 47 48 (Updated to make the error message match the initialization method and clarify the explanation.) 49