I am very new to Client/Server programming and networking in general. I am trying to connect to a server with my app using AFNetworking. It is throwing an error:
the certificate for this server is invalid....
How do I get AFNetworking framework to ignore this error and go ahead and load the data?
I am basically using the AFNetworking example on Twitter as a springboard to integrate it into my application.
Does the server in question have a self-signed SSL certificate by any chance?
If so, then you may find some useful information here:
AFNetworking issue
#45
AFNetworking issue
#189
The suggested approach is to define _AFNETWORKING_ALLOW_INVALID_SSL_CERTIFICATES_ in which cae you may have some success allowing AFNetworking to accept invalid SSL certificates. My experience has been hit or miss with this and the various other suggested ways of dealing with this - which often involve crashing on com.apple.NSURLConnectionLoader in a background thread.
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 am using an iOS app and I get the below error when testing in iOS 9.
CFNetwork SSLHandshake failed (-9806)
NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9806)
I found a number of links saying this could be due to the NSAppTransportSecurity suggesting to add exception for my domain or to disable ATS. But my server does support TLS1.2 and I get this issue only intermittently. Had this been due to the NSTransportSecurity I assume that the issue should be consistent.
Whats strange is that this is not consistent. The app works fine and is able to connect to server in most cases. But after a while I get the above error. I use NSURLCONNECTION. Most of the app interaction is like click on a button and it makes a network call to server(tomcat). Once the SSL failed error occurs, the only way to get the app to send requests successfully to server is by killing the app and starting again. I have tried changing the connection from wifi to 3g during the issue, and even restarting the server once the issue happens but I could find no luck. I am able to work fine with safari and other apps. I have been trying to find a solution for this for some time now. The server is not forward secrecy enabled.
To check the issue deeply I verified the SSL packets from the client.
When the issue occurs the client is sending a different list of ciphers compared to when the connection is working good.
When the connection is working good I could see the below list of ciphers being sent.
It was also seen that during the issue the client hello packet was shown as SSL where as when the connection is good the client hello packet is shown as TLS1.2
During issue
When there is no issue
I am using the same NSurlconnetion class to connect to server throughout the app. I am confused why and how there could be such a discrepancy and how the same server call that works once is not working later. Does the above data suggest that during the issue the client is trying to connect via tls1.0 or lower? The server supports TLS 1.1 and TLS 1.2 only. The issue is found only in iOS 9. Any help is much appreciated.
The app will probably start with TLS 1.2 and a will offer ciphers which are new with TLS 1.2 too (the ones with GCM in the name). Then I guess there is some handshake problem, maybe cause by temporary server problems, some middlebox (firewall) in between or something else. From then on the app assumes that there are problems with TLS 1.2 and will attempt to use a downgraded connection, i.e TLS 1.0. and stay this way because "it knows" that TLS 1.2 will not work.
This kind of downgrades is often seen in browsers too but usually they remember to do the downgrade only if it was at least once successful. Could there be some SSL intercepting middlebox (firewall) involved which causes the original TLS 1.2 to fail and the downgrade to succeed? I.E. does the problem happens only after the device connected once through this middlebox and then later tries to reconnect to your site?
I'm working at a server that needs to support wss://. The server needs to process the websocket header, to identify the request, and then may decide to pass the SSL context to a worker process. For now, the server uses OpenSSL for SSL comunications, but from my understanding sharing a secure socket between processes is not possible with OpenSSL (tried with SSL_SESSION in parent process and d2i_SSL_SESSION/SSL_CTX_add_session in child process) - reference: http://openssl.6102.n7.nabble.com/How-to-share-SSL-sessions-between-parent-and-child-process-when-doing-fork-exec-td11077.html.
I'm looking to other SSL libraries that may allow this, currently looking at NSS.
Is this possible with any mature open source SSL library?
After a few months of trying to find a way to achieve this with libssl, I decided to make my own TLS implementation. I found no way of implementing this functionality without understanding and modifying libssl (or libressl). I still think is possible, I just didn't find a way. I've implemented a TLS library from scratch and put it on github. Now I have the two needed functions tls_export_context and tls_import_context.
Is this possible with any mature open source SSL library?
I don't think it is possible with any SSL library which is implemented in user-space because then you would continuously need to share the state of a single SSL connection among multiple processes. Contrary to this the state of the underlying TCP connection is managed inside the kernel and there is only a single state even if the same connection is open by parent and child process.
And I don't know of any SSL library which is not implemented in user-space.
I have an existing client that is written in ActionScript that I want to completely replace.
Python and Twisted appear to be the ideal candidate. No changes to the server are allowed.
1..What are the possible stumbling blocks?
2..Is it probable that Twisted can be used to create a bit perfect network connection that would be the same as the current client?
The connection is authenticated and uses SSL.
This is too hard to answer without knowing everything about your current client. Try something, and if you have a problem, ask a separate question.
Yes. Twisted doesn't have any restrictions on what kind of network traffic it can create.
Twisted does support SSL out of the box.
I'm struggling with Netty 4.0.8 Websocket client example and SSL and I can't seem to be able to send data to the Netty SSL websocket server example. Although there have been many posts around this issue, (I went through all, I believe), and the most common suggestion is to just add an sslHandler to the beginning of the pipeline, it doesn't work. Handshake seems to be successful as it is also indicated to a relevant question here.
I remember being in the same situation with version 4.0.0, but I somehow managed to get it working. However, things (and API) changed when I upgraded to 4.0.8.
Can the Netty developers add a working Websocket SSL client example to the examples? Many people struggle with this issue and that would be useful. Maybe the solution is just too simple, but an example would clear things. Again, sorry for reposting a question that might be already there, but the relevant question has also been unanswered and my reputation is just too low to add a comment to other relevant questions :)
I seem to have found a solution to my own question. The sample code on the client uses the channel.write() method, which seems not to send the messages to the Websocket ssl server. By using the channel.writeAndFlush() instead, messages are correctly sent to the server.