Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

> 'It Just Works

Well, apart from the major cloud-breaking side-channel security issues.



sort by: page size:

> Not even such a bad standard once you get used to it.

It ticks all the boxes except for security.

I'm not sure how to get past that one without pushing a private key or a shared secret onto each managed device (maybe with SNMP SET?).


> Also, even if it's [on] TLS/SSL, you're putting a lot of trust in Rainloop not being hacked or malicious.

It seems like no matter how you install the software, you likely have to put at least that level of trust in them. Unless you run it in its own VM or other sandbox, of course.

The TLS point is totally valid, though.


> Obviously, to do stuff like this, you need to generate certificates. The reasonable way to do that in 2020 is with LetsEncrypt. We do that for our users automatically, but “it just works” makes for a pretty boring writeup, so let’s see how complicated and meandering I can make this.

This delighted me.


> It is sad that with PGP being so horribly broken, it still casts its shadow over security products.

How is ssh with a PGP key horribly broken? There's no shadow over Solo/Somu from where I'm standing.


>It has its own certificate system

And it's great. If you're running it portable on another machine you don't have to trust its certificates


> The only problem might be if TLS itself needs an even/odd function, but it probably doesn’t.

Doesn't sound like its ready for cloud scale.


> TLS does a good job at this, and I'm not assuming it's compromised. But it's complex to setup correctly

TLS has nothing to do with it. TLS is transport security, and would imply that the service provider can access your data.

I'm sorry to say this, but this is just word salad, including the "I'm not assuming it's compromised" bit.

> and entrust my most critical information with a 3rd party

The point is you don't need to do that, and can still sync over the Internet.


> And how's that been working out for them (and their users)?

It likely worked out fine for anyone who checked the SHA256 before installing it. Which, unfortunately, is likely a small minority of users.


> It's incredibly naïve to not use encryption at rest on AWS with how incredibly easy and problem free it is to deploy.

It shocks me that this isn't on-by-default in AWS like it is on GCP.


> Our platform only answers on port 22 with OpenSSH.

I do security and I title this "Most secured platform in the world."


> offering most users a free version with weak encryption just so they can pay for the premium version

As long as that wasn't a hidden fact from the users, I don't see the issue.


> I think security and ease of use are mutually exclusive.

> I can't think of a single counterexample where security did not have an effect on usability.

Sticking with the "mutually exclusive" criterion, wouldn't ssh vs. rsh serve as a counterexample? How about https vs. http?

Both replacements brought us greatly improved security, with no effect on usability in the vast majority of time I've spent with them.


> since they're internet based, they aren't vulnerable to SS7 exploits.

I think the problem with SS7 is that there's no authentication between providers. At least as far as I know.


> The "If you can break SSL, you can break MEGA." made my day.

If the the security of MEGA reduces to the security of SSL, then all this Javascript crypto amounts to just extracomplicated security theater.

Q: So why bother?

A: It might be useful in a situation like Megaupload where the adversary seizes their servers while simultaneously shutting down their service.


> 2) It has a free, optional hosted service that stores encrypted passwords with pure client-side decryption, so you can get your passwords from any web-enabled device without having to trust the host.

This is an unbelievably audacious security shell game; I can't really believe this nonsense idea has somehow managed to gain traction.

The server is ephemerally delivering the code that supposedly encrypts your content securely.

How do you not have to trust the host?


> And who knows if it's actually the software they deploy too.

The whole literal point of the protocol is so that you don't have to trust the server, assuming you trust the client and protocol.


> but we don't allow personal devices to connect to internal services, so this isn't an issue for us.

You now have a hard dependency from what snake oil you use to how you provision TLS certificates for your servers, congrats.


> Having seen it work I believe PKI can be practical at scale. And this is why I'd hoped a chat app might break some ground here.

If you believe that this webpage was delivered securely to your computer, then PKI might be practical. Of course, there are a few implementation details with that PKI.


> What I'm working on at the moment, and am sort of stuck on, on is how to make a web app doing in-browser encryption secure

You can't. End of story. Thankfully, most people don't care and will happily use it anyway.

next

Legal | privacy