Hacker News Reader

Comment by illuminated | Hacker News Reader

I'm not the author, but you have the encryption implementation here in the code: https://github.com/cs01/termpair/blob/master/termpair/encryp...

View on HN

That's just an api to generate key and then wrap/unwrap. So OK, you generate the key in the server, and then have to get that over to someone who is using a web browser. How does that work? Then you have to store the key somewhere in the browser and in the server -- is it just in memory, in which case you have to get the key to the browsing user with each connection or if the browser is reloaded? Or is the key stored as a plaintext string on disk somewhere? Is it stored as a cookie in the browser? in gnome-keyring? and how is the key rotated? In other words, key management is the tricky part of all these protocols - is the author rolling their own authentication and key establishment protocol or using an existing one, and if the latter, which one and how are they using it? That's how you figure out the security of this cryptographic system. And remember that any secrets in the DOM loaded from origin X are exposed to code served from that origin, so what isolation guarantees are really being made when you want to make your terminal opaque to the webserver?

From a quick skim it looks like the key is base64 encoded into the URL in terminal_id param, so presumably you just share the URL and the collaborator stays on the URL with the key? If the key is ephemeral/regenerated for each session it seems to eliminate most of your concerns.

https://github.com/cs01/termpair/blob/1d273fa306a543fefbf2cf...

It does also put the key after a # mark in the url so that the browser isn't sending the key as part of the http request.

that hash is still accesible to any javascript loaded from the server, right? And the hash is still sent in referer headers, IIRC (it's been a while since I looked at it)

Hash isn't sent in the headers, but you're right, it doesn't protect against a malicious server stealing the secret via compromised javascript.

The server doesn't need to be compromised, as from the point of the user it is an independent security zone and loads whatever js it wants. Perhaps you could install a browser extension that would compute a hash of the js and only allow the load to proceed if it was verified, but apart from that your browser is going to execute whatever js the server loads.

And that would be fine if the threat model was such that the server was trusted with the keys to the channel (because, for example, you control the server), but in that case what is the point of the end-to-end encryption, which is supposed to protect you from the server? If the server was trusted with the channel key, you can roll a much simpler system without end to end encryption.

Again, this is why I was asking for an actual description of the security design. If you are trusting the server to handle the key, then you can really simplify this system. If you are not trusting the server to handle the key (which would be the case if it was not under your control), then this design doesn't appear adequate.

I really wish these types of projects disclosed these types of design assumptions and operational details so that people could review the security efficiently instead of peering through code and trying to guess what the developer's intentions and assumptions are. It would also help the developers. If they are forced to write down: we don't trust the server to access the key but we must trust the server to not try to access the key, then such an exercise would hopefully trigger a moment of clarity that would lead to the creation of more secure systems. For example, they may want to include a browser extension under the control of the user as a part of the overall system, and have the browser extension touch the key in an origin not controlled by the server or have a key establishment protocol run between the browser extension and the ssh server with the webserver being just a transport layer.

Yes, this is starting to fill out the details. So is the plan:

1. ssh into your server

2. run the program to get a URL

3. close the ssh connection

4. Open a browser SSH connection and use the url?

In which case,

1. hmm, what is the benefit

2. how do you prevent the hosting webserver from seeing the url parameter? Assuming you want the hosting system to not be able to interfere in the session. If you are OK with such interference, you can make an easier key distribution than this.

Or is the idea:

1. Setup your own webserver

2. authenticated to the webserver with some other protocol

3. the webserver grabs the url (it's hosted on the same server as the terminal server?) and then redirects to a page with the URL that you can use for the session

In which case, err, why encourage people to use this third party server if that server can read the url? Also, there are again more secure ways of handling this that don't expose your terminal key as a URL parameter

Remember URL parameters get leaked in referer and it's generally not recommended to store secrets in them if you can avoid it, which I believe in this use case you can, again assuming I have the workflows right.

What this needs is a simple diagram showing the terminal server, the webserver, and the user's browser, defining the trust relationships between these, and explaining the flow of information among these components during key establishment and rotation.

It could be made more resistant to birthday attacks by using the session message count as the IV, but I guess it wouldn't matter unless someone kept one of these terminals open for a really long time.

I think it's important to clarify the statement above, for anymore who is not familiar with the issue and keeps misusing AES-GCM.

AES-GCM has a relatively short IV (= nonce): only 96 bits (12 bytes). To make things worse, if an IV ever gets repeated GCM fails catastrophically[1]. The design document[2] explicitly point out that a FIPS 140-2 compliant GCM hardware[3], must take all possible precaution to ensure an IV never gets repeated, even if the device suffers a critical power loss.

The safe way to use AES-GCM in software (for instance, the way it is used in TLS) is to just use a running counter and replace the key before the counter overflows and starts repeating itself. Random counters bad, since if enough messages are generated with the same key the chance of a message that repeats an IV under the same key increases. The statistic phenomenon behind the chance of something like that being repeated is called the "Birthday Problem"[4], so exploiting this kind of weakness is often referred to as a "Birthday Attack"[5].

tl;dr: If you want an easy life, just never use any form of AES at all. Most AES mode can be completely safe if used and implemented with care - but it is generally quite hard to do that. AES has too many knobs and there is too much bad advice on places like Stack Overflow and various blogs.

Generally, for encrypting multiple messages with the same key, the solid advice is to use NaCl secretbox (XSalsa20-Ply1305) or libsodium aead_xchacha20poly1305_ietf[6].

But you probably need more than that when encrypting potentially long-lived bidirectional streams of data.

---

[1]: It fails even worse than other authenticated counter mode ciphers due to the design of the GHASH function:

https://csrc.nist.gov/csrc/media/projects/block-cipher-techn...

[2]: See section 9 here in NIST 800-38D: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli...

[3] Keep in mind that like most 2000s vintage cipher specs, GCM was designed as a hardware cipher. Software was more or less an afterthought, if anything at all.

[4]: https://en.wikipedia.org/wiki/Birthday_problem

[5]: https://en.wikipedia.org/wiki/Birthday_attack

[6]: https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...

Reply on news.ycombinator.com