Get proper HTTPS for fucks sakes, this isnt 1995 netscape

https certificates Expire. they are only valid for a specific range of dates and times and need to be renewed. It's a pain.

not all websites NEED to be https. https encrypts the data users enter on the page and the data of forms which are submitted between the user and the server.

This site has no logins. the only data you can enter here is search terms, captcha ascii, local upload locations, an anon username (thats not even actually necessary but just so people can track user messages from post to post), maybe an email (optional) and a title and a bunch of text for a subject.

None of the Required info that you can submit here is sensitive. you shouldn't be posting your bank account login and password here, nor any personally identifyable information. unless you want to be doxed and raided? I mean.. welcome to the trollpit where it's all fun and memes..

There is indeed nothing sensitive to encrypt here for normal users, other than your very presence and activities here. HTTPS does prevent other servers from impersonating swfchan.net, though (for whatever that's worth)

Https is purely a meme for any site that doesn't feature logins. It's just a way of certificate companies getting a slice of the control over the web pie.

So no, I'd rather this is 1995 netscape.

The S in the protocol is on top of the HTTP, first a secure channel is established and then HTTP is used as normal entirely within that secure channel.

so no, a cert does not prevent proxying a site through a fake page. the fake proxied copy will even have the same URL. in fact so long as the fake page has the same URL then the https cert is valid for it.

on the note of lets encrypt: forkheads looked into it, our admin noted issues with it compared to manual cert registration. LE has a terms of service which could change on a whim, they reserve the right to refuse to provide cert services to site's whose content is deemed objectionable by the LE team, thier lawyers, or any third parties and thier lawyers who find out your site uses [insert thing they don't like].

swfchan would be banned from recieving certs by LE in an instant. "you allow loli H swfs, no https cert for you, remove every entry since the dawn of time and handover ownership of the site to our designated party and dox yourself and appear in court in Australia or the EU, in order to get your certs reestablished"

"Lol, no."

LE also has terms about mandatory site updates. they'd be quick to tell swfchan that Flash swfs are 'insecure' and that "swfchan needs to remove the ability to host and display swfs in thier native flashplayer" and make all sorts of demands about the way object elements of the site are written. "for security purposes the wrapper for the swf object needs to be written in google javascript 9.0 and should proxy the actual page content from a script to build it hosted on google, this prevents outdated browsers who may be effected by swfs from viewing them."

and they reserve the right to change thier ToS as they see fit, so worse things than I described can find thier way in. they could literally hold the site hostage dangling the cert over it's head.

in short, the less companies and terms of service are involved the better.

Speaking of Cloudflare, all the sites that use HTTPS with Cloudflare only encrypt traffic to and from Cloudflare's server's, they de-encrypt all packets and can see all data from all the visitors (passwords, search terms, urls etc). This happens even if the site is using its own cert and not Cloudflare's auto-HTTPS feature. After de-encrypting they re-encrypt on their end when speaking with the actual web site server, if needed. I think a lot of people don't realize this.

If you have a mirroring API with HTTPS/TLS, then maybe this isn't so urgent for me.

>no https does not prevent site impersonation
It does, as long as the site in question hasn't had its private keys compromised (hacked), and your CORRECTLY FUNCTIONING browser trusts "sensible" certificate authorities. For most users, the default configuration is sensible.
>MS Edge...Fake proxied copy...
Is NOT CORRECTLY FUNCTIONING...To a security-minded user. Edge is shitty corpo software that actively harms its users, or, more kindly, the users "trust" Edge to not harm them, so silently breaking things is okay to these users. We may agree that such users are retarded, but the 5% of users using a shitty browser is not a reason to punish literally everyone else.

But you think they're not being punished?
>not all websites NEED to be https
Yes they do, or at least, swfchan is not an exception. Not all users need or care about encryption, but the improved authentication (anti-impersonation) that HTTPS provides via TLS is crucial for websites to function how users expect. Although plenty of writers have elaborated on this, I'll list the most important attacks this mitigates for the typical user for ANY website they visit:

MAN-IN-THE-MIDDLE: notice how your web browser goes to the website and mindlessly runs whatever JavaScript is on the returned webpage? Remember how JavaScript is required to run swf files online via Ruffle? Most of your users have JavaScript enabled.

Now consider: an attacker manages to intercept a connection request to the website. This attacker could be anyone who routes your request, including your ISP or a proxy or VPN, especially Tor nodes. Proxied users are especially vulnerable to this, but it can happen to anyone.

