Is HTTPS protocol relevant for REST API Webservices?

Question

I have a HTTP REST API in PHP used by an iPhone application.

Some webservices from this API are secured with a user authentication in the HTTP request credentials but I want to avoid "man in the middle" attacks by providing fully encrypted requests data.

I'm not really skilled in security issues and I couldn't find any clear answer to my question anywhere :

Is HTTPS relevant for STATELESS REST API ?

From what I understood, HTTPS does 2 things :

• encrypt your session
• prove to the client that the server he is talking to is secured

So at first sight it does not respond to my need which is to encrypt the data between my server and the application because the API does not use sessions. But I still have doubts.

Can someone make it clear to me ?

My other solution would by to encrypt requests data with public/private keys system. Would it be more suitable ?

Thank you !

Solution 1

Yes, it is. HTTPS has nothing to do with the application, it's a tunneling protocol. Even though TLS is itself a stateful protocol, the HTTP part going over it is not.

Just like if you were using a VPN, you can still have a REST based application. The TLS just sets up and tears down the tunnel automatically for each connection.

That said, there's value in leveraging the pipelining aspects of HTTP and HTTPS to improve throughput over TLS connections, but that's a performance tuning aspect unrelated to the application itself.

Solution 2

HTTPS is very relevant, and yes, that's because of the two points you mentioned. Did you know that OAuth 2 actually enforces HTTPS?

Doing all the encryption yourself could be an option as well, but you lose the part where the API is easy to use.

Most man-in-the-middle attacks on "simple" HTTP requests involve stealing credentials and faking requests, but they can also read the data sent and received. If your issue is with the data being unreadable, use HTTPS. If fake requests are the only problem, an authentication protocol such as OAuth 1 (not 2) would suffice.

Comments

[PeeHaa]

Not sure what you imply by "Doing all the encryption yourself", but it sounds like a bad idea.

[Tom van der Woerdt]

@RepWhoringPeeHaa I was referring to manually encrypting the data with a public/private key system, as the question mentions.

[PeeHaa]

Aha. Evertime I hear somebody suggest trying to do encryption yourself I tend to get trigger happy. And I'm not talking about up-vote triggerhappy :)

[Tom van der Woerdt]

@RepWhoringPeeHaa I'm a big fan of SSL, but would never tell anyone to implement their own cryptography layer instead of using SSL. Also, Apple's App Store doesn't really like it if you build your own encryption system

[Bedu33]

Thanks Will Hartung, you explained exactly what was unclear to me. I had the feeling that HTTPS stateful part could be reset on each request but I wasn't sure at all.

[Bedu33]

Thanks guys for your input. I will definitely try HTTPS first.

[Bruno]

JavaScript crypto is generally a bad idea: matasano.com/articles/javascript-cryptography

[S.M.Mousavi]

REST is stateless and requests processed individually. So adding ssl handshake overhead is problem. Is there any workaround?

[Will Hartung]

@S.M.Mousavi as mentioned, leverage the tunneling aspect of HTTP(S). You can use connection pools to maintain open connections to your servers for situations like this. Just be sure to refresh them regularly.

[S.M.Mousavi]

@WillHartung REST is designed to be stateless in order to be able handle large requests. But resources of the server will be used very soon if it has to handle open connections. Instead, as a basic idea, we can use an initial negotiation to exchange a symmetric key, If there is not any official standard.

[Will Hartung]

@S.M.Mousavi as the post says, TLS has nothing to do with the stateless nature of REST, just like a VPN has no impact on REST. Open connections are cheap. You can anchor your TLS at a fronting proxy or load balancer and have it hold open a connection (thousands upon thousands of them) so as not to impact your backend servers. I most certainly would not recommend implementing your own crypto protocol as you are suggesting. The entire point of TLS is to exchange a symmetric key, and look at the difficulties they have had.

[S.M.Mousavi]

Thank's @WillHartung . REST is designed to be stateless as we know. So used base technologies must be suitable as far as possible (not breaking stateless nature of the REST at least). Thus stateful open connections seems to be a bad idea. Actually using pure HTTP or HTTPS seems to be more accurate. The problem is SSL handshake overhead (cost for security). I looking for any experienced idea.