SIDEBAR
»
S
I
D
E
B
A
R
«
Silent browser redirect on invalid certificate
Nov 15th, 2018 by miki

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.

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;

  • Ubuntu 16.04
    • Firefox 62.0.3: warning, with trailing ‘/’: No warning
    • Chromium 69.0.3497.81: no warning, with trailing ‘/’: no warning
  • Windows Server 2016
    • Firefox 62.0.2: warning, with trailing ‘/’: no warning
    • Google Chrome 70.3538.102: no warning, with trailing ‘/’: no warning
    • Internet Explorer 11.2580.14393.0: warning, with trailing ‘/’: warning
  • Windows Server 2008
    • Firefox 59.0.3: warning, with trailing ‘/’: warning
    • Google Chrome 70.3538.102: no warning, with trailing ‘/’: no warning
    • Internet Explorer 11.0.9600.19080: warning, with trailing ‘/’: warning

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…

One-liner: Decompress file and diff against another file
Dec 8th, 2016 by miki

Below is a handy shell one-liner for comparing the decompressed contents of a compressed file against a plain file. The purpose here is to test whether the compressed file is actually derived from compressing the plain file. This particular example is from a real life situation where log rotation by cron.daily on a Ubuntu server had begun failing. The situation is thought to be the result of an interrupted logrotate execution leaving a compressed (but non-rotated) intermediate file in the file system that prevented further log rotation on subsequent executions.

The command constructs a pipe between two process, specified using the | symbol (vertical line), to send the decompressed contents from gunzip stdout to stdin of the compare tool. The example uses diff as compare tool which is suitable for textual contents. You could use f.x. cmp instead if the contents is binary. Both diff and cmp interprets the file name “-” as meaning that input should be read from stdin.

$ gunzip --stdout /var/log/syslog.1.gz | diff --report-identical-files - /var/log/syslog.1
Files - and /var/log/syslog.1 are identical

The above uses long options for clarity, in a real life situation you would probably be using short options instead. That means -c instead of –stdout and s instead of –report-identical-files.

$ gunzip -c /var/log/syslog.1.gz | diff -s - /var/log/syslog.1
Files - and /var/log/syslog.1 are identical

 

Huawei E1752 on Ubuntu 10.04
Jun 26th, 2010 by miki

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…

»  Substance:WordPress   »  Style:Ahren Ahimsa
© 2016 Mikini Services