SSL error using curl/wget - ssl

Recently, I started seeing this problem on my Mac. I am able to download files or visit any https web page from Chrome, but I am not able to do that anymore with either curl or wget.
$ curl --verbose https://www.google.com/
* Trying 2607:f8b0:4007:803::2004...
* TCP_NODELAY set
* Connected to www.google.com (::1) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /Users/tomkwong/anaconda3/ssl/cacert.pem
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.google.com:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.google.com:443
Here's the wget error:
$ wget --verbose https://www.google.com/
--2018-03-27 23:53:32-- https://www.google.com/
Resolving www.google.com (www.google.com)... 2607:f8b0:4007:803::2004, 172.217.14.68
Connecting to www.google.com (www.google.com)|2607:f8b0:4007:803::2004|:443... connected.
GnuTLS: The TLS connection was non-properly terminated.
Unable to establish SSL connection.
More information by using openssl command as requested. I'm unsure what to make sense out of it... looks like errno=54 means "Connection reset by peer".
$ openssl s_client -debug -connect www.google.com:443 -prexit
CONNECTED(00000003)
write to 0x7feb37558870 [0x7feb3800ca00] (307 bytes => 307 (0x133))
0000 - 16 03 01 01 2e 01 00 01-2a 03 03 73 60 8a 49 d5 ........*..s`.I.
0010 - ad 36 db 41 da 14 20 c9-85 7b f8 5b 2b b3 2b c0 .6.A.. ..{.[+.+.
0020 - b6 47 e1 c5 b9 75 b9 c2-9d d9 1c 00 00 ac c0 30 .G...u.........0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a5 00 a3 00 a1 .,.(.$..........
0040 - 00 9f 00 6b 00 6a 00 69-00 68 00 39 00 38 00 37 ...k.j.i.h.9.8.7
0050 - 00 36 00 88 00 87 00 86-00 85 c0 32 c0 2e c0 2a .6.........2...*
0060 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f .&.......=.5.../
0070 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a4 00 a2 00 a0 .+.'.#..........
0080 - 00 9e 00 67 00 40 00 3f-00 3e 00 33 00 32 00 31 ...g.#.?.>.3.2.1
0090 - 00 30 00 9a 00 99 00 98-00 97 00 45 00 44 00 43 .0.........E.D.C
00a0 - 00 42 c0 31 c0 2d c0 29-c0 25 c0 0e c0 04 00 9c .B.1.-.).%......
00b0 - 00 3c 00 2f 00 96 00 41-00 07 c0 11 c0 07 c0 0c .<./...A........
00c0 - c0 02 00 05 00 04 c0 12-c0 08 00 16 00 13 00 10 ................
00d0 - 00 0d c0 0d c0 03 00 0a-00 ff 01 00 00 55 00 0b .............U..
00e0 - 00 04 03 00 01 02 00 0a-00 1c 00 1a 00 17 00 19 ................
00f0 - 00 1c 00 1b 00 18 00 1a-00 16 00 0e 00 0d 00 0b ................
0100 - 00 0c 00 09 00 0a 00 23-00 00 00 0d 00 20 00 1e .......#..... ..
0110 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02 ................
0120 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f ................
0130 - 00 01 01 ...
read from 0x7feb37558870 [0x7feb38012000] (7 bytes => -1 (0xFFFFFFFFFFFFFFFF))
write:errno=54
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 307 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1522221838
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 307 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1522221838
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

Rebooting the computer fixes the problem!
I should have thought about that earlier :-)

Related

Problem Connecting to SSL 1.2 Host from Java - Ignoring Unsupported Cipher Suite for TLS v1

I am connecting to a finicky host that uses SSL v1.2.
It seems to be failing to connect due to the appropriate cipher not being found. I don't know why?
Host Configuration
Analyzing the host using immuniniweb.com shows it supports the following cipher suites (for TLSv1.2):
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Notes
The connection is using a certificate supplied by the host
The connection works using stunnel
The connection is for a non-HTTP protocol
The Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files have been installed.
Connecting
However when I connect using java (jdk1.8.0_65 on MacOS) with the following options:
-Djavax.net.debug=SSL:handshake:verbose
-Djavax.net.debug=all
-Djdk.tls.client.protocols=TLSv1.2
-Dhttps.cipherSuites=TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
-Dhttps.protocols=TLSv1.2
I get the following results:
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring disabled protocol: SSLv3
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1564124670 bytes = { 182, 166, 70, 240, 207, 103, 192, 255, 249, 156, 39, 115, 16, 135, 116, 22, 247, 138, 216, 231, 235, 150, 230, 254, 147, 191, 153, 156 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
***
[write] MD5 and SHA1 hashes: len = 237
0000: 01 00 00 E9 03 03 5D 3B A6 FE B6 A6 46 F0 CF 67 ......];....F..g
0010: C0 FF F9 9C 27 73 10 87 74 16 F7 8A D8 E7 EB 96 ....'s..t.......
0020: E6 FE 93 BF 99 9C 00 00 64 C0 24 C0 28 00 3D C0 ........d.$.(.=.
0030: 26 C0 2A 00 6B 00 6A C0 0A C0 14 00 35 C0 05 C0 &.*.k.j.....5...
0040: 0F 00 39 00 38 C0 23 C0 27 00 3C C0 25 C0 29 00 ..9.8.#.'.<.%.).
0050: 67 00 40 C0 09 C0 13 00 2F C0 04 C0 0E 00 33 00 g.#...../.....3.
0060: 32 C0 2C C0 2B C0 30 00 9D C0 2E C0 32 00 9F 00 2.,.+.0.....2...
0070: A3 C0 2F 00 9C C0 2D C0 31 00 9E 00 A2 C0 08 C0 ../...-.1.......
0080: 12 00 0A C0 03 C0 0D 00 16 00 13 00 FF 01 00 00 ................
0090: 5C 00 0A 00 34 00 32 00 17 00 01 00 03 00 13 00 \...4.2.........
00A0: 15 00 06 00 07 00 09 00 0A 00 18 00 0B 00 0C 00 ................
00B0: 19 00 0D 00 0E 00 0F 00 10 00 11 00 02 00 12 00 ................
00C0: 04 00 05 00 14 00 08 00 16 00 0B 00 02 01 00 00 ................
00D0: 0D 00 1A 00 18 06 03 06 01 05 03 05 01 04 03 04 ................
00E0: 01 03 03 03 01 02 03 02 01 02 02 01 01 .............
NioProcessor-2, WRITE: TLSv1.2 Handshake, length = 237
[write] MD5 and SHA1 hashes: len = 206
0000: 01 03 03 00 A5 00 00 00 20 00 C0 24 00 C0 28 00 ........ ..$..(.
0010: 00 3D 00 C0 26 00 C0 2A 00 00 6B 00 00 6A 00 C0 .=..&..*..k..j..
0020: 0A 07 00 C0 00 C0 14 00 00 35 00 C0 05 00 C0 0F .........5......
0030: 00 00 39 00 00 38 00 C0 23 00 C0 27 00 00 3C 00 ..9..8..#..'..<.
0040: C0 25 00 C0 29 00 00 67 00 00 40 00 C0 09 06 00 .%..)..g..#.....
0050: 40 00 C0 13 00 00 2F 00 C0 04 01 00 80 00 C0 0E #...../.........
0060: 00 00 33 00 00 32 00 C0 2C 00 C0 2B 00 C0 30 00 ..3..2..,..+..0.
0070: 00 9D 00 C0 2E 00 C0 32 00 00 9F 00 00 A3 00 C0 .......2........
0080: 2F 00 00 9C 00 C0 2D 00 C0 31 00 00 9E 00 00 A2 /.....-..1......
0090: 00 C0 08 00 C0 12 00 00 0A 07 00 C0 00 C0 03 02 ................
00A0: 00 80 00 C0 0D 00 00 16 00 00 13 00 00 FF 5D 3B ..............];
00B0: A6 FE B6 A6 46 F0 CF 67 C0 FF F9 9C 27 73 10 87 ....F..g....'s..
00C0: 74 16 F7 8A D8 E7 EB 96 E6 FE 93 BF 99 9C t.............
NioProcessor-2, WRITE: SSLv2 client hello message, length = 206
[Raw write]: length = 208
0000: 80 CE 01 03 03 00 A5 00 00 00 20 00 C0 24 00 C0 .......... ..$..
0010: 28 00 00 3D 00 C0 26 00 C0 2A 00 00 6B 00 00 6A (..=..&..*..k..j
0020: 00 C0 0A 07 00 C0 00 C0 14 00 00 35 00 C0 05 00 ...........5....
0030: C0 0F 00 00 39 00 00 38 00 C0 23 00 C0 27 00 00 ....9..8..#..'..
0040: 3C 00 C0 25 00 C0 29 00 00 67 00 00 40 00 C0 09 <..%..)..g..#...
0050: 06 00 40 00 C0 13 00 00 2F 00 C0 04 01 00 80 00 ..#...../.......
0060: C0 0E 00 00 33 00 00 32 00 C0 2C 00 C0 2B 00 C0 ....3..2..,..+..
0070: 30 00 00 9D 00 C0 2E 00 C0 32 00 00 9F 00 00 A3 0........2......
0080: 00 C0 2F 00 00 9C 00 C0 2D 00 C0 31 00 00 9E 00 ../.....-..1....
0090: 00 A2 00 C0 08 00 C0 12 00 00 0A 07 00 C0 00 C0 ................
00A0: 03 02 00 80 00 C0 0D 00 00 16 00 00 13 00 00 FF ................
00B0: 5D 3B A6 FE B6 A6 46 F0 CF 67 C0 FF F9 9C 27 73 ];....F..g....'s
00C0: 10 87 74 16 F7 8A D8 E7 EB 96 E6 FE 93 BF 99 9C ..t.............
NioProcessor-2, called closeOutbound()
NioProcessor-2, closeOutboundInternal()
NioProcessor-2, SEND TLSv1.2 ALERT: warning, description = close_notify
NioProcessor-2, WRITE: TLSv1.2 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 03 00 02 01 00 .......
NioProcessor-2, called closeInbound()
NioProcessor-2, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
NioProcessor-2, SEND TLSv1.2 ALERT: fatal, description = internal_error
NioProcessor-2, Exception sending alert: java.io.IOException: writer side was already closed.
NioProcessor-2, called closeOutbound()
NioProcessor-2, closeOutboundInternal()
Any ideas?
It appears that the problem is simply that the -Djdk.tls.client.protocols=TLSv1.2 option is not making its way through to the third party library that is creating the SSL connection.
Running a simple piece of code to perform the connection with that option works.
The giveaway was #user207421 's comment that SSLv2Hello seemed to be enabled - the documentation states that if you specify TSLv1.2 then SSLv2Hello is disabled already.

Old TLS1.0 clients cannot connect to Google App Engine on Custom Domain

We have a Google App Engine project that is setup to work over a custom domain on HTTPS (Using Google managed SSL certs). For most part it is working fine e.g. on Chrome and other modern browsers but NOT for some old TL1.0 clients where it is failing the handshake.
The problem seems with ghs.googlehosted.com GFE servers. AppEngine GFEs on appspot-preview.l.google.com work fine for these clients.
Here is an example log with openssl, connecting to api.my-project.com
$ openssl s_client -connect ghs.googlehosted.com:443 -msg
CONNECTED(00000005)
>>> TLS 1.2 Handshake [length 0139], ClientHello
01 00 01 35 03 03 82 73 d6 6c 32 b7 84 f3 30 57
8f 98 a7 6e e7 c2 f5 b8 be f4 29 55 41 25 35 ab
56 51 3c 1e b9 e3 00 00 98 cc 14 cc 13 cc 15 c0
30 c0 2c c0 28 c0 24 c0 14 c0 0a 00 a3 00 9f 00
6b 00 6a 00 39 00 38 ff 85 00 c4 00 c3 00 88 00
87 00 81 c0 32 c0 2e c0 2a c0 26 c0 0f c0 05 00
9d 00 3d 00 35 00 c0 00 84 c0 2f c0 2b c0 27 c0
23 c0 13 c0 09 00 a2 00 9e 00 67 00 40 00 33 00
32 00 be 00 bd 00 45 00 44 c0 31 c0 2d c0 29 c0
25 c0 0e c0 04 00 9c 00 3c 00 2f 00 ba 00 41 c0
11 c0 07 c0 0c c0 02 00 05 00 04 c0 12 c0 08 00
16 00 13 c0 0d c0 03 00 0a 00 15 00 12 00 09 00
ff 01 00 00 74 00 0b 00 04 03 00 01 02 00 0a 00
3a 00 38 00 0e 00 0d 00 19 00 1c 00 0b 00 0c 00
1b 00 18 00 09 00 0a 00 1a 00 16 00 17 00 08 00
06 00 07 00 14 00 15 00 04 00 05 00 12 00 13 00
01 00 02 00 03 00 0f 00 10 00 11 00 23 00 00 00
0d 00 26 00 24 06 01 06 02 06 03 ef ef 05 01 05
02 05 03 04 01 04 02 04 03 ee ee ed ed 03 01 03
02 03 03 02 01 02 02 02 03
140735490237384:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.50.2/libressl/ssl/s23_lib.c:124:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 318 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
It works connecting to my-project.appspot.com
$ openssl s_client -connect appspot-preview.l.google.com:443
CONNECTED(00000005)
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot-preview.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFNjCCBB6gAwIBAgIIf6MEypLTuRMwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
R29vZ2xlIEludGVybmV0IEF1dGhvcml0eSBHMzAeFw0xODA0MTcxMzQ5NTFaFw0x
ODA3MTAxMjM5MDBaMG8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
MRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKDApHb29nbGUgSW5jMR4w
HAYDVQQDDBUqLmFwcHNwb3QtcHJldmlldy5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQCmdyEZXoKJUUXkt0edaQhKSTWt+6EUBHa2OSGrk5uT9UZo
c2El7MMFl1aFhPzDJR3quZpFXdrGYoB5sVSPHDc33EKhWSG/+4YeYMi/fOiGC3x+
Tqesk+F8TME49MTDvSdOZVuYyVJkIYatTeVdfgW7IZ34bbGviazlf236DRfrhxsQ
HpZEaSXkziDbWCbnAvJSwpmxRX8bOmkncecfwOnS0g8O8is9hmMvFo1yBkvns3bm
5gNzA9JHuLvd6T9iW/rfZbi86oinv+cEUlqxQDesTzaWs399uJDf0Glshs9wr3jM
UzwPP36bulMEfdBak3B+eI+jCm+X7WQbp7aF3GxfAgMBAAGjggHvMIIB6zATBgNV
HSUEDDAKBggrBgEFBQcDATCBxQYDVR0RBIG9MIG6ghUqLmFwcHNwb3QtcHJldmll
dy5jb22CDSouYXBwc3BvdC5jb22CFSoudGhpbmt3aXRoZ29vZ2xlLmNvbYIQKi53
aXRoZ29vZ2xlLmNvbYIRKi53aXRoeW91dHViZS5jb22CE2FwcHNwb3QtcHJldmll
dy5jb22CC2FwcHNwb3QuY29tghN0aGlua3dpdGhnb29nbGUuY29tgg53aXRoZ29v
Z2xlLmNvbYIPd2l0aHlvdXR1YmUuY29tMGgGCCsGAQUFBwEBBFwwWjAtBggrBgEF
BQcwAoYhaHR0cDovL3BraS5nb29nL2dzcjIvR1RTR0lBRzMuY3J0MCkGCCsGAQUF
BzABhh1odHRwOi8vb2NzcC5wa2kuZ29vZy9HVFNHSUFHMzAdBgNVHQ4EFgQU1jst
cVQOljRrrXMTZa4vqe7cCiMwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR3wrhQ
mmd2drEtwobQg6B+pn66SzAhBgNVHSAEGjAYMAwGCisGAQQB1nkCBQMwCAYGZ4EM
AQICMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwucGtpLmdvb2cvR1RTR0lB
RzMuY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQCFibJ0MNHYQk2x6jUHCsdmswo3HACq
nhGV0KXuG0kK6bmPAYYzNuIj6Ee+Dq1x9eFrhxiCu1fQsRKJ42xHTawUBEdhKgcz
wMDxkhRsd3rO1pF8LPTyT4XDACOH20UUxOzBY4yiIP6MU8oZxEGPP7Db2UnpKBJU
/ID1DyAHntoQru/5zNbKFlCfzFgpuTkXCtZlBrY33/V3V3umsOgwOz+isDNW4N+f
RrSpGynywJiHLXFSs/tOr0dFsebG2Dil2ZVDq5aRDhGMn7WKNe8IJvI3GMr6ZUiS
o7WzSPqRij1HOgJoNsL39luSwwOxWJ4znaDkjoewxFmWMqd/7F0lVf4m
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot-preview.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
---
No client certificate CA names sent
---
SSL handshake has read 3166 bytes and written 444 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 7C3AAFD46B8D8C8C95F336DEAFFEAB0950B61A01DE9CCD33BC1B4E00B8778ACA
Session-ID-ctx:
Master-Key: F796ECD4CA06D7B3FD8888F5B74AA70C22846CCD207AFA9BC3686AD53E3CBAEA7E2535B9051C0CE2EB96CBA80090CD14
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 00 cf 37 1b ad 9e 5d e3-33 ca 1f 1a 53 78 e0 1b ..7...].3...Sx..
0010 - 9a 7b fe 86 70 da 77 ee-b6 a4 2d 0e 5d 57 c4 b0 .{..p.w...-.]W..
0020 - 5e 3a f3 37 65 d1 bb c3-9f 47 0c e9 05 fc c0 6b ^:.7e....G.....k
0030 - 26 ed a2 27 dc 18 17 88-79 70 4f e4 92 a0 b7 fa &..'....ypO.....
0040 - b6 91 6e c0 7f c6 6e cc-35 81 02 5b 9d 4c 66 6f ..n...n.5..[.Lfo
0050 - 6e 5b d2 7e c5 8f bb 14-70 a8 dd 9b cb ff 50 07 n[.~....p.....P.
0060 - 0f 9c 86 f6 4a d3 bd c7-20 26 2a b6 c3 f7 52 1e ....J... &*...R.
0070 - ce 1d 8e 77 be 65 d6 41-44 c8 9a 30 31 29 66 93 ...w.e.AD..01)f.
0080 - 15 fc 76 f2 6a c5 68 92-23 96 d5 47 50 92 04 e0 ..v.j.h.#..GP...
0090 - 6a de d4 77 b7 bb 02 cf-fd fe 75 71 13 2c c7 34 j..w......uq.,.4
00a0 - 47 48 f3 fa a2 fc ef 7d-7a bd b9 94 8e 40 06 c6 GH.....}z....#..
00b0 - a3 55 56 ec af 29 77 27-7f 40 98 4e ef 0b dc 54 .UV..)w'.#.N...T
00c0 - 6d 8f d1 93 8f 96 2d c2-79 42 1f 4a 7b f4 d6 d9 m.....-.yB.J{...
00d0 - e7 f0 d1 5a 83 ...Z.
Start Time: 1526935566
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE

openssl s_client only works with -tls1 switch to connect

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 ?
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.

Kafka SSL(Connection with node Disconnected)

I have configured SSL for kafka and I am having following two scenarios :-
A) When I configure the SSL listener on internal IP address (192.168.x.x), It works fine,
B) When I configure the SSL listener on eth1 IP address(10.x.x.x) because that is the only IP of broker my client can reach, It doesnt work but throw following error :-
[2017-04-07 09:04:31,566] DEBUG Completed connection to node -1 (org.apache.kafka.clients.NetworkClient)
[2017-04-07 09:06:17,860] DEBUG Connection with devmoomsg1/10.228.175.83 disconnected (org.apache.kafka.common.network.Selector)
Adding more, When I try to check with the openssl whether the firewall is blockiing the ssl traffic I get output fine.
OpenSSL> s_client -host x.x.x.x -port 443 -debug
CONNECTED(00000003)
write to 0x1500040 [0x1548fa0] (249 bytes => 249 (0xF9))
0000 - 16 03 01 00 f4 01 00 00-f0 03 03 58 e7 49 9b 1b ...........X.I..
0010 - 60 ba 05 65 af 2e d3 2f-18 61 2a 87 ad b6 82 c6 `..e.../.a*.....
0020 - cd 9b d5 16 89 07 dd 65-38 1d 53 00 00 84 c0 30 .......e8.S....0
0030 - c0 2c c0 28 c0 24 c0 13-c0 0a 00 a3 00 9f 00 6b .,.(.$.........k
0040 - 00 6a 00 39 00 38 00 99-00 87 c0 32 c0 2e c0 2a .j.9.8.....2...*
...
0080 - 00 44 00 16 00 13 c0 31-c0 2d c0 29 c0 25 c0 0e .D.....1.-.).%..
0090 - c0 04 c0 0d c0 03 00 9c-00 3c 00 2f 00 96 00 41 .........<./...A
....
00e0 - 04 01 04 02 04 03 03 01-03 02 03 03 02 01 02 02 ................
00f0 - 02 03 01 01 00 0f 00 01-01 .........

