Security proposal: trusted services and shared secrets / request signing

[joostfarla]

In the file sharing context, security is a serious concern. Therefore, it's a best practice to keep your attack surface as small as possible. There are various measures to take when it comes to minimizing risk as much as possible.

TLS/SSL

The TLS/SSL protocol (serving traffic over HTTPS) guarantees, when implemented correctly, an end-to-end secure connection. Support for SSL is an absolute MUST for any decent API nowadays. SSL helps encrypting any private data when transferring it over the wire. However, as we will see in the "Request signing" chapter, SSL only is not always enough.

Trust relationships

To be able to initiate resource sharing between different users on different instances, some API endpoints have to be exposed. These endpoints, especially for open-source projects, are an easy target for malicious services and should be secure and only be accessible by services you trust. Therefore, the concept of "trusted services" could be implemented. When you configure a trusted service, you are whitelisting this service to access the endpoints used for the negotiation and revocation of resource shares.

A trusted service means you trust the owner of the service and all code in the service application to behave itself at all times. You must also be confident that the trusted application will maintain the security of its shared secret.

Request signing

A common approach for managing trust relationships between services is by providing a shared secret, which is generally a long sequence of randomly generated characters, known only to the parties involved. This shared secret could be generated by the trusting service admin and should be provided to the trusted party (to be). The shared secret should be provided to the latter party once and not change over time (of course you could decide to rotate all shared secrets once in a while, but we leave this out of scope for now).

Even when using SSL, there is still the small chance of a man-in-the-middle attack. Recent OpenSSL exploits (e.g. Heartbleed) have also demonstrated that the SSL protocol could not be considered 100% secure. Especially because different sharing services of different vendors could be hosted in various different environments with different security risks/policies and management levels, it's not a wise decision to fully trust on SSL encryption. Therefore, a proper choice would be to use the shared secret for signing requests.

Signing API requests means that the shared secret itself is never sent over the wire (which you often see when using traditional API keys), which takes away the risk of the shared secret being intercepted. Instead, the token is used to sign the request on the requester's side using a cryptographic algorithm like HMAC-SHA1. With the same shared secret, the receiver of the request can verify the validity of the token and the integrity of the message to make sure that the contents of the request (including metadata) has been authored by the person who claims to be the sender and has remained untouched during the transfer.

Signing and validating the request still does not mean that messages could not be intercepted. This means you still have the small chance of leaking confidential information to malicious parties. To take away this risk, one could decide to add encryption so that message are unreadable when intercepted.

Discussion

Do we want to go this far when it comes to security? Or is the data mostly not "that" sensitive? Other thoughts or alternatives?

[labkode]

@joostfarla,

Another alternative would be to use TLS client authentication to create a strong channel between the trusted servers.

[joostfarla]

@labkode you mean apart from SSL/TLS on a connection level? That would be double TLS then ;)

My personal opinion is that encryption on a message-level is a bridge too far. Why should OCM provide more security measures (and thus complexity) than the popular public cloud providers like Google Drive, AWS S3 or Dropbox? Those parties do offer TLS (handshake/encryption), only AWS requires request signing, but none perform encryption at the message level. I guess most OCM participants do not offer this kind of security level for consuming data within their own cloud? If parties for some reason need more security, they could do this by establishing a secure VPN connection between trusted parties.

[labkode]

@joostfarla Hi, I think you misunderstood me or I have not been clear enough.

By TLS client authentication I meant TLS client certificate validation. Usually in the web we only see server-side certificate validation as the server doesn't care about the client. In the OCM model, the "client" will be other server, that need to be trusted, so one server can present to other its client certificate and the receiver server can verify that this certificate is trusted. TLS allows bi-directional authentication. This model is analog to the shared secret model, but using an existing standard for transport layer authentication.

As far as I remember, Dropbox and company rely on the fact of an App Key and App Secret to make calls to Dropbox servers from your own servers , so the trust relationship is based on this, without having to sign the request. Only Amazon uses signed requests, and if you don't have existing libraries, the process to sign the request is not simplest one, check Amazon Signing Process

I think the fact of having App Key/App Secret is a much simpler model, of course, it has its disadvantages, but DropBox and Drive have been running with it since long time ago without major security incidents :)

[joostfarla]

@labkode ah you're right! I misunderstood your comment.

I like the idea of bi-directional TLS. Would that be very complex to setup?

I will update my comment which is slightly incorrect about the public cloud providers. 👍

[michielbdejong]

Re whitelisting -> this is indeed what ScienceMesh does now, see also https://github.com/cs3org/OCM-API/pull/94#issuecomment-2328144198 Re signing requests, yes! We finally implemented this! :) (see PR #92 that Guiseppe linked yesterday)

Yes, MTLS would be quite cumbersome. Also we didn't go for shared secret + HMAC because it's harder to bootstrap between servers that interact for the first time. We're using httpsig (although that specific I-D is quite old and there are now also newer options, it's what we picked for now) for asymmetric crypto message signing in http headers.

In addition, regarding not sending the sharedSecret over the wire, we finally implemented short-lived bearer tokens for the actual WebDAV API access (see #98) once the share is established.

Closing this for now, if there are more security issues to discuss we can open more issues about it.

Do we want to go this far when it comes to security? Or is the data mostly not "that" sensitive? Other thoughts or alternatives?

No, especially now that OCM is starting to get more serious and industry-level, keep it coming, this is very useful!