6

I'm currently building a MVP (financial mobile app) and trying to understand the best ways to prevent rogue clients interacting with the server.

When looking at the security of most mobile apps I can see that it's fairly easy to do a MITM attack on these to intercept the communication over SSL.

Some apps seem to prevent these with certificate pinning but that's also very easy to overcome on a jailbroken phone.

(I see that in this thread Do client certificates provide protection against MITM? it is possible for the server to verify the client - but it appears in practice that virtually no one does this? - not sure why and is it due to possible some inflexibility in pinning a client certificate on the server?)

I can see that a couple of the most secure apps I have looked at, implement certificate pinning on the client, the server then sends an additional public(?) key (which I can see in charles proxy) so most likely a second private-public key exchange, but I can no longer track communications after that. (originally this app like many other financial apps seem to do out-of-bands security via sms).

In short: 1)What are the additional security options available to securing my app which go beyond certificate pinning on the client (and prevent rogue clients accessing the server?) (Excluding jailbreaking prevention).

2) How does the out-of bands- type security work, and how does this give additional protection?

Thanks

Community
  • 1
yunti
  • 61
  • 1
  • 1
    Is the rogue client an authorized user who's tampering with their client in a way you don't want? – cpast Feb 06 '15 at 16:21
  • Generally client side certificates are used for PKI, and not for your general web applications. They're harder to implement because for an app you would have to generate one on a per user basis. Then have the user/app submit it to be signed by your server certificate. It's a lot of back and forth, but does what you're asking. – RoraΖ Feb 06 '15 at 16:32
  • 3
    I'm still somewhat confused by the threat model. Questions: 1) Does the attacker have access to a legitimate copy of the client? 2) Does the attacker have legitimate credentials legitimately issued to him (i.e. he's not using someone else's credentials)? 3) If 2) is "no", does the attacker have a full set of stolen credentials, enough to log in on the normal client? – cpast Feb 06 '15 at 20:02
  • Thanks I'm assuming the attacker does have user login details here - and example attacker would for instance (but not restricted to e.g. be trying to make a non public api - public. ) – yunti Feb 09 '15 at 19:51
  • And has access to a mobile device with the app. – yunti Feb 09 '15 at 20:12
  • 1
    @yunti why would a attacker looking at the api be a problem ? a mobile client is just that, a mobile client, the server should have all of the required protections in place to prevent tampering. If you are deploying for mobile you should assume that anyone with the slightest interest in the code has decompiled it and read it in full already. and has the capacity to sniff data between their own devices and your server in plain text (regardless of ssl/https or not) – Damian Nikodem Feb 10 '15 at 00:38

1 Answers1

1

TLS Mutual Authentication is the only way where we can ensure the client talking to the server is a legitimate one.

You can perform the following things:

Create a self-signed certificate with certificate signing capabilities(CA=true)

For every user, which wants to connect to you, when it registers for your service for the first time, it needs to create a Certificate Signing Request (CSR) and will give it to you.

You need to sign the CSR using your self-signed certificate and give back the signed certificate. Note that, even if an MITM is listening in between, he will only have the CSR and the signed certificate in hand. To actually impersonate the client, the MITM also needs access to the private key generated while creating the CSR. This private key is never sent to you(and hence never sniffed by the MITM).

Now, whenever a client wants to talk to you, it will send a client hello and asks for your certificate. You'll provide it. Now, you will ask for the client's certificate(Mutual auth). Client will send you its certificate. Now, You will check whether the certificate presented is signed by your self-signed certificate. If so, send a nonce by encrypting it using the public key mentioned in client's certificate.

The encrypted nonce will be decrypted by the client using the private key associated with its public key. It will then encrypt a reply using the public key mentioned in the certificate it received from you(during serverHello/serverCertificate handshake of TLS). and will send you the encrypted reply.

You will decrypt the reply using the private key associated with your public key. If it is the reply you're expecting, then it means its a legitimate client. If not, its an MITM on the other end.

Note that in order to successfully hack the connection and decrypt the contents, the MITM needs the private keys of both the legitimate client and you(server). This is not posible since the private keys are never sent across to each other, and hence the MITM can never sniff it.

Hence a secure communication with legitimate client is established.

Hope this clarifies.

commanderdileep
  • 96
  • 3
  • thanks that is useful. I presume we (or a developer) can't just ship certificates for the client in the app as there would need to be a unique one for each user to login? (and the same binary is always downloaded from the app store?) Hence the need to issue a certificate to the client after the user has the app? Also the client certificate setup via CSR is this what is done via the out-of-bands method (e.g. sms)some mobile banking apps do? How does this strengthen security vs seeing up CSR via the same channel? – yunti Feb 09 '15 at 20:17
  • Is a certificate being supplied to the user and the device(possibly attached via mobile number) via the out of bands method above? – yunti Feb 09 '15 at 20:25
  • CSR creattion must be done on the user's device itself. Basically, all devices which support certificate management will have the capability of creating CSRs. Even if the device doesnt support CSR creation, the user can create it in a linux machine using openssl commands. The important thing heres is to know the pricate key associated with the CSR. Later, the CSR can be sent in an open channel. Maybe your app can initiate an ftp session with your server and send the CSR. You can then sign it and send the signed CSR in another open channel(or the same one). – commanderdileep Feb 10 '15 at 04:59
  • The thing I'm trying to say is you don't need a secure channel for exchanging CSRs and signed certificates. How its actually exchanged (via SMS or email or ftp etc) are left as design decisions of the app. – commanderdileep Feb 10 '15 at 04:59