6 ms·

TermPair: Terminal sharing with AES-GCM 128 bit end-to-end encryption

118 points by illuminated 5y ago

rsj_hn 5y ago
This looks cool, but if the author is here, I wish they would actually explain the security rather than just citing AES-GCM, which doesn't really explain the security design. How is the key material established, exactly? How is it rotated? How is it protected when stored? The answers to these questions are a lot more relevant to understanding the security of this application than citing which encryption mode is being used.
- illuminated 5y ago
  I'm not the author, but you have the encryption implementation here in the code: https://github.com/cs01/termpair/blob/master/termpair/encryption.py https://github.com/cs01/termpair/blob/master/termpair/encryp...
  - rsj_hn 5y ago
    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?
    - 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.
  - _nhynes 5y ago
    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.
    - unscaled 5y ago
      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-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf 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/nistspecialpublication800-38d.pdf 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 https://en.wikipedia.org/wiki/Birthday_problem [5]: https://en.wikipedia.org/wiki/Birthday_attack https://en.wikipedia.org/wiki/Birthday_attack [6]: https://libsodium.gitbook.io/doc/secret-key_cryptography/aead/chacha20-poly1305/xchacha20-poly1305_construction https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...
- gruez 5y ago
  >I wish they would actually explain the security rather than just citing AES-GCM Yeah, AFAIK there isn't really much difference between AES-GCM and any other AES + HMAC algorithm (eg. AES-SHA1) other than that AES-GCM is more performant. In this sort of use case, that's not really relevant, so it's strange to advertise it like it's some sort of feature.
  - bawolff 5y ago
    I think you're confused on nomenclature here. GCM is both an authentication method and encryption mode. The big benefit is its all specified as one primitive because combining primitives is where people often screw up. HMAC-SHA1 is an authentication mechanism, there's various ways you can combine it with something like AES-CTR or AES-CBC to make something secure, but also plenty of ways to screw it up. Saying something like AES-SHA1 is meaningless because there's no standard way to combine those two, so you dont know what the person is doing, and you still dont know what the mode is.
    - rsj_hn 5y ago
      I don't believe they are confused about the nomenclature, as everything the parent said was correct. In terms of there not being standard ways to add an HMAC to an encrypted string, there are plenty of standard ways to do that. How do you think people implemented secure channels before Cisco released AES-GCM to speed up their VPNs? Just let attackers modify payloads? SSL/TLS, SSH, IPsec and many other widely used secure channel protocols were over a decade old before anyone standardized an authenticated encryption mode. But none of these widely used and well-standardized protocols require an authenticated encryption mode even though they all have both authentication and encryption as security properties. Authenticated encryption doesn't give you anything other than performance over the standard encrypt + tag approach (which is still widely used). And AES-GCM has some drawbacks that encrypt + tag do not (although the performance gains usually trump the drawbacks).
    - tptacek 5y ago
      AES+HMAC is harder to screw up than GCM, which is notoriously brittle. In particular: AES-CBC + HMAC doesn't fail catastrophically if randomness fails somehow, and GCM does.
- fomine3 5y ago
  Still a bit better than "Military grade encryption"
mushufasa 5y ago
How does this compare to the feature for sharing terminals within VS Code? Is it a similar technique or totally different implementation?
- elliotf 5y ago
  I don't know about this project, but I have used tmate.io (self hosted ssh server) for almost seven years for remote pairing, using vim inside of tmate. Compared to vscode: when sharing the terminal, you don't need to worry about following the other person's cursor or them following yours, as there is only one cursor. You don't need to worry about telling them what dukes you are opening, as there is only one editor. You also don't need to worry about registering for an account, as (at least with tmate) it's simply an ssh connection for the remote person. It is the only way I've found that allows for effective remote pairing. There are a number of downsides, but it is a wonderful tool.
pmccarren 5y ago
for fans of tmux, I'm partial towards tmate[0], instant tmux session sharing over ssh, optionally through a relay refs: [0]https://tmate.io https://tmate.io
- caymanjim 5y ago
  What does this get you over simply attaching to an existing tmux session? You can already SSH into a machine and join any existing tmux session, or better yet, create a new session from an existing session, and get independent viewports and parallel input, or shared, depending on which window you're looking at.
  - whateveracct 5y ago
    I can run tmate in my laptop and a teammate can join.
  - bitbang 5y ago
    You can quickly provide a shared session connection to an external third party, so they can access computers that are not publicly accessable and that they normally would not have access to without having to do any credential management. It's great for tech support. tty-share is also good https://tty-share.com/ https://tty-share.com/
