forums.nesdev.com uses an invalid security certificate.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?
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)
HTTPS is broken
Moderator: Moderators
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:
Re: HTTPS is broken
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.
* 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.
Re: HTTPS is broken
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.koitsu wrote: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.
It can if the user of the caching proxy installs the caching proxy's root certificate. This is common in corporate environments.* HTTPS is substantially slower and in some environments (very specific kinds of caching proxies) cannot be cached.
Even if HTTP/2 (formerly SPDY) is unavailable, false start and keep-alive help with this.One thing that's absolutely guaranteed is that the connection set-up time is substantially longer given the SSL negotiation overhead.
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.* 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.
In other words, where I spend 99.9% of my time on the site.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.
Re: HTTPS is broken
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.koitsu wrote:* 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.
An intermediate caching proxy is also an intermediate rewriting-to-include-ransomware-links proxy.* HTTPS is substantially slower and in some environments (very specific kinds of caching proxies) cannot be cached.
Thanks for the recommendation.I can't stress the importance of using Qualys' SSL Test. People screw up certificate chains all the time.
The idea is that cron will deal with the bullshit every 60.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
Re: HTTPS is broken
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
i dont have much to say
Re: HTTPS is broken
WhoaMan, just start a donation post for PM donations in General. 
Re: HTTPS is broken
This.B00daW wrote:WhoaMan, just start a donation post for PM donations in General.
Re: HTTPS is broken
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).
(Free Hero Mesh - FOSS puzzle game engine)
Re: HTTPS is broken
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!
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!
Re: HTTPS is broken
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]
Last edited by JRoatch on Thu Sep 15, 2016 5:23 pm, edited 2 times in total.
Re: HTTPS is broken
Why not just bookmark the HTTPS version instead?
Re: HTTPS is broken
Doesn't work. As I just edited, practically every link will just revert the connection back to HTTP.lidnariq wrote:Why not just bookmark the HTTPS version instead?
Re: HTTPS is broken
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
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
Re: HTTPS is broken
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?