nesdev.com

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.