Hacker's ramblings

The summer here in Finland has been extremely warm. Given that, I've mostly not been inside doing computer-things, but outside doing outdoorsy things. Here we get couple good months per year, if we're lucky, so I decided to enjoy them fully.

Besides SUPping around the Lake Saimaa, I got a DJI Phantom 3 quadcopter to test out. At the time of writing, I already returned the loaner.

The thing looks like this, when the controller has my iPad attached to it:

Here is some sample footage:

YouTube link: https://youtu.be/w-ISgv08ad0

Just getting the thing flying is pretty easy, but controlling it in a sensible fashion so that the 4K-camera would actually capture a beautiful video is very hard. The above video is a first run and it has tons of camera operator mistakes in it. Some of my un-published videos I did do 3-4 runs to get it right. Still, flying the thing was tons of fun.

Today, I'm combining to previous post into a new one. I've written earlier about going fully Let's Encrypt and the problems I have with them. Now that I'm using them, and those certs have ridiculously short life-span, I need to keep automating all possible updates. That would include the IPMI 2.0 interface on my Supermicro SuperServer.

Since Aten, the manufacturer of the IPMI-chip chose not to make the upload of a new certificate automateable (is that a word?), I had to improvise something. I chose to emulate web browser in a simple Python-script doing first the user login via HTTP-interface, and then upload the new X.509 certificate and the appropriate private key for it. Finally the IPMI BMC will be rebooted. Now its automated!

So, the resulting script is at https://gist.github.com/HQJaTu/963db9af49d789d074ab63f52061a951. Go get it!

A perfectly valid sitemap.xml can be split into multiple files. For that see, the specs at https://www.sitemaps.org/protocol.html. This is likely to happen in any content management system. For example WordPress loves to split your sitemaps into multiple dynamically generated parts to reduce the size of single XML-download.

It should be an easy task to slurp in the entire sitemap containing all the child-maps, right? I wouldn't be blogging about it, if it would be that easy.

Best solution I bumped into was by Viktor Petersson and his Python gist. I had to fix his sub-sitemap parsing algorithm first to get a desired result. What he didn't account was the fact, that a sub-sitemap address can have URL-parameters in it. Those dynamically generated ones do sometimes have that.

Go get my version from https://gist.github.com/HQJaTu/cd66cf659b8ee633685b43c5e7e92f05

My thanks go to Mr. Petersson and Mr. Addyman for creating the initial versions.

Two Zoltáns, Gócza and Kollin are maintaining a superbly good webiste about UX-myths, uxmyths.com.

Given the excellent quality of the site, they list common mis-beliefs people have regarding websites and they thoroughly debunk them with references to actual measured information.

Just by reading their list we learn, that

