I write this as somebody who thinks swfchan is an extremely valuable archive of internet culture, and as somebody who would love to mirror it to ensure these precious swf files don't get lost to the ravages of time. I just wanted to address some misinformation in the thread about why HTTPS does or does not resolve certain security issues, and why LetsEncrypt is or is not a good certificate provider. 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. |