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.
Related
I am trying to see data (using tcpdump) which my browser sends to server which is using https protocol
tcpdump -i any -w /tmp/http.log
but application data is encrypted(as it was expected).
I am wondering is there a way to see data before it will be encrypted when the server is https?
EDIT: Encryption traffic is created by common web browsers like Firefox, Chrome, IE...
If you control the server, you can set it to permit the null cipher then force your client to use the same. The null cipher is just a fancy way of saying "unencrypted". This should NEVER be deployed, as even having it as an option in the ciphers list is HIGHLY insecure.
You could also add a trusted key to the client, and have the client use a proxy. The communication with the proxy uses the trusted key you created, and can look at the data before sending it on, encrypted with the key of the destination server. This is, effectively, a "Man in the Middle attack," and can be defeated by things like certificate pinning. Some companies use this to track employee computer usage (when used in that way, it's somewhat controversial).
Strictly speaking, both of those are attacks to get around the encryption, not looking at the data before it's encrypted. To see it before it's encrypted, you would, generally, have to modify either the client or server to record what it's sending (or maybe use a debugger), as generally the encryption is done by a library directly linked to the programme.
EDIT: the developer tools in Chrome and Firefox might be what you're looking for: if you click the page on the "network" tab (in chrome, I don't have FF up, but it has almost exactly the same thing) you can see almost all the aspects of the info being sent and received.
Just use Charles Proxy (free trial) on your computer. If the certificate is pinned this will not work bit that is probably not the case for a browser..
TL;DR
I want to set up a local HTTPS proxy that can (LOCALLY) modify the content of HTML pages on my machine. Is this possible?
Motivation
I have used an HTTP Proxy called GlimmerBlocker for years. It started in 2008 as a proxy-based approach to blocking ads (as opposed to browser extensions or other OS X-specific hacks like InputManagers). But besides blocking ads, it also allows the user to inject their own CSS or JavaScript into the page. Development has seriously slowed, but it remains incredibly useful.
The only problem is that it doesn’t do HTTPS (from its FAQ):
Ads on https pages are not blocked
When Safari fetches an https page using a proxy, it doesn't really use the http protocol, but makes a tunneled tcp connection so Safari receives the encrypted bytes. The advantage is that any intermediate proxies can't modify or read the contents of the page, nor the URL. The disadvantage is, that GlimmerBlocker can't modify the content. Even if GlimmerBlocker tried to work as a middleman and decoded/encoded the content, it would have no means of telling Safari to trust it, nor to tell Safari if the websites certificate is valid, so Safari would think you have visited a dubious website.
Fortunately, most ad-providers are not going to switch to https as serving pages using https are much slower and would have a huge processing overhead on the ad-providers servers.
Back in 2008, maybe that last part was true…but not any more.
To be clear, I think the increasing use of SSL is a good thing. I just want to get back the control I had over the content after it arrives on my end.
Points of Confusion
While searching for a solution, I’ve become confused by some apparently contradictory points.
(Also, although I’m quite experienced with the languages of web pages, I’ve always had a difficult time grokking networks and protocols. On that note, sorry if I’m missing something that is way obvious!)
I found this StackOverflow question asking whether HTTPS proxies were possible. The best answer says that “TLS/SSL (The S in HTTPS) guarantees that there are no eavesdroppers between you and the server you are contacting, i.e. no proxies.” (The same answer then described a hack to pull it off, but I don’t understand the instructions. It was very theoretical, anyway.)
In OS X under Network Preferences ▶︎ Advanced… ▶︎ Proxies, there is clearly a setting for an HTTPS proxy. This seems to contradict the previous statement that TLS/SSL’s guarantee against eavesdropping implies the impossibility of proxies.
Other things of note
I can’t remember where, but I read that it is possible to set up an HTTPS proxy, but that it makes HTTPS pointless (by breaking the secure communication in the process). I don’t want this! Encryption is good. I don’t want to filter anyone else’s traffic; I just want something to customize the content after I’ve already received it.
GlimmerBlocker has a nice GUI interface, but I’m fine with non-GUI solutions, too. I may have a poor understanding of networking and protocols, but I’m perfectly comfortable on the command line, tweaking settings in text editors, and so on.
Is what I’m asking possible? Or is my question a case of “either you get security, or you can break it with hacks and get to customize your content—but not both”?
The common idea of a HTTP proxy is a server which accepts a CONNECT request which includes the target hostname and port and then just builds a tunnel to the target server. All the https is done inside the tunnel, so there is no way for the proxy to modify it (end-to-end security from browser to web server).
To modify the data you need to have a proxy which plays man-in-the-middle. In this case you have a https connection between the proxy and the web server and another https connection between the browser and the proxy. Between proxy and web server the original server certificate is used, while between browser and proxy a newly created certificate is used, which is signed by a CA specific to the proxy. Of course this CA must be imported as trusted into he browser, otherwise it would complain all the time about possible attacks.
Of course - all the verification of the original server certificate has to be done in the proxy now, and not all solutions do this the correct way. See also http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/
There are several proxy solution which might do this SSL interception, like squid, mitmproxy (python) or App::HTTP_Proxy_IMP (perl). The last two are specifically designed to let you modify the content with your own code, so these might be good places to start.
I've created WCF Service and I share it via ssl. I have little knowledge about security, but I'm curious why can I see whole communication as a plain text in httpAnalyzer, even though POSTs are sending via https?
When my client application invokes wcf service, then I can see it in sniffer - passwords etc.
Does it mean that SSL works only on the lower layer - while transporting data? So every evil application can sniff communication on client's side and an encryption only secures us against man-in-the-middle?
SSL works indeed on a "lower layer" than HTTP. According to the OSI Model, SSL works on the Session Layer, while HTTP is on the Application Layer.
Most of these clientside HTTP Analyzers work from within the browser, analyzing the HTTP traffic on the application layer, before it is processed by the SSL logic. So it is completely normal to see the plain HTTP request.
Concerning security, an evil application installed within the browser can indeed read upon the traffic. But once it is processed by the SSL layer, it becomes way harder for an evil application to read the traffic.
SSL works by firstly authenticating the server to you as a client. (Do I talk to the one I really want to talk to). As you can't know all of the servers and their certificates before hand, you use some well known root certificates, which are pre-installed on your OS. These are used to check if some server is perhaps known by an already well known service. (I don't know you, but some really important server tells me that you indeed are who you say you are).
This authentication step works independent from the encryption of the traffic. No program can decrypt an arbitrary SSL stream by "installing a root certificate". (As said these root certificates are already on your machine from the first moment you install an OS on it =)
But if a evil programs is able to let you believe that you are talking to a legitimate server, using a forged root certificate for example, instead of actually talking to malware, it is able to see what the contents of the SSL traffic is. But then again, you are talking to the evil program itself, not the server you were intended to talk to. This is however not the case with HTTP Analyzer
This is in short terms how SSL works and hopefully answers your question.
Most likely HTTP analyzer install it's own root certificate, and intercepts SSL traffic, working as man-in-the-middle.
I am faced with a WCF security scenario that isn't particularly well documented online.
I am developing a product licensing service in WCF that will be deployed along with our software (i.e. the service is running on the same PC as the client). This licensing service will be responsible for a number of things related to controlling use of our software and connecting to our remote licensing server for updates, revocations etc. Consequently it's not the kind of service I want spoofed, and I don't really want spoof clients communicating with it either.
As it's running on the same PC as the client can anyone suggest a security policy for this scenario? I'm particularly interested in authentication as most of the other security principles are straightforward. I'm reluctant to get into certificates if I can help it but as mutual authentication is a priority I'm beginning to think I may need to implement a custom 'challenge/verify' scheme between the service and client.
Any ideas? Thanks for reading.
Chris.
My suggestion is that no matter how much effort you put into that, there will be an attack vector that makes all of your effort null and void. One option is to use ILMerge to provide a single dll for your entire application, and store it encrypted on disk and create a loader that hits your service passing in the registration information. On your side, the service will validate the customer information and send back a decryption key. The loader would use the decryption key to decrypt the DLL in memory and load it dynamically.
The shortcoming of this approach is that a determined cracker could debug your application and when the DLL is decrypted, write the unencrypted stream to disk. Your only means of retribution would be to place some kind of marker on the DLL so that you can identify who was responsible for breaking your copy protection and bring legal action if it's found open on the Internet.
As long as you're deploying this software to the client, then you cannot store any kind of key inside it without risking compromise. Even if you use certificates, you cannot hide them from the client while still making them visible to your application. And if you embed the key in the assembly itself then someone will just pop it open using Reflector.
Assuming you don't care about outright cracking (i.e. patching the assembly's code to simply bypass the license checks), then there's one and only one correct way to implement this type of security and that is to mimic the way a PKI works, by using a remote server exclusively.
In a PKI, when a server needs to validate a client via a certificate, it checks that certificate against the certificate authority's CRL. If the CRL reports that the certificate is revoked then it refuses access. If the CRL cannot be contacted then the certificate is considered invalid.
If you want to implement this scenario then you need 3 logical services but not in your current configuration. What you need is a remote licensing server, a client, and an application server. The application server can, theoretically, reside on the client, but the key aspect of this app server is that it performs license checks against the remote licensing service and handles all of the important application logic. That way, "spoofing" the server becomes an almost impossible task because a casual cracker would have to reverse-engineer the entire application in the process.
This is significantly less safe than making the application server a remote server, and may not offer many advantages over simply embedding remote security checks in the client itself and scrapping the local app/licensing server completely. But if you are determined to take this 3-tier approach then the aforementioned architecture would be the way to go.
Again, this is assuming that you aren't worried about "direct" cracking. If you are, then you'll have to read up on techniques specific to that particular attack vector, and understand that none of them are foolproof; they can only slow an attacker down, never stop him completely.
I need to send data from my iPhone application to my webserver, and back. To do this securely, I'm using an encryption algorithm. It requires a key that must be known by both the server and the user so that decryption can take place. I was thinking about just using a simple static string in my app and on the server as the key, but then I remembered that compiled code can still be disassembled and viewed, but only to a certain extent.
So, how safe would I be by placing the encryption methods and "secret" string in the source code of my app? Are there any other ways to accomplish communication between an app and server securely?
Thanks.
Yes, it can be found rather easily. Run the strings program on your executable and you'll probably find it. Besides, anything in your program can be "found", since it's necessarily open for reading.
Use SSL for secure connections. It uses asymmetric encryption, which means the key to encrypt the data is not the same that will be required to decrypt it. That way, even if attackers find out your encryption key, they still can't use it to decode. All major HTTP servers and client libraries support HTTPS, and that's what it does.
What "certain extent" do you think that is exactly? Every instruction and every piece of data your application contains is open to possible viewing. Besides, using the same key for every device is the ultimate in cryptographic insanity.
Just use HTTPS. SSL/TLS is a secure, proven technology built into every major HTTP server and every major HTTP client library.
You use a symmetric algorithm. Maybe you should consider to have an unsymetric method if you need a high security. That way you could even recreate the keys at i.e. every session and only need to exchange the public key.
Here some examples:
RSA
Diffie-Hellman
ElGamal
ECDSA
XTR
iOS has Keychain Services for storing things like encryption keys securely and (relatively) easily. Check out Keychain Services Programming.
All of the crypto APIs you're likely to need are also available in the CommonCrypto library included in libSystem. In short, there is no need to take shortcuts when it comes to securing your iOS applications.
As others have said, what you're proposing is completely insecure. If anyone cares about your app, they'll publish the secret key on the Internet within 10 minutes of its release.
Things you need to research are:
Asymetric encryption algorithms
Diffie-Hellman key exchange
(Note - I'm not saying those are the solution to your problem, but learning about them will educate you in the issues involved and better prepare you to pick a solution)
On an additional note, why can't you just use an HTTPS connection?
Finally, if this encryption scheme is protecting critical data, you'd probably be well served to hire a consultant to help you, since as a newbie to the subject, you're sure to make basic mistakes.