Rick's b.log - 2016/09/28
It is the 24th of November 2024 You are 3.147.73.85, pleased to meet you!

Dangling the padlock (SSL at HeyRick)

Now...

Google, in their wisdom, are pushing for HTTPS everywhere. While this sounds like a good idea, it is unfortunately an idea with numerous... shall we say... implementation problems.

I'll start with a minor one. You have probably noticed a lot more scary messages appearing in your browsers lately about the site you are looking at cannot be authenticated as being correct. Ironically, this probably happens most to Google itself. Why does this happen? It's because the heavy-duty HTTPS that Google want to use is shonky and all too quick to throw in the towel if the communication is interrupted. You know, weak WiFi or pretty much any mobile signal. This means the browser will hang up for several seconds and then spit out a "no, can't" message forcing you to reload the page.
It wouldn't be that big a deal, except it happens all the bloody time. And, as I said, mostly with Google. They are probably using a more paranoid version of SSL than ROOL or my own site.

Now for the biggie.
Look what happened when I was connected to the public access point in KFC Laval (France) when I went to Google and ROOL (both https):

Yup. KFC's access point not only blocks VPN, it will also try to man-in-the-middle you if you visit a site that uses SSL. What the message means is they're trying to pass off a fake certificate on you so their AP can snoop on all of the data as it passes between you and them.

This is intentionally and wilfully breaking SSL. That padlock? You know what it is for? It means your data is kept safe between your computer and the site you are looking at. If you are dumb enough to accept a fake certificate, this will grant the issuer (the access point) the ability to intercept and examine the normally-encrypted data. It will still be encrypted, only now in two hops. From your device to the AP, and then from the AP to the site.
I'm sure that anybody called on this will give some bullshit excuse about mumble mumble piracy mumble; however there is nothing that justifies a public access point giving itself the right to interrogate your encrypted data. Login details? Passwords? Credit card data? Think of all the places where that little padlock appears, and then think of all the personal information that can now be intercepted.

Of course, if a company provides an AP then they can set the terms of access; I just don't think people will entirely understand what the above message really means. It's a rather nerdy looking pile of rubbish, I wonder how many people just look for the OK button and don't realise what this is telling them.
So, of course, I would use my mobile phone as a hotspot in such a place.

However, with this in mind, I am not transitioning HeyRick to be an SSL site. Instead, both methods work. HTTP and HTTPS. Use whichever one you like.

Unfortunately, Google is too braindead to have any sort of "http or https" option. Apparently I am expected to migrate my entire site to HTTPS and set up redirections and then tell Google where to find stuff by way of some mapping file or other. As mentioned above, HeyRick is going to support both methods. There will be no migration; or else the site risks being cut off from people using crappy APs (or an unwitting part of the intentional MITM); plus plain HTTP may work better for older software, slower processors, etc (apparently YouTube will stop working on many Smart TVs made prior to 2012 because SSL means a lot of number crunching and they're just not up to it).

For Google, I have created a second site - HeyRick with https. And I have created a 'collection' grouping them. I'd like to think Google would be smart enough to realise that it's the same damn stuff, but I'm half expecting to see things listed twice - once with SSL and once without.

What does this mean for you? Not a lot really. If you read this blog by entering "www.heyrick.co.uk/blog/" into your browser, you will be redirected to the SSL version automatically.
If you do not want this (if you want normal http), then you should suffix "?nossl" to the end of that URL (bookmark it as such if that's easier). In other words, "www.heyrick.co.uk/blog/?nossl".

If you are a programmer wanting to do this in software for whatever reason, the server returns a redirection to take you to the correct "latest entry" page. Parse the URL, and just switch "https" for "http". It'll work.

If you come directly via an HTTP URL, then you will not be redirected to HTTPS. For instance, the direct URL of this entry is "http://www.heyrick.co.uk/blog/index.php?diary=20160928" and this will be served to you as such. More than that, all of the links within the blog (calendar, last five entries, etc) will also be HTTP links (not HTTPS).

On the other hand, if you come directly using an HTTPS URL (such as "https://www.heyrick.co.uk/blog/index.php?diary=20160928") then all of the links within the blog will be HTTPS.

Your comments:

Rick, 28th September 2016, 23:20

And, of course, trying to use HTTPS with nossl is dumb. I have not filtered it out as there's really no point in doing such a thing. You'll see the "use HTTPS" nag, you'll then see a big read "bogus parameters" nag, plus most of the links will still be HTTPS anyway.  I just thought I'd mention that, as somebody is bound to try. ☺

VinceH, 29th September 2016, 00:23

You should point out that KFC naughtiness to El Reg.

No perrrrkele, 15th October 2016, 21:11

Rick, I was thinking, you seem like a great guy. Anyway, sorry if bothered you with this.

Rick, 15th June 2019, 17:10

For the .eu version of HeyRick, you can access it without SSL by going to http://heyrick.eu/...etc...