I have a server app running on my computer listening on a certain port. When I try to use OpenSSL (on Mac, i upgraded via brew already from the default Mac version for OpenSSL).
openssl s_client -connect 0.0.0.0:80051 -showcerts -prexit -servername localhost -debug
Response
CONNECTED(00000003)
write to 0x7fe62b41b370 [0x7fe62b80d000] (118 bytes => 118 (0x76))
0000 - 16 03 01 00 71 01 00 00-6d 03 01 58 d2 84 72 d5 ....q...m..X..r.
0010 - 1b d3 47 9c 8e 6b b3 fb-10 a5 21 af 0e 5d 79 7b ..G..k....!..]y{
0020 - 54 77 4b 70 11 b0 77 5e-1e 9c e7 00 00 2e 00 39 TwKp..w^.......9
0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f .8.5.......3.2./
0040 - 00 9a 00 99 00 96 00 05-00 04 00 15 00 12 00 09 ................
0050 - 00 14 00 11 00 08 00 06-00 03 00 ff 01 00 00 16 ................
0060 - 00 00 00 0e 00 0c 00 00-09 6c 6f 63 61 6c 68 6f .........localho
0070 - 73 74 00 23 st.#
0076 - <SPACES/NULS>
read from 0x7fe62b41b370 [0x7fe62b812600] (7 bytes => 0 (0x0))
85473:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.60.1/src/ssl/s23_lib.c:185:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 118 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
On server
E0322 10:04:34.017891000 123145312870400 ssl_transport_security.c:947] Handshake failed with fatal error SSL_ERROR_SSL: error:1408A10B:SSL routines:ssl3_get_client_hello:wrong version number.
E0322 10:04:34.017964000 123145312870400 chttp2_server.c:123] Handshaking failed: {"created":"#1490191474.017913000","description":"Handshake failed","file":"../src/core/lib/security/transport/security_handshaker.c","file_line":274,"tsi_code":10,"tsi_error":"TSI_PROTOCOL_FAILURE"}
I have tried passing -ssl3 and -tls1 in the OpenSSL command with no success. Any thoughts on how to process the info or use the openssl to debug further what might be causing ssl client connection issues to the server. Thanks
i upgraded via brew already from the default Mac version for OpenSSL...
0000 - 16 03 01 .... 03 01
The debug logs shows a ClientHello with TLS version 1.0 (0x0301). This suggests that an old version of OpenSSL was used and not the upgraded one, since this version 1.0.1 (released 2012) it supports TLS 1.2 and will use it by default.
Related
I would like to implement a sniffer for incident response and forensic investigations, to sniff the traffic and identifying malicious packets and C2 (C&C -Command and Control) IP.
In incident response i can't install npcap/winpcap or other librairies detected by antivirus softwares and i should use the faster way to sniff the local traffic. So i would like to develop a simple CLI sniffer (it must be launched on Windows core servers) in a simple executable file to copy/paste it on the server and launch it with admin privileges.
Context example: a ransomware is running on a server and exfiltrate data, there are some NAT (Network Address Translation) between firewalls and the server (so it's difficult to identifying the the malicious traffic).
I write a POC in python on my github.
How i use my raw socket:
from socket import socket, AF_INET6, SOCK_RAW, IPPROTO_IP, IPPROTO_IPV6, IPV6_PKTINFO, SIO_RCVALL, RCVALL_ON, RCVALL_OFF
sock = socket(AF_INET6, SOCK_RAW, IPPROTO_IP)
sock.bind(("<IPv6 address>", 0))
sock.setsockopt(IPPROTO_IPV6, IPV6_PKTINFO, 0)
sock.ioctl(SIO_RCVALL, RCVALL_ON)
while True:
data, source_address = sock.recvfrom(65535)
sock.ioctl(SIO_RCVALL, RCVALL_ON)
sock.close()
What i get when i sniff a ICMPV6 packet:
0000 80 00 68 62 00 01 42 dc 61 62 63 64 65 66 67 68 ..hb..B.abcdefgh
0010 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 ijklmnopqrstuvwa
0020 62 63 64 65 66 67 68 69 bcdefghi
It's just the data section without any IPv6 headers so i can't see IPv6 address and protocol type (so i can't parse data).
What i want:
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60 00 ..............`.
0010 00 00 00 28 3a 80 fe 80 00 00 00 00 00 00 12 23 ...(:.*........Z
0020 34 45 56 65 67 78 fe 80 00 00 00 00 00 00 00 00 :(B.#.*..P#.....
0030 00 00 00 00 12 23 80 00 68 6a 00 01 42 d4 61 62 .... ...hj..B.ab
0040 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 cdefghijklmnopqr
0050 73 74 75 76 77 61 62 63 64 65 66 67 68 69 stuvwabcdefghi
Here i have the Ethernet frame, i would like it but for if you can help me to get only the IPv6 headers, it's okay. If you know how i can get the full ethernet frame, packet and segment it's better for me.
I see IPV6_HDRINCL but it's only to send IPV6 headers not to receive it and i see this RFC, i don't find what i search.
I want to build a BLE Beacon with Raspberry Pi Zero W and with an iOS and Android app (which I'll develop) I'll list the beacons and select one to send 4-6bytes of data to trigger some action on the Pi. Is that possible with Beacons or should I use something else. I am writing in Go and I don't want to pair the devices.
Yes, it is possible to make a Raspberry Pi Zero W scan for beacons and take action which identifier it saw. (Although please note that this must be a Zero W. The base Raspberry Pi Zero does not have wireless functionality.)
You won't find beacon detection code in Go on the Raspberry Pi, so your best bet is to use a native C program to do the beacon scanning part, and call it as a shell script from your Go program. The following C program is one I use on a Raspberry Pi to scan for beacons:
https://gist.github.com/davidgyoung/0a18028b4338ff6cb201fba274502662
That program must be compiled on the Raspberry Pi with cc scanner.c -lbluetooth -o scanner, after which you can start the scanner with just scanner. The output of the program will be something like this:
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
71:5C:23:9D:BC:7F -68 02 01 1A 02 0A 0C 0B FF 4C 00 10 06 03 1A 3B D4 B2 EB
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
4A:53:7F:64:71:EC -91 03 03 9F FE 17 16 9F FE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
69:0D:FF:7B:75:65 -73 02 01 1A 02 0A 0C 0A FF 4C 00 10 05 03 1C 27 BB 63
61:39:71:E9:1D:C9 -93 02 01 1A 02 0A 18 0A FF 4C 00 10 05 01 18 3B 24 12
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
Each line above shows the MAC address of the detected bluetooth device, followed by the signal strength RSSI, then the hex bytes of the advertisement.
Your Go program will need to read each line of the output of scanner then parse the bytes of the advertisement to look for beacon patterns to perform various functions when it sees a packet with a certain byte pattern (indicating that a mobile phone sent out that packet.)
I'm implementing a PNG encoder in VHDL for learning purposes. It works with image sizes from 1x1 to 4x4. At the image size of 5x5 there is a behaviour I can't understand:
When encoding raw data with values 0...24, the encoding works. However, when using raw data with values 255...231, it generates a broken image.
Input values 0...24:
> hexdump -C png_encoder/gen/test_img_no_compression_5x5.png
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 00 05 00 00 00 05 08 00 00 00 00 a8 04 79 |...............y|
00000020 39 00 00 00 4c 49 44 41 54 78 01 00 04 00 fb ff |9...LIDATx......|
00000030 00 00 01 02 00 04 00 fb ff 03 04 00 05 00 04 00 |................|
00000040 fb ff 06 07 08 09 00 04 00 fb ff 00 0a 0b 0c 00 |................|
00000050 04 00 fb ff 0d 0e 00 0f 00 04 00 fb ff 10 11 12 |................|
00000060 13 00 04 00 fb ff 00 14 15 16 01 02 00 fd ff 17 |................|
00000070 18 0b a4 01 2d d5 1f a2 6d 00 00 00 00 49 45 4e |....-...m....IEN|
00000080 44 ae 42 60 82 |D.B`.|
00000085
> pngcheck -vv png_encoder/gen/test_img_no_compression_5x5.png
File: png_encoder/gen/test_img_no_compression_5x5.png (133 bytes)
chunk IHDR at offset 0x0000c, length 13
5 x 5 image, 8-bit grayscale, non-interlaced
chunk IDAT at offset 0x00025, length 76
zlib: deflated, 32K window, superfast compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
0 0 0 0 0 (5 out of 5)
chunk IEND at offset 0x0007d, length 0
No errors detected in png_encoder/gen/test_img_no_compression_5x5.png (3 chunks, -432.0% compression).
Input values 255...231:
> hexdump -C png_encoder/gen/test_img_no_compression_5x5.png
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 00 05 00 00 00 05 08 00 00 00 00 a8 04 79 |...............y|
00000020 39 00 00 00 4c 49 44 41 54 78 01 00 04 00 fb ff |9...LIDATx......|
00000030 00 ff fe fd 00 04 00 fb ff fc fb 00 fa 00 04 00 |................|
00000040 fb ff f9 f8 f7 f6 00 04 00 fb ff 00 f5 f4 f3 00 |................|
00000050 04 00 fb ff f2 f1 00 f0 00 04 00 fb ff ef ee ed |................|
00000060 ec 00 04 00 fb ff 00 eb ea e9 01 02 00 fd ff e8 |................|
00000070 e7 6a 21 17 bc 9a 17 87 e7 00 00 00 00 49 45 4e |.j!..........IEN|
00000080 44 ae 42 60 82 |D.B`.|
00000085
> pngcheck -vv png_encoder/gen/test_img_no_compression_5x5.png
File: png_encoder/gen/test_img_no_compression_5x5.png (133 bytes)
chunk IHDR at offset 0x0000c, length 13
5 x 5 image, 8-bit grayscale, non-interlaced
chunk IDAT at offset 0x00025, length 76
zlib: deflated, 32K window, superfast compression
row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
zlib: inflate error = -3 (data error)
(0 out of 5)
ERRORS DETECTED in png_encoder/gen/test_img_no_compression_5x5.png
How to interpret the error message zlib: inflate error = -3 (data error)?
I read https://www.zlib.net/zlib_how.html, but didn't find more specific information. My first guess was the row filters are incorrect, but since both files are structured the same, this is unlikely. Is there something wrong with the ADLER32 calculation in the second case (possibly some overflow)?
It was an overflow in the ADLER32 checksum calculation. Specifically, there were two 16 bit numbers added and truncated before applying the modulo with 65521. Unfortunately my ADLER32 unittest didn't catch it, yet.
However, the error message was shown several times during the implementation and I was always not sure about the cause. If anybody could elaborate the error message or explain how to get a better error message, I would be glad to hear it.
I can't finish the authentication phase.
What I am using:
SAM module by NXP
Mifare Desfire PICC
I am following the next steps:
Get PICC SerialNumber (or UID) with GetVersion.
GET VERSION:
Tx: 90 60 00 00 00
Rx: 04 01 01 00 02 18 05 91 AF
GET VERSION 2:
Tx: 90 AF 00 00 00 00
Rx: 04 01 01 00 06 18 05 91 AF
GET VERSION 3:
Tx: 90 AF 00 00 00 00
Rx: 04 65 41 49 65 1B 80 8E 65 58 51 30 46 07 91 00
Get encrypted(RndB) from PICC.
Tx: 90 0A 00 00 01 00 00
Rx: 31 15 1A 19 DB ED CD 5A 91 AF
Send to SAM PICC_SN + ek(RndB).
Tx: 80 41 01 03 0F 80 1B 65 49 41 65 04 31 15 1A 19 DB ED CD 5A
Rx: 61 20
Get from SAM encrypted(RndA + RndB_rotated) + 1st half Session Key
Tx: 00 C0 00 00 20
Rx: F3 10 55 B1 D3 18 91 5B 92 48 16 1F E1 58 D5 CB E9 F3 51 04 41 8A 4E A5 A2 B5 67 CA FF D8 D2 35 90 00
Send PICC encrypted(RndA + RndB_rotated).
Tx: 90 AF 00 00 10 F3 10 55 B1 D3 18 91 5B 92 48 16 1F E1 58 D5 CB 00
Rx: 91 AE
So, this is a guide I have received from my suplier, and i don't have explanations about the apdus used; some i have found them on the internet, some others i guessed.
What I need to know is what does the next command i use:
to SAM module: 80 41 01 03 Lc Data
I need to know what encryption it deploys, why it needs PICC's UID (is this the IV), how can i know RndB, and what is expecting the PICC to end the authentication.
Thanks
Pd: Sorry for the text's format, it seems I'm unable to use correctly the tools for posting, everything gets in the same line it's disgusting...
I solved the problem and finished authentication.
The error was that i was requesting RndB encrypted with keyNo = 0, while corresponding key from SAM's key encryption should be keyNo = 2.
So:
--> 90 0A 00 00 01 02 00
<-- 91 B6 08 CE 9F B5 34 3B 91 AF
Carrying on, i finnish authentication:
--> 90 AF 00 00 10 0F DC FA B6 37 5F 30 34 D7 93 2D A1 3D D6 11 10 00
<-- E9 C2 F2 69 FE 38 78 28 91 00
But now I have the next problem. I've authenticated and I can read PICC's data but i'm afraid it's encrypted. I suppose it is encrypted with session key, so I need some apdu command to be sent to SAM, with data and session key, in order to decrypt data retrieved from PICC.
Am I right? if that is... which would be that SAM APDU?
We have a https client that connects to a webservice over ssl. This always works fine with Java 1.6.
Last week we switch the client to use Java 1.7. Unfortunately the client is no longer able to connect to the webservice. I want to know what is causing this and how to fix it?
And the client throws the following exception:
javax.net.ssl.SSLException: Received fatal alert: unexpected_message
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.
java:1312)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82
)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream
(HttpConnection.java:827)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodB
ase.java:1975)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.j
ava:993)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(Htt
pMethodDirector.java:397)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMe
thodDirector.java:170)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav
a:396)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav
a:324)
Here is the detailed log info.
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Allow unsafe renegotiation: true
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
main, setSoTimeout(30000) called
main, setSoTimeout(30000) called
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1392263294 bytes = { 158, 254, 253, 221, 176, 200, 181, 30,
189, 167, 209, 227, 105, 106, 207, 196, 50, 6, 21, 179, 125, 69, 112, 158, 49, 2
34, 113, 10 }
Session ID: {}
Cipher Suites: [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_WI
TH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128
_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WI
TH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_E
DE_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, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INF
O_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp19
2r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1
, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, s
ect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [host_name: messaging.xxxxx.com]
***
[write] MD5 and SHA1 hashes: len = 180
0000: 01 00 00 B0 03 01 53 FC 40 7E 9E FE FD DD B0 C8 ......S.#.......
0010: B5 1E BD A7 D1 E3 69 6A CF C4 32 06 15 B3 7D 45 ......ij..2....E
0020: 70 9E 31 EA 71 0A 00 00 2A C0 09 C0 13 00 2F C0 p.1.q...*...../.
0030: 04 C0 0E 00 33 00 32 C0 07 C0 11 00 05 C0 02 C0 ....3.2.........
0040: 0C C0 08 C0 12 00 0A C0 03 C0 0D 00 16 00 13 00 ................
0050: 04 00 FF 01 00 00 5D 00 0A 00 34 00 32 00 17 00 ......]...4.2...
0060: 01 00 03 00 13 00 15 00 06 00 07 00 09 00 0A 00 ................
0070: 18 00 0B 00 0C 00 19 00 0D 00 0E 00 0F 00 10 00 ................
0080: 11 00 02 00 12 00 04 00 05 00 14 00 08 00 16 00 ................
0090: 0B 00 02 01 00 00 00 00 1B 00 19 00 00 16 6D 65 ..............me
00A0: 73 73 61 67 69 6E 67 2E 63 6F 76 69 73 69 6E 74 ssaging.xxxxx
00B0: 2E 63 6F 6D .com
main, WRITE: TLSv1 Handshake, length = 180
[Raw write]: length = 185
0000: 16 03 01 00 B4 01 00 00 B0 03 01 53 FC 40 7E 9E ...........S.#..
0010: FE FD DD B0 C8 B5 1E BD A7 D1 E3 69 6A CF C4 32 ...........ij..2
0020: 06 15 B3 7D 45 70 9E 31 EA 71 0A 00 00 2A C0 09 ....Ep.1.q...*..
0030: C0 13 00 2F C0 04 C0 0E 00 33 00 32 C0 07 C0 11 .../.....3.2....
0040: 00 05 C0 02 C0 0C C0 08 C0 12 00 0A C0 03 C0 0D ................
0050: 00 16 00 13 00 04 00 FF 01 00 00 5D 00 0A 00 34 ...........]...4
0060: 00 32 00 17 00 01 00 03 00 13 00 15 00 06 00 07 .2..............
0070: 00 09 00 0A 00 18 00 0B 00 0C 00 19 00 0D 00 0E ................
0080: 00 0F 00 10 00 11 00 02 00 12 00 04 00 05 00 14 ................
0090: 00 08 00 16 00 0B 00 02 01 00 00 00 00 1B 00 19 ................
00A0: 00 00 16 6D 65 73 73 61 67 69 6E 67 2E 63 6F 76 ...messaging.xxx
00B0: 69 73 69 6E 74 2E 63 6F 6D xx.com
[Raw read]: length = 5
0000: 15 03 01 00 02 .....
[Raw read]: length = 2
0000: 02 0A ..
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, unexpected_message
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLException: Received fatal alert: unex
pected_message
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
main, called close()
main, called closeInternal(true)
Solution to this problem is:
Disable ecliptic curves with command: -Dcom.sun.net.ssl.enableECC=false
Disable server name extension: -Djsse.enableSNIExtension=false