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

Add a transport library. #358

Merged
merged 18 commits into from
Nov 3, 2015
Merged

Add a transport library. #358

merged 18 commits into from
Nov 3, 2015

Conversation

kisom
Copy link
Contributor

@kisom kisom commented Oct 1, 2015

The transport library provides tools for building TLS-secured client
and server connections. It is designed to minimise the number of knobs
and switches that are presented to end users, and supports features
such as auto-updating of certificates.

}

hosts := make([]string, 0, len(csr.DNSNames)+len(csr.IPAddresses))
for i := range csr.DNSNames {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

copy(hosts, csr.DNSNames)

@0xhaven
Copy link
Contributor

0xhaven commented Oct 5, 2015

It's possible this should be under cfssl/helpers/transport

t.Fatal("key provider shouldn't have a key yet")
}

err = kp.Generate("ecdsa", 256)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For better test coverage you could add a test for Generate with "rsa" as well

@0xhaven
Copy link
Contributor

0xhaven commented Oct 21, 2015

Rebase off master to fix CI issues...


// Dial initiates a TLS connection to an outbound server. It returns a
// TLS connection to the server.
func Dial(address string, tr *Transport) (*tls.Conn, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not:

func (tr *Transport) Dial(address string) (*tls.Conn, error)

Copy link
Contributor Author

@kisom kisom Oct 27, 2015 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kisom and others added 11 commits October 27, 2015 14:28
The transport library provides tools for building TLS-secured client
and server connections. It is designed to minimise the number of knobs
and switches that are presented to end users, and supports features
such as auto-updating of certificates.
The SHA384 GCM ciphersuites aren't supported in Go 1.4; instead of
having version-specified suites, include them as manually-specified
suites. The TLS package won't send ciphersuites it doesn't actually
support, and there is no compile-time generation of the ciphersuite
list.
TrustStore provides a mechanism for obtaining trusted roots. By default,
it will use the system roots; otherwise, it will attempt to load
certificates from a set of specified roots.
This commit simplifies the listener structure, and ensures that it
satisfies the net.Listener interface.
* Move common functions to an example library.
* Various clean ups: splitting things into separate functions and making
  it easier to extend the examples later.
* Client sends a few messages this time, and the server will acknowledge
  them. In the future, a more extensive example might be useful.
This README explains how to bootstrap a CFSSL for use in the examples,
how to run the server, and how to run the clients.
Add configurations to demonstrate the case where the remote CFSSL
requires authentication.
This is mostly commentary adjustments via
https://travis-ci.org/cloudflare/cfssl/jobs/87769654.
@@ -0,0 +1,16 @@
// Package ca provides the CertificateAuthority interface for the
// transport package, which provide an interface to get a CSR signed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*provides

* Remove unused core/config.go file. Users should just use the `Dial`
  and `Listen` functions in the `transport` package.
* Fix spelling and grammar issues.
* Clean up formatting on JSON file.
var ErrNoAuth = errors.New("transport: authentication is required for non-local remotes")

var v4Loopback = net.IPNet{
IP: net.IP{127, 0, 0, 1},
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Threw me for a second. Maybe make it net.IP{127, 0, 0, 0}?

kisom added 3 commits October 29, 2015 13:03
* Notation change in specifying local IPv4 network.
* Explicitly mark AutoUpdate channels as write-only.
* Add a recovery and associated critical log message in the event an
  autoupdate goroutine panics.
* Use "client" as the profile name for consistency with the
  authenticated version.
* Add an error channel to server to demonstrate its use.
This was requested by @jkroll. Also adds package documentation.
// New builds a new transport from an identity and a before time. The
// before time tells the transport how long before the certificate
// expires to start attempting to update when auto-updating.
func New(before time.Duration, identity *core.Identity) (*Transport, error) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if before > lifetime of a freshly issued cert?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the auto updater is running, every time it checks the time (e.g. every PollInterval seconds) it will request a new certificate.

@lmb
Copy link

lmb commented Oct 29, 2015

Questions on certificate rollover, all in the context of very long running connections:

  • Does a server have to react to an updated cert by resetting connections?
  • Does a client have to AutoUpdate?
  • If yes, should a client restart connections as well on a new certificate?

Otherwise a pleasure to read!

@grittygrease
Copy link
Contributor

Re: certificate rollover questions, the certificate is only used at the establishment of a connection so long-running connections can have the certificate swapped out from under them with no danger. Clients should auto-update when their certificate is close to expiration. The same logic applies, no restart needed.

Question #1:
"What happens if before > lifetime of a freshly issued cert?"

Question #2:
"Questions on certificate rollover, all in the context of very long
running connections:

* Does a server have to react to an updated cert by resetting
  connections?
* Does a client have to AutoUpdate?
* If yes, should a client restart connections as well on a new
  certificate?"

Rekey was renamed to RefreshKeys, and the documentation now reflects this.
@kisom
Copy link
Contributor Author

kisom commented Oct 29, 2015

@lmb Answered these questions in the latest commit (so that they're also in the documentation now), but the gist is:

  • If AutoUpdate is running, no additional actions have to be taken. Existing connections are fine, new connections will use the new certificate.
  • Clients don't need AutoUpdate if they're only making a single connection, but otherwise they should run it.
  • If before > the issuance life time of a certificate, every time an update check is done, the package will request a new certificate.

@grittygrease
Copy link
Contributor

Looks good to merge.

@lziest
Copy link
Contributor

lziest commented Nov 2, 2015

LGTM

errChan <- err
}

<-time.After(5 * time.Minute)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exponential back-off?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ashishgandhi
Copy link

👍

grittygrease added a commit that referenced this pull request Nov 3, 2015
@grittygrease grittygrease merged commit f0a7d05 into master Nov 3, 2015
@0xhaven 0xhaven deleted the kyle/transport branch November 10, 2015 22:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants