Go https client issue - remote error: tls: handshake failure - ssl

I am hitting this error 'remote error: tls: handshake failure':
~/go/bin/aci-tls 10.0.0.201 user pass
2016/12/20 18:12:04 post error: Post https://10.0.0.201/api/aaaLogin.json: remote error: tls: handshake failure
Code is basic HTTPS client: https://play.golang.org/p/cqPT0oR__q
OpenSSL is happy with this https server:
$ openssl s_client -connect 10.0.0.201:443
(snip)
SSL handshake has read 1383 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
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-AES256-GCM-SHA384
(snip)
Tested on:
$ go version
go version go1.7.4 linux/386
C:\>go version
go version go1.7.4 windows/amd64
gotlsscan says:
lab#ubu:~$ go version
go version go1.8beta2 linux/386
lab#ubu:~$ ~/go/bin/gotlsscan -host 10.0.0.201 | grep -v NOT
Testing SSL30 (DISABLED)
Testing TLS1.0
Testing TLS1.1
Testing TLS1.2
lab#ubu:~$
lab#ubu:~$ ~/go/bin/gotlsscan -insecure -host 10.0.0.201 | grep -v NOT
Testing SSL30 (DISABLED)
Testing TLS1.0
Testing TLS1.1
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA [OK]
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA [OK]
Testing TLS1.2
How can I further troubleshoot this issue?

The server for some reason doesn't accept the TLS1.2 handshake, nor does it properly fall back to TLS1.1. You can force the client to use only TLS1.1 and the compatible cipher suites with
cfg := &tls.Config{
CipherSuites: []uint16{
tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
tls.TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
},
PreferServerCipherSuites: true,
InsecureSkipVerify: true,
MinVersion: tls.VersionTLS11,
MaxVersion: tls.VersionTLS11,
}

Related

How to set up TLS on verneMQ Broker on AKS

I'm baffled by this one. I followed instructions setting up mqtts port and server certs -
enable the port
create a k8s secret with my ca cert and intermediate cert file as well as .key ( I tried with both .crt/.key and pem files, neither option worked).
set up mount
set up docker environment variables as below -
- name: DOCKER_VERNEMQ_LISTENER__SSL__CAFILE
value: "/etc/ssl/vernemq/vernemq_ca.crt"
- name: DOCKER_VERNEMQ_LISTENER__SSL__CERTFILE
value: "/etc/ssl/vernemq/vernemq.crt"
- name: DOCKER_VERNEMQ_LISTENER__SSL__KEYFILE
value: "/etc/ssl/vernemq/vernemq.key"
- name: DOCKER_VERNEMQ_LISTENER__SSL__REQUIRE_CERTIFICATE
value: "on"
- name: DOCKER_VERNEMQ_LISTENER__SSL__DEFAULT
value: "0.0.0.0:8883"
- name: DOCKER_VERNEMQ_LISTENER__TCP__DEFAULT
value: "0.0.0.0:1883"
However, when I tried running test with mosquitto_pub by passing in --cafile, I'm getting "protocol error". Did anyone set up VerneMQ TLS to work?
mosquitto_pub -h <hostIP> -t test -m ‘test’ --cafile ca.crt -i testClient -d
Client testClient sending CONNECT
Error: Protocol error
I used openssl s-client connect to test the connection, I'm getting write: error(54) with some other output. How can I get around that? Thanks!
CONNECTED(00000003)
write:errno=54
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 287 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1670975815
Timeout : 7200 (sec)
Verify return code: 0 (ok)
I tried using self generated certs, it didn't work either. I also tested try setting up chained CA files, using different format...etc. To no avail

Enovy error - The following ciphers were rejected when tried individually: TLS_AES_128_GCM_SHA256

