1 Topic by Frank42 (edited by Frank42 2018-04-12 13:46:31)

  • Registered: 2018-03-22
  • Posts: 21

Topic: Failing TLSv1.2 handshake

I've got Wolf ver3.14 running on a WinCE6 device.  It is running an SMTP client.  I'm not having much success getting through the TLSv1.2 handshake.  If I try to connect to my own PostFix server I have consistent success.  If I try to connect to Gmail or Yahoomail I have a 98% failure rate.  I suspect the server is closing the TCP session due to an improper handshake.  I'm unable to prove this.  The only feedback I get is the server closing the session [FIN, ACK].

I have attached a *.CAP of the traffic.  There are a few TCP issues.  (This is a high latency [many seconds], low bandwidth [modem] use case.)  I'm thinking the latency is not an issue for the handshake as TCP will address these issues.

Is there anything that jumps out as a TLS issue?  As in, why does the handshake die?

I can't tell if I am chasing a TLS, TCP, or firewall issue.

Thanks

Post's attachments

gmail-fail.cap 6.71 kb, 2 downloads since 2018-04-12 

You don't have the permssions to download the attachments of this post.

Share

  • From: Bozeman
  • Registered: 2014-05-09
  • Posts: 777

Re: Failing TLSv1.2 handshake

Hi Frank,

The biggest thing that sticks out is the time. Over the course of the connection it looks like from packet 1 to packet 25 of the wireshark you sent a total of 19.85 seconds has expired. Nothing in the wireshark sticks out as an obvious issue in fact everything is progressing normally and then at 20.08 seconds we see 4 reset messages come from the server destined for the client, I honestly think you are just hitting a timeout for the server.

I tested this theory by placing a "sleep(4);" in the default IO Send callback and using our example client to test:

./examples/client/client -M smtp -h 64.233.168.108 -p 587 -d

Sure enough I was able to produce a wireshark very similar to yours just without the spurious re-transmissions. The peer hung up on me after only 12 seconds.

I tried again with sleep(3); and got similar results but the peer kept talking up to 15 seconds. It seems like there may be a threshold between messages that if exceeded too many times the peer aborts the connection.

Options to alleviate this would be to use a faster cipher suite. Have you run the <wolfssl-root>/wolfcrypt/benchmark/benchmark.c application on your device to see which algorithms perform the best on your device? Typically an ECDHE_ECDSA cipher suite will outperform any RSA cipher suites if that is an option for you.

Could you try running the benchmark app and running one of the faster cipher suites to see if you can up your success rate above 2%?

Warm Regards,

Kaleb

Kaleb J. Himes's Website

Share

  • Registered: 2018-03-22
  • Posts: 21

Re: Failing TLSv1.2 handshake

Thank you for reviewing this.

I must conclude the same,.. hitting a timeout for the server.
Gmail fails the handshake.
Yahoo fails the handshake.
Outlook works reliably.

I'm not able to get the benchmark built.
I have run the client benchmark on the HTTP sites.  It appears -b does not support SMTP (-M smtp).

  • client -h 13.107.21.200 -p 443 -d -b 40

  (bing.com)
wolfSSL_connect avg took:  48135.322 milliseconds

Others have suggested that TLS will add 45-60 SECONDS of overhead.

I will add TLSv1.3 to the Wolf lib.  There doesn't seem to be an easy way to add this for a VStudio build.  i.e Something more than: #define WOLFSSL_TLS13   The manual say's the code is supported but fails to say how to include it.

Is there a single #def that adds TLSv1.3?

Share

  • Registered: 2018-03-22
  • Posts: 21

Re: Failing TLSv1.2 handshake

Added this to user-settings.h

// Add TLSv1.3 support to lib
#define WOLFSSL_TLS13
#define HAVE_AEAD
// Add TLSv1.3 support to examples
#define HAVE_HKDF
#define WC_RSA_PSS

The Lib & most examples build.  I'm unable to send the TLS1.3 traffic as the client doesn't appear to support -v 4

Share

  • From: Bozeman
  • Registered: 2014-05-09
  • Posts: 777

Re: Failing TLSv1.2 handshake

Hi Frank42,

Great question! At the moment if you configure with --enable-tls13 using the autoconf system the following flags are set by the configure.ac (input to auto reconf):

#define WOLFSSL_TLS13
#define HAVE_TLS_EXTENSIONS
#define HAVE_SUPPORTED_CURVES
#define HAVE_FFDHE_2048
#define HAVE_HKDF
#define WC_RSA_PSS

