Subrosa – An encrypted communication platform(subrosa.io)
subrosa.io
Subrosa – An encrypted communication platform
https://subrosa.io/
9 comments
That is such a good article and I cannot believe that I am just reading it for the first time now. Thank you so much for posting the article and your explanation of the two mutually exclusive statements. Crypto is just about the coolest thing I have ever heard of and I love learning about different types of attacks!
This is not a "good" article. It's very hand wavey with lots of fud.
For example, he talks about the chicken and egg problem of delivering javascript over an insecure connection and then solves it later with SSL/TLS (but he doesn't acknowledge that this is a valid solution). Furthermore, we're all harping on javascript when you can't download PuTTY over an SSL connection.
He talks about browser cache but says that javascript can't control it. That doesn't mean it can't be controlled (see MANIFEST file).
I could go on, but the point is made, there are answers to the problems raised in the article. They may not be _easy_ (as the article complains some things are complex), but it's security on wildly complex systems...of course it's hard.
For example, he talks about the chicken and egg problem of delivering javascript over an insecure connection and then solves it later with SSL/TLS (but he doesn't acknowledge that this is a valid solution). Furthermore, we're all harping on javascript when you can't download PuTTY over an SSL connection.
He talks about browser cache but says that javascript can't control it. That doesn't mean it can't be controlled (see MANIFEST file).
I could go on, but the point is made, there are answers to the problems raised in the article. They may not be _easy_ (as the article complains some things are complex), but it's security on wildly complex systems...of course it's hard.
I think that I disagree, but I am not experienced enough to know what I don't know. Judging from your response, you know way more than me, so if it's okay with you, I will tell you why I disagree. Then, it would make my day (and help me a tremendous amount) if you would tell me why I am wrong.
a) The chicken and egg problem of delivering javascript:
I am far from being good at this stuff, but I am confident that, given the opportunity if you deliver .js (or anything else) over an insecure connection, I can modify the content before it ever reaches the user.
As you and the article state, you could solve this problem by delivering the .js file with SSL/TLS. But, if you do this, I presume that you would need to encrypt every single resource on the page. And, if you have already gone that far, what would you gain by implementing browser based crypto when you have already solved the problem?
It strikes me that SSL/TLS are old enough to be well tested and researched, whereas if I wake up some morning and decide to implement my own crypto, I'm going to f* something up. I'd rather let smarter people do the heavy lifting.
But, I don't know what I don't know. What don't I know?
Furthermore, we're all harping on javascript when you can't download PuTTY over an SSL connection.
Please correct me if I am wrong, but if you can download PuTTY via an insecure connection, an attacker can just as trivially swap out the real version of PuTTY with a compromised version. That sounds really dangerous, but isn't that why the PuTTY developers add RSA/DSA signatures to their downloads page?
I would argue that if someone is smart enough to find a collision in both RSA and DSA, they can likely find easier ways to attack me than to swap out the real version of PuTTY with a compromised version.
What am I missing? disregard this question because I missed something very important - see my edit below
He talks about browser cache but says that javascript can't control it. That doesn't mean it can't be controlled (see MANIFEST file).
Thank you for this - I need to do some more reading. Though, wouldn't you get into the same problem where, unless you can control every single resource on the page (ie - serve it encrypted and make sure there are no XSS vulnerabilities) you can't guarantee that the browser is using the correct code? Then, doesn't that get back to the chicken and egg problem where if you're already implementing encryption, you don't need crypto in the browser?
--
Some of the ideas on that page (ie - the inability to generate strong random numbers) are kind of outdated. I believe that Opera uses a cryptographically secure Math.Random(). And, I think that there is an API to accomplish this in other browsers. window.crypto.GetRandom or something?
However, I still see all kinds of traffic with old versions of Internet Explorer (sorry to pick on IE). Wouldn't solving the crypto in a browser problem reliably require making everyone update to a modern browser?
I hope that I'm not coming across as being difficult, but I would love to learn and would appreciate any help you would provide.
Edited -- jimktrains2 wrote:
But those sigs are also coming over a non-ssl connection:-p
There goes my entire RSA/DSA argument! What a great thread...
a) The chicken and egg problem of delivering javascript:
I am far from being good at this stuff, but I am confident that, given the opportunity if you deliver .js (or anything else) over an insecure connection, I can modify the content before it ever reaches the user.
As you and the article state, you could solve this problem by delivering the .js file with SSL/TLS. But, if you do this, I presume that you would need to encrypt every single resource on the page. And, if you have already gone that far, what would you gain by implementing browser based crypto when you have already solved the problem?
It strikes me that SSL/TLS are old enough to be well tested and researched, whereas if I wake up some morning and decide to implement my own crypto, I'm going to f* something up. I'd rather let smarter people do the heavy lifting.
But, I don't know what I don't know. What don't I know?
Furthermore, we're all harping on javascript when you can't download PuTTY over an SSL connection.
Please correct me if I am wrong, but if you can download PuTTY via an insecure connection, an attacker can just as trivially swap out the real version of PuTTY with a compromised version. That sounds really dangerous, but isn't that why the PuTTY developers add RSA/DSA signatures to their downloads page?
I would argue that if someone is smart enough to find a collision in both RSA and DSA, they can likely find easier ways to attack me than to swap out the real version of PuTTY with a compromised version.
What am I missing? disregard this question because I missed something very important - see my edit below
He talks about browser cache but says that javascript can't control it. That doesn't mean it can't be controlled (see MANIFEST file).
Thank you for this - I need to do some more reading. Though, wouldn't you get into the same problem where, unless you can control every single resource on the page (ie - serve it encrypted and make sure there are no XSS vulnerabilities) you can't guarantee that the browser is using the correct code? Then, doesn't that get back to the chicken and egg problem where if you're already implementing encryption, you don't need crypto in the browser?
--
Some of the ideas on that page (ie - the inability to generate strong random numbers) are kind of outdated. I believe that Opera uses a cryptographically secure Math.Random(). And, I think that there is an API to accomplish this in other browsers. window.crypto.GetRandom or something?
However, I still see all kinds of traffic with old versions of Internet Explorer (sorry to pick on IE). Wouldn't solving the crypto in a browser problem reliably require making everyone update to a modern browser?
I hope that I'm not coming across as being difficult, but I would love to learn and would appreciate any help you would provide.
Edited -- jimktrains2 wrote:
But those sigs are also coming over a non-ssl connection:-p
There goes my entire RSA/DSA argument! What a great thread...
> if you have already gone that far, what would you gain by implementing browser based crypto when you have already solved the problem?
This is indeed the point made by Matasano, but I don't think it's valid. Sometimes you want to segment the trust, or maybe your software provider doesn't even want to be in the data storage game. So I might trust one entity to provide me with software to manage my inbox, particularly if I can inspect that software at will, and have seen it pass through a security review, however I might not want to trust them with actually storing the contents of my inbox. In that case, it's nice to be able to encrypt the inbox (and the index, to allow for nice searching) in my browser, and then actually store them on a commodity storage provider (s3 or dropbox). And yes, I'd use modern web standards to give the user control over when a new version was downloaded too.
So, I need to get the software over SSL, and be able to verify within reason that it does what it is supposed to, and then use that trusted software to work with data which I can store on untrusted services.
This is indeed the point made by Matasano, but I don't think it's valid. Sometimes you want to segment the trust, or maybe your software provider doesn't even want to be in the data storage game. So I might trust one entity to provide me with software to manage my inbox, particularly if I can inspect that software at will, and have seen it pass through a security review, however I might not want to trust them with actually storing the contents of my inbox. In that case, it's nice to be able to encrypt the inbox (and the index, to allow for nice searching) in my browser, and then actually store them on a commodity storage provider (s3 or dropbox). And yes, I'd use modern web standards to give the user control over when a new version was downloaded too.
So, I need to get the software over SSL, and be able to verify within reason that it does what it is supposed to, and then use that trusted software to work with data which I can store on untrusted services.
Not to mention that it will protect the data at rest in the DB, where storing crypto keys on the server is as bad as plain text because they can just be harvested from wherever you store them... Obviously. Now, if your server is compromised then the attacker can deliver JS to the client, but the client needs to load the page and decrypt their data for this to apply; the attacker can't just wholesale steal all your data.
>we're all harping on javascript when you can't download PuTTY over an SSL connection
This shouldn't matter, and would just provide a false sense of security. You ought to be verifying the signature of any program you're installing before you use it. Since you're running Windows the point is probably moot, but it is possible to install software reasonably securely.
This shouldn't matter, and would just provide a false sense of security. You ought to be verifying the signature of any program you're installing before you use it. Since you're running Windows the point is probably moot, but it is possible to install software reasonably securely.
But those sigs are also coming over a non-ssl connection:-p
Honestly, whenever you download anything, evne over SSL, you're essentially trusting that the remote computer is not only who you think the computer is, but the person you expect to be controlling it is the only person controlling it.
Out-of-band communication built out-of in-person trust are really the only way around that (i.e. trusting someone who trusts the PuTTY devs and gets you the hash/sig).
Honestly, whenever you download anything, evne over SSL, you're essentially trusting that the remote computer is not only who you think the computer is, but the person you expect to be controlling it is the only person controlling it.
Out-of-band communication built out-of in-person trust are really the only way around that (i.e. trusting someone who trusts the PuTTY devs and gets you the hash/sig).
You only need to trust their signature to really be sure. That's why the Web of Trust aspect of PGP/GPG is so important. It's probably more valuable than the ability to encrypt a few emails.
It doesn't seem that PuTTY has made very effective use of this or managed to explain the problem to most of their users.
http://noncombatant.org/2014/03/03/downloading-software-safe... http://noncombatant.org/2014/03/05/followup-to-downloading-s...
http://noncombatant.org/2014/03/03/downloading-software-safe... http://noncombatant.org/2014/03/05/followup-to-downloading-s...
I don't much like this article either, despite being its author, but I don't see how you've managed to refute its applicability to the application being discussed on the thread. The mutual exclusion referenced up thread is real.
Because this article is highly cited, and because you strike me as a personality who would appreciate micro-detail feedback: there is a typo ("algoritms") in the first sentence that immediately threw off my attention from an otherwise quite interesting piece of writing.
This is offered with respect and not a desire to nitpick. I hope it doesn't come across as annoying :)
This is offered with respect and not a desire to nitpick. I hope it doesn't come across as annoying :)
Everything this article says is true. That being said, it also applies to any regular application that can be upgraded automatically or that's upgraded at all by a third party. Anything you get off an app store can have its code switched out from under it with minimal and routine or in some cases even no user interaction. All someone has to do is compromise the signing key, which is probably not that hard in many cases.
Sure; but there's a world of difference between communicating with a webapp that claims to protect your privacy even from the NSA (but actually cannot) vs. "any regular application", which makes no such security claims, and from whom savvy users won't expect that kind of protection.
People with important information to communicate that they must protect from the powers that be (quite possibly to protect their own lives) will seek out secure methods; at the same time, the powers they're avoiding will be targeting secure communication methods.
People with important information to communicate that they must protect from the powers that be (quite possibly to protect their own lives) will seek out secure methods; at the same time, the powers they're avoiding will be targeting secure communication methods.
This application doesn't protect communications from the owners of the application under any circumstances. Forget about the NSA.
Scarily true. The amount of damage malicious actors with keys can do is greatly magnified by the auto-update mechanisms that developers love.
I have an app with auto-update, and one day I realized that I had (more or less) root on hundreds of users' machines. I'm not special in this regard.
I take fairly strong precautions with my keys: offline storage, encrypted, signing on an air-gapped machine. I'd bet you money that most people aren't so careful. There are probably a lot of secret signing keys sitting in DropBox.
I take fairly strong precautions with my keys: offline storage, encrypted, signing on an air-gapped machine. I'd bet you money that most people aren't so careful. There are probably a lot of secret signing keys sitting in DropBox.
Can you explain how these two statements are mutually exclusive?
These statements are mutually exclusive: End to end encrypted: Nobody, not even us, can read or listen into your conversations. Works everywhere: Visit subrosa.io from any computer. No download or install needed.
These statements are mutually exclusive: End to end encrypted: Nobody, not even us, can read or listen into your conversations. Works everywhere: Visit subrosa.io from any computer. No download or install needed.
subrosa can choose at any time to send you javascript which will send your password back to them. You have no way of checking for this (well, except reading all the javascript, every time you log in)
Ah yes, that makes sense, thanks!
Except it's a GPL'd web application, so you're free to run your own server.
Sure, but if you run your own server, then the site's claim that there was "no download or install needed" doesn't apply to you.
If you don't run your own server, the site's claim that "nobody, not even us, can read or listen into your conversations" doesn't apply to you.
There's nobody to whom both claims apply at the same time!
If you don't run your own server, the site's claim that "nobody, not even us, can read or listen into your conversations" doesn't apply to you.
There's nobody to whom both claims apply at the same time!
If you run your own server, you can make trusted calls from machines that don't have any client software set up, as can others using your server. Seems straightforward enough. It's clear the "no install" claims are about the client.
I read the claims on their home page as referring to the use case where someone starts using it immediately. (The benefit that they mention on the home page from open source is third-party auditability; the home page doesn't even mention the ability to create your own instance!)
The developers might well be thinking along the lines that you describe, but I don't think that a visitor to the site is likely to understand the threats that way.
Edit: Looking at https://subrosa.io/security I think it's even more clear that they're making these claims for their own hosted instance of their software -- and that's what people here are most skeptical of.
The developers might well be thinking along the lines that you describe, but I don't think that a visitor to the site is likely to understand the threats that way.
Edit: Looking at https://subrosa.io/security I think it's even more clear that they're making these claims for their own hosted instance of their software -- and that's what people here are most skeptical of.
You can use github or you can run a private gitorious install (assume here function parity.) Most people will choose github because that's where the people are.
Subrosa's value proposition is more as a meeting place then as a "secure" chat software.
Subrosa's value proposition is more as a meeting place then as a "secure" chat software.
Unless they're using a browser extension, there's no way a user can trust this application. It's a web app. At any moment the developer or a malicious third party with unauthorized server access can remotely modify the JavaScript files to dump all data in plaintext to the NSA.
"Nobody, not even us, can read or listen into your conversations."
This cannot possibly be true, given they are the root of trust for establishing the recipient's authentic public key.
Also, minified javascript really does not count as a source code release.
This cannot possibly be true, given they are the root of trust for establishing the recipient's authentic public key.
Also, minified javascript really does not count as a source code release.
Quite right. If they were compelled -- e.g., "insert this backdoor or we'll imprison you" -- they might trivially serve up a tweaked version of their JavaScript to the one user the NSA was interested in.
And it wouldn't take a complicated tweak at all to sneak the real password (or some sufficient version of it) back to the server, after which point certainly "even us" can read & listen in to all of that user's conversations.
And it wouldn't take a complicated tweak at all to sneak the real password (or some sufficient version of it) back to the server, after which point certainly "even us" can read & listen in to all of that user's conversations.
(Comment moved to today's topic.)
A quick check with wireshark reveals the use of a VBR codec for audio, so there's another probable side channel besides the Javascript related issues already discussed.
I don't know much about WebRTC, but I think it's something you can set and Subrosa should be doing so in app-webrtc.js.
I don't know much about WebRTC, but I think it's something you can set and Subrosa should be doing so in app-webrtc.js.
The login protocol require sending a hash of the key used to decrypt the rsa key bundle stored server-side. I hope they implemented a constant time compare for that hash so that verification can't be used to work out key...
Why have both "username" and "display name"?
At first I thought it was an extra layer of security , like most online games have, to discourage username/password bruteforcing. (It's an obscurity layer, but obscurity layers are not by definition bad.) But you need to tell others your username to communicate with them.
At first I thought it was an extra layer of security , like most online games have, to discourage username/password bruteforcing. (It's an obscurity layer, but obscurity layers are not by definition bad.) But you need to tell others your username to communicate with them.
In the description of the key exchange mechanism (section 'Conversation Keys' under 'Security') it sounds like they're using one symmetric key for both directions of a two-way channel. If true, this is a pretty serious security flaw. Anyone from Subrosa care to comment?
More importantly, one of the party is trusted to come up with the key alone. The other party just has to accept that it's a good key with no other proof then that it was encrypted with their public key. The description is really weak on details.
They keep repeating they've been audited but not naming the auditors.
They keep repeating they've been audited but not naming the auditors.
Not really, from what I understand. Seems they are exchanging a symmetric key via RSA to facilitate two-way encrypted communication. This is pretty standard, browsers do this via TLS.
TLS does not use a single symmetric key for bidirectional comms. It establishes keys per direction.
I ran this through the SSLlabs SSL Test and it came back with an F. Perhaps an oversight on their end?
Looks like it's because it's vulnerable to the OpenSSL CCS exploit. http://ccsinjection.lepidum.co.jp/
A system bragging about security leaving a known, patched hole like this open isn't a great sign.
A system bragging about security leaving a known, patched hole like this open isn't a great sign.
First impression:
- There is no demo, i can only guess that this is a "browser-based skype". I hate when i can't try it but it's free.
- Open-source, but no git repo?
Btw I had the same idea before (I posted it to an Idea Sunday thread) but I dropped the idea because i realized that no one needs this level of security, NSA is not interested in your chat with family and friends...
- There is no demo, i can only guess that this is a "browser-based skype". I hate when i can't try it but it's free.
- Open-source, but no git repo?
Btw I had the same idea before (I posted it to an Idea Sunday thread) but I dropped the idea because i realized that no one needs this level of security, NSA is not interested in your chat with family and friends...
"There is no demo" -- just make an account quickly and try it out. I did this and it was easy.
"Open-source, but no git repo" -- Open-source does not always entail git or Github.
"I dropped the idea because i realized that no one needs this level of security, NSA is not interested in your chat with family and friends..." -- I'm glad you dropped the idea because someone who doesn't understand why privacy is important shouldn't be making privacy applications. The NSA doesn't care about your chat with family and friends, until suddenly they DO start caring and everything you've said can be manipulated and transformed against you, whether your conversations were innocent or not.
"Open-source, but no git repo" -- Open-source does not always entail git or Github.
"I dropped the idea because i realized that no one needs this level of security, NSA is not interested in your chat with family and friends..." -- I'm glad you dropped the idea because someone who doesn't understand why privacy is important shouldn't be making privacy applications. The NSA doesn't care about your chat with family and friends, until suddenly they DO start caring and everything you've said can be manipulated and transformed against you, whether your conversations were innocent or not.
Some sort of reproducible version control chain is essential for any kind of privacy- or security-related application. It makes auditing about a hundred times easier.
I know it can be open source without git, but GitHub gives a lot of benefits.
Also as I understood, you don't have Facebook, Twitter, Skype, Googe, Outlook, YouTube, and even HN account because NSA could one day transform everything against you?!
Also as I understood, you don't have Facebook, Twitter, Skype, Googe, Outlook, YouTube, and even HN account because NSA could one day transform everything against you?!
Possible scenario: you are chatting with a friend about how you bought bitcoin at 300 and sold at 500, making 6000USD on the trade. Your money is in an offshore exchange. Next year, you receive a bill from the IRS wanting their cut of the $6000. How did they know? You never pulled out your money.
Well, the NSA gave them a tip.
Now imagine you're running for public office and your opponents will pay top dollar for dirt on you. Imagine that one day you're at odds with your government and they'll use every piece of information they can to prosecute you.
Privacy from one's government and those who control/buy into it is something that nobody needs until they do.
That doesn't mean you can't have a public life as well. But why give out more than you need to?
Well, the NSA gave them a tip.
Now imagine you're running for public office and your opponents will pay top dollar for dirt on you. Imagine that one day you're at odds with your government and they'll use every piece of information they can to prosecute you.
Privacy from one's government and those who control/buy into it is something that nobody needs until they do.
That doesn't mean you can't have a public life as well. But why give out more than you need to?
I like your example, but it is also why a lot of folks don't care so much about privacy. Ie. in the scenario there was an illegal hiding of revenue from the IRS. The privacy infringement simply corrected a wrong. So, for many folks they remain unconvinced because they aren't doing anything wrong, so they feel they have nothing to hide, and don't take issue.
Perhaps, a better scenario is that you are chatting with a fellow entrepreneur about bitcoin, a short while later they are charged by the IRS for tax evasion. Meanwhile, your conversation with them on the subject is discovered through the NSA machinery and is used to kick off an investigation against you.
I wish I had a better example, as that would serve us well to educate folks on the value of privacy. I'm writing in part that someone has a better example to share.
Perhaps, a better scenario is that you are chatting with a fellow entrepreneur about bitcoin, a short while later they are charged by the IRS for tax evasion. Meanwhile, your conversation with them on the subject is discovered through the NSA machinery and is used to kick off an investigation against you.
I wish I had a better example, as that would serve us well to educate folks on the value of privacy. I'm writing in part that someone has a better example to share.
You're right, it's a tricky line to walk.
When not citing technology-focused issues, I like to use the bathroom example: "Would you use a public bathroom with glass walls?" It illustrates the difference between covering up wrongdoing and need for personal privacy, two entirely different things.
When not citing technology-focused issues, I like to use the bathroom example: "Would you use a public bathroom with glass walls?" It illustrates the difference between covering up wrongdoing and need for personal privacy, two entirely different things.
You misunderstood, completely. I never indicated that I don't have any FB/Twitter/Skype/... accounts.
The idea of having a secure communication channel doesn't mean that ALL your communications have to be over secure channels, that would be ridiculous. Having the option to bank on a secure channel for conversations you deem private is a perfectly reasonable compromise. People in government agencies switch between insecure and secure mediums regularly.
Having a FB/Twitter/Skype/HN account just means that I am willing to make a tradeoff of privacy to use these services, one that I am okay with. This does not completely exclude me from occasionally using a secure medium, right?
The idea of having a secure communication channel doesn't mean that ALL your communications have to be over secure channels, that would be ridiculous. Having the option to bank on a secure channel for conversations you deem private is a perfectly reasonable compromise. People in government agencies switch between insecure and secure mediums regularly.
Having a FB/Twitter/Skype/HN account just means that I am willing to make a tradeoff of privacy to use these services, one that I am okay with. This does not completely exclude me from occasionally using a secure medium, right?
So you're using FB to communicate with family and friends. As far as i know Facebook messages are not encrypted. Then NSA could use these messages against you (you said this). Am i right?
Yep, you got it! Once again, I don't encrypt all my conversations because I'm making a tradeoff, but I would definitely prefer that they were all private. And again, having a distinct communication channel that was private would not be unwelcome.
The published source code is only the client-side. So not quite open-source, at least in my book if a client is open-source the protocol it implements ought to be documented somewhere or the implementation provided.
These statements are mutually exclusive:
End to end encrypted: Nobody, not even us, can read or listen into your conversations.
Works everywhere: Visit subrosa.io from any computer. No download or install needed.