4 ms·

this feels like yet more inordinately & vastly incorrect obvious hogwash. how is tls end to end? it's literally you to your immediate service: it will never eve

this feels like yet more inordinately & vastly incorrect obvious hogwash. how is tls end to end? it's literally you to your immediate service: it will never ever be end to end by definition. could it be any more obvious? why does such an obviously irrelevamt non-sequitor keep showing up? if the server you are talking with can decrypt it, it means it's not a secure channel. definitional, inarguable, basic. how can are all the replies so wrong? what is this conspiracy against reason? what definition of e2e encryption are you using, when i communicate with my friend, and how does it accomodate this twisted ass warped "google can so read my messages" flagrantly incorrect viciously wrong misinformation view that merely having singleink tls security that you & other dude argue for? why is everyone so up on being immoral & misleading & wrong here about end-to-end encryptiom? it secures a connection. but data going from party to party traverses multiple parties. end to end encryption, by definition, is not encryption between you & the service: it's between you & the other party. intensely fantastically stupidly wrong & insistent argumentation keeps happening. i keep getting downvoted, ya'll keep making wrong posts with way off base claims. so sad. hopeless universe. again, folks lole nitrokey saw exactly this weakness, this inability for current web crypto standards tk ever help secure user data from the services they connected to, something tls cannot ever help with. but ya'll keep focusing.on the tiniestost irrelevant hop of data, keep insisting one leg of encrytion is equal to end to end. no.

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.

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.