adding https?

[DFF-fred]

http is ran using Tiwsted. I looked briefly but didn't find any specific file to point to SSL certificates. Any direction to achieve that?
Thank you.

[jayjb]

Hi @DFF-fred,

We don't currently support it on our OpenCanary version. It is a reasonable request so ill bubble it up and see if we can get it sorted.

[DFF-fred]

Thank you very much!

[weslambert]

I too, would love to have HTTPS as a supported option. Are there any plans for this to be included in the near future?

Thanks!

[HybridAU]

I'm happy to look at this one, I've got work and family commitments so it will probably take a month or two before I have a PR ready, but I'll see what I can do.

I've got some initial thoughts though that I think are worth discussing before writing any code; in episode 665 of risky business (at 52 minutes) Haroon Meer was talking about how vendors have to make choices and pick sensible defaults rather than providing the user with 1001 knobs to twiddle to tune a service. I think he was right on the money there, but that's something that makes HTTPS hard. We must make a bunch of decisions for the user.

My first thought is that we should have valid certificates, but that's hard because we need at minimum a domain name, DNS entry and some way of getting valid certificates on to the OpenCanary. Let's encrypt makes getting certificates easy if you're on the internet, but if you are on an internal network (I would assume almost all OpenCanaries are), you can still generate certificates but you need to be able to create TXT records. This means different DNS providers, DNS Made Easy, Amazon Route 53, Azure DNS and so on will all need their own instructions and will require a fair amount of setup by users.

The alternative, that would be a lot easier, is self-signed certificates. We could look for certificates in a specific location on startup, if they exist, we use them, otherwise we generate a self-signed one. This way advanced users can manage their own if they want, and regular users can just start up an OpenCanary and get something that works.

The next question is, if we do generate self-signed certificates, what should we use for the subject name etc? opencanary.local might be a bit of a giveaway 😝. I've got a Ubiquity EdgeRouter at home. My router generates a self-signed cert when it first starts, and it would be easy enough to emulate one of them. We could use the same details in the certificate and copy the login page, but they are not super common kit, and finding one that's on the network, but not the default gateway might be suspicious.

I think the current http module that emulates a NAS is a clever idea, but I don't have a NAS to play with, if anyone has a NAS that generates a self-signed cert and can share the details that would be great. Otherwise, I can just make something up, but the more we can look like a real device the better.

[DFF-fred]

I'm a bit puzzled by your writing... I have a firewall which is its own CA and all my devices have certificates issues by it. My idea was that one could "simply" upload his/her SSL certificate to one directory on the Pi and then enable SSL . That's how I do it with Home Assistant (also running on a Pi) and a lot of other stuff. So I don't look at this as a self-signed certificate, but a self-signed certificate should be handled similarly. One creates it and upload it.
For Let's Encrypt it requires people to install certbot so... not sure how this works on your platform.

Just my perspective, if it can help.

And thank you!

Fred

[jayjb]

@DFF-fred, I'm not sure if you saw, but we have added an HTTPS module now. Essentially there are some new config values to specify where the Opencanary process should looks for the certificates, otherwise it will generate its own.

The config keys to specify the paths are:

"https.certificate": "path/to/certificate.pem",
"https.key": "path/to/certiticate.key",

with the default paths being /etc/ssl/opencanary/opencanary.pem and /etc/ssl/opencanary/opencanary.key respectively.