Where I work there are pretty stringent enterprise security rules on using web sockets.
Basically if you have client A and server B, any instantiated communication from A->B or from B->A needs to be authenticated.
So if client A calls server B server B should be able to validate that the message it’s receiving is valid.
And vice versa should be true.
So for example, if the data window my subscription is looking at on the client changes, when server B sends client A the subscription update, client A should be able to validate that the message is coming from a reliable source (ie not sub intermediary who is spoofing the message).
I was bouncing around the DDP code but did find anywhere the client explicitly validates the message the server sends. I could have easily missed this.
If the answer is “there is no explicit validation happening but that’s is why you should always be running SSL so nobody in the middle can decipher your channel data” I get it but that is not the answer I am looking for and one that does not meet our security rules.
If validation does occur and I just couldn’t find it a link to the relevant code would be very helpful.
How do you see this validation happening ? Because I think you can hack DDP to apply maybe a sort-of signature for the message sent with a salt that is privately agreed in the beginning of the DDP connection.
I think this may be the infamous https://en.wikipedia.org/wiki/Byzantine_fault_tolerance which has no real solution. (Except the bitcoin “solution” that state the middleman does not have enough processing power 
)
We’ve successfully implemented a zero knowledge system with Meteor, where an attacker can have access to the source code, database, write-access to the server execution, and have no knowledge or any way to decrypt the information (at least until RSA gets hacked), because decryption and encryption happens on the client.
1 Like
DDP authenticates that for the duration of an uninterrupted connection, the latest valid login token belongs to the client that sent it.
It’s valid insofar as the message is a JSON-serialized dict that duck-types to a DDP message. JSON as a data model serializes only to dicts, so it doesn’t have the same issues as e.g. java.io.serialization does.
I’ll be blunt, I guess your security rules are stupid then. If you want to make clients tamperproof for the most part, use native iOS applications (or for that matter Xbox One or PS4 applications) distributed via the App Store.
So out of the box some enterprise environments might reject Meteor.
I am not sure how stupid it is but the concept where a server can initiate communication means the server is now the client. It seems reasonable to want what ever receives that information to be confident that info is coming from a legit source… just like a server does when a web client communicates to it.
@diaconutheodor your salt approach is similar to what others are doing.
https://www.apollographql.com/docs/graphql-subscriptions/authentication.html
That is almost verbatim the purpose of TLS (HTTPS).
I guess he’s looking for a signature scheme or something, and doesn’t necessarily know why in the particular protocol of DDP there are no “signatures.”