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*

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*

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.

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?

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.)

koitsu wrote:

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.

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.

Last edited by rainwarrior on Fri Sep 16, 2016 10:51 am, edited 1 time in total.

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.

rainwarrior wrote:

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.)

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)

tepples wrote:

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?

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.

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.

LE also sends mail before the 90 days are up.

koitsu wrote:

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).

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.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum