iPlayer stopped working?

As someone wrote in another place:
"I'm starting to think that Humax haven't been paying their rent."

The strange thing is that later models were also affected at the same time. I don't suppose anyone at Humax created a certificate for, eg, FVP-4000T in 2010. Is it that the newer models been masquerading as HDR-Fox T2 but can be updated remotely? If there's a revalidated cert, maybe someone at Humax would like to post a copy in the CF forum!

When tested a few minutes ago, iPlayer was no longer displaying a warning about the problem, but still not playing the test show.
 
Is it something at the BBC end which is rejecting an obsolete certificate, or something at the Humax end? (If the latter, is there any way of setting the clock back and fooling it? Not that remember ever having to set the clock on it... assumed it was just something which is just broadcast with the DVB streams. Maybe there's an override somewhere though).
 
The BBC are still warning of a problem for the device, while Humax claim to have made a temporary fix; if so, it's not for HD/R-Fox T2 (at least not yet) because the Humax Portal still shows "Under maintenance" and blocks access.

With a test setup on a Linux PC (browser with certs imported from Humax, UA matching HDR-Fox T2), one can navigate to an iPlayer programme page and it works pretty much (or not) as on-box using new-portal.

On attempting to play a test programme ("Love Life E01"), the browser log shows errors attempting to access two similar URLs, of which the below is one, in code called from the LoadMedia() function in core_appstart.js:
Code: 
http://securegate.iplayer.co.uk/mediaselector/6/select/version/2.0/vpid/p08s6w6r/format/json/mediaset/legacy-iptv-sd/jsfunc/_antie_callback_ms_p08s6w6r/proto/http/transferformat/plain
The failure is SSL_ERROR_HANDSHAKE_FAILURE_ALERT and this looks like the situation described here, though I can't be certain whether the failure is an artefact of the test setup (eg, the imported certs are not being used) rather than that the browser doesn't have a valid client certificate matching one of those listed by openssl s_client -state -prexit -connect securegate.iplayer.bbc.co.uk:443.

The TV Portal doesn't check the device certificate but it does have some JS that tries to obtain the device characteristics using (what I think are) OIPF interfaces and punts to a "Humax STB only" page if that doesn't pass muster. Some NoScript work allows one to open the Portal page, but then it needs the OIPF stuff to populate the apps.
 
Going a bit off topic but can anyone explain why Humax have the access to iPlayer going through their own portal?
 
The normal process is that the STB user opens the TV Portal; the TV Portal (a Humax OIPF website) provides the applications, including iPlayer. In the case of iPlayer, the Portal application redirects to a cloud page which in turn redirects to the BBC iPlayer site.

If the new-portal CF package is installed, the first step is skipped, and activating the iPlayer icon just navigates to the cloud redirect page; the Humax Portal doesn't play an active part.

Once the STB is connected to the iPlayer site, the BBC iPlayer code (as above) requires a client certificate that matches its list of known STB suppliers in order to serve the playlist that's used to stream a show. This allowed Humax the opportunity to create a certificate with a lifetime less than the reasonable life of the rest of the STB, whether by accident or otherwise.

Quaintly, basically the same playlist is available to non-STB clients, but only after going through the pointless login rigmarole. As the formats of the playlist URLs are actually available through a BBC tool, third-party tools are able to use them without either of the above limitations. In fact, perhaps some user JS configured in the STB Opera browser could change the STB iPlayer playlist URL to a PC iPlayer playlist URL, and so bypass the expired certificate issue.

The current trend is to force server certificates to have short lifetimes and so to require a means of updating them regularly. One consideration is the possibility that a certificate may last so long that its encryption becomes vulnerable through new techniques or just Moore's law. It's not entirely clear why the HDR-Fox T2 client certificate wouldn't have a very long lifetime, since the importance of its security would decay as the product aged. Although certificates may be set to expire in 9999, Year 2038 may be a more realistic limit.

This article explains what a nest of worms the whole digital certificate business is. Who needs the Great Firewall when you've got TLS?
 
If all Humax models can use the same certificate (and it isn't personalized to a specific machine) if we can get a copy of the new certificate we could possibly create a boot time routine to replace the obsolete certificate in flash storage.
 
See post #41?

I'm not sure how a client certificate in RO flash gets imported into the Opera working certificate store in RW flash, but from file modification time the STB program may do this at start-up.

If so, a new CF should be able to include a revalidated certificate, and I doubt it would matter which Humax device it claimed to be, or even if it were for another STB type altogether, as long as the supplier is on the BBC's favoured list.

The corollary is that it might not be possible to update the working certificate store separately, and even if one inserted a copy of the updated store it might get trashed by the STB program.

The root certificates appear to get updated from /usr/browser/opera_dir/certs/root/* when starting the TV Portal.

See also /usr/browser/client.conf; this looks like a Humax file as the comments don't show the superb English expected of Opera's 2010-era Norwegian programmers.
 
The root certificate import folder is also RO.

The equivalent desktop Opera version had a settings UI for updating the root certificate store, though I'm sure up-to-date root certificates also came with program updates. I guess that the embedded version has an API for it, perhaps like one or more of these:
Code: 
humax#  nm -DC /usr/browser/lib/libopera.so.3.2 | grep certificate
005310d0 T op_close_certificate_manager
0053115c T op_create_certificate_manager
00530fb4 T op_delete_certificate
00531000 T op_get_certificate
00531068 T op_get_number_of_certificates
00534818 T op_import_certificate
00534790 T op_import_certificate_noninteractive
00534928 T op_set_certificate_manager_master_password
0053489c T op_update_certificate
humax#
 
Last edited:
If a Humax HD/R-Fox T2 believes that the IP address of securegate.iplayer.bbc.co.uk is that of open.live.bbc.co.uk, the iPlayer app starts working: test shows "Love Life E1-4". I'd say this is at least as reliable as before, say 30% chance of playing a desired show without a hang or crash on HD-Fox T2: HDR may be better, and a freshly rebooted system similarly.

Apparently the STB and general playlist URLs (post #46) have identical formats apart from the domain; however, it's always possible that some formats available for STBs might not be listed for general use, or that no formats are listed for some programme.

The necessary delusion might be ensured by, eg:
  • writing the mapping of the domain securegate.iplayer.bbc.co.uk to the other IP address (currently 212.58.249.158) into the STB's hosts file, using CF;
  • directing the STB to use a DNS, perhaps a local proxy, that either resolves securegate.iplayer.bbc.co.uk directly to the other IP address or, preferably, aliases it using a CNAME record.
The second method could be applied with normal DHCP configuration of the STB and doesn't require CF.

Whatever method is used, CF is required (new-portal) to reach the iPlayer app in the first place as long as the Humax TV Portal site is blocking iPlayer.
 
The point about CF is that some hold-outs insist on running the retail firmware. Delusion method #2 could work for them, although they would have to tweak their home network instead. While a tweak to the firmware of the CF itself might make delusion method #1 easier, as you say, it's not required.

In my test just now,
  • the Humax Portal is now allowing access to iPlayer, so delusion method #2 becomes feasible for the hold-outs;
  • (but then) playing a show gives error 02001, which is linked in the iPlayer code to MEDIA_SELECTOR_LOAD (as always since the certificate expiry);
  • after restarting, spoofing the IP address and launching iPlayer via new-portal, the show plays.
 
Yes, I was mistaken, it needs a 'delusion' in order to be able to play anything.
It might be best to make a new package though. That will then give the user the option to use the standard portal or install the new-portal.
 
We should be holding out for the supplier's firmware update, but then I ought to be complaining to them, and TBH fixing it oneself is a less painful experience, especially since the iPlayer application is so flakey.

This script could be used in a CF machine. It ought to be run regularly (every few minutes? further study needed) as the DNS mappings change quite frequently. The busybox CF package is needed for nslookup.
Code: 
#!/bin/sh

lookup() { # dns_name
        nslookup "$1" | 
                tail -n +4 | 
                grep -m 1 -E "^Address [0-9]:" | 
                (read -r _ _ ip _ && echo "$ip" ) 
}

SCG=securegate.iplayer.bbc.co.uk
OPL=open.live.bbc.co.uk

ip="$(lookup "$OPL")"

[ -z "$ip" ] && exit 1
# dnsmasq DNS caching proxy, started by /etc/init.d/S41dnsmasq
killall dnsmasq 2>/dev/null
# -A /X/Y  - always return IP Y for domain X
/usr/bin/dnsmasq -A "/${SCG}/${ip}"
 
/df said:
We should be holding out for the supplier's firmware update
Click to expand...
Why would any supplier devote resources to providing an update for an end-of-life product? What's more, the main method for distributing HDR-FOX/HD-FOX updates is no longer available.
 
For CF users it should be added to /mod/etc/hosts and then rebooted afterwards.
e.g.
Code: 
echo -e "212.58.249.158\tsecuregate.iplayer.bbc.co.uk" >> /mod/etc/hosts
Edit: I didn't see the previous two messages before posting this!
 
You must log in or register to reply here.
Back
Top