The benefits of using Let's Encrypt

Retro

Founder
Staff member
Joined
4 Jun 2021
Messages
2,403 (3.91/day)
Securing your website with an SSL certificate is a must nowadays. For example, this one is secured with a free and maintenance-free Let's Encrypt cert, for example.

Here's an opinion piece on why SSL certs are so widespread now and whether LE should be used in preference to commercial, paid for, certs or not. However, he fails to mention that LE is backed by the biggest names in the industry such as Amazon, Microsoft and Oracle, which is huge, solidly legitimising the whole LE concept and operation.


 

Tiffany

Pixel Princess
Staff member
Joined
13 Apr 2022
Messages
1,070 (3.57/day)
I've got your article opened to read today, thank you! I have my websites secured with Let's Encrypt too....much easier SSL option and free rather then when I purchased SSL's through Godaddy; very expensive just to get your websites link in green colored text. ;)
 

Arantor

Well-known member
Staff member
Joined
24 May 2022
Messages
891 (3.44/day)
That article was kinda... fluffy and didn't really get to any useful conclusions about why things should be done or not, but that's because I think there is a lack of understanding about what the certificate is doing and why.

First up, why do we care about encryption? Especially for sites that you'd think wouldn't need it. Well, his point about the USA surveillance programs is valid - but with a caveat... if something is public information (like, say, business hours) why would it matter if you encrypt it at all or not?

There is the argument that the government has no need to see what you're looking at - but, well, your ISP knows, or at least, someone knows because you need to get DNS records from somewhere so which *site* you're going to will be findable in some fashion. (We can talk about DNS-over-HTTPS some other time, and the host of issues *that* has.)

But there are a couple of things we don't talk about: passive listeners and MITMs.

So, how many sites do you have a login for? How many of those - like small forums, blogs, etc. - previously weren't using HTTPS? That would mean that, in most cases, you were sending your username/password over the internet in plain text, and that little data packet was travelling a long way between your computer and the other server, through several networks. It wouldn't have been hard for someone to add a packet sniffer *somewhere in the way* and for your username/password to be sniffed that way. And of course, the world's gone mobile so you're not just sending data through wires where you'd need a physical intercept, you're sending it in the air where *anyone* could have read it.

