HTTPS support for the Agama web server

[lslezak]

Problem

• The communication between the user and the Agama web server needs to be encrypted

Solution

• Enable HTTPS support using the standard openSSL library
• Automatically redirect all external HTTP requests to HTTPS
• Allow using HTTP locally (http://localhost)
• Use the SSL certificate specified from the command line or generate a self-signed one

Testing

• Tested manually

TODO

• Update the documentation

For later:

• Use the gethostname crate and include the current host name in the generated self-signed certificate
• Read the SSL certificate from some default location (something like /etc/agama.d/ssl/{certificate,key}.pem ?)
• Implement struct for handling key / certificate and associate it with relevant methods

[coveralls]

coverage: 74.222% (-0.3%) from 74.566%
when pulling d3870eb on https_support
into 8946391 on master.

[imobachgs]

First of all, congrats for your first Rust contribution! Great work :-)

I have added a few comments, and I would like to have a closer look at the start_server as it is quite complex.

[imobachgs]

Prefer &str to &String because it is more versatile.

[imobachgs]

Anyway, I would consider keeping both arguments together as part of the same thing:

struct Certificate { // well, I suck at naming...
  content: String,
  key: String
}

impl Certificate {
  pub read(cert: &str, key: &str) -> Result<Self>;
  pub new() -> Self; // generates the content
}

Then you can use the same code:

tls_builder.set_certificate(crt.content.as_ref());
tls_builder.set_private_key(crt.key.as_ref());

And as a bonus, you could test the certificate creation in isolation (without having anything to do with the acceptor).

[imobachgs]

This code could be part of the Certificate struct I mentioned before.

[imobachgs]

I did some tests, and this change seems to break the WebSocket support. At least websocat does not work (I tried ws and wss). It works :-)

[jreidinger]

so basically we create certificate that is valid from today for a next year. Question is are we sure we have correct date in agama? if not, then it can be issue with remote browser, that will have different date.

[lslezak]

Ah, good point. On the other hand the certificate is self-signed so the browser will complain anyway. Wrong date will make the problem just a little bit more serious. 😄

[lslezak]

We could use something like

// Jan 1 1970 00:00 UTC
let not_before = Asn1Time::from_unix(0)?;
// Jan 1 2040 00:00 UTC 
let not_after = Asn1Time::from_str_x509("20400101000000Z")?;

This would cover bigger range.

Anyway, I guess this will be reviewed by the security team later so this might change...

[lslezak]

Uh, wrong date would even make troubles connecting to other remote https resources like SCC. As a solution we should probably run NTP synchronization on the Live ISO...

[imobachgs]

I did some tests, and this change seems to break the WebSocket support. At least websocat does not work (I tried ws and wss).

That's not true, it works just fine 😅

[imobachgs]

Just a few comments. It is looking better now.

[imobachgs]

There is no need to change it now (time pressure), but it is weird that ServeArgs is responsible for creating the SSL acceptor.

[lslezak]

If the server listens on two ports then it would be a good idea to use the same generated self-signed certificate on both ports. So the SSL acceptor needs to be created early. I added a TODO mark.