We are working on the documentation but it won't be finalized/released until tls 1.3 is finalized. Currently we are supporting the latest draft (draft 28) and we are optimistic this is the final draft but until it's confirmed we will have to wait to finalize our documentation and default settings.

Warm Regards,

Kaleb

Kaleb J. Himes's Website

Share

6 Reply by Frank42 (edited by Frank42 2018-04-23 11:59:23)

  • Registered: 2018-03-22
  • Posts: 21

Re: Failing TLSv1.2 handshake

Thanks for the settings.

In addition to your settings, I still need  #define HAVE_AEAD to get a successful build.


client.exe does support -v 4
WOLFSSL_LIB needs to be defined for the client build to pull in user_settings.h

Share

  • Registered: 2018-03-22
  • Posts: 21

Re: Failing TLSv1.2 handshake

Can I use the -d flag with a TLSv1.3 connection?  i.e. Skip the cert verify?

I'm not having any success using Wolf to connect to a TLSv1.3 site.
The handshake fails at the client-hello.  i.e. The server response with an Alert (Handshake failure)

The WolfSSL.com site does not appear to support TLSv1.3. 
I can't connect to it w/ a FireFox browser (force TLSv1.3).
I can't run: client -v 4 -l TLS13-AES128-GCM-SHA256 -h www.wolfssl.com-p 443 -g -A ./certs/wolfssl-website-ca.pem

WireShark tags the Wolf TLS activity as TLSv1.2 though I see what looks like v1.3 payloads.
I get the same behavior from: client -h 104.28.30.12 -p 443 -d -b 40 -v 4 -g -l TLS13-AES128-GCM-SHA256
(This may just be a WireShark issue, but something seems to be missing.)

Using FFox I can connect w/ TLSv1.3 to istlsfastyet.com and WireShark does tag the TLS traffic as v1.3.


Would you have any idea what I may be doing wrong?

Share

8 Reply by Frank42 (edited by Frank42 2018-04-25 12:46:25)

  • Registered: 2018-03-22
  • Posts: 21

Re: Failing TLSv1.2 handshake

One issue: #define HAVE_ECC   // needed for server to generate a key
I can get the client example to connect to the server example but that is it.  Client will not connect to any TSL1.3 sites.

From: wolfssl.com/docs/lts13/    Section: Using TLS 1.3 in wolfSSL
  client -v 4 -l TLS13-AES128-GCM-SHA256 -h www.wolfssl.com-p 443 -g -A ./certs/wolfssl-website-ca.pem
Does not successfully connect.

wolfSSL Leaving SendTls13ClientHello, return 0
connect state: CLIENT_HELLO_SENT
received record layer msg
got ALERT!
Got alert
wolfSSL error occurred, error = 40 line:11884 file:c:\development\gemini\devarea
wolfSSL error occurred, error = 313 line:9424 file:c:\development\gemini\devarea

Can you confirm if your site supports TLSv1.3 or not?
(FFox (draft 23) say's no.  My build of client (draft 23) say's no.)

Share

  • From: Bozeman
  • Registered: 2014-05-09
  • Posts: 777

Re: Failing TLSv1.2 handshake

Hi Frank42,

I can confirm that our site no longer supports TLS 1.3.

A few months back we were using cloud flare to host our site as they were supposed to speed up our page load times. Could flare had support for TLSv1.3. We have since stopped using cloud flare and our site is now back to being hosted by go daddy. Godaddy does not support TLS v1.3 so we can no longer test against it.

Since TLS v1.3 is not yet finalized there are a few different configure options in wolfSSL at the moment:

  --enable-tls13-draft18  TLS v1.3 Draft 18
  --enable-tls13-draft22  TLS v1.3 Draft 22
  --enable-tls13-draft23  TLS v1.3 Draft 23
  --enable-tls13              TLS v1.3 Draft 28

If doing inter-op testing you'll need to check which draft is supported by the site you're testing against and configure wolfSSL accordingly!

Warm Regards,

- K

Kaleb J. Himes's Website

Share

10 Reply by Frank42 (edited by Frank42 2018-04-27 09:45:55)

  • Registered: 2018-03-22
  • Posts: 21

Re: Failing TLSv1.2 handshake

Thanks for the info.

I'm using: LIBWOLFSSL_VERSION_STRING "3.14.0"

