It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
high rated
I've got a number of security/privacy plugins installed in Firefox, and some of them are geared towards trying to force websites to use SSL (https) whenever possible to to potentially provide an increase in security, privacy, help to protect against identity theft, protect against prying eyes of both would be criminals, corrupt (and so called democratic) governments and their spy agencies and other actors. I've been involved with computer security for a long time and have had to deal with it as part of my former day to day career in the past, so it's both something related to my former profession as well as something of personal academic interest and hobby. So, I prefer to surf as much of the web encrypted by default as the web will allow.

The EFF's (Electronic Frontier Foundation) Firefox web browser extension <span class="bold">HTTPS Everywhere</span> comes preconfigured with a large list of preset configurations for a huge number of highly popular websites which have SSL capability available in some manner but may or may not use it or enforce it by default. This browser addon will do its best to attempt to enforce SSL as much as possible on websites that appear to have the capability either fully or even partially. I've been using it for 7 or more years now and it works quite well.

There are other extensions like NoScript, or ForceTLS which have a similar functionality however they are limited in capability compared to what HTTPSEverywhere is capable of doing, largely because HTTPSEverywhere has support for powerful syntax that the other extensions generally lack (namely regular expressions).

Parts of the GOG web properties are SSL enabled, such as the forums, but not the main storefront catalogue and gamecards unfortunately. It would be really nice if the entire gog.com domain and all of its subdomains were available over SSL, or even exclusively SSL like many other sites are starting to move towards such as Facebook and Google, but it is not quite there yet. In the mean time, those who wish to use GOG.com over SSL as much as possible could try to use the functionality built into NoScript or ForceTLS or other extensions but due to the nature of how GOG implements SSL it becomes rather difficult to force it on all the time without causing some complex problems that can lead to being inadvertently logged out often when going from one part of the site to another, or other oddities in the website.

This is where HTTPSEverywhere comes in and shines. The secure part of gog.com appears to entirely be within the secure.gog.com domain, however the entire web property is not all present there, as such some parts of the site's navigation will work fine replacing www.gog.com with secure.gog.com, while other parts of the site work only on www.gog.com, and other parts only on secure.gog.com. Additionally, the navigation links within the website to other parts of the site may point to www.gog.com pages from secure.gog.com pages when the same page is actually available udner secure.gog.com, which causes you to go from a secure page to an insecure one when you click on certain links (such as the pulldown menus at the top of the site). This usually causes you to be logged out inadvertently and have to log back in again and can be really frustrating until you figure out what is going on. :)

Using the HTTPSEverywhere browser extension, it is possible to configure it so that parts of secure.gog.com always link to other parts of the website which are also available under secure.gog.com even if GOG's own web pages point to www.gog.com, thus causing you to stay within the secure domain as often as possible, and to avoid being logged out when crossing back and forth between the two subdomains. This happens for example when you visit the forums or your gamecard over SSL then try to visit the homepage -> bang -> logged out.

To improve the SSL experience on GOG.com I have created a very simple custom configuration for HTTPSEverywhere which will force SSL to be used on parts of the site which I have found work properly with SSL enabled all the time, and I will update it to fix bugs or add additions if I encounter any problems (or someone reports them to me and I can figure out a workaround).

Here is the current configuration file that I'm using which appears to work fairly well for me in a few hours of testing and navigating around the website:

<ruleset name="GOG.com">
<target host="www.gog.com" />
<rule from="^http://www.gog.com/forum/"
to="[url=https://secure.gog.com/forum/"/>]https://secure.gog.com/forum/"/>[/url];
</ruleset>

To use this ruleset with the HTTPSEverywhere plugin, you simply create a new text file named "gog.com.xml" inside of your Mozilla Firefox profile, under the subdirectory "HTTPSEverywhereUserRules". The location of this directory will vary from Windows XP to Windows 7 to other operating systems and if you're not familiar with where the directory is on your system, simply do a web search to find out where the Firefox profile directory is for <your operating system>. I'm using Windows 7/x64, and the subdir is located on my system at:

C:\Users\Mike\AppData\Roaming\Mozilla\Firefox\Profiles\R4Qtp9Vy.default\HTTPSEverywhereUserRules

Installing the browser plugin and restarting the browser, then saving the above ruleset I provided above into the textfile "gog.com.xml" in the subdirectory indicated, and loading up gog.com web pages should result in your browser using SSL for the GOG web forums, but should not affect other parts of the site. I will provide updates to the configuration over time if any problems are discovered, or if others submit fixes or suggestions to provide further enhancements etc.

If anyone is currently trying to use NoScript or other plugins with simple forced SSL implementations, you would do well to give HTTPSEverywhere a whirl. It is not for everyone however, and intended more for more tech-savvy power users such as myself with a hobby/enthusiast or professional interest in online security/privacy.

I thought I'd share this here in case it might benefit or pique the interests of others. If you have any problems or questions feel free to comment below.

Enjoy!


See also: https://www.eff.org/https-everywhere/rulesets
Post edited June 15, 2014 by skeletonbow
Awesome. =) I already use HTTPSEverywhere so I will definitely try this out. Thanks!
Thanks for the information.

Can I do the same thing for HTTPSEverywhere extension in google chrome?
Post edited June 16, 2014 by asrul1992
avatar
asrul1992: Thanks for the information.

Can I do the same thing for HTTPSEverywhere extension in google chrome?
Yes, it appears they have it available for Chrome, Opera, and Android as well.
Is this a good place to promote my now-more-easily-accesible-than-before ruleset?
https://github.com/Maighstir/GOGHTTPS

It's a bit more involved than yours, among other things securing the cookies (so that cookies set on https can't be accessed on http) and taking into account more subdomains than just www.
Post edited June 16, 2014 by Maighstir
Thanks to you both, skeletonbow and Maighstir!
avatar
Maighstir: Is this a good place to promote my now-more-easily-accesible-than-before ruleset?
https://github.com/Maighstir/GOGHTTPS

It's a bit more involved than yours, among other things securing the cookies (so that cookies set on https can't be accessed on http) and taking into account more subdomains than just www.
Absolutely! Nice, thanks for the contribution/share. I've updated my ruleset to expand its reach also a bit but not quite as much as you've got going on with your ruleset. I'll have a closer look later on today. Good to see others are interested in this sort of thing too!
avatar
Maighstir: Is this a good place to promote my now-more-easily-accesible-than-before ruleset?
https://github.com/Maighstir/GOGHTTPS

It's a bit more involved than yours, among other things securing the cookies (so that cookies set on https can't be accessed on http) and taking into account more subdomains than just www.
avatar
skeletonbow: Absolutely! Nice, thanks for the contribution/share. I've updated my ruleset to expand its reach also a bit but not quite as much as you've got going on with your ruleset. I'll have a closer look later on today. Good to see others are interested in this sort of thing too!
Yeah, the first rule (from https to https) in my ruleset is most likely not needed any more, but it doesn't hurt. Some time ago GOG did the sensible thing and served the "www" subdomain over https as well, rather than separating https traffic to the "secure" subdomain, and if a Firefox user still has https://www.gog.com in its history, it'll automatically try that (and complain because www no longer replies on https) for www.gog.com unless one specifically types [url=http://www.gog.com]http://www.gog.com[/url]. So that's there even though the better fix is to remove the affected addresses (anything starting with https://www.gog.com) from the browser history.

The second could likely also be made a little simpler by removing the "|secure", as that's similarly likely not needed (it's unlikely anyone tries to access secure.gog.com over http).

And there's other changes that could be made (for example, I don't bother redirecting the home page because it's broken over https), which is one reason I released it openly.
avatar
skeletonbow: Absolutely! Nice, thanks for the contribution/share. I've updated my ruleset to expand its reach also a bit but not quite as much as you've got going on with your ruleset. I'll have a closer look later on today. Good to see others are interested in this sort of thing too!
avatar
Maighstir: Yeah, the first rule (from https to https) in my ruleset is most likely not needed any more, but it doesn't hurt. Some time ago GOG did the sensible thing and served the "www" subdomain over https as well, rather than separating https traffic to the "secure" subdomain, and if a Firefox user still has https://www.gog.com in its history, it'll automatically try that (and complain because www no longer replies on https) for www.gog.com unless one specifically types [url=http://www.gog.com]http://www.gog.com[/url]. So that's there even though the better fix is to remove the affected addresses (anything starting with https://www.gog.com) from the browser history.

The second could likely also be made a little simpler by removing the "|secure", as that's similarly likely not needed (it's unlikely anyone tries to access secure.gog.com over http).

And there's other changes that could be made (for example, I don't bother redirecting the home page because it's broken over https), which is one reason I released it openly.
Yeah, I've had similar experiences but hadn't yet codified them all in regexes. One other that I noticed though was that some links point to <domain>/account/foo while others point to <domain>/en/account/foo, or likely more accurately <domain>/<countrycode>/account/foo in an inconsistent manner. Also some links on the pages seem to be relative links that work well enough on http or https without mucking with them while others appear to hard code the http://www.gog.com in them inconsistently. In short the site is a little bit of a mess. :) Nothing some good old regex-fu can't fix though right? ;oP
avatar
skeletonbow: Yeah, I've had similar experiences but hadn't yet codified them all in regexes. One other that I noticed though was that some links point to <domain>/account/foo while others point to <domain>/en/account/foo, or likely more accurately <domain>/<countrycode>/account/foo in an inconsistent manner. Also some links on the pages seem to be relative links that work well enough on http or https without mucking with them while others appear to hard code the http://www.gog.com in them inconsistently. In short the site is a little bit of a mess. :) Nothing some good old regex-fu can't fix though right? ;oP
While there may have been an idea originally to have the site in different languages, there has only ever been /en/, and more recently you're redirected to an address with /en removed if you use one with it added. So yeah, /en/account/foo redirects to /account/foo since several months (a year? more?) ago.
avatar
skeletonbow: Yeah, I've had similar experiences but hadn't yet codified them all in regexes. One other that I noticed though was that some links point to <domain>/account/foo while others point to <domain>/en/account/foo, or likely more accurately <domain>/<countrycode>/account/foo in an inconsistent manner. Also some links on the pages seem to be relative links that work well enough on http or https without mucking with them while others appear to hard code the http://www.gog.com in them inconsistently. In short the site is a little bit of a mess. :) Nothing some good old regex-fu can't fix though right? ;oP
avatar
Maighstir: While there may have been an idea originally to have the site in different languages, there has only ever been /en/, and more recently you're redirected to an address with /en removed if you use one with it added. So yeah, /en/account/foo redirects to /account/foo since several months (a year? more?) ago.
They really should have the site available in both Cuneiform, Klingon and Sindarin IMHO. :)
avatar
skeletonbow: They really should have the site available in both Cuneiform, Klingon and Sindarin IMHO. :)
Na'ven would be preferable, as it's easily learned by simply listening for a minute or two.
Post edited June 17, 2014 by Maighstir
Could someone explain to me why quoted posts open to their plain http addresses and not the secure ones, even when using HTPPSEverywhere and the respective GOG.com ruleset?

Am I misunderstanding that the ruleset forces secure connections on the forum?
GOG's web side code creates the URLs and it isn't http/https clean so some of the URLs are http and some are https around the site. All HTTPS-Everywhere does is take URL targets and expand them with the supplied rules and if there is a match it turns them into https as described in the rule. The links on the page will still be whatever the webserver static or dynamic page code generates though. The https redirection occurs client side prior to fetching a URL.

To have the URLs on the pages match where clicking on it will redirect to on https pretty much means the website has to be updated to work with https properly on its own so HTTPS-Everywhere isn't even needed on the site.

Another way of putting it is that the URLs on the web pages come from GOG and whatever they put in their page code, http or https, but clicking on them will go over https if the URL matches an HTTPS-Everywhere rule.
That's not what I asked, but I figured it out and fixed it myself, all's good now.

Thanks anyway.