BGS5 TLS 1.2 availability | Telit Cinterion IoT Developer Community
November 13, 2017 - 1:52pm, 3967 views
Hi,
For the BGS5, I'm trying to establish a secured connection to my application server, using my java application:
SecureConnection theConnection = (SecureConnection) Connector.open("ssl://serverurl")
When I try to do this, my application hangs, and the server generates an exception during the SSL-handshaking:
System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
I have tried various protocols (SSL3, TLS1.X). My server is using a PKCS #12 file.
What type of algorithms does the BGS5 support?
This is the output of my ATI1:
Cinterion
BGS5
REVISION 01.100
A-REVISION 00.000.21OK
Hello,
You will find the supported algorithms in the Java User's Guide document. If you don't have it please see here: https://iot-developer.thalesgroup.com/documentation/download-documentati...
Have you tested your server with some other client or the application with some othere server?
Maybe it would be possible to make a pcap trace on the server side to see the communication?
Regards,
Bartłomiej
I have created the following c# client application that connects without any problems:
TcpClient t = new TcpClient("[Server URL]", [Server Port]); using (SslStream theSslStream = new SslStream(t.GetStream())) { X509CertificateCollection unused = new X509CertificateCollection(); theSslStream.AuthenticateAsClient("[URL for Certificate]", unused, System.Security.Authentication.SslProtocols.Tls12, false); System.Console.Out.WriteLine(theSslStream.IsAuthenticated); theSslStream.Write(new byte[] { 0x7F, 0x2, 0x4 }); theSslStream.Flush(); }I will try to see in wireshark what the difference is between what the c# client does, and what the BGS5 java module does.
I believe that the trace will show us where the problem is and what can be changed to avoid it.
I did run the trace on the server, both for the test-ssl-client c# application that I wrote, and for the J2ME java application that runs on the BGS5. It seems to be a c# server problem.
The J2ME client correctly seems to send a SSL client handshake, and lists a large number (42, in fact) of possible TLS1.2 cyphers to use:
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02e)
etc.
Meanwhile, the c# server does not send a ***** response back to the java client, in stead exceptioning out of the connection with the error mentioned above ("The client and server cannot communicate, because they do not possess a common algorithm").
The c# client sends 21 suites in it's SSL ***** (a bunch of which have overlap with the suites also specified by the java client). The c# server DOES return a the server *****-response for the SSL handshake to the c# client.
I'll try to find out if I can list the ciphers that the server supports, and maybe improve on the server configuration, if that is possible.
Thanks for the help.
Oh well...
Took a while to find out that the server actually did support the TLS 1.2 ciphers that the J2ME client required (at least one, which is enough). However, the BGS5 client was power cycled, and did not yet retrieve the time from NTP. So it sent a timestamp from June 2011 to the SSL server, which was not amused and just ignored the ***** client handshake.
So the problem is solved.
Great!
I thought so, but there seems to be a problem with the BGS5 and TLS 1.2.
TLS 1.1 does work. I thought the problem was due to the timestamp in the Client SSL handshake, but this was not the case, that was a red-herring (or at least not the most important part of it). If I run the server with SslProtocols.Tls12, the client handshake will not be accepted. If I run the server with SslProtocols.Tls11, the client handshake will be met with the SERVER *****, and everything will be ok.
Could it be that the TLS1.2 client handshake from the BGS5 is ill-formatted? Note that I'm able to connect with c#-clients. I am also able to connect from a browser to my server, so I'm pretty sure the problem is not with the server code.
Hello,
If the module sends a list of possible cypher suites whre there are the suites that the server requires I think that the problem may not be in the cypher suites.
You'd have to compared the Client Hello messages sent by the module and your PC client - and there would probably be some differences, possibly in the extensions. Maybe the server have some requirements that the module does not fulfill - it's just a hypothesis. In such case maybe it would be possible to configure the server in a way that it would accept the communication. Or if it's not the production server maybe it would be worth testing with the production server.
It is also possible that some future firmware release will wotk fine with this particular server configuration as the TLS functionality is also being updated across releases.
Regards,
Bartłomiej
Hi. As it's been a few years since this post, does BGS5 module support TLS 1.2? Thanks.
Hello,
BGS5 does support TLS 1.2.
BR,
Bartłomiej