- usr1106 5y ago
  Great link, I have been searching for something like that for a while. Sharing terminals over Google Meet does not work very well. The video compression is particularly lossy with red on black. Pretty annoying with syntax highlighting or colored shell output. At a quick glance this is not seem to be end to end encrypted, but tmux is running on their server? That's not something I could ever use for work, we are in regulated domain. But you can run your own server, need to check that out.
  - usr1106 5y ago
    >the video compression is particularly lossy with red on black. The irony is that 20 years ago video conferencing was unthinkable, but I used VNC over a dial-up modem. Lossless and much better for terminal sharing than what is generally available today. Modern computing feels like the dark Middle Ages after the downfall of the Roman empire in some aspects...
chrissnell 5y ago
I like to use SSH and GNU screen(1) to do follow-the-leader sharing of a screen session. There's probably a tmux equivalent. https://www.endpoint.com/blog/2009/09/24/gnu-screen-follow-leader https://www.endpoint.com/blog/2009/09/24/gnu-screen-follow-l...
solresol 5y ago
Back in my day we used to use kibitz (from the expect package)... https://linux.die.net/man/1/kibitz https://linux.die.net/man/1/kibitz https://opensource.apple.com/source/tcl/tcl-20/tcl_ext/expect/expect/example/kibitz.auto.html https://opensource.apple.com/source/tcl/tcl-20/tcl_ext/expec... Not bad for 415 lines of code.
sam_lowry_ 5y ago
How is that different from screen -x?
mlang23 5y ago
I realize the browser is the target audience here, but... I prefer tmux, esp. because it does NOT bypass local access control.
ignoramous 5y ago
Project devs: Consider using CPACE (a password-authenticated key exchange) which is in the process of being standardized by IETF. https://github.com/jedisct1/cpace https://github.com/jedisct1/cpace
xvector 5y ago
Is it really E2EE if you could compromise the server to serve a compromised web-app? Same issue with ProtonMail.

118 points by illuminated 5y ago

This looks cool, but if the author is here, I wish they would actually explain the security rather than just citing AES-GCM, which doesn't really explain the security design. How is the key material established, exactly? How is it rotated? How is it protected when stored? The answers to these questions are a lot more relevant to understanding the security of this application than citing which encryption mode is being used.

illuminated 5y ago
I'm not the author, but you have the encryption implementation here in the code: https://github.com/cs01/termpair/blob/master/termpair/encryption.py https://github.com/cs01/termpair/blob/master/termpair/encryp...
- rsj_hn 5y ago
  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?
  - 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.
- _nhynes 5y ago
  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.
  - unscaled 5y ago
    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-techniques/documents/bcm/comments/800-38-series-drafts/gcm/joux_comments.pdf 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/nistspecialpublication800-38d.pdf 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 https://en.wikipedia.org/wiki/Birthday_problem [5]: https://en.wikipedia.org/wiki/Birthday_attack https://en.wikipedia.org/wiki/Birthday_attack [6]: https://libsodium.gitbook.io/doc/secret-key_cryptography/aead/chacha20-poly1305/xchacha20-poly1305_construction https://libsodium.gitbook.io/doc/secret-key_cryptography/aea...
gruez 5y ago
>I wish they would actually explain the security rather than just citing AES-GCM Yeah, AFAIK there isn't really much difference between AES-GCM and any other AES + HMAC algorithm (eg. AES-SHA1) other than that AES-GCM is more performant. In this sort of use case, that's not really relevant, so it's strange to advertise it like it's some sort of feature.
- bawolff 5y ago
  I think you're confused on nomenclature here. GCM is both an authentication method and encryption mode. The big benefit is its all specified as one primitive because combining primitives is where people often screw up. HMAC-SHA1 is an authentication mechanism, there's various ways you can combine it with something like AES-CTR or AES-CBC to make something secure, but also plenty of ways to screw it up. Saying something like AES-SHA1 is meaningless because there's no standard way to combine those two, so you dont know what the person is doing, and you still dont know what the mode is.
  - rsj_hn 5y ago
    I don't believe they are confused about the nomenclature, as everything the parent said was correct. In terms of there not being standard ways to add an HMAC to an encrypted string, there are plenty of standard ways to do that. How do you think people implemented secure channels before Cisco released AES-GCM to speed up their VPNs? Just let attackers modify payloads? SSL/TLS, SSH, IPsec and many other widely used secure channel protocols were over a decade old before anyone standardized an authenticated encryption mode. But none of these widely used and well-standardized protocols require an authenticated encryption mode even though they all have both authentication and encryption as security properties. Authenticated encryption doesn't give you anything other than performance over the standard encrypt + tag approach (which is still widely used). And AES-GCM has some drawbacks that encrypt + tag do not (although the performance gains usually trump the drawbacks).
  - tptacek 5y ago
    AES+HMAC is harder to screw up than GCM, which is notoriously brittle. In particular: AES-CBC + HMAC doesn't fail catastrophically if randomness fails somehow, and GCM does.
fomine3 5y ago
Still a bit better than "Military grade encryption"

mushufasa 5y ago

How does this compare to the feature for sharing terminals within VS Code? Is it a similar technique or totally different implementation?

elliotf 5y ago
I don't know about this project, but I have used tmate.io (self hosted ssh server) for almost seven years for remote pairing, using vim inside of tmate. Compared to vscode: when sharing the terminal, you don't need to worry about following the other person's cursor or them following yours, as there is only one cursor. You don't need to worry about telling them what dukes you are opening, as there is only one editor. You also don't need to worry about registering for an account, as (at least with tmate) it's simply an ssh connection for the remote person. It is the only way I've found that allows for effective remote pairing. There are a number of downsides, but it is a wonderful tool.

pmccarren 5y ago

for fans of tmux, I'm partial towards tmate[0], instant tmux session sharing over ssh, optionally through a relay refs: [0]https://tmate.io https://tmate.io

caymanjim 5y ago
What does this get you over simply attaching to an existing tmux session? You can already SSH into a machine and join any existing tmux session, or better yet, create a new session from an existing session, and get independent viewports and parallel input, or shared, depending on which window you're looking at.
- whateveracct 5y ago
  I can run tmate in my laptop and a teammate can join.
- bitbang 5y ago
  You can quickly provide a shared session connection to an external third party, so they can access computers that are not publicly accessable and that they normally would not have access to without having to do any credential management. It's great for tech support. tty-share is also good https://tty-share.com/ https://tty-share.com/
usr1106 5y ago
Great link, I have been searching for something like that for a while. Sharing terminals over Google Meet does not work very well. The video compression is particularly lossy with red on black. Pretty annoying with syntax highlighting or colored shell output. At a quick glance this is not seem to be end to end encrypted, but tmux is running on their server? That's not something I could ever use for work, we are in regulated domain. But you can run your own server, need to check that out.
- usr1106 5y ago
  >the video compression is particularly lossy with red on black. The irony is that 20 years ago video conferencing was unthinkable, but I used VNC over a dial-up modem. Lossless and much better for terminal sharing than what is generally available today. Modern computing feels like the dark Middle Ages after the downfall of the Roman empire in some aspects...

chrissnell 5y ago

I like to use SSH and GNU screen(1) to do follow-the-leader sharing of a screen session. There's probably a tmux equivalent. https://www.endpoint.com/blog/2009/09/24/gnu-screen-follow-leader https://www.endpoint.com/blog/2009/09/24/gnu-screen-follow-l...

solresol 5y ago

Back in my day we used to use kibitz (from the expect package)... https://linux.die.net/man/1/kibitz https://linux.die.net/man/1/kibitz https://opensource.apple.com/source/tcl/tcl-20/tcl_ext/expect/expect/example/kibitz.auto.html https://opensource.apple.com/source/tcl/tcl-20/tcl_ext/expec... Not bad for 415 lines of code.

sam_lowry_ 5y ago

How is that different from screen -x?

mlang23 5y ago

I realize the browser is the target audience here, but... I prefer tmux, esp. because it does NOT bypass local access control.

ignoramous 5y ago

Project devs: Consider using CPACE (a password-authenticated key exchange) which is in the process of being standardized by IETF. https://github.com/jedisct1/cpace https://github.com/jedisct1/cpace

xvector 5y ago

Is it really E2EE if you could compromise the server to serve a compromised web-app? Same issue with ProtonMail.