Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trsst: a distributed secure blog platform for the open web

kickstarter.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Trsst: a distributed secure blog platform for the open web

#51

Post by w1ntermute »

wahsd wrote: post #20
w1ntermute wrote: post #6

Horrible name - please change it. People are going to have no idea how to pronounce that. Just because you were able to get a 5 character .com domain name doesn't mean you should use it for your new venture.

ummm ... trust? I didn't find it that difficult. What does Facebook tell us about its service? Reminds me of a perpetrator log, which, I guess it has kind of revealed itself as with revelations that facebook is essentially a mass surveillance dossier system. But I get your point, it will need some marketing to get people to understand what it is all about. But it's not like we knew what Twitter was at first. Did we?

> But I get your point

No, you don't. It's not a matter of understanding the meaning, it's a matter of pronunciation.

Re: Trsst: a distributed secure blog platform for the open web

#53

Post by mpowers »

zedpm wrote: post #48
mpowers wrote: post #8

Earlier quoted context omitted.

JS on the client, and that's the important bit where all the crypto happens. Likely Java on the server, basically a drop-in servlet for any Tomcat, but still TBD.

Java/Tomcat is an unsavory prospect for many folks. The options for building the server side are numerous; Tomcat is a clunky, resource-hungry PITA that many folks, myself included, go out of their way to avoid. If the devs are Java guys then that's their business, but the choice will almost certainly decrease the user base.

Yes, this is the kind of feedback we're looking for with regard to another comment here. This is why we haven't committed to a language for the server-side reference impl yet, because we're not sure what would be useful. (Our prototype is java, fwiw.)

Re: Trsst: a distributed secure blog platform for the open web

#54

Post by mpowers »

tptacek wrote: post #39
mpowers wrote: post #31

Earlier quoted context omitted.

If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime. Similarly if a host is compromised to serve bad js files. We can't solve endpoint security. And clearly NSA is now very good at breaking the endpoint at both ends. I agree that it's not useful to say "just inspect the code"; no one really inspects their binary executables either, but we're committed to le…

I don't even know how to respond to this: "the endpoints might be compromised, so why bother making the crypto secure"? That's the idea? Browser JS is a uniquely terrible vector for delivering crypto to end users. Use something different.

Your logical fallacy is: putting words into my mouth (argumentum ad logicam). I didn't say "why bother making the crypto" secure. I said that you can't point to endpoint security as a reason to fault JS more than you can fault every other crypto implementation.

Schneier thinks NSA may have already compromised certain binaries and checksums, and John Gilmore is wondering if certain source trees have been compromised.

JS is not immune to these kinds of attacks, nor is it any more susceptible. All we can do is make sure our implementation is clear and correct and avoids browser exploits. We can't control your binaries, OS, browser, or otherwise.

Re: Trsst: a distributed secure blog platform for the open web

#55

Post by mpowers »

timtadh wrote: post #40
mpowers wrote: post #31

Earlier quoted context omitted.

If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime. Similarly if a host is compromised to serve bad js files. We can't solve endpoint security. And clearly NSA is now very good at breaking the endpoint at both ends. I agree that it's not useful to say "just inspect the code"; no one really inspects their binary executables either, but we're committed to le…

> If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime. It is trivial to compromise the browser context of the page. In the case of a browser bug another tab can interact badly with the current tab. In the case of a MITM attack on (sadly quite possible given the potential adversary) the attacker can modify the JS in flight to the browser. In the case of an e…

I appreciate your concern, but you can't fault JS for browser bugs or OS bugs.

It's also not clear to me why you're any more secure with a signed browser extension or native app. Just because it's signed doesn't mean you can trust it any more than you can trust JS that you download via HTTPS from a server. What's worse, you didn't compile it from source, so how can you know there's nothing sinister lurking in there?

You are correct that people like native apps for their microblogging, and we want to encourage many native, hardened, peer-reviewed implementations for every platform imaginable.

Because the client is just appending signed entries to the end of an RSS file, send pushing and pulling those files over http, you could write a nice client running inside emacs (if you trusted your os crypto libs).

Re: Trsst: a distributed secure blog platform for the open web

#56

Post by mpowers »

wglb wrote: post #50
mpowers wrote: post #26

Earlier quoted context omitted.

Gah, HN is rate-limiting my responses. Very familiar with the document, but it mainly just boils down to watch-out for XSS attacks. We require SSL to deliver the entire page with no external libraries or references. His response to this doesn't really say anything. See: "WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE?" We need the crypto for keygen and signing and encryption, so he's missing the point…

Dismissing one of the leading penetration tester's essays with it mainly just boils down to watch-out for XSS attacks. seems unwise.

I'm not being flip about it. Granted, entropy is an issue with in-browser JS, but the rest of it is really just cautionary about browser bugs, compromised browsers, and known page-based browser attacks. Very little doesn't also apply to every crypto system on every platform. If you can't trust your OS or browser, you've got bigger problems.

I'll submit that because it's in-browser it's additionally difficult - very difficult - to get right, but I don't see that it's impossible.

Re: Trsst: a distributed secure blog platform for the open web

#57

Post by e12e »

mpowers wrote: post #55
timtadh wrote: post #40

Earlier quoted context omitted.

> If your device or browser is compromised, you have bigger problems than someone subtly modifying your js runtime. It is trivial to compromise the browser context of the page. In the case of a browser bug another tab can interact badly with the current tab. In the case of a MITM attack on (sadly quite possible given the potential adversary) the attacker can modify the JS in flight to the browser. In the case of an e…

I appreciate your concern, but you can't fault JS for browser bugs or OS bugs. It's also not clear to me why you're any more secure with a signed browser extension or native app. Just because it's signed doesn't mean you can trust it any more than you can trust JS that you download via HTTPS from a server. What's worse, you didn't compile it from source, so how can you know there's nothing sinister lurking in there?…

> It's also not clear to me why you're any more secure with a signed browser extension or native app. Just because it's signed doesn't mean you can trust it any more than you can trust JS that you download via HTTPS from a server.

For one, one would hope that a team takes more care to manage their private (code) signing key, than their ssl private key. The signing key should probably be on an air gapped system. That isn't feasible with the key use for https/tls.

You could compromise ftp-servers all day without being able to generate a valid signature for your bad code.

Now, on the subject of: Wouldn't it be possible, in the future, to create mechanism where we could deliver signed js code in a more secure manner than we do today? Absolutely. But it that future doesn't seem to be arriving any time soon.

Re: Trsst: a distributed secure blog platform for the open web

#58

Post by e12e »

mpowers wrote: post #41
pyre wrote: post #33

Earlier quoted context omitted.

Assume for a moment that JS crypto is insecure. If you use a web client with JS crypto to bootstrap acceptance, then the majority of your clients will end up using JS crypto. If the majority of the clients on the 'network' are insecure, then what's really the point?

A single client isn't weakened by other compromised clients. If you run a hardened trustworthy client, your own public posts are still verifiable, and private posts meant for you are decodable only by you. You would just need to make sure to send your private posts only to others that use trustworthy clients. But, because you're sending them a secret message in the first place, you already implicitly trust them.

> You would just need to make sure to send your private posts only to others that use trustworthy clients.

And how would you make sure of that? Is there a field in the user data that says: "419 I speak the protocol, but I don't give security grantees - fool you for talking with me?". Is there planned an easy UI for showing you which of your contacts are part of the secure network, and which ones are backdoors into the network?

Post reply on HN