[colug-432] self-signed cert on the main website.

[Rick Hornsby]

On February 8, 2020 at 18:09:22, Rob Funk (rfunk at funknet.net) wrote:

On Saturday, February 8, 2020 6:48:35 AM EST jep200404 at columbus.rr.com
wrote:
> On Sat, 8 Feb 2020 00:23:33 -0500, Chris Punches <punches.chris at gmail.com>

wrote:
> > Also I noticed today that we're now using a self-signed cert on the main

> > website. We should probably stop doing that. I highly recommend ACME.
>
> What do we need a cert for?

1. Because people going to the site over https will get a scary error page
from their browser telling them it's insecure and unsafe. I don't know about

Firefox, but on Chrome you have to click two different things from there in
order to get to the page.

2. Because encryption is no good if you can't be sure who you're talking to.

Without a valid signed certificate the site can be intercepted (MITM) and
modified/replaced by ISPs or anyone else who can get in your network path
(e.g. someone else at the coffee shop) and use their own self-signed
certificate.

3. If the key is compromised and someone uses your self-signed certificate,
the self-signed certificate can't be revoked.

It’s certainly nostalgic, but I don’t particularly care for the world that
we live in, where HTTPS is all but a requirement for all sites. An
encrypted link to your destination regardless of protocol more generally is
the norm now - authenticated or not, as it unfortunately should be.

My earliest experiences of playing with TCP-enabled applications was using
the RFCs to figure out how to manually SMTP/POP3 into OSU’s mail servers
because they would break too often and somehow that would break Eudora. I
learned a ton about how things worked by doing that. Part of the reason I
was able to do that - using just telnet - was we weren’t nearly as worried
about bad actors then, so it was plain vanilla no SSL/TLS SMTP/POP3/IMAP.
Today, there are too many bad apples - the ones you don’t know like hax0rs
and the ones you know like your ISP - to make encryption optional.

You wouldn’t think that #2 would be a thing from your ISP who is just
supposed to provide a link and that’s it. But I’ve seen them inject content
and basically stand between us and the interwebs - either through cheesy
“did you mean X? Here’s some search results we think relate to domain name
you seem to have misspelled” DNS redirect pages (gtfo! AT&T), or ads
injected/added onto web pages you visit. That’s not to mention logging and
selling your interweb activity to anyone with a nickel.

I can’t remember which ISP(s) do the ad injection thing, but I seem to
recall at least one recently offering a cheaper price if you allow them to
modify web pages in flight to show ads.

On the server side, LetsEncrypt/ACME makes dealing with TLS certs _way_
easier than it ever has been. Also, LE is free as in beer. There’s not a
good reason to not have a properly signed cert fronting your site, and a
bunch of really good reasons to use HTTPS everywhere.

I haven’t gone full site-to-site VPN from my residential link, but I use
CloudFlare encrypted DNS (DHCP server supplies the config to all devices),
and put a Ubiquity ERL/firewall between the cable modem and the LAN. All to
keep TWC out of my business, and reduce the impact of any cable modem
vulnerabilities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20200208/ea5173cc/attachment.html