In istio 1.5.1, when I tried to add a particular cipher suit to the gateway's tls section using this syntax:
minProtocolVersion: TLSV1_3
mode: SIMPLE
cipherSuites: [TLS_AES_128_GCM_SHA256]
I got the following error in the istio-ingress pod's logs:
[Envoy (Epoch 0)] [2020-06-08 15:15:44.033][22][warning][config] [external/envoy/source/common/config/grpc_subscription_impl.cc:87]
gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) 0.0.0.0_443: Failed to initialize cipher suites TLS_AES_128_GCM_SHA256.
The following ciphers were rejected when tried individually: TLS_AES_128_GCM_SHA256
If I remove the cipherSuites line from the tls section, there is no errors, and the same cipher suit appears in the list of valid cipher suits.
Any advise? Thanks
As far as I checked in envoy documentation And BoringSSL documentation
TLS 1.3 ciphers do not participate in this mechanism and instead have a
built-in preference order. Functions to set cipher lists do not affect TLS
1.3, and functions to query the cipher list do not include TLS 1.3
ciphers.
cipher_suites
If specified, the TLS listener will only support the specified cipher list when negotiating TLS 1.0-1.2 (this setting has no effect when negotiating TLS 1.3). If not specified, the default list will be used.
In non-FIPS builds, the default cipher list is:
[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305]
[ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA
In builds using BoringSSL FIPS, the default cipher list is:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA
Additionally take a look at this github issue.

RabbitMq TLS/SSL connection error with Type not compatible with table constraint

I am setting up TLS for RabbitMQ and running in to issues handshake issues.
RabbitMq on establishing a connections shows
error on AMQP connection <0.1019.0>: {ssl_upgrade_failure,
{{{badmatch,
{error,
{asn1,
{'Type not compatible with table constraint',
{{component,'Type'},
{value,{5,<<>>}},
{unique_name_and_value,id,
{1,2,840,113549,1,1,11}}}}}}},
[{public_key,pkix_decode_cert,2},
{ssl_cipher,filter,2},
{ssl_handshake,select_session,8},
{ssl_handshake,hello,4},
{ssl_connection,hello,2},
{ssl_connection,next_state,3},
{gen_fsm,handle_msg,7},
{proc_lib,init_p_do_apply,3}]},
{gen_fsm,sync_send_all_state_event,
[<0.1020.0>,start,5000]}}} (unknown POSIX error)
Question
1) Is it an erlang issue. I run a pretty old erlang version. (Erlang R14B04 (erts-5.8.5)) ?
2) Is it an issue with TLS version?
Extra info:
ssl:versions().
[{ssl_app,"4.1.6"},
{supported,[tlsv1,sslv3]},
{available,[tlsv1,sslv3]}]
rabbitMq Config:
{ssl_listeners, [5671]},
{ssl_options, [{cacertfile,"/etc/rabbitmq/certs/dev/ca_certificate.pem"},
{certfile, "/etc/rabbitmq/certs/dev/server_certificate.pem"},
{keyfile, "/etc/rabbitmq/certs/dev/server_key.pem"},
{verify, verify_none},
{depth, 3},
{versions, ['tlsv1.1', 'tlsv1']},
{fail_if_no_peer_cert, false}]}
Also, on running
openssl s_client -connect localhost:5672 -cert client_certificate.pem -key client_key.pem -CAfile ca_certificate.pem
CONNECTED(00000003)
139969158874952:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 247 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE`enter code here`
Expansion: NONE
---
All help appreciated!
Upgrading to latest version of Erlang fixed the TLS issues.

Why can I connect TLSv1 if OpenSSL only support SSLv2 and SSLv3?

I am using openssl-0.9.8e-7.el5.
openssl ciphers -v shows support only for SSLv2 and SSLv3 cipher types.
However, if I test this connection using tls 1.0 it connects successfully:
openssl s_client -connect hostname:15000 -tls1
CONNECTED(00000003)
SSL handshake has read 2136 bytes and written 413 bytes
...
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
How does it show Protocol is TLSv1 yet OpenSSL itself only supports SSL 3 and 2?
SSLv3 cipher suites are usable with protocol versions SSLv3 and up, i.e also TLS1.x. The version of the cipher suite only tells you the minimal protocol version.
This also means that if you disable SSLv3 and SSLv2 ciphers suites you effectively disable not only SSLv3 but also TLS 1.0 and TLS 1.1, since new cipher suites were only introduced with TLS 1.2.

Problems getting a site's https certificates

I have an Android app that has some trouble with a site's certificate when connecting via https. As I'm experiencing trouble even when using a custom keystore with the certificates ("No peer certificate") I'm trying to get more information about the connection, handshake and certificates actually given by the server.
The version of openssl is follows:
$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
When I just try to get info about the certificates I get this response:
$ openssl s_client -showcerts -connect [hostname]:443 </dev/null
CONNECTED(00000003)
3069977808:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:749:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
This is how Chrome describes the connection (sorry for the Norwegian text, but you get an idea of the connection and encryption type:
Based on the info from Chrome I've tried different commands to get the certificates, but they all seem to fail. My top candidate was this one:
$ openssl s_client -showcerts -connect [hostname]:443 -tls1_2 -cipher RC4-MD5
CONNECTED(00000003)
3069396176:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1258:SSL alert number 40
3069396176:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
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: 1414399499
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
Anyone got any hints based on the info given?
This might be an SNI issue, where the server has no default certificate defined for non-SNI clients. Android included a version of Apaches httpclient which is known to not support SNI and your openssl s_client command also does not use SNI.
Please try openssl s_client -servername hostname -connect ... to use SNI and see if this helps.