• People don't read the text you post (myth #1)
• Navigation isn't about 3 clicks, it's about usability of the navigation (myth #2)
• People do scroll, on all devices (myth #3)
• Accessibility doesn't make your website look bad and is not difficult (myths #5 and #6)
• Having graphics, photos and icons won't help (myths #7, #8 and #13)
• IT'S ALWAYS ABOUT THE DETAILS! (myth #10)
• More choices make users confused (myths #12 and #23)
• You're nothing like your users and never will be! (myths #14, #24, #29 and #30)
• User experience is about how user feels your site (myth #27)
• Simple is not minimal is not clarity, they are three different things! (myths #25 and #34)
• ... aaaand many more

Go see all the studies, research and details in their site.

And thank you for your work Mr. Gócza and Mr. Kollin. Thanks for sharing with all of us.

Roughly 4 years ago, I blogged about a battery change to my UPS. The post is at APC Smart-UPS battery change. My unit eats APC Replacement Battery Cartridge #7 as replacment, and they are generally available in the net. The price point is there, such a replacement costs 250,- € easily. Much more, if you're not careful.

Couple years after publication Mr. Oliver commented my post (https://blog.hqcodeshop.fi/archives/195-APC-Smart-UPS-battery-change.html#c2000) about getting a pair of Yasa NP7-12 batteries. In his comment, he posted a PDF-spec http://www.yuasabatteries.com/pdfs/NP_7_12_DataSheet.pdf. Just by eyeballing the details, it became obvious, that there is no way in freezing hell, to be able to use that particular battery unit as replacment.

While I dismissed the suggestion quickly, Mr. Oliver succesfully incepted the idea (if somebody hasn't seen Inception, you missed my point there). In life, there are situations where the plan is a crappy one to begin with. On the other hand, sometimes the plan is rock solid, but implementation falls short. For best results, a good plan and good implementation is needed. So, I decided to investigate this battery replacement thingie and come up with a good plan. Initially it was more like a wish, I had no way of knowing how my chips would fall out.

The Investigation

So, when yanked out of the UPS, a APC Replacement Battery Cartridge #7 looks like this:

During the 4 years of running, it gathered some amount of dust. If I would care, I would have cleaned the worn out unit before taking the pics, but ... naah. And if you want to know how to actually yank it out, see my previous post.

In a glance, the #7 doesn't have any moving parts in it. There is nothing to remove, nothing to un-screw. But a closer inspection reveals some plastic covers just attached to the battery with a two-sided tape:

Yes! I'm, getting somewhere here. A close-up on the battery connectors:

The battery connectors have holes in them and there is a M6-screw running trough them. A 10mm wrench and a PH2 screwdriver will do magic there.

Finally I had all the parts separated:

There was some adhesive tape to make the two batteries stick together. As all the connector bits were removed, I just applied brute force to separate the lead acid batteries from each other.

The Plan

Battery used by APC:

A Hitachi Chemical Energy Technology Co. Ltd, GP12170. Spec is at: http://www.csb-battery.com/english/01_product/02_detail.php?fid=5&pid=13

My simple plan was to:

1. Find out if a suitable replacement battery was available. Mr. Oliver suggested that the price range would be £30,-
2. Get the replacement batteries
3. Apply some adhesive tape and screw the APC-connector bits and their plastic covers back
4. Plug the refurbished unit back to my UPS and admire the results (success of failure)

The Implementation

Finding and getting the replacment units

Nope. Just by googling, I didn't find that particular GP 12170 battery anywhere where the shipping costs wouldn't kill me. Lead acid batteries are heavy, as in expensive to ship, remember, the lead-part there.

• Since asking doesn't hurt, I just popped by my local battery-guy at Akku-Arkka Oy.
• His first question was: "Which lawnmower did your take that from?"
• I was in luck! He had suitable units in stock. For some reason, they are sold as a twin-box:
  
• Obviously, a twin-box is exactly what I needed for this purpose!

Assembly

At this point, my plan was coming together.

1. I just got some two-sided tape, stuck some of that on the side of the battery and stuck the other battery to the tape to form a single unit.
2. I screwed the APC-bits back to the connectors. Even the holes were precisely the same size.
3. More two-sided tape to the top and battery connectors were nicely covered.

I didn't bother taking any pics of this. My final result looked un-surprisingly like the original APC-unit.

Plugging it in & testing

Since these quality UPS-things have hot-swappable batteries, the UPS-unit was running my computers all the time since the batteries failed, I removed the old battery-pack and finally was about to test the new battery-pack. The obvious risk at this point was if I made a mistake and my UPS would completely fry because of that.

But no, it didn't happen. Everything worked perfectly! My APC utilities on Linux indicated following:

# apcaccess
APC      : 001,043,1009
DATE     : 2018-05-20 13:03:11 +0300
VERSION  : 3.14.14 (31 May 2016) redhat
CABLE    : USB Cable
DRIVER   : USB UPS Driver
UPSMODE  : Stand Alone
STARTTIME: 2018-05-20 13:03:07 +0300
MODEL    : Smart-UPS 1500
STATUS   : ONLINE
LINEV    : 234.7 Volts
LOADPCT  : 13.6 Percent
BCHARGE  : 100.0 Percent
TIMELEFT : 91.0 Minutes

Finally

Looks like all the lead-acid batteries in world come from Vietnam. See article Is Vietnam the new China for lead-acid battery manufacturers? about that.

I saved ~150,- € by doing this instead of going for the official unit. Nice!

Again, bit of a pause from blogging. I dragged my ass back to Finland. See my post from last year about moving to Sweden for further info.

I served my contract at King and chose not to continue there. The reasoning was actually very simple: my entire life has always been and is in Finland. Taking a brief side-step and living abroad was fun and all, but quite soon it become obvious, that I cannot sustain that for very long time.

So, I started a new job and am trying to continue my projects here. That does include some hacking and blogging about that.

Whenever there are new toys, I'm excited! Now that I have new iPhone 8, there is no other way to phrase it: it IS same as 7, which was same as 6. The observation Woz pointed out when X and 8 came out:

I’m happy with my iPhone 8 — which is the same as the iPhone 7, which is the same as the iPhone 6, to me.

Here are the comparison pics:

Last year around this time, I wasn't especially impressed when I got my 7. See and/or read it at /archives/345-New-toys-iPhone-7.html. This year, I'm kinda hoping to still have my 6. The good part is, that I won't have to pay for these toys myself. If I would, I would be really really disappointed.

Today, I had my last day at King. Right now I'm toasting this fine drink to my wonderful ex-colleagues.

Next I'm taking a breather and next week starting something new back in Finland!

Toying around with RFID, tags has always been something I wanted to do, but never had the time. Contactless payment is gaining traction all around the world. The reason is very simple: it is fast and convenient for both the customer and vendor to just touch'n'go with your credit card or mobile phone on a point-of-sale.

Credit/Debit card payments are based on EMV, or Europay MasterCard and Visa, standard. See generic EMV info at https://en.wikipedia.org/wiki/EMV. Back in 2011 Visa started driving the contactless standard worldwide, and given the situation today, their efforts paid off. However, my understanding is, that at the time of writing this, regardless number of people attempting it, there are no known vulnerabilities in the contactless EMV. Finding one, would be sweet, but finding one would also be extremely hard and time consuming. So, I decided to go for something easier. MIFARE Classic.

What's this RFID, isn't it NFC?

Short answer: yes and no.

Long answer:

This infographic is courtesy of atlasRFIDstore
http://blog.atlasrfidstore.com/rfid-vs-nfc

MIFARE Classic info

Since this topic isn't especially new, I'm just posting some useful sites I found to be very useful when doing RFID-hacks:

• Finding the encryption keys:
  • https://linuskarlsson.se/blog/acr122u-mfcuk-and-mfoc-cracking-mifare-classic-on-arch-linux/
  • http://barisguvercin.com/mifare-1k-cracking/
  • https://github.com/FireFart/blog/blob/master/content/post/how-to-crack-mifare-classic-cards.md
• Cloning the tag:
  • https://gist.github.com/alphazo/3303282
  • http://www.ibuynfc.com/?cat=6
• Information about Mifare Classic encryption key hacking:
  • https://www.blackhat.com/docs/sp-14/materials/arsenal/sp-14-Almeida-Hacking-MIFARE-Classic-Cards-Slides.pdf
  • https://dl.packetstormsecurity.net/papers/general/cooking-with-mifare-classic-PS.pdf
• ISO/IEC 14443 Type A generations:
  • http://nfc-tools.org/index.php?title=ISO14443A

Going to eBay for the hardware

I had a real-world RFID -tag, and wanted to take a peek into it. For that to happen, I needed some hardware.

The choice for reader/writer is obvious, an ACR122. Info is at: https://www.acs.com.hk/en/products/3/acr122u-usb-nfc-reader/. The thing costs almost nothing and is extremely well supported by all kinds of hacking software.

Going to GitHub for the software

All the software needed in this project can be found from GitHub:

• libusb, https://github.com/libusb/libusb
  • Some software want libusb 0.1 some 1.0. I had only 0.1 installed so I had to compile the latest also.
• libnfc, https://github.com/nfc-tools/libnfc
  • Latest installed
• MiFare Classic Universal toolKit, mfcuk, https://github.com/nfc-tools/mfcuk
  • Installed, because it has Mifare Classic DarkSide Key Recovery Tool. This is an advanced approach into cracking the encryption keys.
• mfoc, https://github.com/nfc-tools/mfoc
  • offline nested attack by Nethemba
  • This is the one, NXP tried to prevent the hack to be publicly released, see info from https://www.secureidnews.com/news-item/nxp-sues-to-prevent-hackers-from-releasing-mifare-flaws/
  • Creating an own encryption algorithm and expecting nobody to figure out how it works will work for a very short period of time. Going to a judge to prevent the information from leaking also works... if you're high on something! But on real life it works never.

All of the above software was installed with ./configure --prefix=/usr/local/rfid to avoid breaking anything already installed into the system.

Running the tools

Basic information from the tag (the actual tag UID is omitted):

# nfc-list
NFC device: ACS / ACR122U PICC Interface opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  04
       UID (NFCID1): 11  22  33  44
      SAK (SEL_RES): 08

ATQA 00, 04 is listed in ISO/IEC 14443 Type A generations and is identified as MIFARE Classic. Goody! It's weak and hackable.

Just running mfoc to see if a slow attack can proceed:

# mfoc -O card.dmp
Found Mifare Classic 1k tag
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  04
UID size: single
bit frame anticollision supported
       UID (NFCID1): 11  22  33  44 
      SAK (SEL_RES): 08
Not compliant with ISO/IEC 14443-4
Not compliant with ISO/IEC 18092

Fingerprinting based on MIFARE type Identification Procedure:
MIFARE Classic 1K
MIFARE Plus (4 Byte UID or 4 Byte RID) 2K, Security level 1
* SmartMX with MIFARE 1K emulation

And very soon, it results:

We have all sectors encrypted with the default keys..

Auth with all sectors succeeded, dumping keys to a file!

WHAAT! The card wasn't encrypted at all!
A closer look into card.dmp reveals, that there was no payload in the 1024 bytes this particular MIFARE Classic stored.

Since, the card doesn't have any payload, the application has to work based on childish assumption, that the UID of a RFID-tag cannot be changed. Nice! Because it can be set to whatever I want it to be! Like this:

# nfc-mfsetuid 11223344
NFC reader: ACS / ACR122U PICC Interface opened

Found tag with
 UID: 01234567
ATQA: 0004
 SAK: 08

My blank UID-writable tag had UID of 01 02 03 04, but I changed it into something else. Note: This is not allowed by the specs, but using very cheap eBay-hardware, obviously it can be done! Nice.

To verify my hack:
I walked into the appliation and used my clone successfully. Also, I informed the owners, that their security is ... well ... not secure. They shouldn't use UIDs as the only authentication mechanism. It's only 4 bytes and anybody in the world can use that 4-byte password. Using encrypted payload would make more sense, if MIFARE Classic wouldn't have a major security flaw in it's key generation algorithm.

This was one of the easiest hacks I've completed for years.

Year ago, I posted about CAcert root certificate being re-hashed with SHA-256 to comply with modern requirements. The obvious problem with that is, that it is not especially easy to install own certificates (or the new CAcert root) into a phone anymore.

When you try to access your mail server (or any other resource via HTTPS), the result will be something like this:

Not very cool. Getting the "Cannot Verify Server Identity" -error. This is especially bad, because in modern iOS you really don't have a clue how to get the new root cert installed and trusted. No worries! I can describe the generic process here.

Apple Configurator 2

Get it from https://itunes.apple.com/us/app/apple-configurator-2/id1037126344. Install it into your Mac. It doesn't cost anything, but will help you a lot!

If you dream on running it on a Windows/Linux/BSD, just briefly visit your nearest Mac-store and with your newly purchased Mac start over from the part "Get it from..."

Root certificate to be installed

Get a root certificate you want to distribute as trusted root CA. With the Apple Configurator 2, create a profile containing only one payload. The certificate in question.

This is what it would look like:

When that mobile profile is exported from Apple Configurator 2, you will get an unsigned .mobileconfig-file. That will work, but just give grievance during install-time about not being unsigned. If you can live with an extra notice, then just go to next step. If you cannot, get a real code-signing -certificate and sign your profile with that.

Publishing your .mobileconfig from a web server

Your precious .mobileconfig-doesn't just automatically fly into your iOS-device, you need to do some heavy lifting first.

On your favorite web-server, which can be accessed from your iOS-device and you can fully control, place the .mobileconfig-file there as a static resource and make it have content-type application/x-apple-aspen-config.

On Apache:

AddType application/x-apple-aspen-config .mobileconfig

On Nginx:

types {
    application/x-apple-aspen-config mobileconfig;
}

Testing the content-type setting with curl:

# curl --verbose "https:...."
> User-Agent: curl/7.32.0
>
< HTTP/1.1 200 OK
< Content-Type: application/x-apple-aspen-config

Install the profile into your iOS-gadget

That's simple: just whip up Mobile Safari and surf to the URL. Given the correctly set content-type, it will launch profile installer:

During the process you will need to punch in your PIN-code (if you're using one in your device). There are way too many confirmations, if you really, really, for sure want to install that particular profile. The questions are there for a very good reason. A mobile profile can contain a combination of settings that will eventually either leave you powerless to control your own device, or alternatively allow remote control of your very own device. Or both. So, be very careful when installing those mobile profiles!

Finally

Now you have your new root certificate installed and trusted. Go test it!

For those who are very brave:

My recommendation is not to do this. Do not trust me or my published files!

I have published my own .mobileconfig into the web server of this blog. The address for the profile is:
https://blog.hqcodeshop.fi/CAcert/CAcert.org%20root%20CA%20profile.mobileconfig

I'll repeat: That is there for your reference only. Do not trust me for such a security-sensitive file.

People running servers at home always get dynamic IP-addresses. Most ISPs have a no-servers -clause in their terms of contract, but they really don't enforce the rule. If you play a multiplayer on-line game and have voice chat enabled, you're kinda server already, so what's a server is very difficult to define.

Sometimes the dynamic IP-address does what dynamic things do, they change. To defeat this, people have had number of different approaches to solve the problem. For example, I've ran a DHIS-server (for details, see: https://www.dhis.org/) and appropriate client counterpart to make sure my IP-address is properly updated if/when it changes. Then there are services like Dyn.com or No-IP to do exactly the same I did with a free software.

The other day I started thinking:

I'm already using Rackspace Cloud DNS as it's free-of-charge -service. It's heavily cloud-based, robust and has amazing API to do any maintenance or updates to it. Why would I need to run a server to send obscure UDP-packets to to keep my DNS up-to-date. Why cannot I simply update the DNS-record to contain the IP-address my server has?

To my surprise nobody else thought of that. Or at least I couldn't find such solutions available.

A new project was born: Cloud DynDNS!
The Python 3 source code is freely available at https://github.com/HQJaTu/cloud-dyndns, go see it, go fork it!

At this point the project is past prototyping and proof-of-concept. It's kinda alpha-level and it's running on two of my boxes with great success. It needs more tooling around deployment and installation, but all the basic parts are there:

• a command-line -utility to manage your DNS
• an expandable library to include any cloud DNS-provider, current version has Rackspace implemented
• systemd service descriptions to update the IP-address(es) at server boot, it really supports multiple network interfaces/hostnames on a same server

Any comments/feedback is appreciated. Please, file the bug reports directly to GitHub-project.

Human stupidity has always intrigued me. It is, after all, the driving force of this world. Most people will disagree with me and say, the driving force being money or sex or ... whatever. But take my word for it, it is stupidity! All you have to to is look around and realize, that stupid clowns get elected to powerful positions in democratic systems, idiots are disputing easily proven scientific facts and as an example are claiming that world is flat. Also in our everyday life we do stupid things just because "we always have done so". So, it is stupidity that drives you! People in general are not designed to make critical observations, instead we wired to crowd-behave in a socially acceptable manner. Being stupid.

When taken the context of any regular place of work, two gentlemen Mr. Alvesson and Mr. Spicer took a very close look on this phenomenon. And their book The Stupidity Paradox investigates these.

Stupidity: Entire book is written around a concept of functional stupidity. Authors define functional stupidity as:

Functional stupidity is the inclination to reduce one's scope of thinking and focus only on the narrow, technical aspects of the job.

Paradox: For an organization, just focusing on a narrow scope is often beneficial. Cutting corners makes everybody's life easier and consumes less resources, it is simply thoughtless and useful. There comes the paradox, your useful thing might be very destructive without you knowing it.

Nobody is safe from functional stupidity, especially smart people are able to wrap themselves in a "comfort zone" or a bubble, where everything they do and say appear smart. Outside the bubble, things may look a bit different.

The book describes functional stupidity inducing from five different sources:

• Leadership:
  • Often leaders are deluded. They really don't have a grasp what's going on. It doesn't stop them making decisions, though.
• Structure:
  • Add bureucracy. If there isn't enough information to do one's job, just add more forms to be filled and couple guidelines to get that information. What harm could dozens of contradicting guidlines and mandatory forms cause, right?
  • Alternatively, just change the existing organization structure to "improve" it. Throw in couple "promotions" with really cool title and minor pay raise without actual change to the tasks to improve morale. Do this couple times and everybody will be so lost.
• Imitation:
  • "Since everybody else is doing it, also we must do it". However, whatever "it" is, they may be doing it on a different context and have some kind of minor tweak in their way of doing it. Also, in reality not "everybody" does it. Such activities include typically just corporate window dressing, with little actual changes.
• Branding:
  • Sometimes a consultant approaches corporate execs and tells them, that how others perceive the corporation is somehow wrong or bad. This triggers an instant imago "improvement" -campaign to make changes, which are not based on reality but merely on bullshit. Often, the results are not something you'd really want to be proud of.
• Culture:
  • Getting bad news really sucks, right? Getting bad news about from your organization really really sucks, right? Easy fix: let's make a decision to never tell each other bad news! The result is a corporate culture, where you really cannot criticise anything, bring forward potential improvements or just not be able to tell, that corporation is in a downward spiral.

At the end of the book, authors cover the most important part, how to manage functional stupidity. How to detect it and how to make sure, that it doesn't cause more harm. If such a mighty force is left un-wrangled, lots of damage can be done. Ultimately the cure is simple: create a culture where smart people can observe and criticise day-to-day practices and top-level execs to take the feedback seriously. Sometimes the emperor is naked, insted of having new clothes.

Of all the vivid examples of stupidity in the book, my favorite is The Credit Crunch of 2007. Really smart (but greedy) people created a money-making-machine called CDOs. Those smart people made tons of money to themselves and to their employers, but lost the focus on the big picture. We know how that ended up.

I read trough this book with a mixed feelings. Sometimes laughing out loud but at the same time felt like crying, when the description of functional stupidity ripped open old wounds.

Ok. It's dead! It won't live long.

That seems to suprise few people. I know it did surprise me.
Google has had this info in their website for couple years already:

What happens to reCAPTCHA v1?

    Any calls to the v1 API will not work after March 31, 2018.
    Starting in November 2017, a percentage of reCAPTCHA v1 traffic will begin to
    show a notice informing users that the old API will soon be retired.

Yup. This blog showed information like this on comments:

Now that the above deadline is gone, I had to upgrade S9y ReCaptcha plugin from git-repo https://github.com/s9y/additional_plugins/tree/master/serendipity_event_recaptcha. There is no released version having that plugin yet.

Now comments display the v2-style:

To get that running, I simply got the subdirectory of plugins/serendipity_event_recaptcha with the content from Github and went for settings:

I just filled in the new API-keys from https://www.google.com/recaptcha and done! Working! Easy as pie.

Update 5th April 2018:
Today, I found out that Spartacus has ReCaptcha v2 plugin available to S9y users. No need to go the manual installation path.

Last week I was sitting in an aeroplane and while being bored, I flicked the phone on to test the Wi-Fi. Actually, I had never done that before and just ran a Speedtest:

Yup. That's the reason I had never done that before.
Half a meg down, 150 up. That's like using a 56 kbit/s modem or 2G-data for Internet. Both were initially cool, but the trick ran old very fast given the "speed" or ... to be precise - lack of it.

More investigation:

As expected, round-trip time was horrible. Definitely a satellite link. Or ... is it? But the answer to the topic's question is: no. There is no real Internet access mid-flight.

The exit IP-address was in /24 block of 82.214.239.0/24 belonging to Hughes Network Systems GmbH. I took a peek into Hughes Communications Wikipedia page at https://en.wikipedia.org/wiki/Hughes_Communications and yes. They have a German subsidiary with the same name.

After I landed and was in safe hands of a 150 Mbit/s LTE-connection, I did some more googling. Side note: When your internet access gets a 100x boost, it sure feels good!

There is a Quora article of How does Wi-Fi internet access in an airplane work? It has following diagram:

That suggests a satellite connection. Also I found The Science of In-Flight Wi-Fi: How Do We Get Internet At 40,000 Feet? from travelpulse.com, but it had some non-relevant information about a 3G-connection being used. That surely was not the case and I seriously doubt, that in Europe such a thing would be used anywhere.

Ultimately the issue was closed when I found the article Row 44 to begin installing connectivity on Norwegian's 737-800s from flightglobal.com. So, it looks like company called Row 44 does in-flight systems for commercial flights. They lease the existing infrastructure from HughesNet, who can offer Internet connectivity to pretty much everywhere in the world.

Wikipedia article Satellite Internet access mentions, that number of corporations are planning to launch a huge number of satellites for Internet access. Hm. that sounds like Teledesic to me. The obvious difference being, that today building a network of satellites is something you can actually do. Back in IT-bubble of 2001, it was merely a dream.

Little bit of background about having certificates

A quote from https://www.brightedge.com/blog/http-https-and-seo/:

Google called for “HTTPS Everywhere” (secure search) at its I/O conference in June 2014 with its Webmaster Trends Analyst Pierre Far stating: “We want to convince you that all communications should be secure by default”

So, anybody with any sense in their head have moved to having their website prefer HTTPS as the communication protocol. For that to happen, a SSL certificate is required. In practice any X.509 would do the trick of encryption, but anybody visiting your website would get all kinds of warnings about that. An excellent website having failing certificates is https://badssl.com/. The precise error for you would see having a randomly selected certificate can be demonstrated at https://untrusted-root.badssl.com/.

Google, as the industry leader, has taken a huge role in driving certificate business to a direction it seems fit. They're hosting the most used website (google.com, according to https://en.wikipedia.org/wiki/List_of_most_popular_websites) and  the most used web browser (Chrome, according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers). So, when they say something, it has a major impact to the Internet.

What they have said, is to start using secured HTTP for communications. There is an entire web page by Google about Marking HTTP As Non-Secure, having the timeline of how every single website needs to use HTTPS or risk being undervalued by GoogleBot and being flagged as insecure to web browsing audience.

Little bit of background about what certificates do

Since people publishing their stuff to the Net, like me, don't want to be downvalued or flagged as insecure, having a certificate is kinda mandatory. And that's what I did. Couple years ago, in fact.

I have no interest in paying the huge bucks for the properly validated certificates, I simply went for the cheapest possible Domain Validated (DV) cert. All validation types are described in https://casecurity.org/2013/08/07/what-are-the-different-types-of-ssl-certificates/. The reasoning, why in my opinion, those different verification types are completely bogus can be found from my blog post from 2013, HTTP Secure: Is Internet really broken?. The quote from sslshopper.com is:
"SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate."

Nowhere in the technical specifcation of certificates, you can find anything related to actually identifying the other party you're encrypting your traffic with. A X.509 certificate has attributes in it, which may suggest that the other party is who the certificate says to be, but's an assumption at best. There is simply no way of you KNOWING it. What the SSL certificate industry wants you to believe, is that they doing all kinds of expensive verification makes your communications more secure. In reality it's just smoke and mirrors, a hoax. Your communications are as well encrypted using the cheapest or most expensive certificate.

Example:
You can steal a SSL certificate from Google.com and set up your own website having that as your certificate. It doesn't make your website Google, even the certificate so suggests.

Little bit of background about Symantec failing to do certificates

Nobody from Symantec or its affiliates informed me about this. Given, that I follow security scene and bumped into news about a dispute between Google and Symantec. This article is from 2015 in The Register: Fuming Google tears Symantec a new one over rogue SSL certs. A quote from the article says:

On October 12, Symantec said they had found that another 164 rogue certificates had been issued
in 76 domains without permission, and 2,458 certificates were issued for domains that were never registered.

"It's obviously concerning that a certificate authority would have such a long-running issue
and that they would be unable to assess its scope after being alerted to it and conducting an audit,"

So, this isn't anything new here. This is what all those years of fighting resulted as: Replace Your Symantec SSL/TLS Certificates:

Near the end of July 2017, Google Chrome created a plan to first reduce and then remove trust (by showing security warnings in the Chrome browser) of all Symantec, Thawte, GeoTrust, and RapidSSL-issued SSL/TLS certificates.

And: 23,000 HTTPS certs will be axed in next 24 hours after private keys leak.

In short:
They really dropped the ball. First they issued 164 certificates, which nobody actually ordered from them. Those rogue certificates included one for google.com. Then they somehow "lost" 23k private keys for already issued certificates.

That's really unacceptable for a company by their own words is "Global Leader In Next-Generation Cyber Security". That's what Symantec website https://www.symantec.com/ says, still today.

What next?

Symantec has a website called Check your website for Chrome distrust at https://www.websecurity.symantec.com/support/ssl-checker.

I did check the cert of this blog, and yup. It flagged the certificate as one needing immediate replacement. The certificate details have:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            24:6f:ae:e0:bf:16:8d:e5:7a:13:fb:bd:1e:1f:8d:a1
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=GeoTrust Inc., CN=RapidSSL SHA256 CA
        Validity
            Not Before: Nov 25 00:00:00 2017 GMT
            Not After : Feb 23 23:59:59 2021 GMT
        Subject: CN=blog.hqcodeshop.fi

That's a GeoTrust Inc. issued certificate. GeoTrust is a subsidiary of Symantec. I did study the history of Symantec' certificate business and back in 2010 they acquired Verisign's certificate business resulting as ownership of Thawte and GeoTrust. RapidSSL is the el-cheapo brand of GeoTrust.

As instructed, I just re-issued the existing certificate. It resulted in:

Now, my certificate traces back to a DigiCert CA root.

That's all good. I and you can continue browsing my blog without unnecessary this-website-is-not-secure -warnings.