Handshake failed when using builtin TLS package: no cipher suite supported by both client and server

[Alexandr Emelin]

When using builtin TLS for http/websocket server I noticed that handshakes from some old browser clients fail. The reason why I find this strange is that other TLS implementations work with those connections without any problems. I used ssllabs.com/ssltest/ to emulate handshakes.

To be more specific: clients using Chrome 49 on Windows XP SP3 can't establish secure connection with my Go server. When I use Heroku reverse proxy in front of the app - connection succesfully established using TLS 1.2. In case of Go I see "tls: no cipher suite supported by both client and server" message in server log.

I investigated this a bit and found that actually client and server have many cipher suites in common but none of them set in setCipherSuite function. Here is list of supported and preference suites:

Supported: []uint16{0xc02f, 0xcca8, 0xcc13, 0xc014, 0xc013, 0x9c, 0x35, 0x2f, 0xa}
Preference: []uint16{0x5600, 0xc02f, 0xc02b, 0xc030, 0xc02c, 0xc011, 0xc007, 0xc013, 0xc009, 0xc014, 0xc00a, 0x9c, 0x9d, 0x5, 0x2f, 0x35, 0xc012, 0xa}

They are all rejected by this code (some because there were no rsaSignOk set, some because there was no rsaDecryptOk set).

trying 0xc02f for version 0x303 
reason rejected: !rsaSignOk

trying 0xc013 for version 0x303 
reason rejected: !rsaSignOk

trying 0xc014 for version 0x303 
reason rejected: !rsaSignOk

trying 0x9c for version 0x303   
reason rejected: !rsaDecryptOk

trying 0x2f for version 0x303   
reason rejected: !rsaDecryptOk

trying 0x35 for version 0x303   
reason rejected: !rsaDecryptOk

trying 0xa for version 0x303
reason rejected: !rsaDecryptOk

I am not skilled in TLS area so looking for help – what's going on here, why Go implementation does not support connections supported by other TLS termination proxies?

[James Bardin]

What cipher quite is negotiated when you connect to the Heroku proxy?

What version of Go are you using on the server, and are you using the default tls.Config?

I don't have that client directly available to test with, but does your particular client show the expected information when you visit https://www.ssllabs.com/ssltest/viewMyClient.html?

[Alexandr Emelin]

James, thanks for response. I am using go1.7.5 linux/amd64

I have no that client available too - it was originally seen in production logs, and now I rely only on SSLLabs handshake emulation feature that has that Chrome 49 SP3 client in list.

Here is what SSLLabs shows for that client when application behind Heroku proxy:

Firefox 49 / XP SP3

RSA 2048 (SHA256)

TLS 1.2

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS

For Go I used both examples from https://gist.github.com/FZambia/b51fa33ea4ec78caa7722299da5ae09e - one with default config, and one with all available cipher suites set in TLSConfig and PreferServerCipherSuites option. Both examples use autocert (Let's Encrypt) to get HTTPS certificate. Output of SSLLabs in both cases is:

Chrome 49 / XP SP3

Server sent fatal alert: handshake_failure

And no cipher suite supported by both client and server in logs for this handshake.

понедельник, 6 февраля 2017 г., 17:15:04 UTC+3 пользователь James Bardin написал:

[Alexandr Emelin]

Copied wrong line from Heroku proxy report, here is the correct one:

Chrome 49 / XP SP3

RSA 2048 (SHA256)

TLS 1.2

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS

вторник, 7 февраля 2017 г., 14:59:42 UTC+3 пользователь Alexandr Emelin написал:

[James Bardin]

Sorry, I'm not really sure what's going on here. Just to test, have you tried loading the cert temporarily without using autocert?

You probably need to setup a system to reproduce this and get more info. I know there have been some issues in the past with WinXP and LetsEncrypt certs, though I don't know if it's related as those caused invalid certificate errors. 

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/neu_jKq9pYk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christian von Pentz]

On 02/05/2017 09:44 AM, Alexandr Emelin wrote:
> Chrome 49 on Windows XP SP3

Are you using a cert from let's encrypt? There have been issues in the
past (although LE officially lists Windows XP with SP3 as supported),
check these links out:


https://github.com/certbot/certbot/issues/1660

https://community.letsencrypt.org/t/lets-encrypt-certificates-do-not-work-on-xp-in-ie8-or-chrome/2654/13

https://community.letsencrypt.org/t/xp-compatibility-issues/24277


If possible try to buy a cert (there are some for ~5$) from someone else
that is still selling SHA1 certs and try it again with that one.

My totally personal opinion however is to simply drop XP support. It's a
dying and unsupported OS with some major security flaws, but I know that
this route is not always an option.

[Alexandr Emelin]

Just tried trial certificate from Comodo - it works! So the problem is in Let's Encrypt issued certs. Having such a workaround solves my issue, many thanks for pointing me in right direction guys!

среда, 8 февраля 2017 г., 21:09:00 UTC+3 пользователь cynexit.x написал:

[Alexandr Emelin]

For history: we've made it work with Let's Encrypt issued certificates too: adding ForceRSA: true to autocert.Manager did the trick.

четверг, 9 февраля 2017 г., 10:48:08 UTC+3 пользователь Alexandr Emelin написал: