Hit an odd browser behaviour today.
Trawling through some of those nice and dandy terms for a service (no I won’t tell) I followed a link and suddenly hit an “insecure connection” message from Firefox.
Examining the certificate using the usual “openssl s_client” and “openssl x509” tools surely enough revealed that the served certificate didn’t include the second-level but only on the third-level www sub-domain. Strangely enough I discovered that when entering the same URL directly into the address bar of Firefox the connection was somehow redirected to the www sub-domain and loaded fine without any complaints from Firefox.
Looking into what was happening on the wire using wget directed to not check the certificate (–no-check-certificate) and displaying server responses (–server-response/-S) revealed that the server behind the misconfigured certificate was aiming to issue a HTTP 301 redirect to the valid www sub-domain of the site (actual site replaced by foo.bar and localhost ip);
$ wget –server-response –no-check-certificate –output-document=/dev/null https://foo.bar –2018-11-15 18:59:14– https://foo.bar/ Resolving foo.bar (foo.bar)… 127.0.0.1 Connecting to foo.bar (foo.bar)|127.0.0.1|:443… connected. WARNING: no certificate subject alternative name matches requested host name ‘foo.bar’. HTTP request sent, awaiting response… HTTP/1.1 301 Moved Permanently Content-Type: text/html; charset=UTF-8 Location: https://www.foo.bar/ Date: Thu, 15 Nov 2018 17:59:13 GMT Content-Length: 152 Location: https://www.foo.bar/ [following] …
Apparently Firefox’s behaviour in this scenario differs depending on the method in which the user is supplying the URL, in some cases silently ignoring the TLS/SSL warning. A little more experimentation revealed that it was actually not the source of the URL, link followed versus one entered in address bar, that made any difference. Instead it is the presence of a trailing slash on the URL that triggers the silent suppression of the serious red flag that the second-level domain asked to be fetched is not present in the served certificate. I was fooled by the fact that when entering URLs in the address bar Firefox suggests ending the URL on a slash (‘/’) if it is not already present. Manually removing this when editing in the address bar also makes Firefox display the security warning. Alas, the link I originally followed was also missing the trailing slash and behaved as expected by throwing me into a security warning.
The whole “feature” of silently ignoring a security issue seemed very odd to me, but a bit of searching revealed that this was apparently championed by Google Chrome a couple of years ago. It is described in this servertastic post which also directs to a discussion on Twitter, with some key points replicated below, about its presence in Chrome and confirmation from a Chrome team member that the behaviour is intended.
Interesting. Chrome recognizes https ://onlineservices.nsdl.com has a cert valid only for www and redirects to https://www… @Scott_Helme pic.twitter.com/j9XdqiXqAI — Anand Bhat (@_anandbhat) October 26, 2016
Interesting. Chrome recognizes https ://onlineservices.nsdl.com has a cert valid only for www and redirects to https://www… @Scott_Helme pic.twitter.com/j9XdqiXqAI
— Anand Bhat (@_anandbhat) October 26, 2016
invalid cert for raw TLD but valid cert for www will trigger redirection down to www — Adrienne Porter Felt (@__apf__) October 26, 2016
invalid cert for raw TLD but valid cert for www will trigger redirection down to www
— Adrienne Porter Felt (@__apf__) October 26, 2016
The thread ends with a guy who had dug up the source code of the feature in Chromium (on which Chrome is based) known as “SSLCommonNameMismatchHandling” in file browser/ssl/common_name_mismatch_handler.cc (see all mentions across code base).
This has obviously also trickled down into Firefox, however, not much mention of that is to be found. Not even traces of it by some quick searches of the mozilla-central codebase. Some day I promise (really!) to dig through all source of Mozilla and hunt down the implementation, but for now I’ll revert to a bit of practical experimentation showing the behaviour in the different browsers and operating systems I happen to have access to at the moment;
So somewhere between 59.0.3 and 62.0.2 Firefox also implemented a policy of silently accepting invalid certificates when certain non-obvious criteria is met (is the redirect actually followed and certs checked, or is “www.” just prefixed?), but this happens only when the URL ends on a slash. Go figure…
When dealing with policy enforcement for products that you distribute from business partners and whose sales your organization directly profits from, you’d think that you’d want to engage in some kind of communication with your peers before making drastic moves like shutting down distribution of these products. Especially when your peer is a national lottery organization partly owned by a European state, who is strictly professional about their business and which probably has a non-significant turnover facilitated by the product.
Well, if your are Google and runs the Google Play software distribution system for the Android platform, you apparently couldn’t care less. At least that is what a move today by Google implies, when banning an Android gaming app by Danske Spil, the national Danish lottery, who has a governement enforced monopoly on lottery in Denmark. This was done without any interaction with Danske Spil which of course was taken by surprise when realizing this, as reported (GTrans) by Danish tech magazine Version2.
Admittedly, as it stands now from an objective point of view, the app clearly breaks the content policy of Google Play which states that “We don’t allow content or services that facilitate online gambling”. So the real question, apart from the peculiar behaviour of Google towards this app provider for Google Play, is for Danske Spil; “How on earth did you think you could distribute an app through Google Play which so blatantly is in direct violation of the content policy?”.
Maybe the endorsement by the Danish legislation has risen to their heads, making them think their monoploy in Denmark made them so special that they could ignore Google’s standard policies? The current response from Danske Spil is that the app had been previously “approved” by Google, whatever that means because to my knowledge there is no verification procedure as such for content on Google Play (that’s a point for further investigation when time permits) .
At the moment not only the app itself, but also the provider page for Danske Spil A/S is inaccessible at Google Play, even though marketing from Danske Spil still tries to lure new users to the lotteries provided by the app, both from the web, TV and electronic billboards.
If your business model relies on outside partners (and which doesn’t?), this might be a good occasion to take the time for a second thought about what dependencies it has. And especially who is in the power to pull the carpet below it without interacting with you.
If I had a business with parts, components or services not under my in complete control, I’d prefer a partner which had a fellow human representing him, with which I could meet and look into his eyes. That way a social bond is created, which hopefully increases the probability that I will know if anything is about to happen that affects my business.
Today I managed to get a Huawei E1752 3G modem (USB id 12d1:1446/140c, usually called E1552 by lsusb) running on Ubuntu 10.04 without all the hassle described elsewhere (see this, this or this or this …).
This particular modem came from the danish cable ISP YouSee, in an offering known as Mobilt Bredbånd (mobile broadband), targeting their existing cable internet customers. Pricing starts at lowest offering of 1 Mbit/384 kbit transmission speed with 1GiB/month data limit at DKK 99/month (~USD 16.5 ~EUR 13.3).
As many recent USB modems, this one is a mode switching type with multiple personalities (Option ZeroCD(TM)). At plugin it defaults to an emulated CD mass storage drive (USB ID 12d1:1446), with an onboard Windows driver and dialer (Mobile Partner). When detected by a driver knowing it’s schizophrenic nature, it can be manipulated, utilizing psychotherapeutic tricks, to switch it’s personality to the modem it actually is (USB ID 12d1:140c). Hence, on non-Windows systems some magic needs to be established to make the modem actually behave like a modem.
One incarnation (se discussion about other stuff here) of this magic is called usb_modeswitch. That is also the solution chosen by the Ubuntu distribution team, and it is present in the repositories and configured for the Huawei E1752 in Ubuntu 10.04 ‘Lucid Lynx’, so we just need to know that we need it. You do now…
Activating usb_modeswitch is a matter of installing the usb-modeswitch package. Find it in Synaptic or issue the following in a terminal:
sudo apt-get install usb-modeswitch
Now all you have to do is insert the modem and check (we like to be certain, right?) with lsusb that you have the 12d1:140c modem device instead of the 12d1:1446 mass storage device.
The Gnome Network Manager should now pick up on the new modem device, and offer you the possibility of adding a new mobile broadband connection. In my case, it defaulted to an Oister connection, but removing that and using the wizard to create a TDC connection (YouSee is a part of/close associate of TDC) did the trick, after reinserting the modem once more.
Now I wonder why my own E160G modem works without usb_modeswitch installed…
