I have a simple websocket server and I currently XOR the bytes to provide simple encryption to prevent data tampering, sniffing, no AES, no other cipher algorithms - the key can be reverse engineered anyway. When I google "how to secure websockets" I get only one answer: SSL/TLS. Using SSL requires from me to generate certificates in order to use it and protocol handles encryption for me so I don't have to call my encrypt/decrypt functions myself. I don't understand the difference between those two approaches. Certificates ensure that the server we connect to is the right one am I right - they are like identification cards. But I'm confused. Do I really need SSL for my simple server? My client is written in C++, websocket server is on Node.js. I'm planning to make a webclient for it later.
SSL/TLS is correct and well vetted. The chances of creating a solution with equivalent security is close to 0. But perhaps you have many years of full time experience developing cryptographic solutions, but then this question would not be asked.
In answer to: "Do I really need SSL for my simple server?" Yes if you need security.
See the "Schneier's Law" comment,
Related
I have a WCF service that needs to be secured to be consumed by an iphone app. I would like to know what my options are. I looked around the net and found that using SSL or api key or username/password over SSL is an option but I wasn't able to find any links about how to properly implement them for consumption by an iphone app. I'd really appreciate if someone could point me to the right direction.
Configure the WCF service for basicHttp binding and transport security. To make the client side of things work, you will need to implement an NSUrlConnection delegate. The phone will then be able to authenticate correctly. You can use the Keychain to store the user's credentials.
Stay away from the WS-* protocols that are typically turned on by wsHttp binding. These greatly increase the complexity of the XML you need to read and/or generate.
Although the phone can receive and send XML, it's not nearly as convenient as in .NET. You might want to consider a simpler serialization format such as JSON. This will require the use of webHttp binding.
I'm using an NSMutableURLRequest in an iPhone app, that uses a Content-Type:
application/x-www-form-urlencoded
The protocol is https.
From what I understand, this means the app uses encryption. But, what kind of encryption? According to Apple's export compliance page, they need to know whether I use > 64-bit symmetric or > 1024-bit asymmetric algorithms.
I honestly have no idea whether I do or not! Is there any simple answer to this question?
Assuming the NSMutableURLRequest uses the standard root certificates stored on the phone, you may not have to worry about it at all.
Also the form encoding is not part of the connection security, it's just about how fields are passed to the server in the request. It's independent of HTTPS.
There isn't any reason you should care about this, the api should handle everything for you. However to answer you question the bit depth of the encryption is based on the certificate the site uses, so it can change for each site. Also you must have an ssl certificate installed on your site to use encryption you can't just use https as the protocol and hope it will work :)
I am not an expert in SOAP, but from my knowledge SOAP is just an HTTP request formatted in XML in order to supply structured data.
I need to implement a simple API with a list of parameters.
I proposed using a simple REST interface, but I have been told that SOAP is more secure.
Any ideas on this topic?
My guess would be that you have been told SOAP is more secure because of the existence of various standards that relate to security:
http://en.wikipedia.org/wiki/WS-Trust
http://en.wikipedia.org/wiki/WS-Security
http://en.wikipedia.org/wiki/WS-SecureConversation
http://en.wikipedia.org/wiki/WS-Federation
Most REST implementations are based on HTTP which has Basic Auth, Digest Auth, SSL and OAuth as security related specs. Which is more secure is topic that is could be debated forever!
An important question is does your service need something more secure than online banks use? HTTPS seems to be sufficient for them, and they are a pretty big target.
No, it's not.
I can only guess why would anybody think the API flavor has any relevance in security, or safety (not the same thing, and it's not clear which one is referred to); it might be because the common misconception that REST means simply exposing your data objects. If that were the case, such an approach would surely be utterly unsafe! (in any meaning of the word)
I am looking for an open source framework to build a proprietary protocol onto (Agent/Client talks to a Receiver/Server that stuffs things into a SQL database).
I need session handling (ie login/logout) and some kind of encryption.
I found the Spread Framework which looks great, but does not appear to support authentication or encryption of any kind out of the box.
My preferred language is C, C++, Python, or Perl.
Anyone know of anything off hand? Hoping for something to be out there to save me time rather than doing it the hard way all in *nix sockets ;)
Thanks in advance!
Why not use libcurl, as it can do SSL.
http://curl.haxx.se/libcurl/c/example.html
DJango and DJango ORM, or SQLAlchemy combinations can be a good start. A python base framework and ORM.
Since you are working at the socket level, I assume that you are trying to write an application from the ground up. Or are you trying to run within an existing web server?
Could you use lighttpd with HTTPS & mod_cgi? This isn't really a framework, per se, but it would keep your application portable to other infrastructures.
On the server side, CGI::Session could take care of the session management. Authentication could be done using mod_auth.
Why not use SSL/TLS? On the client you can use libcurl, which works with C, C++, Python, and Perl. On the server, use Apache, lightttp etc, with cgi or your favorite language. You can use mutual authentication to ensure verify the identify of both the client and server, as well as provided an encrypted channel.
We are a .Net shop that has standardized on WCF Services. We are in the processs of developing an iPhone application that needs to make secure web services calls to obtain data for the app. To ensure secure communiations we have enabled SSL on our web servers. But this does not ensure the service can only be consumed by authorized apps. We have configured our services to support x509 certificate authentication. Is it even possible to call a secure WCF service with certifcate authentication from an IPhone app?
I have spent many hours searching the internet for examples but to no avail. I HAVE been able to successfuly call an un-secure WCF service with no issues. I have also done a lot of research on the WS-Security and WS-Trust communications standards. I believe I understand how this should work. I am just having trouble piecing together the steps/objects within the iPhone frameworks I need to make this work.
Any thoughts and ideas on the subject would be greatly appreciated.
Also, any thoughts on any of the following:
How best to deploy the P12 certifcate file with the iPhone application
How best to secure the password for the P12 file within the app
Is deploying the P12 file with the app a best practice
Are there facilties within the iPhone frameworks to support this kind of secure communication? If not, what would be an alternative recommendation.
For starters, I'd say if you are really serious about security please dedicate the proper time and resources to it and treat it like a first class citizen in your feature list. Don't just "turn on SSL" and pretend things are secure. I'm not suggesting you are doing this or not doing this, but I just feel like I have to say it before proceeding.
That said, you probably already know that WS-* is all built on top of http requests, and any time you are doing loads of http requests, you'll probably find ASIHTTPRequest very helpful on the iPhone. However, that will not get you 100% of the way there.
From the iPhone's perspective you have:
The URL loading system, which is a high level API for dealing with network resources of any kind
The CFNetwork C API which is lower-level and allows you a great deal more control of encrypting streams and network traffic any way you see fit
The Certificate, Key, and Trust Services that do the heavy lifting, and more specifically the X509 trust policies
On Macs you get to use Secure Transport, but as far as I know they haven't ported that to the device so I wouldn't get too distracted reading up on that unless you are planning on bringing this to the desktop or are just in the mood to learn everything :)
If you are doing any security with WCF, the first thing you probably realized is that there are many options available to you, but it all boils down to this short list:
Transport layer security (https) with clear text messages (xml/json/...)
Message layer security (encrypted message body) over an open transport (http)
Secured messages over a secured transport
The last time I was doing WCF (about a year ago) the general recommendation from Microsoft seemed to be Message layer security over an open transport because of firewall / accessibility issues introduced when trying to secure the transport. However, this approach assumed that all parties involved were .NET / WCF capable. I believe it would be easier to consume on the device if it were an HTTPS transport level security, with clear XML or JSON message bodies. That way you can take advantage of all the stuff baked into CFNetwork and NSHTTPRequest that Apple has done.
Once you get something working, you'll want to refer to the Enterprise Deployment Guide, and specifically the documentation on Over-the-Air Enrollment so that you can install the certificates on the devices. Remember, anything is possible, and don't be afraid to use one of those Apple support tickets that come with the program :)
EDIT:
I completely forgot to mention the GenericKeychain and CryptoExcercise examples
EDIT 2:
After I got downvoted for no apparent reason I re-read my response and realized I rambled a bit too much without actually answering your question about how to open a p12 file on the device. You ought to be able to simply [[UIApplication sharedApplication] openURL:urlToP12FileEitherLocalOrRemote]] and have it kick out to the OS for the installation procedure.
You can also use ssl + user/pass authentication at the message level.
Generally, if you want to install certificates on the iPhone, there are two options I have found (both of them from here):
Email the certificate to the recipient. If it is a valid certificate and the headers in the email are in order, then it will allow the recipient of the email to install the certificate. The problem here of course is a man-in-the-middle attack.
Use the iPhone enterpirse configuration utlity.
That should get you part of the way there (installing the certificate locally). I should note that in general, you don't want to install one certifiate for the entire application, but have separate certificates for your users. As a general practice, authenticating the application is a very bad thing, whereas you should be authenticating the user.
However, if you are authenticating the user already, then this shouldn't be an issue, as using basic authentication over HTTPS would work just as well (and easier to code).
I agree with Yaron Naveh's solution too, probably the best bet is to use SSL. I believe SSL/TLS encryption is better performance wise than message/XML based encryption in WCF too.
I think the certificate would probably need to be from a trusted CA (certificate authority) for this to work though. From memory, I had difficulty with the iPhone SDK with self-signed certificates, but that may well have changed in the last year...
An iPhone should be able to access a Certificate-secured WCF application. If you make your WCF service a RP of Azure ACS it should work using OAuth among other methods.
Take a look at the samples here for more: http://acs.codeplex.com/