HTTPS is broken

I know someone who is unwilling to participate in the forum and wiki over HTTP but might consider it over HTTPS. As of right now, https://nesdev.com/, https://www.nesdev.com/, https://forums.nesdev.com/ and https://wiki.nesdev.com/ produce the following:

forums.nesdev.com uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.
The certificate is only valid for localhost
The certificate expired on 07/25/2014 01:04 AM. The current time is 02/21/2016 07:39 PM.

(Error code: sec_error_unknown_issuer)

The barrier to implementing HTTPS used to be the cost of a separate IPv4 address per domain, but that ended in April 2014 when the last major SNI-ignorant desktop web browser (Internet Explorer for Windows XP) reached end of life. The barrier after that was the cost of TLS certificates, but since Let's Encrypt opened to the public, a TLS certificate is available without charge to the server administrator. What other barriers to making HTTPS work exist, other than the server administrator's time?

General brain dump from someone who's been doing this for a long, long time:

* Let's Encrypt certs expire every 30 days (apparently this has been increased to 90). There are "hacks" (as in shitty shell scripts, and generally borderline ridiculous nonsense) to try and "automate" getting a new cert + putting it in place via this method, which is disappointing when compared to, say, an actual decent CA (ex. NameCheap, Gandi, etc.) which will send you an Email reminding you that your certs need to be renewed before their expiry.

* Let's Encrypt doesn't support wildcard certificates citing some sort of ACME hard-on. Otherwise you're going to need a cert that's for the root domain (this is something CA-based wildcard certs don't actually give you in most cases -- it ends up having to be one of the names in your subjectAltName list, i.e. you have to pay for it), one for www, one for forums, one for wiki, and god knows what else. Someone will need to do a full review of all DNS records that point to said server.

Oh, and don't forget about any redirections for old names, e.g. https://nesdev.parodius.com --> https://nesdev.com will not work (I'm not going to get SSL for something legacy -- sorry). HTTP-to-HTTPS redirection is possible but "generally shunned" because it gives users a false sense of security when visiting legacy URLs.

* HTTPS is substantially slower and in some environments (very specific kinds of caching proxies) cannot be cached. One thing that's absolutely guaranteed is that the connection set-up time is substantially longer given the SSL negotiation overhead. SPDY helps with this, but SPDY isn't available in all webservers, and getting it to work correctly as a module in Apache is sometimes tedious at best. My point is, expect worse performance.

