当前位置: 动力学知识库 > 问答 > 编程问答 >

ssl - How to design a secure & light-weighted protocol between server and the mobile app?

问题描述:

I'm in a dilemma while designing a communication protocol between server and the iOS/Android clients.

I'll like to make the protocol:

  • secure:since we would send important messages
  • light-weighted: to have the iOS/android clients responsive for better user experience.

I've even drafted a solution with some encryption/encoding/compressing algorithms over the HTTP REST interfaces. In brief, use DH algorithm or RSA to secure the transmission of symmetric key for later encryption of the messages in the session. A bit like the iOS official example CryptoExercise

However, while I searched similar questions in Stackoverflow, I found almost all suggestions are 'using HTTPS' rather than 're-invent the wheel by yourself'.

I agreed that it's not wise to re-invent the wheel, but I'm not sure if HTTPS can work fine in the poor network conditions, which is typically faced by mobile App?

HTTPS will transmit keys every time the connection establishes. Is it really suitable for the HTTP REST API which is quick and has just small payloads?

Any other faults?

Thanks in advance for your replies.

网友答案:

...or RSA to secure the transmission of symmetric key

You should probably stick with cipher suites that provide forward secrecy. Its standard practice to use ephemeral key exchanges like DHE and ECDHE. And I believe the TLS Workging Group is deprecating RSA key transport in TLS 1.3. See TLS: Clarifications and questions: TLS1.3 - Static RSA and AEAD from the TLS WG.


light-weighted: to have the iOS/android clients responsive for better user experience

The pain point is key exchange, and you probably can't avoid it.

For bulk encryption, perhaps you should use the new ChaCha/Poly1305 cipher suites, like TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_DHE_RSA_WITH_CHACHA20_POLY1305 and TLS_RSA_WITH_CHACHA20_POLY1305. They are 4x or so faster. See Speeding up and strengthening HTTPS connections for Chrome on Android.


I've even drafted a solution with some encryption/encoding/compressing algorithms over the HTTP REST interfaces

WebCrypto is months away from standardizing something. After that, the browsers have to adopt it. So you probably won't have primitives for months to years.

For the custom DH, you will lack the BigIntegers. Even when WebCrypto publishes its first standard, it will not include BigIntegers. See WebCrypto: Question on BigInteger operations. (By the way, I have a custom DH scheme for multifactor authentication. Its why I needed those BigIntegers, too).


I've even drafted a solution with some encryption/encoding/compressing algorithms

I hope you realize compression leaks information in the higher layers. See, for example, Rizzo and Duong's CRIME Attack on HTTP and SPDY protocols.


However, while I searched similar questions in Stackoverflow, I found almost all suggestions are 'using HTTPS' rather than 're-invent the wheel by yourself'.

You should probably be on Google Scholar looking at articles on mTCP and mUDP, mobile VPN, mobile TLS, wireless TLS, etc.

Encryption is not going to be your problem. Quick recovery is going to be your problem.


I agreed that it's not wise to re-invent the wheel, but I'm not sure if HTTPS can work fine in the poor network conditions...

Well, its like Dr. Jon Bentley said: If it doesn't have to be correct, I can make it as fast as you'd like it to be. You should probably stick with SSL/TLS, harden it where deficient, and then speed it up with choice in cipher suites.


if HTTPS can work fine in the poor network conditions, which is typically faced by mobile ApP

Mobile is not that bad in practice. There's nothing you can do about dropping a connection. There's nothing you can do if your IP is not transferred when roaming. And there's nothing you can do about the device's ConnectionManager claiming the write succeeded even when you know you have no coverage.

About all you can do is ensure fast recovery.

Maybe you should look into UDP and DTLS.


Is it [HTTPS] really suitable for the HTTP REST API which is quick and has just small payloads?

See Bentley's quote.

And don't use that damn browser security model. Its a curse. (Unless, of course, Diginotar- and Trustwave-like failures are acceptable in your models).

网友答案:

I made a test to compare the HTTP and HTTPS performance in 'typical' network conditions:

  • use 3G network with an android phone
  • Test at home, then test in the way office, with walk, train, and bus
  • In each round of tests, use http and https to fetch a json string of 700 Bytes alternatively

TEST RESULT: HTTP calls: 2138 times of success, 13 failures, average fetch time: 492 miliseconds HTTPS calls: 1957 times of success, 5 failures, average fetch time: 778 miliseconds

The test result shows to fetch a small payload: 1. HTTPS is as stable as HTTP 2. The main shortage is latency, 58% slower than HTTP

I think it's acceptable, so I'm considering to turn to HTTPS.

After all, though it's not difficult to invent a wheel, but it's not easy to invent one BETTER ENOUGH, just as @jww 's comments.

I will continue to make another test to see how HTTPS performance with a larger payload.

Thank you all.

分享给朋友:
您可能感兴趣的文章:
随机阅读: