4 ms·

Sorry, it's you misunderstanding. TLS doesn't require that it's a client to a server, TLS doesn't care, TLS says this connection from A <-> B is secure, that's

by zie 5y ago

Sorry, it's you misunderstanding. TLS doesn't require that it's a client to a server, TLS doesn't care, TLS says this connection from A <-> B is secure, that's it. 99% of deployed TLS is client to server, but it doesn't have to be. TLS IS however limited to 1 connection A <-> B. I think what you are trying to talk about is: You want A to talk THROUGH B to get to C and have the connection secure between A and C. This is generally a terrible idea, if you can at all avoid it, but sadly for many reasons, we can't. And you are right TLS can't do this. Noise totally does this, which I linked to in my first comment. So We are just talking about different meanings behind E2E. E2E == End To End, i.e. both ends are secure from eavesdroppers, TLS 100% fits this bill, as each end of the connection is secure. You seem to imply E2E is ONLY defined as encryption through some other connection, i.e. A <-> B <-> C, where B can't inspect/understand the contents. It's important to know that, even with E2E as you seem to be defining it, there is still a LOT of data leakage, B knows that A is talking to C, they maybe can't uniquely identify who A and C are directly, but they probably can indirectly. There is 100% a reason that NSA and friends care a lot about metadata and learn a ton from it. Hence why P2P (i.e. talk directly to the person you want to talk to, nothing in the middle) is way better from a security perspective, less metadata to exploit. If the Internet was better, Signal wouldn't have to use Noise and shunt traffic through their servers, and we could just use TLS directly between you and I for instance. Anyways, I hope this helps further your education and you learned something.

rektide 5y ago
This has been useful. It still is wildly off target from what I see as a core weakness with the web, which is that security keys cant be used to help a client create secure data. We can only authenticate ourselves with keys, not protect ourselves. The server we are talking to has more favor than us. Introducing the term e2e was a mistake, & mislead everything. TLS isnt really a factor. It was frustrating being so very very far off course from the relevant problem. But I certainly didnt handle this drift well at all & was frustrated at being so off topic from such a vital & core web weakness.
- zie 5y ago
  > The server we are talking to has more favor than us. Well, now I'm not sure what you are talking about, can you give a concrete example?
  - rektide 5y ago
    WebAuthn is about presenting credentials to the server from the security key. The server gets to check our private keys, but the end client (the page) doesn't have any validation or tools at it's own disposal. NitroKey & myself want the web to have a standard way to encrypt & secure data, ideally that allows for security keys to help do (sign) the encryption. https://github.com/Nitrokey/nitrokey-webcrypt https://github.com/Nitrokey/nitrokey-webcrypt
    - zie 5y ago
      > WebAuthn is about presenting credentials to the server from the security key. The server gets to check our private keys, but the end client (the page) doesn't have any validation or tools at it's own disposal. Clients get to check the servers TLS certs & DNS entries for proof that they are who they say they are. > NitroKey & myself want the web to have a standard way to encrypt & secure data, ideally that allows for security keys to help do (sign) the encryption. https://github.com/Nitrokey/nitrokey-webcrypt https://github.com/Nitrokey/nitrokey-webcrypt OH, so you want a way for the server to encrypt data just for a given client, that they can't read. This doesn't really make a ton of sense. The server has to have the plaintext version to encrypt, which means they have the data un-encrypted before they encrypt it for you. Hence you MUST trust the server with your plaintext data. Since you have to trust them anyway, this doesn't really buy you much. But sure, fine whatever. If people want to play with that, it's fine. Not hugely practical though.
      - rektide 5y ago
        > OH, so you want a way for the server to encrypt data just for a given client, that they can't read. No, we want a way for the client to encrypt data in such a way that the server can't read. Ideally also with MLS capabilities, so we can encrypt data in a way that other people can read, but not any intermediaries. But let's just ignore that for now, because it threatens to inject only more insane chaotic out of control mayhem. Please, make this pain stop. Why does this thread never go anywhere clear & always goes to misinformation? I really don't think Nitrokey made everything crystal clear, but it's far far less confusing than where we are right now after this brand new vast massive tragic & sorrowful retrogression in the discussion, so, > While FIDO is supported by web browsers, using Nitrokey as a secure key store for email and (arbitrary) data encryption requires native software. Therefore email encryption in webmail has not been possible with the Nitrokey until now. At the same time strong end-to-end encryption in web applications all share the same challenge: To store users' private keys securely and conveniently. Therefore secure end-to-end encryption usually requires native software as well (e.g. instant messenger app) or – less secure – store the user keys password-encrypted on servers. Nitrokey aims to solve these issues by developing a way to use Nitrokey with web applications. 100% of my premise is that we should not need to always trust the server we connect to. We should be able to secure data on the client, in a way the server cannot access. Because we should not have to trust all data we access to the servers we connect to. It cannot be more basic & simple than that. But this voice & this perspective has been run off the site by confusion & bedlam that obfuscates & distracts from this simple point. I am so sorry.

by zie 5y ago

rektide 5y ago

This has been useful. It still is wildly off target from what I see as a core weakness with the web, which is that security keys cant be used to help a client create secure data. We can only authenticate ourselves with keys, not protect ourselves. The server we are talking to has more favor than us. Introducing the term e2e was a mistake, & mislead everything. TLS isnt really a factor. It was frustrating being so very very far off course from the relevant problem. But I certainly didnt handle this drift well at all & was frustrated at being so off topic from such a vital & core web weakness.

zie 5y ago
> The server we are talking to has more favor than us. Well, now I'm not sure what you are talking about, can you give a concrete example?
- rektide 5y ago
  WebAuthn is about presenting credentials to the server from the security key. The server gets to check our private keys, but the end client (the page) doesn't have any validation or tools at it's own disposal. NitroKey & myself want the web to have a standard way to encrypt & secure data, ideally that allows for security keys to help do (sign) the encryption. https://github.com/Nitrokey/nitrokey-webcrypt https://github.com/Nitrokey/nitrokey-webcrypt
  - zie 5y ago
    > WebAuthn is about presenting credentials to the server from the security key. The server gets to check our private keys, but the end client (the page) doesn't have any validation or tools at it's own disposal. Clients get to check the servers TLS certs & DNS entries for proof that they are who they say they are. > NitroKey & myself want the web to have a standard way to encrypt & secure data, ideally that allows for security keys to help do (sign) the encryption. https://github.com/Nitrokey/nitrokey-webcrypt https://github.com/Nitrokey/nitrokey-webcrypt OH, so you want a way for the server to encrypt data just for a given client, that they can't read. This doesn't really make a ton of sense. The server has to have the plaintext version to encrypt, which means they have the data un-encrypted before they encrypt it for you. Hence you MUST trust the server with your plaintext data. Since you have to trust them anyway, this doesn't really buy you much. But sure, fine whatever. If people want to play with that, it's fine. Not hugely practical though.
    - rektide 5y ago
      > OH, so you want a way for the server to encrypt data just for a given client, that they can't read. No, we want a way for the client to encrypt data in such a way that the server can't read. Ideally also with MLS capabilities, so we can encrypt data in a way that other people can read, but not any intermediaries. But let's just ignore that for now, because it threatens to inject only more insane chaotic out of control mayhem. Please, make this pain stop. Why does this thread never go anywhere clear & always goes to misinformation? I really don't think Nitrokey made everything crystal clear, but it's far far less confusing than where we are right now after this brand new vast massive tragic & sorrowful retrogression in the discussion, so, > While FIDO is supported by web browsers, using Nitrokey as a secure key store for email and (arbitrary) data encryption requires native software. Therefore email encryption in webmail has not been possible with the Nitrokey until now. At the same time strong end-to-end encryption in web applications all share the same challenge: To store users' private keys securely and conveniently. Therefore secure end-to-end encryption usually requires native software as well (e.g. instant messenger app) or – less secure – store the user keys password-encrypted on servers. Nitrokey aims to solve these issues by developing a way to use Nitrokey with web applications. 100% of my premise is that we should not need to always trust the server we connect to. We should be able to secure data on the client, in a way the server cannot access. Because we should not have to trust all data we access to the servers we connect to. It cannot be more basic & simple than that. But this voice & this perspective has been run off the site by confusion & bedlam that obfuscates & distracts from this simple point. I am so sorry.