I'm building with:
#define WOLFSSL_TLS13
#define HAVE_TLS_EXTENSIONS
#define HAVE_SUPPORTED_CURVES
#define HAVE_FFDHE_2048
#define HAVE_HKDF
#define WC_RSA_PSS
  #define HAVE_AEAD     
  #define HAVE_AESGCM   
  #define HAVE_ECC   

I'm using cmd:
  client -h 104.28.30.12 -p 443 -d -v 4 -l TLS13-AES128-GCM-SHA256

The client is sending:
  Supported Version: TLS 1.3 (draft 23) (0x7f17)

Per your description this should be: TLS 1.3 (draft 28) (0x7f1c)

That is, I'm pretty sure I'm building draft28 but it is reporting draft23.
I am unsure if this is related to the 313 error I'm seeing.  (I'll suggest it is not.)
The server does not like the Client Hello  (Handshake Failure)

A successful server handshake (Server Hello) sends:
Extension: supported_versions (len=2)
  Supported Version: TLS 1.3 (draft 23) (0x7f17)
though the Server Hello handshake occurs in:
  Handshake Type: Server Hello (2)
  Version: TLS 1.2 (0x0303)

Share

11 Reply by Frank42 (edited by Frank42 2018-04-27 12:41:39)

  • Registered: 2018-03-22
  • Posts: 21

Re: Failing TLSv1.2 handshake

In regards to the -313 error,....
I'm working on the idea that the server is looking for a missing extension.  Not the content of the extensions.   (I'd expect a different alert msg if this were the case.)  I had always considered extensions as option info.

The client info below comes from my Wolf Example Client.
The server info below comes from a successful handshake using FFox, (forced to TLSv1.3, shows as draft 23).

The Client Hello is using one cipher:  Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
The Server Hello supports this one as well: Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)

FFox is sending many more extensions than Client is.
Both Client and FFox send:
  Extension: supported_versions (len=3)
  Extension: signature_algorithms (len=16)
  Extension: ec_point_formats (len=2)
  Extension: supported_groups (len=16)
  Extension: key_share (len=432)
FFox send these as well:
1   Extension: server_name (len=21)
2   Extension: extended_master_secret (len=0)
3   Extension: renegotiation_info (len=1)
4   Extension: application_layer_protocol_negotiation (len=14)
5   Extension: status_request (len=5)
6   Extension: psk_key_exchange_modes (len=2)
7   Extension: padding (len=160)

I doubt #'s 1, 3, 4, 5, 6, 7 are necessary.
That leaves #2.

Does anything here jump out as different/wrong?

Share

  • From: Bozeman
  • Registered: 2014-05-09
  • Posts: 777

Re: Failing TLSv1.2 handshake

Hi Frank,

Resolved.

If you connect to that IP in a browser it essentially tells you what's wrong with connecting that way (though it might not be obvious)

Error 1003 Ray ID: 4124d098b0e95029 • 2018-04-27 22:44:37 UTC
Direct IP access not allowed

What happened?
You've requested an IP address that is part of the Cloudflare network. A valid Host header must be supplied to reach the desired website.

This means it wants to see the server name indication extension to connect you with the correct host.

Please try configuring wolfSSL like so:

kalebhimes$ ./configure --enable-tls13-draft23 --enable-sni && make

Then use the -S flag to send the server name indication extension when connecting to 104.28.30.12

kalebhimes$ ./examples/client/client -h 104.28.30.12 -p 443 -d -v 4 -l TLS13-AES128-GCM-SHA256 -S cloudflare.com
SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
SSL curve name is SECP256R1
HTTP/1.1 400 Bad Request
Server: cloudflare
Date: Fri, 27 Apr 2018 22:46:33 G

Warm Regards,

- K

Kaleb J. Himes's Website

Share

  • Registered: 2018-03-22
  • Posts: 21

Re: Failing TLSv1.2 handshake

FFox does not show the cloudflare error.  It gives: SSL_ERROR_NO_CYPHER_OVERLAP
I never saw the cloudflare screen/error.  (InetExplorer shows it.)

--enable-sni translates to #define HAVE_SNI

It all makes sense when you explain it.

Thanks

Share

  • From: Bozeman
  • Registered: 2014-05-09
  • Posts: 777

Re: Failing TLSv1.2 handshake

Frank42,

Glad to hear I helped clear it up, let me know if you have any further questions or encounter any other issues.

Cheers,

Kaleb

Kaleb J. Himes's Website

Share