Steward issues certificates for keeps not running in TEEs

[rvolosatovs]

Currently it's possible to receive a Steward certificate from a keep running even on a nil backend, that should not happen, since the certificate grants access to all artifacts in Drawbridge.

Proof:

$ enarx deploy --backend nil rvolosatovs:tls-server:0.1.0
Using preopened socket FD 3
You can connect to the server using `nc`:
 $ nc <IP> <PORT>
You'll see our welcome message and anything you type will be printed here.
Accepted connection from: 0.0.0.0:0
Received data: pwned
Connection closed

And from another terminal:

$ echo pwned | openssl s_client -showcerts -connect localhost:9000
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 C = US, ST = North Carolina, L = Raleigh, CN = Proof of Concept
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=1 C = US, ST = North Carolina, L = Raleigh, CN = Proof of Concept
verify return:1
depth=0 
verify error:num=7:certificate signature failure
verify return:1
depth=0 
verify return:1
---
Certificate chain
 0 s:
   i:C = US, ST = North Carolina, L = Raleigh, CN = Proof of Concept
-----BEGIN CERTIFICATE-----
MIIBqTCCAVCgAwIBAgIQV0eMZ7eXTI+aJDlA/XAdJTAKBggqhkjOPQQDAjBTMQsw
CQYDVQQGEwJVUzEXMBUGA1UECAwOTm9ydGggQ2Fyb2xpbmExEDAOBgNVBAcMB1Jh
bGVpZ2gxGTAXBgNVBAMMEFByb29mIG9mIENvbmNlcHQwIhgPMjAyMjA3MTIxMzQ1
MDVaGA8yMDIyMDgwOTEzNDUwNVowADBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IA
BG71DhtYIDLV9YmXJvwrDPMLQjlfQ3C5kfa1xkjaMIufgixfaYN0odC/lOkU9fJx
x/MbVkBeF8eNHR8TDan1wV6jVTBTMA4GCisGAQQBg8ceAQEEADAiBgNVHREEGzAZ
ghdmb28uYmFyLmh1Yi5wcm9maWFuLmNvbTAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwCgYIKoZIzj0EAwIDRwAwRAIgKY4oBf2qZwb4c/CzXBTvIqzVot8H
nTr7kz356Dsof9cCIFOvF7lA0uBvJSZgLCIZvKGNODAvrQe93S+a/usYDElP
-----END CERTIFICATE-----
 1 s:C = US, ST = North Carolina, L = Raleigh, CN = Proof of Concept
   i:C = US, ST = North Carolina, L = Raleigh, CN = Proof of Concept
-----BEGIN CERTIFICATE-----
MIICITCCAcigAwIBAgIUbEloiHhyUp9fPD3R777hHFgMSnwwCgYIKoZIzj0EAwIw
UzELMAkGA1UEBhMCVVMxFzAVBgNVBAgMDk5vcnRoIENhcm9saW5hMRAwDgYDVQQH
DAdSYWxlaWdoMRkwFwYDVQQDDBBQcm9vZiBvZiBDb25jZXB0MB4XDTIyMDcwNTE3
MTIyM1oXDTIyMDgwNDE3MTIyM1owUzELMAkGA1UEBhMCVVMxFzAVBgNVBAgMDk5v
cnRoIENhcm9saW5hMRAwDgYDVQQHDAdSYWxlaWdoMRkwFwYDVQQDDBBQcm9vZiBv
ZiBDb25jZXB0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1/pjBNy26Lxd7MtP
ELRzppdhnTrvSgh8hBDQ3cWN5ljP2AOyUuQzAt5BqBpuNlrXamVjeHitphkuigFB
uhOSeqN6MHgwDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYwOQYJYIZIAYb4
QgENBCwWKlByb2ZpYW4gYXR0ZXN0YXRpb24gc2VydmljZSBDQSBjZXJ0aWZpY2F0
ZTAdBgNVHQ4EFgQU0ySz74UrsmTLt3WtQmGpdUUbxTIwCgYIKoZIzj0EAwIDRwAw
RAIgLMOHEaOY/m9xmU1XwnnMcBJ4PnWcNJlQXcnQaNd1u7YCIB19lAc+xNWot2cu
DIZBa5YpkMkPSbiG8V7OEPpuymCX
-----END CERTIFICATE-----
---
Server certificate
subject=

issuer=C = US, ST = North Carolina, L = Raleigh, CN = Proof of Concept

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1354 bytes and written 373 bytes
Verification error: certificate signature failure
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 7 (certificate signature failure)
---
DONE

Enarx.toml:

steward = "https://attest.profian.com"

[[files]]
kind = "stdin"

[[files]]
kind = "stdout"

[[files]]
kind = "stderr"

[[files]]
kind = "listen"
prot = "tls"
port = 9000
name = "TEST_TCP_LISTEN"

[platten]

@npmccallum @definitelynobody @rjzak @rvolosatovs This warrants a discussion.

[rvolosatovs]

https://github.com/profianinc/steward/blob/692ac758eb1ae4a19e32821e4fdc208d73f48cdc/src/main.rs#L275-L281

The culprit is here

IMO KVM branch should be guarded by #[cfg(test)] or an --insecure/--debug flag to the binary
dbg parameters should also be removed.
For SNP we can already do that, but for SGX we should first fill in the missing fields here https://github.com/profianinc/steward/blob/692ac758eb1ae4a19e32821e4fdc208d73f48cdc/src/ext/sgx/mod.rs#L92-L118
@jarkkojs perhaps you can assist @rjzak here?