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

Show HN: Free, instant, secure, disposable chat rooms built in Go

niltalk.com

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#71

Post by StavrosK »

soft_dev_person wrote: post #68
hurin wrote: post #61

Earlier quoted context omitted.

> New keypairs would be generated on the client every time you join a chatroom. Another member of the chatroom sends you the shared_key encrypted by your public key. Server knows nothing, stores no keys. Keys exchanged between users. The question is - how does the first public key exchange happen? It has be done outside of the site for it to be secure and your private key must exist locally on your device - which is…

It's asymmetric encryption. Even if the server got a hold of the public key, it would not be able to decrypt the contents. How to ensure the server doesn't get a hold of the private key is the issue (can you really trust the code you're running?).

The bigger problem is "how do you ensure that the public key the server sent is actually the other user's, and not a MITM?".

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#72

Post by new299 »

pjc50 wrote: post #67
new299 wrote: post #56

Earlier quoted context omitted.

why does the client need to be built locally? Are you inherently suspicious of anything delivered over HTTPS? I'm genuinely interested in why people feel local clients are more secure than something running in a browser. It's something I came across when writing an ssh client in browser (www.minaterm.com). I guess it's the potential for a HTML page to updated overtime so it no longer reflects an audited version. Howe…

Users fall into two categories: 1) Don't really care about privacy. Might not want their chat on the front page of the papers, but aren't going to go to great lengths to achieve that. 2) Actually care about privacy and are informed. There's not many of these people, but they're trained to be wary of every outside dependency and opportunity for hostile code injection. Crypto running in the browser can be replaced any…

> Yes, it could be hashed, but it isn't and there's no mechanism for this nor plans to build one.

That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories.

> Not to mention that the browser itself presents a pretty large attack surface.

As does the operating system itself. I would have thought with a local (likely native) client, you just have one less layer to get through.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#73

Post by cmdrfred »

new299 wrote: post #56
hiddentao wrote: post #43

