Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of TLS #267

Open
jaysoncena opened this issue Jan 30, 2020 · 4 comments
Open

Implementation of TLS #267

jaysoncena opened this issue Jan 30, 2020 · 4 comments
Assignees
Labels
question Further information is requested

Comments

@jaysoncena
Copy link

Is there any existing implementation of TLS? Our current infrastructure uses CA auth and I would like to use the same. Is there any example on how to do that? If there isn't, can anyone point me where to start on implementing a plugin for TLS?

@iwasaki-kenta
Copy link
Contributor

Is there a mandatory requirement for full TLS? Noise strictly only supports the following handshake protocol:

Nodes have ephemeral Ed25519 keys established. To communicate with each other, they:

  1. send each other their ephemeral Ed25519 public keys,
  2. convert the public keys they received into Curve25519 public keys,
  3. convert their ephemeral Ed25519 private keys into Curve25519 private keys,
  4. establish a shared secret by performing ECDH (noise.ECDH; Elliptic-Curve Diffie Hellman) by feeding in their private Curve25519 private key and their peers Curve25519 public key,
  5. use the shared secret as an AES 256-bit GCM symmetric key,
  6. communicate from then-on with messages encrypted/decrypted via. AES 256-bit GCM.

The handshake overall is very much similar to TLS v1.3 but is simpler and more straightforward.

Should you have the need to implement a custom handshake, it would for the time being require forking the repository and modifying a single function here.

Happy to assist should this be the case.

@iwasaki-kenta iwasaki-kenta self-assigned this Jan 30, 2020
@iwasaki-kenta iwasaki-kenta added the question Further information is requested label Jan 30, 2020
@jaysoncena
Copy link
Author

Unfortunately, it is a requirement to use CA cert to validate peer client cert.

If there's no straightforward way, I'll probably use tls.Conn in place of net.TCPConn and tls.Listen in place of net.Listen

Aside from deriving shared secret and the encryption provided by default, do you have any other tips?

@iwasaki-kenta
Copy link
Contributor

iwasaki-kenta commented Jan 30, 2020

Unfortunately, it is a requirement to use CA cert to validate peer client cert.

If there's no straightforward way, I'll probably use tls.Conn in place of net.TCPConn and tls.Listen in place of net.Listen

Aside from deriving shared secret and the encryption provided by default, do you have any other tips?

tls.Client and tls.Server may also be used and plugged in directly in (*Client).handshake().

In pseudocode, it would resemble:

if c.side == clientSideInbound {
 conn := tls.Server(c.conn, &tls.Config{...})
 if err := conn.Handshake(); err != nil { return err }
} else {
 conn := tls.Client(c.conn, &tls.Config{...})
 if err := conn.Handshake(); err != nil { return err }
}

To help support these types of use cases, in the next patch I'll make it a medium priority to provide options to allow for disabling the default handshake + session encryption/decryption, and to optionally provide your own customary handshake function that will be injected into (*Client).handshake().

For the time being, please do keep me posted on how your TLS implementation goes :) It will help when it comes the time I work on a PR to make these options available.

@jaysoncena
Copy link
Author

Thanks for the feedback, that really helps.

Will definitely keep you posted. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants