1

I have just stepped into ssl domain and started exploring how to implement ssl. My question is i understand ssl certificates signed by CA actually allow the client or browser to validate that the webserver or webservice is actually the authentic web service what it says it is. But if in my mobile client i am actually hardcoding the webservice url then the client will always call the url unless the apk is modified. So a self signed openssl certificate should be enough right? or not...

Also do i need to put in some code in the client application to actually validate the certificate, because it seems if an attacker wants he can even modify the certificate validation code in the client application also if he has access and so can he modify the url to point to enirely different remote service.

Please guide me on what would be the best way to implement ssl for a hybrid app downloadable from app store or play stores. Or what is the best practice that i should follow. Thanks for any help!

DevD
  • 267
  • 2
  • 7

2 Answers2

3

So a self signed openssl certificate should be enough right?

Only if your mobile app only accepts that certificate and no other. That is, you'll need to update your mobile app if your website/web service's SSL certificate changes and your website/web service will be rejected by normal browsers as untrusted. So you save a small amount of money on a commercial certificate at the cost of no default browser or operating system accepting the web site.

Do i need to put in some code in the client application to actually validate the certificate?

Most HTTPS libraries will look in a variety of places for trusted CAs. So as long as you have added the self-signed certificate or the CA that signed it to the application or library's trust-store, the validation process will occur automatically.

What would be the best way to implement ssl for a hybrid app?

Answering every facet of this question would be... rather large. So I suggest these basics:

  • Buy a normal long-length SSL certificate from a normal provider. Obviously one whose Root CAs is included in the phone's default trust store.
  • If you want to lock down the trust to just your certificate, there are ways to do this but you'll need to ask the Android stack exchange. It shouldn't require more than a few lines of code with an appropriate HTTPS library/client.
  • If you want to lock down the web service to only your mobile app, generate a client certificate to be embedded inside your app. Not foolproof but it does raise the bar.
  • Don't grow your own. If a somewhat heavy open-source library exists for this purpose, use it. At least if you run up against problems you will have a decent developer community to ask questions of. I can't tell you how many times I've seen code-snippet questions on StackOverflow that would have been avoidable if the developer was using a standard one-line call to a popular library.

Oh. And regarding "modify the certificate validation code in the client application" - yeah you have no easy way to stop that as you have to deal with same piracy and reverse-engineering problems that every other software studio providing client-side applications has to deal with.

LateralFractal
  • 5,173
  • 18
  • 41
  • Thanks for your answer. My app is basically a html5/javascript wrapped as an app. I understand your other points but i dont understand when you say "your website/web service will be rejected by normal browsers as untrusted". so even if i am not using a browser to access the app but hardcoding the https link in the app code would it still result in a warning display that the url is untrusted. – DevD Oct 25 '13 at 10:11
  • If the only HTTPS service on your server is for your app, then the rejection of the SSL certificate by normal browsers will be irrelevant. But if you decide later to have the same server provide content for normal browsers / internet access, you will need at least one SSL certificate signed by a trusted Root CAs (e.g. Verisign, Go Daddy, etc). – LateralFractal Oct 25 '13 at 10:18
  • @DevD Whether a HTML5/Javascript app uses a normal browser and its certificate trust store or not depends on what container precisely runs the app. In practice, if the app doesn't have direct control of the HTTPS client library, it will be using the phone OS or browser's trust store - and thus prone to the same 'untrusted' warnings. – LateralFractal Oct 25 '13 at 10:20
  • Thanks again... so i get that but still my concern is in the background i believe the browser loads the html5 webapp so would the app still display the untrusted url warning or popup or would that be hidden from the end user. – DevD Oct 25 '13 at 10:27
  • Yes it uses webkit and the browsers trust store probably i think.. – DevD Oct 25 '13 at 10:29
  • @DevD If the browser is the container that the webapp runs within; then yes you will get a 'untrusted' warning for either the webapp and/or any AJAX call made by the webapp to self-signed webservices. I don't think that Javascript is allowed to override or edit the browser's trust store due to XSS risks that would raise. – LateralFractal Oct 25 '13 at 10:29
  • Thanks Again so i see the trusted ssl certificate providers charge from a range of $50 to $1500 how do i decide which to take..can you provide some guidance or do you have any links that show these comparison..Thanks for your help and patience. – DevD Oct 25 '13 at 10:37
  • Have a look at this question: http://security.stackexchange.com/q/31883/30521 – LateralFractal Oct 25 '13 at 10:44
  • @DevD Actually this one's better: http://security.stackexchange.com/q/13453/30521 – LateralFractal Oct 25 '13 at 10:45
  • Thanks a lot! I can see now that domain level validations are affordable and enough for me but still it pinches to just pay for ignoring the warnings. but may be the contention is that one cant get the best of all the worlds (html5 or native). Thanks again for all your answers! – DevD Oct 25 '13 at 11:08
1

The URL incarnates what server the client wants to talk to; it does not guarantee that the client really talks to that server. The attack model here is that the client has the right URL, but its connection is redirected by the attacker to an attacker-controlled server. The attacker tries to impersonate the server. This is rather easy even for a low-power attacker in WiFi contexts (the attacker just runs an "open WiFi" access point, for instance) or with DNS poisoning.

To defeat the attacker, the client must know the correct public key for the intended server. That's where certificates come into play: as a way to distribute public keys and assert the name of the server who owns each public key.

If you want to do it without a CA, then you may hardcode the server certificate itself in the client. That way, the client will "inherently" know the server's public key, and won't be fooled by the attacker. CA are in fact an indirection in this model: the client hardcodes some "trusted root CA" and accepts as true whatever these have signed.

Another option, if users have passwords and need to authenticate with a server through your app, is to use SRP: client and server mutually authenticate with regards to the shared password, and there is no certificate at all. However, client and server code which can do that may not be widely deployed yet.

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • Thanks for the answer! it definitely explains why a CA would be absolutely necessary. Just out of curiosity wanted to ask is it possible that attacker can get a domain validated certificate from a trusted authority against my url since i read that checks for domain validation are not much...can any body show that he is the owner of my domain... – DevD Oct 25 '13 at 12:15
  • Also as you said if i hardcode the self signed server certificate itself in the client wont the html5 app display warnings about untrusted signature (also since i wont be able to make it into the trust store with javascript; plus i read that ios is strict on trusted certificates so may be i will explore more...please comment if you have some idea on this..thanks! – DevD Oct 25 '13 at 12:18
  • I dont understand SRP very well there is very little material for this on the web...i am trying to tap in users from the public domain where the count may be huge...i understand SRP provides mutual authentication and sharing of a password is required between the client and the server. So would SRP eliminate the need for the user to remember another password for authentication + the need for public/private key ssl...do you have a link that will help understand this better. Thanks again! – DevD Oct 25 '13 at 12:25