I have been using SSL to connect a SIMCOM SIM800 GSM Module to a Microsoft Azure function endpoint. This has been working for months and has now stopped working and reports a 606 error code which indicates an "SSL alert message with a level of fatal result and the immediate termination of the connection" according to SIM800 Series_SSL_Application Note_V1.02
I tried HTTPS connections to various other sites using the SIM800 e.g. google and httpbin and got mixed results: I could connect to some e.g. google but not others e.g. httpbin. See here for a similar result.
Does anyone know if sites have recently changed SSL cipher or protocol requirements? The SIM800 module (only) supports SSL2.0, SSL3.0 and TLS1.0.
I'm using a SIM808 (V2 / R14.18) to make some GET requests to HTTPS endpoints such a https://www.google.com and a personal Azure website.
I get successful answers from google but from Azure, even if change the "Minimum TLS version" I'm always having a 606 answer.
So, I'm not sure if my SIM808 does really support TLS1.0. Maybe your SIM800 does (documentation is quite confusing).
I kept getting a 606 error while trying to 'GET' my AWS API and I could not figure this out. Reconfigured the custom domain mapping to use TLS1.0 instead of TLS1.2 and communication is now flowing through.
Related
We are using the SIM868E module for connection via GSM, with internal communication over UART.
We need the SIM868E module to communicate with an HTTPS server, (using SSL), however after sending the commands AT+HTTPSSL=?, AT+HTTPSSL=1 or AT+CIPSSL=? the SIM868E module responds:
+CME Error: unknown
(with CMEE level 2).
The specs note that SSL/TLS are supported by this module: (https://simcom.ee/modules/gsm-gprs-gnss/sim868e/).
The firmware on the chip (requested using AT+CGMR) is Revision:1418B02SIM868E32_BLE_EAT.
How can we fix this problem?
According to 2019 SIMCom products catalogue it seems that for SIM868E device there's not support for TLS feature (TLS is the standard name for the SSL protocol).
Just in case the link becomes unreachable, I attach a screenshot of the relevant page of the document:
as you can see, TLS dot is "empty".
Nevertheless, I have to say that SIMCom documents are sometimes contradictory and confusing: in fact in the SIM868E flier claims that the SSL SW feature is supported, but in the SIM800 series AT command manual there's no mention of SSL AT commands.
I will update in case I find any new piece of information about it.
I would honestly avoid trying strange things like flashing the SW of another module. It would be like searching for trouble. And in your case you would lose your positioning capabilities (GPS/GNSS).
Talking about your issue in particular, you'll probably have to compile an SSL library on your host processor (for SSL handshake and data encryption) using the TCP/HTTP commands of your device to transport data to the server. It's not a simple job.
I try to submit my RSS feed:
https://www.ahcafr.com/feed/
To feedvalidator.org and I get error:
Server returned [Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
It happens with all my Cloudflare sites. Why is that?
Trying to use feedvalidator.org against my own site and doing a packet capture shows that feedvalidator.org uses a modern TLS version (TLS 1.2) but fails to use the server_name TLS extension (SNI) to indicate which specific host it wants to access. This extension is set by all modern web browsers and many sites rely on the client using this extension, as does your site behind Cloudflare.
A failure to use this extension by a client results in the handshake failure got. To fix the problem you either need to make your site accessible without SNI (some more expensive Cloudflare plans might offer this) or just ignore this feedvalidator and try to find one which uses more up-to-date behavior regarding HTTPS.
I have a website using tls1.2,1.1 and 1.0(ssllabs) . I am using websense proxy to access it. Have enabled tls1.1 and tls1.2 on the WCG. I am still getting Peer disconnected error. The website worked once and is giving the error randomly. I have websense 8 and the URL in question is https://rem2.piiapps.com/site/login. It works fine with websense 7. I dont have a ssl bypass option due to security restrictions. Sometimes the browser indicates that the certificate is broken and sometimes it is healthy.
I did some analysis and found that this URL was using a real time communication protocol which is not supported by deafult in websense. It has to be tunneled in the incident list.
We have been battling with an issue where I've been getting a 5006 error using "SagePay Server" for 24 hours after moving a nopcommerce site to a new server with a different IP address.
We use a free cloudflare service with SSL enabled on Cloudflare in Full SSL mode and then a self signed certificate on our server so the connection is always secured end to end. This was also the same on the old server.
When moving servers we simply updated the IP address in couldflare to point at the new IP address but we started getting 5006 errors during the checkout process...
SagePay support told us they could not connect to our notification URL which was using SSL. Our server showed no attempt from their server to connect to ours yet SapePays log files show an "internal_error" with no more useful information.
However it is possible to the call the notification URL passed to SagePay from a browser and it works without issue.
After talking with SagePay on several occasions it would seem the SagePay system does not support websites / traffic using SSL with SNI which means they can not connect to the notification URL over SSL.
In a time when IPv4 addresses are fast running out I would imagine more and more people will start to use SNI for SSL so they can run multiple sites using SSL from one IPv4 address - a massive oversight on SagePay's part me thinks.
Contrary to JaxUK, I can confirm SagePay does support SSL/TLS with SNI. Hope this helps someone
We are facing a problem and I am sure this is the right place. We have a load balancer (cisco's) and for various reasons the SSL configuration on the load balancer (the server) side is set to use "SSLv3" protocol version. Now after setting the same, when I access the load balancer in CHROME browser, I am able to access the pages but I do see the below message when I click on their security icon.
"connection had to be retried using ssl 3.0" - I looked at the packet capture using wireshark and I see that browser tries TLSv1 and receives a "fatal alert" from the server saying "protocol_version" and then immediately browser tries SSLv3 version and finishes the handshake. So browser is able to negotiate this as a client.
However when I set up a stand alone java (tried using 1.6 as well as 1.7) client from eclipse and try connecting to the server I am getting the below exception.
: Received fatal alert: protocol_version javax.net.ssl.SSLException: Received fatal alert: protocol_version
As per various documentations, I saw two options I have
to set https.protocol system property to SSLv3. [this works for us, but the problem is it is affects the outbound SSL calls globally. I have another outbound SSL call to another server which does not work with SSLv3]
setEnabledprotocols() - this works as well but sometimes, we dont have access to the socket directly (sometime we generates stubs using third party and the stub takes care of the low level connection stuff, so no access to that socket).
But my actual question is, If by default TLSv1/SSLv3 and SSLv2Hello(just the format I believe) are enabled in java, why is JSSE implementation not able to negotiate like how chrome browser is able to negotiate. Is this expected? If browser is doing it, I believe it should be part of some SSL RFC and if that is the case, same functionality of this "negotiation" should be provided by java itself right?
I did go through this http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/SSLSocketImpl.java and was not able to find any part for this negotiation during handshake.
Is there a possibility of issue from the server side (load balancer) that i. I see that server sends fatal alert but that being cisco I believe the ssl implementation should be perfect and that is expected. Am I wrong?
Issue happens both in java 1.6 and 1.7. Do let me know if more information would be required to answer, will be happy to help.