35 ms·

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

by themgt 5y ago

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/1d273fa306a543fefbf2cfa615f6b47eaadf49ea/termpair/share.py#L55-L57 https://github.com/cs01/termpair/blob/1d273fa306a543fefbf2cf...

tyingq 5y ago
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.
- rsj_hn 5y ago
  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)
  - gruez 5y ago
    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.
    - rsj_hn 5y ago
      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.
rsj_hn 5y ago
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.

by themgt 5y ago

tyingq 5y ago

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.

rsj_hn 5y ago
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)
- gruez 5y ago
  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.
  - rsj_hn 5y ago
    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.

rsj_hn 5y ago

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.