TLS setup

[ala-mode]

Different feature branch name, same code as #10 - closed because of issues migrating github repo from private to public which broke our forked personal github repos.

I'll also copy-paste the comments from #10 here.

[ala-mode]

To generate self-signed keys, open /self_signed_certs/ in a terminal and use
openssl req -newkey rsa:4096 -x509 -sha512 -days 500 -nodes -out cert.pem -keyout key.pem

Running locally, a text-file is retrieved with a browser navigating to https://127.0.0.1:3953/getme and using wget --https-only --no-check-certificate https://127.0.0.1:3953/getme

No testing with nc to this point.

[ala-mode]

to clarify the above cli invocation openssl req -newkey rsa:4096 -x509 -sha512 -days 500 -nodes -out cert.pem -keyout key.pem

req requests a keypair
-newkey rsa:4096 create an RSA key of 4096 bits
-x509 binds an identity to a public key using a digital signature, in this case it will be self-signed. at the prompts, the user can input any information they choose.
-sha512 specifies the message digest to sign the certificate
-days 500 specifies for how long the certificate is valid
-nodes we don’t want to encrypt the generated private key
-out cert.pem -keyout key.pem naming the certificate and the key that are outputted

[ala-mode]

Fixes #9.

[ala-mode]

you can also inspect the handshake of the TLS connecting with curl --insecure -vvI https://127.0.0.1:3953/getme 2>&1 while the server is running.

[ala-mode]

Latest commit is a merge commit, largely modified from previous dev branch with tracing.

Now, there is TLS support + tracing.

Tracing is not using tokio::net::TcpListener any longer, instead assigning the Router (app) a layer with TraceLayer::new_for_http().

also updated README.

using curl --insecure -vvI https://127.0.0.1:3953/getme 2>&1

I see:

* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=MN; ST=Outback; O=Zingolabs; OU=Autonomous Squad 0x1F`

on the client side, and

[timestamp] DEBUG request{method=HEAD uri=https://127.0.0.1:3953/getme version=HTTP/2.0}: tower_http::trace::on_request: started processing request
[timestamp] DEBUG request{method=HEAD uri=https://127.0.0.1:3953/getme version=HTTP/2.0}: tower_http::trace::on_response: finished processing request latency=0 ms status=200

on the server side.

[nachog00]

I noticed that logs by tracing are spitting the whole app before logging the intended message.
I haven't pinpointed where that behavior comes from (might be tracing's default?).
It seems a bit cluttering to me, but I wouldn't block this PR on that anyways.

@ala-mode Do you agree on changing that or is there any big pro of having it that way that I'm missing? Maybe we would like to cap it to DEBUG level logs only?

Besides that, this PR seems fine to me.

[ala-mode]

I noticed that logs by tracing are spitting the whole app before logging the intended message. I haven't pinpointed where that behavior comes from (might be tracing's default?). It seems a bit cluttering to me, but I wouldn't block this PR on that anyways.

@ala-mode Do you agree on changing that or is there any big pro of having it that way that I'm missing? Maybe we would like to cap it to DEBUG level logs only?

Besides that, this PR seems fine to me.

Thanks! I don't remember the particulars of the tracing. If we can find a way to streamline, I think that would be great. Because this has been merged, I suggest you open an issue with any details you know right now or fill find out, or just that it's a topic at all, so that we can remember to look into this.