ssl connection failed because of sanity check fail

I am working in establishing a secure communication channel between a java server and a tls client. During the handshake, all goes well, the client Hello and server Hello messages are correct. Moreover, they both generate the same master secret for the engaged session. But at the really end of the handshake, server throws an exception telling "Ciphertext sanity check fails".
Client trace
0050 - 34 68 ed 2f 6e 4h./n
>>> TLS 1.2 ChangeCipherSpec [length 0001]
01
write to 0x1878b98 [0x18891f0] (6 bytes => 6 (0x6))
0000 - 14 03 03 00 01 01 ......
>>> TLS 1.2 Handshake [length 0010], Finished
14 00 00 0c 14 54 0c 4d c0 22 62 90 c2 92 a1 d1
write to 0x1878b98 [0x18891f0] (45 bytes => 45 (0x2D))
0000 - 16 03 03 00 28 b7 76 bd-36 cd cd eb 8d 9f 34 46 ....(.v.6.....4F
0010 - 25 f7 61 cc cd a3 8e af-6d da 14 60 3c 0f 50 21 %.a.....m..`<.P!
0020 - f4 cc 7a a4 af cf 75 d8-48 54 ee b9 44 ..z...u.HT..D
read from 0x1878b98 [0x187f7e3] (5 bytes => 5 (0x5))
0000 - 15 03 03 00 02 .....
read from 0x1878b98 [0x187f7e8] (2 bytes => 2 (0x2))
0000 - 02 28 .(
<<< TLS 1.2 Alert [length 0002], fatal handshake_failure
02 28
Server's side:
[Raw read]: length = 5
0000: 14 03 03 00 01 .....
[Raw read]: length = 1
0000: 01 .
Thread-0, READ: TLSv1.2 Change Cipher Spec, length = 1
[Raw read]: length = 5
0000: 16 03 03 00 28 ....(
[Raw read]: length = 40
0000: B7 76 BD 36 CD CD EB 8D 9F 34 46 25 F7 61 CC CD .v.6.....4F%.a..
0010: A3 8E AF 6D DA 14 60 3C 0F 50 21 F4 CC 7A A4 AF ...m..`<.P!..z..
0020: CF 75 D8 48 54 EE B9 44 .u.HT..D
Thread-0, READ: TLSv1.2 Handshake, length = 40
%% Invalidated: [Session-1, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256]
Thread-0, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
Thread-0, WRITE: TLSv1.2 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 03 00 02 02 28 ......(
Thread-0, called closeSocket()
Thread-0, handling exception: javax.net.ssl.SSLHandshakeException: ciphertext sanity check failed
What I can not understand is why the server is launching such exception while it succeeds in decrypting the ChangeCipherSpec message sent from the client? What could be the reason for such exception?
N.B: I already check and they both derived the same master key, here it is:
Server's side
CONNECTION KEYGEN:
Client Nonce:
0000: 48 B2 6C 02 B1 40 0B D9 6E 14 EB 7A 93 7D 2F 07 H.l..#..n..z../.
0010: 90 CF 1E 5D 65 8A 66 89 54 D4 60 50 BD AC AB 34 ...]e.f.T.`P...4
Server Nonce:
0000: 54 FD 9A E3 BB D4 15 61 A6 0C D3 30 FA 07 0A 16 T......a...0....
0010: 79 A8 79 0B 0A 81 00 95 9C CA C0 7A F1 FF 37 E7 y.y........z..7.
Master Secret:
0000: 39 5B EB 11 66 09 25 B5 6D E4 C7 86 E4 3E 10 BB 9[..f.%.m....>..
0010: B4 F0 D9 B7 BD 7D 8F AD 58 38 31 42 B6 90 53 AD ........X81B..S.
0020: 54 46 36 DC F5 75 8A 9D 77 58 D5 24 6C 96 90 02 TF6..u..wX.$l...
Client's side
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES128-GCM-SHA256
Session-ID: 54FD9AE3A3B3BF807F408FA830641F850702E986C27FC631AF8E8E3097038166
Session-ID-ctx:
Master-Key: 395BEB11660925B56DE4C786E43E10BBB4F0D9B7BD7D8FAD58383142B69053AD544636DCF5758A9D7758D5246C969002
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
Thanks in advance to you guys.