[Openvpn-devel] Progress on Version negotiation

[Timothe Litt]

It does not appear to be the negotiation, rather it's TLS1.2.





The connection failed.  So, we didn't negotiate, TLSv1.2 fails.





Remember that the client log shows

Wed Apr 09 21:10:52 2014 us=748478 TLS Error: TLS handshake failed








2) the data received is larger than the buffer.
3) the message length is corrupted.



Interesting things to instrument:
  Is bio_read reducing the read size?  If so, from what to what?
  What is the actual data received size?


Let me know if there's more I can do.


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

I debugged the client hello in OpenSSL - a bit tricky due to the timeouts, but I established that the server is picking TLS1.2. I then switched the tls_ctx_{client,server}_new to use TLSv1_2_{client,server}_method in the call to SSL_CTX_new. Next, I switched to TLSv1.1 (TLSv1_1_{client,server}method). The tunnel comes up. So, it appears that the issue has to do with TLSv1.2. (Also, it is 100% reproducible here.) Wed Apr 09 21:10:52 2014 us=748478 TLS_ERROR: BIO read tls_read_plaintext error: error:04066083:rsa routines:RSA_EAY_PRIVATE_ENCRYPT:invalid message length: error:14099006:SSL routines:SSL3_SEND_CLIENT_VERIFY:EVP lib Wed Apr 09 21:10:52 2014 us=748478 TLS Error: TLS object -> incoming plaintext read error I don't have development tools on my windows client, but perhaps someone can build me an instrumented version. Here's what I think is happening: The error is coming from ssl_openssl.c:key_state_read_plaintext, where bio_read is failing. bio_read (same file) fails if openssl/crypto/bio/bio_lib.c: BIO_read fails with a hard error. There are several possibilities: 1) bio_read will reduce the read to 'maxlen', which I think is TLS_CHANNEL_BUF_SIZE. According to the log, the client has received and verified the server certificate. So the server hello has been processed successfully -- it's not the longer cipher suite in TLS1.2. What would happen if we built with larger TLS_CHANNEL_BUF_SIZE (common.h defines it as 2048; suppose it was doubled...) What is actually being read? Is it something else that we can reduce on the server end?

smime.p7s
Description: S/MIME Cryptographic Signature