-1

We have some legacy systems that are still only support tls1 (there are plans to move off this soon, but not soon enough).

In order to connect to our new system, I have enabled tls1 connections. However, when i run a command like: openssl s_client -connect host:port i get a failure to connect. When adding the -debug switch to see why i see the following:

CONNECTED(00000004)
write to 0x8000d02160 [0x8000d64000] (139 bytes => 139 (0x8B))
0000 - 80 89 01 03 01 00 60 00-00 00 20 00 00 39 00 00   ......`... ..9..
0010 - 38 00 00 35 00 00 88 00-00 87 00 00 84 00 00 16   8..5............
0020 - 00 00 13 00 00 0a 07 00-c0 00 00 33 00 00 32 00   ...........3..2.
0030 - 00 2f 00 00 45 00 00 44-00 00 41 03 00 80 00 00   ./..E..D..A.....
0040 - 05 00 00 04 01 00 80 00-00 15 00 00 12 00 00 09   ................
0050 - 06 00 40 00 00 14 00 00-11 00 00 08 00 00 06 04   ..@.............
0060 - 00 80 00 00 03 02 00 80-00 00 ff 29 c2 dd fb 71   ...........)...q
0070 - 5b 62 90 9e 5b b7 e7 5f-2e 67 9f a2 d2 01 eb bd   [b..[.._.g......
0080 - 7f 16 28 2a 66 eb 37 78-92 d7 80                  ..(*f.7x...
read from 0x8000d02160 [0x8000d6a000] (7 bytes => 0 (0x0))
59659:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/home/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_lib.c:182:

but, when i add the -tls1 switch i get connected as expected. I am confused why this is happening. Shouldn't openssl try all acceptable methods when connecting ?

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
johca
  • 43
  • 9

1 Answers1

2
0000 - 80 89 01 03 01 ...

This is a SSLv2 compatible ClientHello (0x01) announcing support for TLS version 1.0 (0x0301). My guess is that the server does not understand a SSLv2 compatible handshake (long obsolete) but expects a proper TLS handshake which you can get with the -tls1 option.

Given that your openssl s_client does this SSLv2 compatible handshake by default and that it only supports TLS 1.0 and not better (since this is the largest it is announcing by default) suggests that you are using an old and unsupported version of OpenSSL, i.e. 0.9.8 or 1.0.0.

Shouldn't openssl try all acceptable methods when connecting ?

That's not how SSL/TLS works. There is not trying of various methods. Instead the client announces the best it can do (TLS 1.0 in your case) and the server picks a protocol version equal or lower to the version supported by the client, in the hope that the client will accept this.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • Steffen, thank you for your comment. I am using OpenSSL 0.9.8zg 11 Jun 2015. I am not able to upgrade on this host. Due to this, am i totally screwed on this ? – johca Jun 29 '17 at 18:26
  • Also - Is it possible to force tls1 in the openssl.cnf file ? – johca Jun 29 '17 at 18:29
  • @john: you cannot force a the use of a specific protocol in openssl.cnf or anywhere else. The behavior is specific for each application using openssl. Apart from that, `openssl s_client` is just a tool for testing so you should care more that your applications are doing it properly instead of `s_client`. As for OpenSSL 0.9.8 - it does support TLS 1.0 but not TLS 1.1 or TLS 1.2. Thus if the requirement will be to use a better protocol you will be screwed. – Steffen Ullrich Jun 29 '17 at 18:34
  • thank you very much for your answers. I understand much better now. – johca Jun 29 '17 at 18:41
  • 1
    *... and the server picks a protocol version equal or lower to the version supported by the client"* - That's not standard behavior. Some servers, like OpenSSL based ones, will select in the range `[TLS Record Version, TLS Handshake Version]` because TLS does not offer a way to specify a range. But it assumes the versions are meaningful in that manner, `TLS Record Version <= TLS Handshake Version`, etc. OpenSSL is supposed to abort the handshake if it does not support the client version. The client is supposed to retry with the next lower protocol version and `TLS_FALLBACK_SCSV` set. – jww Jul 01 '17 at 02:40
  • @jww: *"The client is supposed to retry with the next lower protocol version and TLS_FALLBACK_SCSV set."*- I don't think so. In my opinion the client has no obligation to retry with a lower version and most clients don't. TLS_FALLBACK_SCSV is only supposed to be used to signal that the client has retried (because maybe a downgrade attack is going on) but does not mean that the client must retry in the first place. Retrying is only needed if the server is broken and does not properly reply to the ClientHello. – Steffen Ullrich Jul 01 '17 at 04:48
  • 1
    *"I don't think so..."* - Well, that's the way it works. Dave Garrett and I have tried to get it changed for the last several years. Rescorla and others are against it. *"most clients don't \[retry\]"* - Web browsers do. They are the ones to thank for `TLS_FALLBACK_SCSV`. Also see [Prohibit <1.2 support on 1.3+ servers](https://www.ietf.org/mail-archive/web/tls/current/msg16433.html) and [New TLS version negotiation mechanism](https://www.ietf.org/mail-archive/web/tls/current/msg15707.html) on the TLS WG mailing list. – jww Jul 01 '17 at 05:26
  • 1
    @jww: if you count it by the pure number of clients then you might be right because desktop browsers are the majority of clients and many implement fall back. Although Firefox has disabled in in version 37 if I understand [this bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1084025) correctly. But if you count by the number of different applications instead then most don't do fallback. Browsers are really an exception because they employ workarounds for many broken servers, not only at the TLS level. – Steffen Ullrich Jul 01 '17 at 05:43