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

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

Related

Can't visit https://gentoo.org when connected over NAT

I have NAT configured on desktop for laptop to use. All is working except one thing: I cannot open https://gentoo.org. In links it hangs at "SSL negotiation. So, I guess this strange issue is related to SSL. All other HTTPS sites work fine.
NAT configuration on desktop:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i eth1 -j ACCEPT
wg0: Internet interface of desktop
eth1: laptop is connected to this interface
openssl s_client -connect www.gentoo.org:443 -prexit -debug shows:
CONNECTED(00000003)
write to 0x557ba3f68e50 [0x557ba3f78d70] (316 bytes => 316 (0x13C))
0000 - 16 03 01 01 37 01 00 01-33 03 03 ca da b4 c8 0d ....7...3.......
0010 - 7a 15 7b dc 4b cc 1b f9-1f 28 93 31 53 6b 6e 6f z.{.K....(.1Skno
0020 - 56 1d c2 df 06 b2 eb 35-a9 e8 56 20 c4 85 26 09 V......5..V ..&.
0030 - 1c 4b 8f d2 52 cb 76 a5-2c 06 2a da d8 a0 83 e2 .K..R.v.,.*.....
0040 - 64 53 87 5e ba 63 d1 d8-0e 25 24 d1 00 3e 13 02 dS.^.c...%$..>..
0050 - 13 03 13 01 c0 2c c0 30-00 9f cc a9 cc a8 cc aa .....,.0........
0060 - c0 2b c0 2f 00 9e c0 24-c0 28 00 6b c0 23 c0 27 .+./...$.(.k.#.'
0070 - 00 67 c0 0a c0 14 00 39-c0 09 c0 13 00 33 00 9d .g.....9.....3..
0080 - 00 9c 00 3d 00 3c 00 35-00 2f 00 ff 01 00 00 ac ...=.<.5./......
0090 - 00 00 00 13 00 11 00 00-0e 77 77 77 2e 67 65 6e .........www.gen
00a0 - 74 6f 6f 2e 6f 72 67 00-0b 00 04 03 00 01 02 00 too.org.........
00b0 - 0a 00 0c 00 0a 00 1d 00-17 00 1e 00 19 00 18 00 ................
00c0 - 23 00 00 00 16 00 00 00-17 00 00 00 0d 00 30 00 #.............0.
00d0 - 2e 04 03 05 03 06 03 08-07 08 08 08 09 08 0a 08 ................
00e0 - 0b 08 04 08 05 08 06 04-01 05 01 06 01 03 03 02 ................
00f0 - 03 03 01 02 01 03 02 02-02 04 02 05 02 06 02 00 ................
0100 - 2b 00 09 08 03 04 03 03-03 02 03 01 00 2d 00 02 +............-..
0110 - 01 01 00 33 00 26 00 24-00 1d 00 20 95 79 e4 57 ...3.&.$... .y.W
0120 - 04 d6 24 e3 cd 64 f7 16-89 f7 41 da dc 4d 12 45 ..$..d....A..M.E
0130 - 14 02 b5 b5 92 d0 f8 30-7a e0 cf 64 .......0z..d
and hangs.
Tried to debug using openssl s_client -connect

red5pro SSL with AWS EC2

I have successfully installed the red5pro server at my AWS EC2 instance. Works with http. To allow the access to my webcam I need to install an SSL certificate. I have set all inbound ports required for red5pro to work with SSL at my EC2 instance.
I have followed this guide from red5pro docs to get my certificate with letsencrypt. I have all the files mentioned there:
sudo ls /etc/letsencrypt/live/stream.gettoworkout-live.de/
cert.pem fullchain_and_key.p12 keystore.jks tomcat.cer
chain.pem fullchain.pem privkey.pem truststore.jks
After configuring red5pro to work with SSL (making said changes in red5.properties etc) I have tested my configuration with the mentioned open SSL test:
openssl s_client -connect stream.gettoworkout-live.de:443
The console output is:
CONNECTED(00000003)
After setting the debug option:
CONNECTED(00000003)
write to 0xed22d0 [0xed2350] (305 bytes => 305 (0x131))
0000 - 16 03 01 01 2c 01 00 01-28 03 03 c9 07 ca 58 2d ....,...(.....X-
0010 - 6f 9f b2 24 d6 6c af 3a-ad 2f 44 c1 54 18 9e 14 o..$.l.:./D.T...
0020 - b8 57 5a 53 b0 23 eb 0b-fd 03 1d 00 00 aa c0 30 .WZS.#.........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-c0 11 c0 07 c0 0c c0 02 .<./...A........
00c0 - 00 05 00 04 c0 12 c0 08-00 16 00 13 00 10 00 0d ................
00d0 - c0 0d c0 03 00 0a 00 ff-01 00 00 55 00 0b 00 04 ...........U....
00e0 - 03 00 01 02 00 0a 00 1c-00 1a 00 17 00 19 00 1c ................
00f0 - 00 1b 00 18 00 1a 00 16-00 0e 00 0d 00 0b 00 0c ................
0100 - 00 09 00 0a 00 23 00 00-00 0d 00 20 00 1e 06 01 .....#..... ....
0110 - 06 02 06 03 05 01 05 02-05 03 04 01 04 02 04 03 ................
0120 - 03 01 03 02 03 03 02 01-02 02 02 03 00 0f 00 01 ................
0130 - 01
Nothing more. No success or error message. Could somebody help?
UPDATE:
This is the Output after -state -nbio:
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
EDIT 2:
I have found out that my red5.log says
"o.r.n.w.SecureWebSocketConfiguration - Keystore or Truststore file does not exist"
I have installed red5pro in
/usr/local/red5pro
My keystore + truststore files are in
/etc/letsencrypt/live/stream.gettoworkout-live.de/
I reference the files in red5.properties with:
/etc/letsencrypt/live/stream.gettoworkout-live.de/truststore.jks
/etc/letsencrypt/live/stream.gettoworkout-live.de/keystore.jks

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

OpenSSL ClientHello fails in latest version

I need to connect to an SSL server. When I connect using OpenSSL 1.0.1r it works fine:
CONNECTED(00000304)
write to 0x6e13e8 [0x730a98] (297 bytes => 297 (0x129))
0000 - 16 03 01 01 24 01 00 01-20 03 03 16 f2 71 5f 26 ....$... ....q_&
0010 - a5 9b 64 cb 8f 0b 27 65-8d a3 54 e6 de a5 18 7a ..d...'e..T....z
0020 - 3c 5a e4 08 ab ff 6a 92-d7 45 f3 00 00 8a c0 30 <Z....j..E.....0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b .,.(.$.........k
0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a .j.9.8.....2...*
0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 2f .&.......=.5.../
0060 - c0 2b c0 27 c0 23 c0 13-c0 09 00 a2 00 9e 00 67 .+.'.#.........g
0070 - 00 40 00 33 00 32 00 9a-00 99 00 45 00 44 c0 31 .#.3.2.....E.D.1
0080 - c0 2d c0 29 c0 25 c0 0e-c0 04 00 9c 00 3c 00 2f .-.).%.......<./
0090 - 00 96 00 41 00 07 c0 11-c0 07 c0 0c c0 02 00 05 ...A............
00a0 - 00 04 c0 12 c0 08 00 16-00 13 c0 0d c0 03 00 0a ................
00b0 - 00 15 00 12 00 09 00 ff-01 00 00 6d 00 0b 00 04 ...........m....
00c0 - 03 00 01 02 00 0a 00 34-00 32 00 0e 00 0d 00 19 .......4.2......
00d0 - 00 0b 00 0c 00 18 00 09-00 0a 00 16 00 17 00 08 ................
00e0 - 00 06 00 07 00 14 00 15-00 04 00 05 00 12 00 13 ................
00f0 - 00 01 00 02 00 03 00 0f-00 10 00 11 00 23 00 00 .............#..
0100 - 00 0d 00 20 00 1e 06 01-06 02 06 03 05 01 05 02 ... ............
0110 - 05 03 04 01 04 02 04 03-03 01 03 02 03 03 02 01 ................
0120 - 02 02 02 03 00 0f 00 01-01 .........
>>> TLS 1.2 Handshake [length 0124], ClientHello
01 00 01 20 03 03 16 f2 71 5f 26 a5 9b 64 cb 8f
0b 27 65 8d a3 54 e6 de a5 18 7a 3c 5a e4 08 ab
ff 6a 92 d7 45 f3 00 00 8a c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 00 a3 00 9f 00 6b 00 6a 00 39 00
38 00 88 00 87 c0 32 c0 2e c0 2a c0 26 c0 0f c0
05 00 9d 00 3d 00 35 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 9a 00 99 00 45 00 44 c0 31 c0 2d c0 29 c0
25 c0 0e c0 04 00 9c 00 3c 00 2f 00 96 00 41 00
07 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 6d 00 0b 00 04 03 00 01 02 00
0a 00 34 00 32 00 0e 00 0d 00 19 00 0b 00 0c 00
18 00 09 00 0a 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 20 00
1e 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04
02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 00
0f 00 01 01
read from 0x6e13e8 [0x735ff8] (7 bytes => 7 (0x7))
0000 - 16 03 03 00 57 02 ....W.
0007 - <SPACES/NULS>
read from 0x6e13e8 [0x736002] (85 bytes => 85 (0x55))
0000 - 00 53 03 03 56 bb 11 21-1a ac 49 84 2d be 94 ad .S..V..!..I.-...
0010 - a0 c4 57 46 bc 70 d0 84-95 ce 96 c6 8c 92 07 2e ..WF.p..........
0020 - 4e 13 d6 f3 20 aa d7 86-ca 48 5e 01 a1 8c d3 f1 N... ....H^.....
0030 - d7 74 f9 2c 84 48 7d c1-95 6d 22 81 ff 53 ab d3 .t.,.H}..m"..S..
0040 - 0c 89 81 7d a2 00 3d 00-00 0b 00 0b 00 02 01 00 ...}..=.........
0050 - ff 01 00 01 ....
0055 - <SPACES/NULS>
<<< TLS 1.2 Handshake [length 0057], ServerHello
02 00 00 53 03 03 56 bb 11 21 1a ac 49 84 2d be
94 ad a0 c4 57 46 bc 70 d0 84 95 ce 96 c6 8c 92
07 2e 4e 13 d6 f3 20 aa d7 86 ca 48 5e 01 a1 8c
d3 f1 d7 74 f9 2c 84 48 7d c1 95 6d 22 81 ff 53
ab d3 0c 89 81 7d a2 00 3d 00 00 0b 00 0b 00 02
01 00 ff 01 00 01 00
read from 0x6e13e8 [0x735ffb] (5 bytes => 5 (0x5))
// etc.
However when I connect using OpenSSL 1.0.2f, the server closes the connection immediately:
CONNECTED(00000300)
write to 0x7812d0 [0x7ceef0] (317 bytes => 317 (0x13D))
0000 - 16 03 01 01 38 01 00 01-34 03 03 45 1c 09 c2 2e ....8...4..E....
0010 - 46 06 85 a1 01 fd 0a 2c-bb 6f 15 10 42 74 b3 bf F......,.o..Bt..
0020 - 9f 2e 5c 00 9f f2 93 8e-c0 18 9c 00 00 b6 c0 30 ..\............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 15 00 12 00 0f 00 0c ................
00e0 - 00 09 00 ff 01 00 00 55-00 0b 00 04 03 00 01 02 .......U........
00f0 - 00 0a 00 1c 00 1a 00 17-00 19 00 1c 00 1b 00 18 ................
0100 - 00 1a 00 16 00 0e 00 0d-00 0b 00 0c 00 09 00 0a ................
0110 - 00 23 00 00 00 0d 00 20-00 1e 06 01 06 02 06 03 .#..... ........
0120 - 05 01 05 02 05 03 04 01-04 02 04 03 03 01 03 02 ................
0130 - 03 03 02 01 02 02 02 03-00 0f 00 01 01 .............
>>> TLS 1.2 [length 0005]
16 03 01 01 38
>>> TLS 1.2 Handshake [length 0138], ClientHello
01 00 01 34 03 03 45 1c 09 c2 2e 46 06 85 a1 01
fd 0a 2c bb 6f 15 10 42 74 b3 bf 9f 2e 5c 00 9f
f2 93 8e c0 18 9c 00 00 b6 c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 00 a5 00 a3 00 a1 00 9f 00 6b 00
6a 00 69 00 68 00 39 00 38 00 37 00 36 00 88 00
87 00 86 00 85 c0 32 c0 2e c0 2a c0 26 c0 0f c0
05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0
23 c0 13 c0 09 00 a4 00 a2 00 a0 00 9e 00 67 00
40 00 3f 00 3e 00 33 00 32 00 31 00 30 00 9a 00
99 00 98 00 97 00 45 00 44 00 43 00 42 c0 31 c0
2d c0 29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00
96 00 41 00 07 c0 11 c0 07 c0 0c c0 02 00 05 00
04 c0 12 c0 08 00 16 00 13 00 10 00 0d c0 0d c0
03 00 0a 00 15 00 12 00 0f 00 0c 00 09 00 ff 01
00 00 55 00 0b 00 04 03 00 01 02 00 0a 00 1c 00
1a 00 17 00 19 00 1c 00 1b 00 18 00 1a 00 16 00
0e 00 0d 00 0b 00 0c 00 09 00 0a 00 23 00 00 00
0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05
03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02
02 02 03 00 0f 00 01 01
read from 0x7812d0 [0x7d4450] (7 bytes => 0 (0x0))
10124:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:.\ssl\s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 317 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: 1455100247
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
I don't suppose anyone speaks ClientHello sufficiently well to tell me what the difference is, and how to get OpenSSL 1.0.2f to behave like the old version (even if it is insecure; I don't control the server).
I checked both traces with Wireshark, and the only significant differences I can see are that OpenSSL 1.0.2's ClientHello packet is identified as "SSL" by Wireshark, and the record layer is SSL:
Whereas OpenSSL 1.0.1 is identified as TLS 1.2. It also has fewer cypher suites (I guess they removed some insecure ones?).
I've tried the following combinations, and these are how Wireshark labels them in the "Protocol" column:
1.0.1: <no options>=TLSv1.2; -ssl2=SSLv2; -ssl3=SSLv3; -tls1_2=TLSv1.2
1.0.2: <no options>=SSL; -ssl2=SSLv2; -ssl3=SSLv3; -tls1_2=SSL
Any ideas about:
Why Wireshark decodes 1.0.1 and 1.0.2 differently?
Why the connection is failing with 1.0.2?
How I can get OpenSSL 1.0.2 to behave like 1.0.1?

Why Wireshark decodes 1.0.1 and 1.0.2 differently?
See SSL Record Layer vs SSLv3 Record Layer on the Wireshark Q&A bulletin board and Secure Socket Layer (SSL) on the Wireshark wiki.
Why the connection is failing with 1.0.2?
Looks like a buggy server that's rejecting a record layer that's not an early one, like one used in SSLv3.
The record layer is just that... It specifies the version of the record layer, which is simply the framing of SSL/TLS protocol messages. It is not a MIN-TLS-VERSION as many people think.
The TLS protocol version is just that... It specifies the version of the SSL/TLS protocol. It is not a MAX-TLS-VERSION as many people think.
How I can get OpenSSL 1.0.2 to behave like 1.0.1?
Use the following in your client, but its not exactly the same. The OpenSSL client will do the right thing and select TLS 1.2 if its available:
/* Uses the early record layer for downlevel servers */
const SSL_METHOD* method = SSLv23_method();
if(NULL == method) handleFailure();
ctx = SSL_CTX_new(method);
if(ctx == NULL) handleFailure();
/* Cannot fail ??? */
const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1 | SSL_OP_NO_COMPRESSION;
SSL_CTX_set_options(ctx, flags);
I checked OpenSSL 1.0.2's ssl/ssl.h, and both SSL_OP_NO_TLSv1 and SSL_OP_NO_TLSv1_1 are available.
There's a different way to do it for OpenSSL Master (a.k.a, OpenSSL 1.1.0 and above); see Working around servers requiring SSL 2/3 record layer, and using TLS 1.2?
... [OpenSSL 1.0.2] also has fewer cipher suites (I guess they removed some insecure ones?).
You should not leave cipher suites to chance. You should do something like the following:
const char* const PREFERRED_CIPHERS = "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4";
res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
if(res != 1) handleFailure();
The !PSK and !SRP simply removes cipher suites that are not usually used. !MD5 and !RC4 are removed for servers to help avoid the Obsolete cryptography warning from Browser.
You could even do the following:
const char* const PREFERRED_CIPHERS =
"ECDHE-ECDSA-AES256-GCM-SHA384:"
"ECDHE-RSA-AES256-GCM-SHA384:"
"ECDHE-ECDSA-AES128-GCM-SHA256:"
"ECDHE-RSA-AES128-GCM-SHA256:"
"DHE-DSS-AES256-GCM-SHA384:"
"DHE-RSA-AES256-GCM-SHA384:"
"DHE-DSS-AES128-GCM-SHA256:"
"DHE-RSA-AES128-GCM-SHA256";
res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
if(res != 1) handleFailure();
Be sure to always offer a AES/GCM cipher suite because as server configurations move to a TLS 1.2-only configuration, that's the cipher suite they usually choose.
Also, each cipher suite takes up to bytes in the ClientHello, and you want to minimize the number of them. You want to minimize them because some older Proxies and Interception boxes use a fixed size buffer for the client's ClientHello, and they can't handle the proliferation of cipher suite options available in TLS 1.2. The older boxes include F5 and Ironport middleware.

Why Wireshark decodes 1.0.1 and 1.0.2 differently?
No idea.
Why the connection is failing with 1.0.2?
Hard to tell but I've seen several servers having problems with some ciphers added to OpenSSL 1.0.2 or that too much ciphers were given or similar. I've seen similar problems with recent LibreSSL versions. In this case the servers have obviously broken TLS stacks.
How I can get OpenSSL 1.0.2 to behave like 1.0.1?
You can try to reduce the cipher set so that it only uses the same ciphers as OpenSSL 1.0.1. Notable I've seen servers croak ChaCha20-Poly1305 was inside the cipher set, probably they did not understand what kind of cipher this is.

Unspecified bytes in SSL serverhello message

During SSL 3.0 handshaking server responses with the following serverhello message
16 03 00 00 51 02 00
00 4d 03 00 4f a1 c1
eb e3 fb 00 a9 c8 25
25 48 6f 89 27 ec bb
80 f3 8c 5d db f7 6c
94 56 d8 34 7a b5 9d
02 20 54 ab 20 ea 05
a6 38 6f ee 55 40 ae
af e2 5d ae 2a 4d c1
c6 f4 09 a7 08 b1 c5
49 39 87 82 d3 f7 00
39 00 00 05 ff 01 00
01 00
I understand this response as follows:
Content-type: 22 (Handshake protocol)
Version: 3.0
Length: a1 (81 bytes)
Content-type: 02 (ServerHello)
Length: 4d (77 bytes)
Version: 3.0
Random: 4f a1 c1 eb e3 fb 00 a9
c8 25 25 48 6f 89 27 ec
bb 80 f3 8c 5d db f7 6c
94 56 d8 34 7a b5 9d 02
SessionID Length: 20 (32 bytes)
SessionID: 54 ab 20 ea 05 a6 38 6f
ee 55 40 ae af e2 5d ae
2a 4d c1 c6 f4 09 a7 08
b1 c5 49 39 87 82 d3 f7
Cipher Suite: 00 39
Compression method: 00
But i can't understand how the last 7 bytes should be interpreted: 00 05 ff 01 00 01 00

That would be the renegotiation_info extension, as defined in RFC 5746:
o If this is the initial handshake for a connection, then the
"renegotiated_connection" field is of zero length in both the
ClientHello and the ServerHello. Thus, the entire encoding of the
extension is ff 01 00 01 00. The first two octets represent the
extension type, the third and fourth octets the length of the
extension itself, and the final octet the zero length byte for the
"renegotiated_connection" field.