TLS server/client

[haerdib]

We have two options to open a tls ws connection from the enclave to outside (and vice versa):

1. Open the socket entirely within the enclave. This if most likely the most secure option. However, we can not spawn new threads to process the messages. Examples can be found here for the server and the client.

2. We open up the TCP connection and do the mio polling of the stream outside of the enclave. This way we can spawn a new thread whenever a message is received. The ws handshake handling (TLS cipher suite decision, authentication (SSL certificate) and key generation) will be done within the enclave. Therefore, even though the worker is in charge of forwarding the messages (from and to the enclave), it can not decipher it.. a necessary man in the middle so to say. I have not yet tested the thread spawning but I will do so next week.
   A relatively poorly documented example can be found here:

   • enclave client part
   • worker client part
   • the server works in a similar way, see this example

I've tried to do a better job with the documentation, though I'm pretty sure the quality decreased over time:

• tcp client: worker part
• The enclave counter part can be found here but do not take this as a reference - its a poorly programmed ws client not using tls. It will eventually be replaced by the TLS client.

If we go with option 2, we should probably provide some kind of interface or template for future implementations.. it's not really trivial to implement and uses up to 5 (?) different ecalls.

[haerdib]

Linking related issues: #61 as well as #281

[brenzi]

It seems to me that (2) is the only option that allows the architecture we're envisioning because we need multithreaded rpc to get the throughput we're aiming for

[brenzi]

can we close this in favor of #352?

[murerfel]

Imho this can be closed, yes - the decision has been made, and the work needed is described in #352