How would you bring transport security to meteor? (Other than https)

I need reliable, future compatible solutions that are maintained.

The packages/solutions I have found so far are listed below, any feedback appreciated.

Thank you.

Cenk


mylar
outdated (no update >1 year)
based on not so preferred ways of doing things, possibly broken

planifica
outdated (no update >1 year)

meteor-server-encryption
does not look mature (v0.0.2)
not sure if this would handle subscriptions or not

MylarDistributedDB
outdated (no update >1 year)

Is there a problem with HTTPS/WSS?

2 Likes

These are all end-to-end-encryption solution, no transport encryption.

If you need just transport security, it’s best and easy to put an nginx in front of meteor that does the https-stuff.

1 Like

Sorry, I did not mention that https would already be used. What could be done for the data being transported over the wire? Like an automated encrypted pub/sub

let’s assume that https is vulnerable to man-in-the-middle attacks, and is already being used, what other solution could be implemented without modifying the core?

Without modifying the core? You’re SOL.

If you don’t want to be susceptible to MITM attacks, you’ll need to provide an out-of-band exchange of public keys and through those you can then negotiate the exchange of keys for a symmetric encryption scheme (asymmetric encryption is a bit too expensive for streaming data).

Basically, what https already does. So, why exactly do you want to reinvent the wheel?

Me totally agrees.

We have a client who is very sensitive about HIPAA. They implied that the data to be shared among clients required encryption. Which looks like an overkill to me. That’s why I started this investigation.

What I have so far:

at the application level:

  • enforcing strong passwords
  • periodic password change policies etc.

The problem about HIPAA is, everyone wants their app to be compliant but no one knows what level of security is enough.

Well, you could install custom, self-signed certificates out-of-band at each client to make really sure that no-one can do a MITM but why bother?

HIPAA is not about preventing the once-in-a-lifetime superspecial event no-one on Earth would have predicted, but rather about using bog-standard, industry-proven standards to make it very unlikely that unauthorized data access happens (yes, “unlikely”. Not “impossible” - you cannot achieve that, ever. The only impossible-to-breach computer system is an offline and powered-down computer, sealed in a seamless steel shell, surrounded by meters of concrete at the bottom of the Mariana Trench).

An “impossible-to-breach” system is also an unusable system.

1 Like

:grinning: great answer!

Oh, and you should rethink the “periodic password change” policy.

It actually weakens security. Security researchers did a paper on this (they used leaked user databases from numerous companies with and without this policy).

Turns out that companies with this policy had considerably weaker passwords on average.

I can see that effect with my colleagues - one of our programs has this “feature” and they all are using the scheme: “Easy, Old password + number which is regularly incremented”

2 Likes