Good work. Though I have to say I've seen so many of these web-based "secure, private, anonymous" chat services now, I've lost track. What we need is end-to-end encryption and with an open source client that just has to be downloaded and built/installed once (and in such a way that it's verifiably secure, think reproducible builds).

why does the client need to be built locally? Are you inherently suspicious of anything delivered over HTTPS? I'm genuinely interested in why people feel local clients are more secure than something running in a browser. It's something I came across when writing an ssh client in browser (www.minaterm.com). I guess it's the potential for a HTML page to updated overtime so it no longer reflects an audited version. Howe…

I was looking for something like minaterm the other day, trouble is i'd be scared to put my credentials into it. A when I think about it logically that isn't rational (putty can grab my credentials just as easily), but still.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#74

Post by new299 »

cmdrfred wrote: post #73
new299 wrote: post #56

Earlier quoted context omitted.

why does the client need to be built locally? Are you inherently suspicious of anything delivered over HTTPS? I'm genuinely interested in why people feel local clients are more secure than something running in a browser. It's something I came across when writing an ssh client in browser (www.minaterm.com). I guess it's the potential for a HTML page to updated overtime so it no longer reflects an audited version. Howe…

I was looking for something like minaterm the other day, trouble is i'd be scared to put my credentials into it. A when I think about it logically that isn't rational (putty can grab my credentials just as easily), but still.

yes, and I also would be scared to too. It's interesting thinking about why though. I think there's a significant social/psychological component to the decision.

I'd also be less scared if it was running on my own server, but it's not clear to me that this is completely logical either.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#75

Post by jerf »

new299 wrote: post #56
hiddentao wrote: post #43

Good work. Though I have to say I've seen so many of these web-based "secure, private, anonymous" chat services now, I've lost track. What we need is end-to-end encryption and with an open source client that just has to be downloaded and built/installed once (and in such a way that it's verifiably secure, think reproducible builds).

why does the client need to be built locally? Are you inherently suspicious of anything delivered over HTTPS? I'm genuinely interested in why people feel local clients are more secure than something running in a browser. It's something I came across when writing an ssh client in browser (www.minaterm.com). I guess it's the potential for a HTML page to updated overtime so it no longer reflects an audited version. Howe…

"why does the client need to be built locally? Are you inherently suspicious of anything delivered over HTTPS?"

A good question.

In order to have end-to-end security, you need some sort of secret that is only known on the end points (possibly negotiated over some sort of key exchange protocol), and it should be impossible for the server in the middle to have the secrets.

The core problem is that a webpage is really, really, really designed to be a representation of the server, sitting on a client sandbox. There is no built-in way for a web browser to inject anything into the connection that could be used for a security connection in such a way that the server can't see it. All the local storage the page has access to, the server has access to. All the cookie data the page has access to, the server has access to. Anything else you can come up with that the page has access to, the server can either read or destructively set by sending down the correct HTTP or HTML. There's no independent client "context" that can be passively, safely used by the page somehow, and in a world where the page is running javascript provided by the server it's not even particularly clear what could be "used" by the page without being something that the server could "use" by reading, then sending to the server.

There is, therefore, no way to use the web through a conventional browser to create an end-to-end connection that the server doesn't have full access to. Browsers just aren't designed for this use case.

Note nothing stops you from providing an HTTPS REST interface that would allow full end-to-end encryption that is used by a client that is capable of having local secrets and does not provide any way for a server to run code against it. It is specifically the browsers making this impossible. I'd also observe this isn't necessarily fundamental, browsers could be changed to fix this, but... I'm not sure it would be a good idea. Browsers are already insanely complicated security environments that just barely work on the best of days. Not sure I want to add "secure-from-the-server secret storage" to the list of things a browser is supposed to be able to do. (It is also possible certain extensions in the browser have already hacked together this ability, such as the video chat extensions, I haven't studied them to that detail, but AFAIK secure secret storage and key negotiation aren't generically and generally available.)

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#78

Post by lukeschlather »

new299 wrote: post #72
pjc50 wrote: post #67

Earlier quoted context omitted.

Users fall into two categories: 1) Don't really care about privacy. Might not want their chat on the front page of the papers, but aren't going to go to great lengths to achieve that. 2) Actually care about privacy and are informed. There's not many of these people, but they're trained to be wary of every outside dependency and opportunity for hostile code injection. Crypto running in the browser can be replaced any…

> Yes, it could be hashed, but it isn't and there's no mechanism for this nor plans to build one. That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories. > Not to mention that the browser itself presents a pretty large attack surface. As does the operating system itself. I would have thought with a local (likely native) client, you just have o…

> That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories.

This sounds like a theoretical impossibility. The server's source code is by nature closed, and while the server could provide you a copy of the source with a signature, there's really no way for you to verify that the code you've been promised is the code that is running.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#79

Post by new299 »

lukeschlather wrote: post #78
new299 wrote: post #72

Earlier quoted context omitted.

> Yes, it could be hashed, but it isn't and there's no mechanism for this nor plans to build one. That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories. > Not to mention that the browser itself presents a pretty large attack surface. As does the operating system itself. I would have thought with a local (likely native) client, you just have o…

> That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories. This sounds like a theoretical impossibility. The server's source code is by nature closed, and while the server could provide you a copy of the source with a signature, there's really no way for you to verify that the code you've been promised is the code that is running.

A browser feature would be required that could calculate/display the hash of the delivered code and optionally verify it against a 3rd party server. Ideally you'd want have particular versions signed as "audited" etc.

I don't see how it's a theoretical impossibility.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#80

Post by thwarted »

hurin wrote: post #54
8rian wrote: post #52

I only feel safe using end-to-end encrypted chatrooms. Currently, niltalk can read every message. At the very least, AES encrypting messages by the chatroom's password will reduce reliance on SSL. But it really should use public key crypto for a key exchange between users. This is what's done by other disposable chatrooms: https://crypto.cat/ https://ephemeral.pw/chat/ (Also written in Go)

The problem with end-to-end encryption is not the encryption but the key-exchange (and especially so for multi-user setups). If you are trusting the server to create or associate identities with keys, the end-to-end encryption is easily subvertible.

Is there a chat system that leverages keybase.io?
Post reply on HN