The attacker returns the page you requested (by requesting it from the website themselves), but they add just a little EXTRA JavaScript. This evil JavaScript is some sort of zero-day or other exploit that allows them to compromise the browser due to bugs in the JavaScript engine, and BOOM the attacker can do whatever they want with the user's authority: your shit's hacked. Alternatively, when the user tries to download a swf file, the attacker sends them a file infected with similar malware targeting a browser, or Adobe Projector, or desktop Ruffle, or whatever offline player everyone uses. (someone may have uploaded malicious swf files to swfchan, possibly by MITM-ing, but that's a separate issue. Most of swfchan's users aren't uploading to the site.)

The JavaScript shenanigans aren't just theoretical. Browsers are constantly fixing these kind of bugs. A recent example is https://www.cve.org/CVERecord?id=CVE-2024-9680 where ACTUAL HACKERS in the wild were, in this case, abusing a bug in Animation Timelines in Firefox to run arbitrary code on actual victim's machines. People were literally getting hacked before Firefox could fix the issue.

DNS SPOOFING: even something as basic as entering the domain "boards.Swfchan.Net" can have problems. The user might not even end up at the right server! In short, hackers are constantly tricking legitimate DNS servers into serving malicious DNS records. When a user enters "boards.Swfchan.Net", the user may end up getting an attacker's IP address. This is a problem with (vanilla) DNS and there's nothing you can do. For more info, see https://en.wikipedia.org/wiki/Dns_cache_poisoning

The idea is a hacker sets up a server that is a permanently online, automatic man-in-the-middle, and then they trick DNS servers into sending unsuspecting users to the malicious server.

DOES THIS APPLY TO SWFCHAN?

Does swfchan serve webpages meant to be viewed in a browser? Do your users run JavaScript or download files? Yes, these problems apply to swfchan users.
>doesn't feature logins
Doesn't matter. You serve webpages, and any time a user running JavaScript receives a malicious webpage, if their browser mindlessly runs the JavaScript on that page (because it thinks it actually came from swfchan.com or whatever), they can get hacked. Potential malware injection into swf downloads is icing on the cake.

DOES THIS REALLY HAPPEN THAT OFTEN?

Do you have "always use HTTPS" configured in your browser?

If so, how many times have you gone to a website, you know they use HTTPS, and your browser said, "oops there's no HTTPS, are you sure you want to continue?" or "HTTPS misconfigured". You think, "Huh, that's unexpected, the website shouldn't have a configuration issue or anything." You refresh the webpage. It shows up fine the second time, browser has no complaints, you see the lock or checkmark next to the URL showing that your connection is over HTTPS.

Occasionally, the website or your DNS is actually misconfigured, they forgot to update their certs or whatever. But, especially when visiting sites you know are well-maintained (such as duckduckgo.com) almost EVERY SINGLE TIME this happens, you just evaded some sort of attack that, if not for HTTPS, you would have been exposed to. You could have gotten hacked. That's how often these attacks occur.

HOW DOES HTTPS ADDRESS THIS?

If the site uses HTTPS, these attacks aren't really a problem. Users may connect to an attacker, but the browser will realize they're not authentic and will WARN THE USER OF THIS. If the user isn't retarded, they'll back up. No more malicious data, no malicious JavaScript, they don't get hacked.

But if there is no HTTPS, there is no warning! The browser will run any JavaScript it receives, no matter how shady or malicious, from god knows where, and the user can get hacked.

Your users trust you. You're a nice swf archive site. But your users don't have much assurance that they can visit your website and/or download swf files without getting hacked. Even if you, the site admins, are totally nice and honest, hackers can still fuck everything up. HTTPS provides a very strong assurance of the authenticity of the webpages and files they get. It may even be the simplest way for you to provide such an assurance.

IF I WANT CERTS FOR HTTPS, WHY LETSENCRYPT?

Well, they don't charge you, and they provide a simple open source daemon you can install (Certbot) that automatically keeps your certs up-to-date (you can even configure it to point to another ACME v2 [RFC 8555] provider if you don't like LE). Some operating system distributions even have a "certbot" or similarly named package. Once configured, this puts a stop to the nonsense where you manually generate a cert, then upload to a provider, maybe manually verify some other fields, etc. NO. Just configure and forget. In my personal experience, on several website domains over 4 years, I have literally never had to reconfigure or even think about certificates. In the case of swfchan, as long as everything's behind a single load balancer or reverse proxy, this is exactly the architecture LE is optimized for, and you can expect maintenance to be trivial.

>LE has a terms of service

EVERYONE has a terms of service. All certificate authorities can change their terms on a whim. LE can cancel certs for any reason? So can everyone else. This is true for all authorities. This is true whether you update certs manually or automatically. If someone assures you they won't ever cancel your certs, they're full of shit. If they have to choose between standing up for an swf archive and staving off government goons, you think they won't break their contract with you? They choose survival. LE is no different from other authorities in this regard, no worse than your current provider that you use on certain parts of swfchan. Even in theory. In practice, LE is actually better than you would expect.

>swfchan would be banned from recieving certs by LE in an instant
>they'd be quick to tell swfchan that Flash swfs are 'insecure'
How LE is different in practice is that (aside from cert automation being easy), as long as you do simple, basic shit that everyone that uses HTTPS does, they don't care about details. They don't care what's on your website. Basically, the subscriber agreement section "Your Warranties and Responsibilities" is extremely liberal to subscribers (you) and boils down to:

>don't lie to us to trick us into giving you a cert
>don't hack us
>try not to get hacked
>revoke your cert if your shit's hacked