* Configuration of SSL/HTTPS -- meaning PROPER configuration, especially when CA/cert chains are involved! -- can be painful. Use of Qualys' SSL Test is highly useful, but the information given there isn't always immediately clear. How to configure Apache properly is substantially different than nginx, and the configuration methodology/approach even varies per CA (I'm not making this up -- it all depends on what the CA gives you back). I can't stress the importance of using Qualys' SSL Test. People screw up certificate chains all the time.

* Actual forum or software configuration bits. Sometimes changing the scheme (HTTP -> HTTPS) will break badly with software configurations that need to know what the scheme is. Forum software and wiki software come to mind -- I can imagine them botching internal links and so on unless configured correctly. And sometimes there's multiple places this needs to be done.

* HTTP-to-HTTPS redirections within the webserver itself (e.g. mod_rewrite, not HTTP header Location: redirects!) may need to be done for things like images, i.e. there may be old links in people's forum posts or wiki content that refer to the http:// version. You get to deal with "migrating" all of those over to https:// otherwise.

* The admin now needs to begin tracking OpenSSL security holes (usually one or two coming out every few months at this rate) and patches for OpenSSL for their OS and/or Linux distro. In other words: what wasn't a concern before now becomes a serious concern. Let's not discuss the feasibility of switching to WolfSSL or LibreSSL at this time -- let's remain practical/realistic.

In other words: "other than the administrator's time" is putting it very, very lightly. SSL is a total nightmare.

That said, my personal (I'd border on saying professional) opinion is this: the main reason people want HTTPS (for non-banking-related things) is because they're don't want their L/P credentials possibly sniffed and decoded. That's it. So really the only things I'd recommend HTTPS be considered for are the forum and the wiki. There's nothing on the main site that warrants use of HTTPS.

So, at NameCheap, that's either $9/year (if you had separate certs, one per hostname; PositiveSSL), or $30/year (one cert for both hostnames, one as CommonName the other as a subjectAltName; PositiveSSL Multi-Domain). At Let's Encrypt, that's either one or two certs (not sure which), and the admin gets to deal with a bunch of bullshit every 90 days -- and if they fail to deal with it, users get a wonderful warning (often a dialog box) telling them of the expiry until it's dealt with.

If you put a Strict-Transport-Security header on the HTTPS side, the browser will automatically do the redirection for you for page views after the first.


It can if the user of the caching proxy installs the caching proxy's root certificate. This is common in corporate environments.


Even if HTTP/2 (formerly SPDY) is unavailable, false start and keep-alive help with this.


The Content Security Policy spec includes upgrade-insecure-requests, which instructs the browser to rewrite all HTTP URIs for scripts, images, and the like as HTTPS URIs.


In other words, where I spend 99.9% of my time on the site.

An update, based on several months of successful operation of Let's Encrypt and some recent events:


The SANs I can think of at the moment are 8bitalley.com, nesdev.com, www.nesdev.com, nesdev.parodius.com, forums.nesdev.com, wiki.nesdev.com, and the other hosted sites.


An intermediate caching proxy is also an intermediate rewriting-to-include-ransomware-links proxy.


Thanks for the recommendation.


The idea is that cron will deal with the bullshit every 60.

Just so you all know,I'm working on coming up with funding to get a newer server, when and if I can come up with the money I will get proper HTTPS setup and a more traditional hosting system for hosted sites

WhoaMan, just start a donation post for PM donations in General.

This.

It should be made available both HTTP and HTTPS, if it can be done. HSTS is bad and don't use it, and don't implement it in the client-side either (I have hacked out HSTS from Firefox).

HTTPS works now

Works, but HTTP doesn't work any longer (it's automatically redirecting to HTTPS). Encryption is nice, but it's also slower, at least on old computers.
Which, well, I guess nobody but me is having any problems with it. And even with the encryption, nesdev does still feel faster than sites like wikipedia or facebook.
Anyways, an option to disable HTTP-to-HTTPS redirection would be nice for retro people with old hardware. This is an 8bit forum after all : )

EDIT: Now it's working again, and it's really loading faster that way. Thanks for fixing!

OK, is there a way to enable HTTP-to-HTTPS redirection? Because without that, anything can just downgrade the connection. The links within this site, and malicious downgrade attacks outside this site.[citation needed]

Why not just bookmark the HTTPS version instead?

Doesn't work. As I just edited, practically every link will just revert the connection back to HTTP.

I wonder what's breaking for you?

It's working for me: this reply was made from the https URL, clicked on the "reply" button and stayed on the https version, and followed links that stayed on the https version. Both forum and wiki.

Could be the proxy, maybe?

—

That said, the very front page is using http (rather than protocol-relative) links for its stylesteet and favicon

I've added a private custom profile field "Redirect to HTTPS" of type Boolean. How easy would it be to wire up automatic redirection if and only if this is checked?

What on earth are people trying to solve here? I really don't get it.

If the problem is with all the sites being forcably redirected from HTTP to HTTPS, then yes, I maintain that was a very bad choice (yes I was aware of it after the server upgrade, but obviously did not test everything -- I figured it was done for the forum and only the forum); I get the impression that was being done in nginx. There are an extremely large number of caveats/problems created by HTTP-to-HTTPS redirection, many of which aren't noticed until after-the-fact (these threads are proof).

"Migrating" from HTTP to HTTPS is something that can happen on a per-site basis, but as I've stated in the past, I disagree heavily with the "HTTPS everywhere" mentality.

The sites should've remained as they were originally -- HTTP -- and HTTPS added later so that it could be tested (and quirks/kinks/changes be worked out in advance for a full migration if needed/wanted).

What exactly are we trying to solve with moving all the sites to HTTPS? Are people *that* concerned about their forum and wiki credentials being compromised by mysterious intermediary forces? Because I'm completely sure that shady ISPs and compromised backbone providers are collecting all the L/Ps as to destroy everything related to nesdev. *blinks repeatedly*

I'm sorry that I asked.

This was more a stern but friendly jab towards whoever decided to move everything over to HTTPS as part of the server migration (not sure if that was WhoaMan or tepples or who), not so much you. :-)

Migrating from HTTP to HTTPS should've been a separate thing done much later (after thorough discussion, esp. considering all the caveats and complications as a result -- it's not as easy as sticking everything under HTTPS and then HTTP 302ing to HTTPS).

In general though, I really beg people to be practical about HTTPS usage -- there are more downsides to it (IMO) than upsides. SSL truly isn't needed most of the time. What most end users are concerned with that justify SSL are 1) banking transactions, 2) PII (personally identifiable information), 3) L/Ps for sites they consider extremely important, and 4) "general information" that needs to be obscured in some way given plaintext transport (i.e. even using something like XOR "encryption" would be sufficient). #3 is tricky because the importance level varies per person.

For example, #3 might be more important to a user with moderator level or greater access to a system. For example, a site might force HTTPS for its Administrator Control Panel.

With the growing prevalence of ad blocking, I expect more sites to offer subscriptions. A site that debits the user's account for each article that the user views turns each page view into the equivalent of a "banking transaction[]". And a site that offers a monthly or annual subscription is likely to have terms of service that ban sharing credentials or a session with a nonsubscriber. Such a site would use HTTPS to prevent inadvertent sharing with others on the same Wi-Fi.

And sometimes the confidentiality aspect of TLS isn't as important as the integrity aspect. Sometimes you want to ensure that nobody has modified a piece of information on its way to you, such as to insert advertisements containing malicious scripts into a web page or to replace the executable that you are attempting to obtain with a trojan. For something like software downloads, would you prefer code signing to tamper-evident transport?

This is also why there are proposals to limit the Fullscreen API to a secure context, so that a site can't phish your banking credentials or PII by simulating the operating system and browser chrome and making you think you're on a site that you're not on.

I prefer that sites that offer binary executables for download use HTTPS, so that I know I'm getting the file I expect. (I think there's at least a few of these on the forum.)


I imagine that most MITM attacks are not targeted to a specific site, but are trying to capture anything that looks like a login in an automated way, replace exectuables, etc. It's also relatively easy to set up compromised "free wifi" in public places. So... IMO a "shady ISP" is a real and present danger, and the obscurity of NESDev is no protection against threat.

The biggest problem isn't really that someone stealing an NESDev login can use it to access NESDev.com, the problem is that it's a certainty that tons of NESDev users are using shared passwords. The point of Google's SEO demotion is to protect users from themselves, more than anything else. (I don't think we should be concerned with SEO for NESDev, but I do think protecting its users is worth considering.)


Actually the executables thing is why I feel a bit anxious about all the binaries hosted on my own website. I try to put them on github, etc. where I can, but a lot of my hobby stuff isn't applicable to that, and I don't want someone to get malware because they tried to download my game demo at a coffee shop. I wish my site had HTTPS for that reason.

By the way, https://wiki.nesdev.com/ appears to redirect to http://wiki.nesdev.com/w/index.php/Nesdev_Wiki, which seems like a problem for users that are trying to use HTTPS.

There's probably a bunch of places on this site that hop from HTTPS to HTTP... I imagine this is a pain to do consistently if you're not just always redirecting to HTTPS.


Don't feel like I'm pushing for HTTPS here. I'd prefer to be using it, personally, but please just do whatever you think is best for the site. I was OK with it being HTTP in the past, and I'd be OK with that in the future too. (It's obviously an administration hassle.)

Limiting fullscreen API to a secure context doesn't help so much (it does prevent unauthorized MITM, but that's all it helps with). Disabling it entirely (with fullscreen enabled only if user agree and activates it) is better.

That is sensible, and I generally only offer source codes on my own server (except if the binary is designed to run in a sandboxed VM anyways)

That might work, but I think the following is a better idea:

• Make files available over both HTTP and HTTPS, with no redirect in either direction if no cookies are set to indicate to do so.
• Next to the "login" link, also add a "secure login" link. When "secure login" is selected, cookies are set secure-only, except for the redirect cookie. Logout clears all of these cookies, and cancels the redirect even if you login again insecurely.
• For wiki, to do the similar thing too.

I don't know if either your or my idea are easier or more difficult to implement.

LE also sends mail before the 90 days are up.


For what it's worth, after StartSSL's new owners severely mismanaged it, I recently switched pineight.com's certificate to Namecheap and paid $15 for 3 years.