> On Apr 16, 2015, at 09:51, Chris Ross <[email protected]> wrote:
>> On Apr 16, 2015, at 03:01, Jan Just Keijser <[email protected]> wrote:
>> if no list of TLS ciphers is specified then the client will attempt the full
>> list of ciphers that you see with "--with-tls" ; with OpenSSL it is actually
>> quite hard to tell which ciphers it is trying and in which order. I'm saying
>> OpenSSL here, as it's a an SSL library call that does this part. For
>> PolarSSL builds the same applies, IIRC.
>>
>> One thing you could try is to run the underlying openssl command on both
>> client and server:
>> server:
>> openssl s_server -msg -CAfile ca.crt -cert server.crt -key server.key
>> client:
>> openssl s_client -connect <server-IP>:4433
>>
>> (adjust ca.crt and server.{crt,key} to your setup).
>> The server should print the list of shared ciphers.
>
> Well, at least we’re consistent with the openvpn failure. The server shows:
>
> Using default temp DH parameters
> Using default temp ECDH parameters
> ACCEPT
> <<< SSL 2.0 [length 0080], CLIENT-HELLO
> […]
>>>> TLS 1.0 Alert [length 0002], fatal handshake_failure
> 02 28
> ERROR
> 3148076708:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared
> cipher:/data/NetBSD/src/crypto/dist/openssl/ssl/s3_srvr.c:1076:
> shutting down SSL
> CONNECTION CLOSED
Interesting. While googling around for openssl errors saying “no shared
cipher", rather than openvpn errors, I found someone suggesting a similar set
of commands for debugging an application programming problem. But, they used
“-tls1” on each side. When I retried your commands above adding “-tls1” to the
client side, it established a connection successfully, and at the end of the
establishment processed showed:
>>> TLS 1.0 Handshake [length 0010], Finished
14 00 00 0c be 9a 23 37 31 2b 0e b1 63 32 90 31
-----BEGIN SSL SESSION PARAMETERS-----
MFUCAQECAgMBBAIABAQABDDXnAGb7jH8WIrEMiuRnlBMvPOa14Qy+TEkuesiY43W
TgbANspd2fFVo6QMfOignmKhBgIEVS+/kKIEAgIBLKQGBAQBAAAA
-----END SSL SESSION PARAMETERS-----
Shared ciphers:RC4-MD5
CIPHER is RC4-MD5
I was then able to pass data across the connection successfully. So, is
there something I’ve failed to do on the openvpn client side to make it
initiate a TLS handshake that may be [part of] the problem? I’ll attach the
boiled down client config, in case that helps, and I only gave the server
config yesterday IIRC…
- Chris
———
client
;dev tap
dev tun
proto tcp
;proto udp
remote myserver 1194
;remote my-server-2 1194
resolv-retry infinite
nobind
;user nobody
;group nobody
persist-key
persist-tun
;mute-replay-warnings
ca distal-ca.crt
cert client.crt
key client.key
;ns-cert-type server
;tls-auth ta.key 1
comp-lzo
verb 8
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users