That's it. The vast majority of the time, when LE revokes certs, it's because LE fucked up and somebody exploited a bug in LE's systems to get certs they weren't supposed to. They don't care what's on your site. They're not examining your site to see if it meets some security standard. Even the whole "don't break the law" stuff that's boilerplate in every contract...If it's not obviously illegal (in California), they don't care. As anon put it,
>they provide certs to many millions of sites that have a lot less tame content than swfchan
This site's content is generally just not edgy enough for them to care. This site is special, but not that special. To illustrate:

Kiwifarms.St, the clearnet for one of the most notoriously websites on the internet, known for repeatedly doxxing people, repeatedly banned over "concerns" about its content. KiwiFarms uses LetsEncrypt. Even the Internet Archive banned KF, but LE has been providing KF certs for years.

Even if LE reserves the right not to issue you certs, they have a reputation for almost never exercising that right. We already know you remove CP, you remove copyrighted material if someone complains, you respond to and usually respect requests, you notify the right people when there's a security breach...Swfchan already has objectively superior site admins. That's above and beyond what LE wants.

>they could literally hold the site hostage
Even in the 1/1,000,000 chance they revoke your certs, there's nothing stopping you from finding another cert provider, or dropping certs entirely and reverting to HTTP. In the latter case, the site will only be semi-inaccessible until you revert a few config files and maybe reboot something. They can't hold your site hostage.

>Let's Encrypt is too big just like Cloudflare
LE is less dangerous than CF. CF can send your traffic to god knows where, but LE can only revoke your certs. Also, CF can see and snoops and profiles all your traffic. LE cannot. Also, CF banned KiwiFarms. LE did not. LE has a better reputation and less power to abuse.

>The main issue is centralization
Very valid security concern insofar as LE is (sort of) a single point of failure. But, for the reasons above, it simply isn't going to fail, and even if it does, swfchan will be fine.

As far as LE being a third-party that could get compromised by hackers or Nazis or the Illuminati and now evil people have a massive amount data to weaponize against good people...Again LE is not CF. LE only knows which servers have certs, what their IP addresses and domains are, etc. Unlike CF, they generally have no info on end users of websites they issue certs to, and what they do have is difficult to weaponize and is often publicly available anyway.

Even if the Nazis started maliciously issuing invalid certs, ALL certificate authorities can do that. They don't need your permission to do so. Even if you never requested a cert from them, they can still do this. There's nothing you can do about this. In theory, this sounds like a broken system. In practice, does LE or any other commonly trusted certificate authority knowingly do this shit, such that it affects the average user? No. Users trust the certificate authorities that their browser or system trusts for a reason: in practice, this setup provides a good-enough assurance of authenticity that is infinitely better than no assurance at all.

And even if you thought LE specifically might be a little too big or too evil, you can always choose another provider. But your current tedious workflow where you manually manage certs isn't how it's supposed to be. For a woefully incomplete list of other providers you can do automatic certs with see https://acmeclients.com/certificate-authorities/

That said, are there other reasons why you think LE would be a pain? Based on my experience with it, I genuinely find putting "LetsEncrypt" and "a pain" in the same sentence confounding.

However, this only helps if the user's DNS resolver supports it. Often, they don't, so users still get spoofed DNS records.

Replacing it once every 10 years can't be too much of a hassle, can it?

>hurr durr self-signeds over interwebs are bad!
They are bad trust-wise. They are perfectly serviceable privacy-wise*.
Compared to no https at all - which gives neither trust nor privacy - this is a huge step up.
The cost to pay? Your browser won't warn you that you are viewing a website whose owner you probably shouldn't trust (oh no, the horror!)
(* - in principle, the lack of trust undermines privacy, but *assuming* the owner is who they claim to be, *then* your connection is secure. This is superior to your connection *never* being secure, right? The true reasons for why self-signed certificates are discouraged from WWW use are: creating a false sense of trust, and teaching users bad trust practices).

The downsides of self-signed cert vs. a trusted cert:
- users must manually trust it. A matter of 2 clicks for anyone who knows how. A matter of 5 minutes + search engine to learn how
- does not eliminate the threat of impersonation (though to be honest, Let's Encrypt and other self-serve certification services don't either...)

The upsides of self-signed cert vs. no cert at all:
- if trusted by user, traffic is securely encrypted (privacy, and yes this includes everything in url besides base address)
- if trusted apriori, user will be notified of any potential impersonation (certificate changed since last time you trusted it)

The downsides of self-signed cert vs. no cert at all:
- for user: none. If you leave standard http open, then all of this is 100% opt-in on a per-user basis. Don't want it - don't use it. The choice is user's
- for webmaster: you have to refresh the cert once every 10 years. Realistically you also have to do some minimal crypto maintenance such as cycling TLS protocols and cipher suites as they become vulnerable, but this also is a "once every X years" matter.

tl;dr: if you don't like ANY CERTIFICATION AUTHORITY (which is fair), then sign the certificate yourself. Let users themselves decide if they trust it or not. The cost to you is minimal.