I am implementing a minimal SUPL 2.0 client. I have added SUPL ASN1 specification and LPP ASN1 specification with my application and compiled it. I am trying to implement a SET initiated Immediate services scenario.
I have filled all the fields to SUPL START message with LPP protocol information and LTE cell id (location id) information. I am sending this message to supl.google.com, but I am not able to receive any response from the google supl server.
Does google supl server support LPP?
I have tried with supl.nokia.com also. Similarly I am not getting any response with nokia supl server also.
The same application code is working fine for RRLP protocol.
Please let me know if anybody has come across the similar issue or have some information regarding LPP protocol usage with google SUPL 2.0 server.
Yes, supl.google.com supports SUPL 2.0 and LPP. What port number are you using for the SUPL connection? I think 7275 is encrypted, 7276 is not. You could implement OpenSSL or other encryption, but I would just use 7276.
Are you setting the LPP capability bit? Are you sure you got all your asn.1 packing and aligning done correctly? RRLP working is a good indicator that you know what you are doing, but I think the usual case for no response is a badly formed message.
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 want to implement webrtc server in my project. I want to make my own webrtc server and deploy it in amazon server. How can I achieve this?
WebRTC is a peer-to-peer protocol so you don't need a server for this.
You will need a signaling server for session negotiation. How you'll implement this depends on the technology that you'll use - client side: polling, ajax, websockets, stomp etc and server side.
For STUN/TURN you can deploy an existing server or use RFC and develop your own from scratch.
#Adrian Ber is correct, you need a signalling server such as this one:
https://github.com/peers/peerjs-server
You can set one of these up on AWS
You'll also need some code on the client side. There is a matching javascript client library (which does most of the work) here: http://peerjs.com/
There are some examples on the peerjs web site - they either need to be run on your local machine or on https servers (browsers will no longer allow camera access over http)
Ignore the people saying that WebRTC is peer to peer only. There is no reason why you can't implement an application, run it on a server, and treat it as a 'peer' for the sake of webRTC when it is actually a server.
That said, we've looked into pulling the WebRTC implementation out of Chrome, but it is a huge task. Depending on what you want to do, you will likely only need to support a subset of WebRTC functionality (Data channel / unreliable for example if you're doing a multiplayer web game).
There might be a few implementations out there that have cropped up now, but last I checked there wasn't anything of note.
I would like to display a message to customers who's browser's highest level of encryption is SSLv3. Is it possible for me to target browser settings of SSLv3 and lower? Client or Server code? We will be allowing lower versions of SSL to use our site during a certain grace period. During this grace period, we would like to display a message only to those users that have browser settings of SSL3 or lower.
Not easily. The browser's supported SSL versions are not detectable until the SSL handshake is in progress, and even then only if the browser uses an SSLv2 handshake to allow dynamic version negotiation. If an unsupported version were detected, you would not be able to send a message back since the handshake failed and the connection would be closed before you could send any message. However, SSL itself has an error packet that gets sent during handshaking, and it can specify a version mismatch error.
The best you can do in your own code is support all SSL versions on the server side, let the client complete a handshake normally, and then detect which version was actually used and send back a message if the SSL version is too low.
Or, you could simply enable TLSv1 or higher only, and simply refuse to let older clients connect at all. They just would not get a nice error message unless the browser decided to detect the SSL version mismatch error and display its own pretty message about it.
Firstly, nowadays, you can generally forget about clients that don't support at least SSLv3. SSLv3 has been widely available for many years.
The TLS Client Hello message, sent when the connection is initiated by the browser, should contain the highest TLS version it supports:
client_version
The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client. For this
version of the specification, the version will be 3.3 (see
Appendix E for details about backward compatibility).
Appendix E is of course worth looking at.
(The Client Hello message will also contain the list of cipher suites the client supports, which is possibly relevant for the general idea of your question.)
Of course, this specification is just a "SHOULD", so a client supporting TLS 1.2 could still send a Client Hello for TLS 1.1, but what would be the point? By doing so it would have no chance ever to use TLS 1.2 anyway. It could be a preference box that is turned off, but that would effectively make it a client that doesn't support the highest version anyway. (If you want anything more subtle, you'd need to build a database of known user agents, which will be partly unreliable, and for which you'd need to analyse the full user agent string to know everything possible about the platform.)
Now, how to convey the content of the Client Hello message to your application is another matter, and depends very much on which SSL/TLS stack you use. It might not even be directly possible without modifying that SSL/TLS library or the server you're using.
This being said, you can generally get the negotiated TLS version during the current session quite easily. Since that version is the "lower of that suggested by the client in the client hello and the highest supported by the server" (i.e. "min(max(client), max(server))"). If your server supports SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2, and since the latest version is TLS 1.2 anyway, what you'll get during your current connection will also be the max currently supported by the client. As long as your server supports the latest version, you should be able to know what the client supports at best from any live connection.
If you're behind Apache HTTP server's mod_ssl, you should be able to get that from the SSL_PROTOCOL environment variable. You should also be able to get the protocol from the SSLSession in Java.
(If you are willing to write a more bespoke service, you could pass further details like the cipher suites more directly to your application, like this service from Qualys SSL Labs does, although I'm not sure if it's meant to be widely available or just a test service.)
I'd have to agree with Remy about it being a bit challenging.
However, a good starting point may be to retrieve some SSL (certificate) information.
Something similar to this:
X509Certificate certChain[] =
(X509Certificate[]) req.getAttribute("javax.net.ssl.peer_certificates");
Another way of getting more information is to retrieve the cipher_suite attribute (similar to the code snippet above).
javax.net.ssl.cipher_suite
I hope this (at least) gets you closer.
Good luck.
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.
I'm working on an iOS app, where it needs to connect to a web service that located on a web server. And it needs to give an arguments to some .php files that will receive these arguments via the POST method. The problem is that I don't want anyone to look/know these arguments, and what I've tried is that WireShark can discloses/sniffs the values of these arguments.
So, what is the suitable approach to secure the connection?, I thought about encrypting the data befor sending them to the server (using simle secrete/single key, since my data are not highly sensitive) and the same for fetching data from the server, if I'd go with this approach, then I'll need to implement my own classes, but I'm running out of time.
Thanks in advance :)
Https is an option here, but won't hide data from a determined attacker. An attacker can MITM himself to reverse engineer whatever protocol it is that you are using to communicate from iphone to server, and even modify requests in real time!
Here's a good example of how a researcher was able to reverse engineer's Apple's Game Center protocol and artificially set his own high score in an iOS app:
http://corte.si/posts/code/mitmproxy/tute-gamecenter/index.html
If you are concerned about this type of attack, then you should encrypt your payload using a pre-shared key and a symmetric cipher like AES-256 or blowfish.
Use https instead. Your data are not highly sensitive, so this should be enough. You may not even have to change your iPhone code (other than the URL change), although this depends on your server's certificate.