4 ms·

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 loo

by 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.

by 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.