New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Easy, those sites could sign their OS (or whatever) files and offer that as well. Even with a self-signed cert. Oh, wait, quite a few OS sites and mirrors already do that; also note that many also offer downloading via http ( no 's'), ftp (no 's'), and other protocols ...
Also, kindly note that TLS is about communication security while your example largely is about being tamper-proof. In other words: really getting what you think you are getting - vs - your communication say, with your bank being safe.
To keep hassle-free on production systems, I always prefer a DV WildCard.
If you get a free account with Cloudflare and use their proxies, you can use their SSL certificates for free. Then you don’t have to worry about renewing them at all.
While hiding the IP does reduce visibility to some extent, it’s hardly an appropriate way to strengthen actual security.
Back in the 90s, I remember people selling "SSL accelerator" cards for servers and such, but in 2025, how much burden does it really put on a web server or user's device to do the encryption? Most webservers and PCs have lots of spare CPU to burn, and most of the crypto (all of it?) is now done in hardware anyway.
SSL doesn't solve all problems. Are these xxx,xxx attacks against SSL or against other parts of the system?
Imagine I'm running a web site for a museum. I don't care if the hours and direction page is encrypted, but I probably want the online gift store and membership login pages encrypted. Since there's virtually no cost to encrypting everything on the site, I think it's more secure to do so rather than try to carefully parse out which pages need encryption and which don't, and hope that I don't get something wrong.
Though to be fair, they also strengthen cryptosystems - e.g., DES and differential cryptanalysis.
50% slop maybe, lol. The first paragraph is purely my personal experience, while the second one was assisted by Copilot. Apologies for using AI to help with my response—English is my third language. Thanks for the feedback!
Yes, I remember those cards, but back then a 4-core x86 dedi was a "big fat server, wow" and Sun boxes were out of reach for most, even for many small companies.
As for the burden it quickly gets unpleasant. Let me start it like this: If nowadays a core can do only some ten thousands of something per second that something is a major burden, just as merely receiving and servicing 10_000 connections was and, depending on sheer hardware power and software choices, still can be ...
And then there are the particularly fat and slow TLS implementations which unfortunately also happen to be among the most used ones (hello, OpenSSL *g), and there also is a shit ton of "legacy functionality", questionable and/or crappy functionality, ciphers etc. (often due to standards (hello, NIST & Co.)).
Or there is version 3.x which actually is much, much slower than v 1.1.x, basically for willy nilly "reasons".
As for "lots of spare CPU to burn, and most of the crypto (all of it?) is now done in hardware anyway" - well, yes and no. Many (most?) think "why not doing it when I can afford it?!", but how do you bring "fuck it, we have damn enough processor cycles to burn" together with "let's get ever more functionality into hardware"? ... even to the point of hardware (pseudo) random generators, which actually easily can reach GB/s even in software. So, which one is it then - "we need more speed!" or "let's not care about wasting - actually very expensive! - functions, we can afford it"?
And "most of the crypto (all of it?) is now done in hardware anyway" is a bit more complicated, and wrt TLS even uglier, than many seem to think.
Let me start simple. Yes, most of symmetric crypto (like e.g. AES) is done in hardware nowadays; even 10+ years old Xeons have it built in, and yes again, that kind of crypto is the bulk of en/decryption. But there are 'buts' too, like e.g. we nowadays have quite a few algorithms that can be done fast (as in nearly as fast or even faster than AES in hw), but there the point is NIST & Co., insurance issues, and of course the (I call it supidity but let's stay polite and call it) "inertia" of the masses.
So, why do AES in hardware at all? Bluntly, because it makes many, probably most, "think" that TLS is no problem anymore because, you know, "done in hardware" - but that's plain wrong, because it's the cheap part that's done in hw, the expensive part is not done in hardware (hello TLS and PKI).
And No, also generally. Not all, not even most, crypto is done in hardware; actually, only a select few algorithms are done in hardware, mostly just AES (plus some acceleration via SIMD).
Irrelevant, because once a hacker is in your system, he's in there and can see and usually take also your private keys, etc. But TLS is a very attractive vector, although usually not the target itself but rather e.g. an attractive [D]DOS vector because even nowadays it's a very expensive operation (with, in addition, a large attack surface).
Maybe. Or maybe not. Depends on more factors and details than one might think. Fact is, to provide an example, that a few pages are very likely to make the bulk of your traffic, while your web shop and member pages are comparatively much less visited. So, does it really make sense to put all your pages behind TLS just to protect small fries (traffic wise)? Also again, your premise "there's virtually no cost to encrypting everything" is plain wrong wrt TLS.
Why, do you think, quite a few very major players created their own TLS implementations? Trust me, I happen to know that "actually, there is quite a high cost to TLS encrypting" played a major role in their decision and saving even "just" 20% was well worth the effort.
For your museum web site the problem might be compressed into "oh, well, let's spend $50 or $100 more per month for a heftier dedi", but that is not a sensible approach when you don't get and service a couple of ten thousand connections per day but billions (or if the question whether your corporation lives or dies depends on surviving hundreds of attack each and every day, many not script-kiddie attempts).
Duh! Of bloody course NIST must and does deliver something. After all, they want to stay alive and get a fat budget. Or put friendlier: Yes, NIST & Co. did and do provide many important and good services, but here we're talking about a specific segment and it is known that they bent over willingly for NSA more than once.
Google trust services has better compatibility cloudflare uses it with sectigo to provision certificates
Free DV ssl is enough for personal usage.
https://openssl-library.org/performance.html I think it is fast now. https://istlsfastyet.com/ serving with TLS could be faster than plain http. You don't have to decide between plain Vs TLS because on the main page there could be donation addresses and these can be manipulated to they need to be encrypted. Also asymmetric is fast, symmetric is even faster.
Thanks for making me lough hard and loud.
Oh and btw: I can tell you where you can buy the original Eiffel tower for just $ 5 mio! Even better, if you take 2 original Eiffel towers, you get a third one for free!
Just setup cronjob to renew lets encrypt. you can force it too!