Where is the TLSConfig set for Enclave's http.Server?

Hello!

I want to mention that I loved your paper and this repo because you have put in a lot of work making Nitro Enclaves more accessible!

I have been auditing the code (before using it myself), and I'm wondering why the enclave's private server e.privSrv is using an HTTP connection while the enclave's public server e.pubSrv is using an HTTPS connection.

https://github.com/brave/nitriding/blob/07bc8d73bbfe4a278ffa20dc786cf9ff39f49f02/enclave.go#L267

// startWebServers starts both our public-facing and our enclave-internal Web
// server in a goroutine.
func startWebServers(e *Enclave) error {
    elog.Printf("Starting public (%s) and private (%s) Web server.", e.pubSrv.Addr, e.privSrv.Addr)

    go e.privSrv.ListenAndServe() //nolint:errcheck
    go func() {
        // If desired, don't launch our Internet-facing Web server until the
        // application signalled that it's ready.
        if e.cfg.WaitForApp {
            <-e.ready
            elog.Println("Application signalled that it's ready.  Starting public Web server.")
        }
        e.pubSrv.ListenAndServeTLS("", "") //nolint:errcheck
    }()

    return nil
}

From my understanding of the paper, the TLS connection is between the user and the enclave. The EC2 host should not be able to "man-in-the-middle" the conversation. So why are the TLS certificates only set for e.pubSrv https://github.com/brave/nitriding/blob/07bc8d73bbfe4a278ffa20dc786cf9ff39f49f02/enclave.go#L346?

I have a hunch that e.pubSrv is actually the HTTPS server that is inside the enclave because it has the attestationHandler registered on it https://github.com/brave/nitriding/blob/07bc8d73bbfe4a278ffa20dc786cf9ff39f49f02/enclave.go#L195. Digging into the function, this handler calls the hypervisor to generate an attestation document (which I believe means it must be in the enclave) https://github.com/brave/nitriding/blob/master/attestation.go#L153.

It would be a great help if you could help me understand where I can find 1) The HTTP server that is blindly forwarding encrypted bytes to the enclave and 2) which is the server within the enclave

Thank you again for your work and for reading this!

Hey Curtis, thanks for taking a look at our code!

I'm afraid that the paper may have misled you a bit because nitriding's network architecture has evolved while we haven't updated our paper yet. The paper talks about nitriding as a Go package that provides a SOCKS proxy. This is no longer accurate. We have since improved nitriding and it's now a stand-alone executable that transparently tunnels all network traffic via a tap interface, just like a VPN does. That said, let me answer your questions:

I have been auditing the code (before using it myself), and I'm wondering why the enclave's private server e.privSrv is using an HTTP connection while the enclave's public server e.pubSrv is using an HTTPS connection.

The private Web server is only accessible to the enclave application, which is a separate process that runs alongside nitriding. Nobody can spy on the enclave application talking to this Web server, so there's no need for HTTPS. It's a trusted communication channel.

The public Web server is exposed to the Internet and, among other things, provides the attestation handler. The EC2 host is able to intercept traffic to this Web server and it therefore only answers via HTTPS.

I have a hunch that e.pubSrv is actually the HTTPS server that is inside the enclave because it has the attestationHandler registered on it

That's right. Here are the publicly-reachable endpoints that this Web server supports. If your enclave application also provides an HTTP API, you can configure nitriding's public Web server to also act as a reverse proxy, and forward user requests to your enclave application.

The HTTP server that is blindly forwarding encrypted bytes to the enclave and

That's e.pubSrv if (and only if) it's configured as a reverse proxy. Otherwise, your enclave application can receive user data "directly", without nitriding intervening, by exposing a separate port inside the enclave. In that case, you'll have to tell gvproxy (the untrusted proxy application running on the EC2 host) to forward your custom port.

which is the server within the enclave

That's the enclave application developed by you. It's a separate process that runs in parallel to nitriding. If you want this enclave application to speak HTTP, you can tell nitriding to act as a reverse proxy. Otherwise, you can receive user data "directly" as mentioned above.

I hope this makes more sense? Consider taking a look at the architectural diagram — it hopefully helps with understanding how all these pieces fit together.

Ahhh this makes so much sense now. Thank you so much for the detailed response Philipp!

brave / nitriding

Where is the TLSConfig set for Enclave's http.Server? #56