Get TLS information from the client

Question

The net/http go package has a type request that defines a field TLS holding the ConnectionState. Although, the last statement from the description says it's ignored by the HTTP client. I also checked that while debugging and it is nil.

I need to get the value TLSUnique from that connection state (or somewhere else), so that I can include it in my certificate request, aka CSR, before I can enroll/send it to the server.
The server is out of scope of my question. My concern is about the client.

Then the server receives the request and would check the signature of the CSR along with TLS-unique value, proving that the same client with whom the TLS connection has been established with, is the same who signed the CSR.

This is something that comes from the RFC 7030 - section 3.5 (EST protocol)

[What I'm using]
I'm experimenting the GlobalSign EST Go package, and they don't seem to include this functionality.

Their EST-client seems to create an http client for every EST operation, I thought I could change that behavior and have one client from which we send all requests.
However, since the client accepts a RoundTripper interface, i can't use information of the underlying connection outside of the implementation.

Answer 1

One way of doing it requires a small change from the global sign EST package.

Like I said earlier, the current implementation creates a new http client for every EST operation (CACerts, CSRAttrs, Enroll etc.)

1- Let's have one http client for all EST operations.
2- Either way, we're gonna need to make a call to get the CA certificates before enrolling a CSR.
3- The http response to any client request exposes the field http.Response.TLS.TLSUnique.
4- Let the client inlcude it in the certificate request, sign it and enroll it.

I'm not sure if there are any security concerns with this when I think about the global sign EST package and why they chose to create a new http client every time.
(unless it's just examples waiting to be used according to the user's will)

Answer 2

Heads-up: in the comment thread under this answer, it became clear the OP was rather after getting the "TLS unique" value while making client requests. For that, please see my other answer or the OP's solution.
I have decided to keep this very answer for reference as it showcases a useful technique.

---

Instantiate your http.Server, and then set its field ConnContext to some function which you will need to write.

That function gets called once per each new TCP connection created by a client to your server (one connection is able to serve multiple requests). When called, it receives the net.Conn which is serving the client's request, so you can type-assert it as tls.Conn, then call ConnectionState on it and inspect TLSUnique in the returned value.

Since you probably need to make this value available to HTTP requests carried out over that connection, the arguably most sensible solution for this is to stash that thing as "a value" in the context which will be available via the http.Requests in the code of the handlers.

To do that, in the same callback code, you "wrap" the original context.Context associated with the request, and passed to the callback, with some value extracted from that TLSUnique, so that you can then inspect it in the HTTP handler which is to serve the request.

Something like this (untested):

srv := &http.Server{
  ConnContext: func(ctx context.Context, c net.Conn) context.Context {
    tc := c.(*tls.Conn)

    return context.WithValue(ctx, mypkg.MyKey,
      tc.ConnectionState().TLSUnique)
  },
  // other fields, if needed
}

// ... then, in HTTP request handlers:

func MyHTTPReqHandler(rw http.ResponseWriter, req *http.Request) {
  uniq := req.Context().Value(mypkg.MyKey)
  // verify it's not nil and use
}

Check the docs on context.Context.Value to figure out how to declare mypkg.MyKey.

You might also need to actually copy the value of TLSUique at the point of its extraction–I have no idea whether that's needed.

Answer 3

OK, based on the comment thread under my other answer, here's how I would go about implementing the client side:

package main

import (
    "bytes"
    "context"
    "crypto/tls"
    "errors"
    "io"
    "log"
    "net/http"
    "net/http/httptrace"
)

type csrParams struct{}

type csrLazyBody struct {
    ctx    context.Context
    params csrParams

    constructed bool
    data        bytes.Buffer
}

func newCSRLazyBody(ctx context.Context, params csrParams) *csrLazyBody {
    return &csrLazyBody{
        ctx:    ctx,
        params: params,
    }
}

func (b *csrLazyBody) Read(p []byte) (int, error) {
    if !b.constructed {
        if err := b.construct(); err != nil {
            return 0, err
        }

        b.constructed = true
    }

    return b.data.Read(p)
}

func (b *csrLazyBody) Close() error {
    return nil
}

func (b *csrLazyBody) construct() error {
    switch uniqPtr := b.ctx.Value(tlsUniqKey).(type) {
    case nil:
        return errors.New("missing TLS unique value")
    case *[]byte:
        _, err := b.data.Write(*uniqPtr)
        return err
    default:
        panic("cannot happen")
    }
}

var _ io.ReadCloser = &csrLazyBody{}

type tlsUniqKeyType int

const tlsUniqKey = tlsUniqKeyType(0)

func newCSR(method, url string, params csrParams) (*http.Request, error) {
    uniqPtr := new([]byte)

    ctx := context.WithValue(context.Background(),
        tlsUniqKey, uniqPtr)

    trace := &httptrace.ClientTrace{
        GotConn: func(connInfo httptrace.GotConnInfo) {
            conn := connInfo.Conn

            tc, ok := conn.(*tls.Conn)
            if !ok {
                return
            }

            uniq := tc.ConnectionState().TLSUnique

            *uniqPtr = uniq
        },
    }

    return http.NewRequestWithContext(
        httptrace.WithClientTrace(ctx, trace),
        method, url, newCSRLazyBody(ctx, params))
}

func main() {
    log.SetFlags(0)

    req, err := newCSR("GET", "https://csa.acme.com/api/enroll", csrParams{})
    if err != nil {
        log.Fatal(err)
    }

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        log.Fatal(err)
    }

    defer resp.Body.Close()
}

Key points:

• The function to create HTTP requests transporting CSRs to the enrollment service (I assume that's what needed), newCSR, creates a new http.Request which:

  • Is armed with a context.Context which:

    • Has a special "tracing" facility attached to it (see below).
    • Carries a "value" which is a pointer to a slice to contain the "TLS unique" value to be attached.

  • Contains the request body in the form of a variabe of a special type which initializes itself once the Read method is called on it for the first time.

    This variabe shares the context.Context with the HTTP tracer.

• The HTTP tracer's "got conn" callback is called when an http.Transport in use obtains a connection to carry out the request being traced by any means. This includes new connections or connections pulled from the pool of idle (reused) connections.

  If the connection is a tls.Conn, the callback's code extracts the "TLS unique" value from it and saves it to the variable a pointer to which is stashed in the context.

• Some time later the http.Transport which round-trips the request begins to read the request's body, and that's where the "lazy body construction" kicks in: it reads the pointer to the variable containing the "TLS unique" data obtained by the tracer and uses it to construct the actual CSR data, which is then read "the normal way".

---

The code is convoluted, but on the flipside it works with with any settings of the underlying http.Transport—with connection pooling being the major point of interest.

Of course, if you precisely know the requirements for your setup, this approach can easily be an overkill. For instance, if you know or require that no pooling should ever be used, it's possible to go an easier route, say:

• Use the tls package directly to create a tls.Conn, save it somewhere, and also save the "TLS unique" data extracted from it.

• Use a custom http.Transport which:

  • Has its DialTLSWithContext field set to a callback which merely returns that saved connection.
  • Has HTTP keepalives and idle connections disabled.
  • Maybe is wrapped in an http.RoundTripper which ensures only a single RoundTrip call is active at any given time.