I am using a X20CP1585 with AR M4.93. I am trying to contact a Rwebserver, which requires TLSv1.2
My configuration is as follows:
I am using httpsClient() as FUB.
The FUB responds with Error 35567 – SSL handshake failed.
When I analyze the traffic with WIreshark I see that TLSv1 is being used instead ov TLSv1.2
How can I configure the FUB to only use TLSv1.2?
Hi,
I’m not sure if a protocol version mismatch is the root cause, because the wireshark trace looks incomplete → I can’t see the TLS client and server handshake packets (the “Hello” packets, where protocol versions and cipher suites are exchanged). As I remember, those packets are unencrypted and should be sent at the beginning of every TLS communication, independent of a possibly mismatched TLS version that is determined later by the handshake.
In common, a handshake failure can also happen because of a non-matching cipher suite on client and server side, because of an certificate issue (e.g. the CN in the certificate does not match with the client name / IP / domain → depends on the server seetings around client / certificate validation), or even because of a too large time difference between server and client. For further investigation, I think that a wireshark trace including the handshake packets is needed.
Anyway, I don’t know any special setup for the httpsClient() (or TcpOpenSsl()) function block to use TLS 1.2.
The only setting that maybe influences the TLS version is using the right/wanted SSL configuration for the function block. That means you have to use the ArSslOpen() function block to determine the ident of your SSL configuration by providing the configurations name, and use that ident at the input “.sslCfgIdent” of your httpsClient() instance.
Best regards!
Thank you Alexander,
here is the complete trace:
which results in this reponse:
To test the ciphers, I have enabled all ciphers in the AS-TLSv1.2 cipher suite, same result.
When I test the same configuration with curl, I can clearly see the TLSv1.2 Hello and key exchange lines,
So to me it still looks like that the FUB does not use TLSv1.2
Hi,
thanks for the trace! I agree this looks strange.
Unfortunately I can’t test anything within the next days, but if possible I’ll check it when I’m back in the office.
But as I know the’re no more parameters, only using the suitable SSL configuration ident is important.
Hopefully some others here in the community know more?
Best regards!
Hi again Gerald @c489470 ,
only for my interest: could you please post another screenshot of the client hello packet, where the sub-section “handshake protocol” is opened?
I’m asking because I’m curious about the TLS protocol version of the client provided in this sub-section.
As I understood this explanation,
the first part is the “record header”, and the sub-section is the “handshake header”, and it could be that the record header for compatibility reasons uses a different version information as the handshake header, but the handshake header is the “real information” about the client protocol version.
To be honest, until now I’m not sure how this will help to solve the issue, but as I’m said I’m curious about 
EDIT (one day later):
I started a little test this morning with a CP3585 + AR M4.93 + AS 4.12.5, and for me it looks like it’s working as expected.
For this test, I called a httpsClient instance querying “www.google.de” via https.
As I created a new SSL configuration for this test, I also can see that most of the cipher algorithms are deactivated by default - so I used this setup (maybe the server doesn’t accept clients that offer outdated cipher algorithms?)
Additionally, I used a self-signed certificate with 2048 bits, because I can remember that some servers don’t accept certificates with keys having a lower bitcount.
I also can see, that in the record header TLS1.0 is named, but in the handshake header TLS1.2 is used like configured, and the server accepted by respoding with a “server hello” packet and a chosen cipher - so in general, the lower TLS version in the record header should not be a problem.
So, I would recommend to:
He’re some screenshots of my test setup.
Test code:
SSL configuration (please note the missing “red exclamation mark” at cipher suites like described above):
Client hello packet:
Server hello packet:
I hope those informations help a bit.
Best regards!
This is strange, here is the wireshark trace in my case:
I have done as you suggested. Created new cert + key, confirmed that the right SSL Config is used, and used the default cipher suite.
Same result…
And I confirm the the FUB works with google.de.
So it seems that there is something special with the Rest API I try to reach. The fact remains: curl does just fine…
P.S.: I have been using your sample code for the tests → thanks for providing that
PPS.: I think I have found the problem. Curl is using SNI (Server Name Indication – Wikipedia), whereas the B&R https client does not. If I disable SNI in curl the authentification fails with the same error. So I guess the question is closed for B&R, and I need to figure out how to add SNI to the https client. Thank you Alexander for your help