(You might not think this is a real thing to worry about but consider if you were someone with a legitimate reason to have covert communications, this is one of those considerations. I don't mean 'spies' but think about people trying to escape from an abuser, reaching out to people via forums. This is not a hypothetical situation either.)

HTTPS stops all that by encrypting everything that gets sent between your computer and the destination server. While parts of the network still get to see the start and end, everything in the middle is wrapped up in sealed boxes, meaning it's much much more difficult for people to intercept it.

And that brings me to the MITM, the man in the middle attack. If the traffic isn't encrypted, it's entirely possible to change the content in transit. A relatively benign example might be a proxy service that receives a page, injects an ad and sends it onwards. But there are documented cases of much more insidious things - imagine if you were using a messaging system that wasn't secure, again in the abuser scenario, where the abuser could intercept the communications. Consider someone trying to get away from their abuser, arranging a meet, only for the time, date and address of the meet to change - without the abuse victim knowing, because the content was tampered with in transit. (This is, again, not a hypothetical situation. Sadly.)

HTTPS is a line of defence against both of these, and something that the article didn't address - which to me seemed like a huge problem when explaining that 'so many sites use HTTPS now', well, here's the real reason why.

His argument for not using LE is mostly that "well some people don't trust LE". This is true, some browsers don't. But the same browsers don't tend to trust the paid vendors any better. A quick perusal of some SSL vendors indicates that even if you pay for their certificates, it doesn't guarantee that it'll work:

* RapidSSL - "support for more than 99% of browsers and most mobile device browsers"
* Gandi - "99% browser recognition"
* Comodo - "Trusted by all popular browsers with 99.9% Ubiquity"
* DigiCert - "Compatible with all major browsers"

They're not saying "all browsers" or even "all supported browsers", they're saying high percentages and things that are roughly equivalent to Let's Encrypt. So that's a fiction.

And then there's the matter of lifespan; LE certs are only ever issued for 90 days at a time. Should the cert keys be leaked, that's the maximum window of exposure, unlike SSL where you can buy 10 year certs. This of course also means that not only might you go up to 10 years without renewal, come the end of that 10 years you might forget you need to do it, while LE is intended to be fully automated.

LE even offers wildcards now, which is very convenient if you're running a service where you give users their own subdomain (e.g. user.domain.com) meaning that for most uses you're good.

Where it does fall down is that it's only validating against the domain. You don't have any proof that the person running the domain is the entity you think you're dealing with. For most sites this is of course not an issue because the (vast) majority of sites aren't doing anything where you'd care that the entity on the other end of the connection is *exactly* who they claim to be. Most of the time the domain + DNS is good enough, but when it comes to something like your bank, you'd absolutely want to care that they are who they claim to be.

And this is where the traditional SSL vendors come in with their OV and EV certificates. These do additional checks on the person(s) applying for a certificate, proving that the entity applying is indeed who it claims to be. If it's for a business, it's proof that the business exists and exists at the address in question, and records will be required to substantiate this. This is all stuff most users simply don't need - and even smaller businesses that are taking money don't *really* need this (because they're using services like Stripe and PayPal that will have this sorted out for them).

----

Anyway. Long story short: unless your site is literally static HTML and you have no login system and you don't care if people misrepresent your content, you probably want HTTPS, and free is almost certainly good enough.

Free is possibly not good enough if a) you're doing something LE doesn't support (multi-domain, or for whatever reason you can't validate the domain over DNS), or b) you're an organisation where user impersonation *matters* and has consequences, and by which I mean 'failure to get this right doesn't affect that one person who buys a thing on your website once, but affects millions of people with life altering consequences.

Anything else is somewhere on that spectrum and how much trust you want - not that users often check the extended cert types anyway.
 

Tiffany

Pixel Princess
Staff member
Joined
13 Apr 2022
Messages
1,070 (3.57/day)
More then I ever knew about SSL and HTTPS, thanks @Arantor. I still have the link to the article open to read....didn't want the day to pass without acknowledging your stellar information, which makes us all just that much more informed, which is awesome! Thank you!
 

Retro

Founder
Staff member
Joined
4 Jun 2021
Messages
2,403 (3.91/day)
Arantor, I think your reply is longer than the article! :) Lots of good info there.

I'm very aware of MITM attacks which are still possible with SSL in a clandestine way, but is generally not that easy to do and is helped by social engineering.

Take my workplace for instance, their proxy does this and is, unfortunately, a perfectly legal thing to do by an employer. The web browsers on corporate computers have the proxy cert installed, so access to all SSL sites appear to have proxy certs rather than the site's original. Of course, this allows work to snoop on one's login details, so for this reason, I never log in to NZ from a work computer. I just browse the site logged out and if I want to post or check PMs, I use my iPhone on its separate internet connection via the SIM card.
 

Arantor

Well-known member
Staff member
Joined
24 May 2022
Messages
891 (3.44/day)
You'd be surprised how many of the AV vendors' security products also MITM you by installing a new root certificate that's automatically trusted...
 

Tiffany

Pixel Princess
Staff member
Joined
13 Apr 2022
Messages
1,070 (3.57/day)
I just read the article this morning @Retro. It was informational in an historical sense, really liked that background information on how certificates evolved.

@Arantor your post #3 was the ultimate in information on SSLs/certs, like what a consultant would offer.
 

Arantor

Well-known member
Staff member
Joined
24 May 2022
Messages
891 (3.44/day)
I suppose in a sense that's actually accurate; I work for a digital agency and I have had to field this sort of question in times past - and I'd rather try to be detailed and informative :)
 

Retro

Founder
Staff member
Joined
4 Jun 2021
Messages
2,403 (3.91/day)
Arantor, so you broke out the template explanation and pasted it here then. πŸ˜‰πŸ˜›
 

Arantor

Well-known member
Staff member
Joined
24 May 2022
Messages
891 (3.44/day)
Nah, I don't have a template version, and even if I did it would be on the work's laptop ;) Just... this is literally part of what comes up in my day job so it's not like I have to research it. Been doing this web malarky for... too long.

(When I started noodling in HTML, the years still started with a 1. I'm coming up to 20 years in PHP next March.)
 
Top Bottom