A Very Strange Thing – Yahoo Sometimes Blocks Tallbloke Links

I didn’t know what to make of this. Could just be some kind of glitch, but I doubted it.

On my tablet (Samsung Galaxy Note) earlier today I was reading Tallbloke’s site. No issues looking it up with the search engine set to Yahoo!

This evening, I think with the same search tabs open, I click a link to an article ABOUT Tallbloke, and get a stern warning:



This link is not authorized by Yahoo.

If you would like to continue to this link's intended destination 
at your own risk, click here.

copyright etc. etc.

Just how one can copyright a boilerplate “continue at your own risk” is a bit beyond me, but they claim to…

So I try some more links. One directly to the site. Same thing. One to NoTricksZone about Tallbloke. Same thing. One to DeSmogBlog about Tallbloke. Same thing. It looks for all the world like Tallbloke is a Forbidden Word at Yahoo.

So I hit the Chromebox to post about it. Do the same search / click. It goes right through. No stern warning.

I screen captured it on the Note, but it isn’t very much more interesting than the typed text above (and would take a chip swap to copy over… which was why I was going to just screen capture it here and found out it isn’t happening on this box).

Now I’m not sure what to do. Is Yahoo only blocking on tablets? Is Chrome over riding it? Is there some setting I’ve missed on either one? If it IS a setting, is “Climate Skeptic” now a ‘dirty word’ unsuited for tender ears?

So I Go Fishing… for bits…

Now the Note comes with a default ‘lite’ browser and you can add on others (including FireFox). In this case, I’m using the lite one called “Internet”, of all things… I look in settings, “privacy and security” and find a check box for “Show Security Warnings” that has the text “Show warning if there is a problem with site’s security”.

So it may not be “Tallbloke” that’s the key, so much as some level of SSL encryption or Certificate Authority level. Un-checking the box lets things go right through. Checking it again, same Stern Warning.

At least now I can explain why the Note does, and the Chromebox doesn’t.

Yet all of the sites I listed gave the same “problem”. Do all THREE of them have some technical weakness?… or is the “security” problem something else?

At this point it is a bit ambiguous. It is also well past midnight (and bedtime). So any further exploration ought to wait for tomorrow. But I’m not like that…

I suspect that this is related to the move to tighter SSL encryption levels. There was an exploit found for the older 1.x and even 2.x IIRC. He does a quick search…

Oh Dear! Looks like not just the OpenSSL exploit, but even 3.0 has been found to have a potential exploit:


Alert (TA14-290A)
SSL 3.0 Protocol Vulnerability and POODLE Attack

Systems Affected
All systems and applications utilizing the Secure Socket Layer (SSL) 3.0 with cipher-block chaining (CBC) mode ciphers may be vulnerable. However, the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack demonstrates this vulnerability using web browsers and web servers, which is one of the most likely exploitation scenarios.
Some Transport Layer Security (TLS) implementations are also vulnerable to the POODLE attack.
US-CERT is aware of a design vulnerability found in the way SSL 3.0 handles block cipher mode padding. The POODLE attack demonstrates how an attacker can exploit this vulnerability to decrypt and extract information from inside an encrypted transaction.

So we’re off in the land of needing TLS instead of SSL… but maybe it isn’t quite enough…

The SSL 3.0 vulnerability stems from the way blocks of data are encrypted under a specific type of encryption algorithm within the SSL protocol. The POODLE attack takes advantage of the protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 and then leverages this new vulnerability to decrypt select content within the SSL session. The decryption is done byte by byte and will generate a large number of connections between the client and server.

While SSL 3.0 is an old encryption standard and has generally been replaced by TLS, most SSL/TLS implementations remain backwards compatible with SSL 3.0 to interoperate with legacy systems in the interest of a smooth user experience. Even if a client and server both support a version of TLS the SSL/TLS protocol suite allows for protocol version negotiation (being referred to as the “downgrade dance” in other reporting). The POODLE attack leverages the fact that when a secure connection attempt fails, servers will fall back to older protocols such as SSL 3.0. An attacker who can trigger a connection failure can then force the use of SSL 3.0 and attempt the new attack. [1]

Two other conditions must be met to successfully execute the POODLE attack: 1) the attacker must be able to control portions of the client side of the SSL connection (varying the length of the input) and 2) the attacker must have visibility of the resulting ciphertext. The most common way to achieve these conditions would be to act as Man-in-the-Middle (MITM), requiring a whole separate form of attack to establish that level of access.
These conditions make successful exploitation somewhat difficult. Environments that are already at above-average risk for MITM attacks (such as public WiFi) remove some of those challenges.

On December 8, 2014, it was publicly reported [2,3 (link is external),4 (link is external)] that some TLS implementations are also vulnerable to the POODLE attack.

So is Yahoo just warning me that I’m using SSL? Or that it isn’t the right kind of TLS? Or something else entirely? Their “copyright” stern warning being close to useless…

The major exposure is to Man-In-The-Middle attacks ( i.e. Your Government, PRISM, and NSA / related ) and anyone else with capture of a telco in the chain of service between you and the destination. It isn’t an easy attack to pull off, even with that. If you notice excess time taken to ‘negotiate’ a connection, then I’d do a reset / restart on it. There needs to be a lag time during which the ‘degrade dance’ happens, so if it isn’t quick, drop the link.

Since those are used for https traffic, even my Tallbloke Raid inspired disposable encrypted system would have some traffic exposure. The LUKS file system would still be secure. It is only the https session that can be compromised, albeit with a lot of work and made harder with The Onion Routing in use. IIRC TOR internal encryption is tighter, so you mostly have exposure at the exit node. That, too, might need a bit more R&D to assure.

I’m also pretty sure that ‘recording / playback’ of a session is not exposed, since POODLE depends on a negotiated fall back to a weaker encryption; any recorded session is not degraded, so ought to stay secure. This matters as “Agencies” in the USA are allowed by law to retain ALL encrypted communications and routinely record it ALL (somewhere in a giant facility in Utah, per rumors). No warrant needed. No ‘probable cause’ needed. No nothing needed. (So much for ‘reasonable expectation of privacy’ as a defense against snooping. The historical standard. It held that the outside of a postcard or envelope could be scanned and read as there was no ‘reasonable expectation of privacy’ but the inside of the letter was not allowed to be read as there was a ‘reasonable expectation of privacy’. You would think that “I encrypted it so it would be private” was for the purpose of having a ‘reasonable expectation of privacy’, but the government doesn’t think in straight lines…)

I’m not very worried, since I’m pretty sure nothing on any site I visit really needs encryption. I just do it to fill up their disks…

I may play with this a bit more on other systems. IIRC, one of my boxes complains when I connect to my own WordPress site that I don’t have a shared security protocol (since some folks have shut off SSL 1.x and 2.x and may have shut off all SSL forcing TLS, but older browsers don’t have TLS or SSL 3.0). So I’ll see if it complains in the same way about Tallbloke. If so, this is just a known security aggravation with https encrypted links and the rolling target that is SSL / TLS. Albeit presented in a lousy messaged from Yahoo… (copyright or not, it’s crappy and low information).

But that was a year ago. Is there something newer?


FREAK SSL/TLS Vulnerability
Original release date: March 06, 2015

FREAK (Factoring Attack on RSA-EXPORT Keys CVE-2015-0204) is a weakness in some implementations of SSL/TLS that may allow an attacker to decrypt secure communications between vulnerable clients and servers.
Google has released an updated version of its Android OS and Chrome browser for OS X to mitigate the vulnerability. Microsoft has released a Security Advisory (link is external) that includes a workaround for supported Windows systems.
Users and administrators are encouraged to review Vulnerability Note VU#243585 for more information and apply all necessary mitigations as vendors make them available. Users may visit freakattack.com (link is external) to help determine whether their browsers are vulnerable. (Note: DHS does not endorse any private sector product or service. The last link is provided for informational purposes only.)

So about 7 months back. I could see Yahoo taking that long to get it worked in… It is also well after the last update of my tablet, so my “Internet” browser will not be new enough to have any ‘fix’ applied.

I’ll leave searching for other exposures for another day…

Perhaps all that happened was that Yahoo raised the bar on what level of SSL / TLS is now a ‘complaint’ and that triggered the change of behaviour. If so, there will likely be many folks wondering “what happened”. I’ll likely just swap over to a different search engine, though IIRC, “Internet” browser had a very limited set of choices… which was why I had it set to Yahoo in the first place. While I normally use FFox on it, I have a bunch of open tabs at the moment in it and wanted to just do a ‘quick dip’ in Tallblokes discussion pond. Though it looks like I got sidetracked ;-)

Now added to my “todo” and maybe “someday” lists are:

Update browsers on the Tablet. Test same search / sites on the Raspberry Pi (with current Debian it ought to be OK…) so assure the Tallbloke Special is in fact secure. Test the tablet (prior to upgrade) against my own site, just to see. Wander the CERT notices to see if there is some new attack I’ve not noticed yet. etc. etc. All because Yahoo had a crappy (C) message…

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in AGW and GIStemp Issues, Political Current Events, Tech Bits and tagged , , . Bookmark the permalink.

9 Responses to A Very Strange Thing – Yahoo Sometimes Blocks Tallbloke Links

  1. punmaster says:

    Hmmm, I always assume everything is at my own risk. But I am an adult, most of the time, anyway.

  2. Tim Churchill says:

    I’ve been playing with the Tor browser over the last week. On several occasions Bishop Hill’s site would give me the ‘forbidden’. I had so much trouble with my Webroot ‘Secure Anywhere’ blocking Tor every time it updated I gave up. I don’t have your technical abilities!

  3. Larry Ledwick says:

    As I recall one of Yahoo’s claims to fame was that their search results were “moderated” and verified to be “safe” etc. etc. This was back before Google was the huge market leader it is now and search engines were sort of new and sometimes your search queries returned “surprising” results.

    It would suggest to me that one of their moderators (if they still use that model) took exception to tallbloke’s topics (some of them do go against the consensus in lots of areas) and flagged it as a suspicious site. I almost never intentionally use yahoo search the only exception is when I am checking search returns on a subject and getting what I suspect are filtered hits on Google or Bing or one of the other higher profile search engines.

    In that context they are not saying anything which is wrong, ie forbidden by them and not authorized by them would be technically correct if they do not approve of some of his content. I think it is intentionally worded as Big Scary warning to dissuade folks from even looking at the links without actually blocking.

    His stuff could have gotten flagged because of what someone posted as a reference link. Occasionally those go off into the weeds, especially if you are trying to illustrate some odd ball take on a subject, or pathetically incorrect conclusion.

    I normally use one of the aggregator sites which feed the search query to several sites but I do have to go back to google advanced search sometimes to get highly targeted search results.

  4. E.M.Smith says:

    Well. it’s not happening with the current Debian on the Pi… and IceWeasel.

    Now to reboot on an older release with older SSL handling…

  5. E.M.Smith says:

    The older “Wheezy” Debian with IceApe gives a ‘failed secure connection’ error on the front page of Yahoo. After retrying 3 times, it lets me in.

    (Error code: ssl_error_no_cypher_overlap)

    So I’m pretty sure what’s happening is that they are demanding a particular level of SSL (3.x+?) and refusing to make the connection until you present it. But let me try a couple of times, then ‘give up’ and go with the ‘degrade the connection’ and let me use a down level SSL.

    Yet it then lets me get to Tallbloke just fine…

    My suspicion is that it has gotten over the ‘challenge’ process and ‘set a bit’ somewhere saying “This guy is back level” so I don’t get the “security fail” on Tallbloke. Where the “Internet” browser on the tablet connects OK to Yahoo (so no bit set) but then I get the complaint on the Tallbloke connect attempt.

    I’m coming to suspect this is a ‘bug’ of sorts ( “unanticipated interaction artifact”…) between that particular odd old browser on the Tablet and something Yahoo is doing with respect to “SSL security”…

    It doesn’t seem to manifest on any other browser or SSL level combo that I have tried so far. (Maybe the antique Windows XP would tickle it, it’s decrepit and insecure 8-)

    If I can’t find any other test case to show the effect, I’m going to actually update the tablet and see what happens. I’ve avoided doing that in the (2? 3?) years I’ve owned it (mostly due to bad taste in the mouth from too many MS updates and a few ‘auto update’ Debian / Linux events) but as I’ve now moved most everything off of it, I’d not mind if something horrid happened. It would give me an excuse to finally install Linux on it ;-)

    At one point it was my entire “on the road” system and any risk was “not good”. Now it is just an auxiliary “browsing from the couch” screen and a place to occasionally watch videos. I scrubbed the on-board chip of any ‘me stuff’ a year or so ago, so one final “verification” pass that all is off of it, and I’m ‘good to go’ on the update.

    Probably need to finally copy over all those open tabs and “someday ought to post about this tab” links to the R.Pi first, though… Just in case the browser state doesn’t survive the update …

    So maybe one or two more comments by me, here, in the next few days, but it’s looking like something unique to that combination and unlikely to be experienced by others.

    For anyone wanting to try a test, I’m going to “yahoo.com” and then entering “Tallbloke Talkshop” as the search terms. That brings up his site, the desmogblog link, and the notrickszone link. All give the fail on the tablet, none fail on the Chromebox or R.Pi Raspbians.

  6. LG says:

    No issues observed on Win 7 with Firefox 42.

  7. Larry Ledwick says:

    May be an artifact of that big deal heart bleed SSL bug that forced everyone to update SSL to a non-broken version.
    http://heartbleed.com/ bug reference # CVE-2014-0160

  8. E.M.Smith says:

    Well, an update to the Galaxy Note and now it doesn’t have a problem.

    Looks like the “almost never used” browser was just not keeping up with the level of SSL being required by Yahoo “as of now”. While my main browser on it (FIre Fox) being installed more recently was fine. It also looks like the old browser on the R.Pi has a different interaction, so you get the “up front nag – then forget it” behavior from it.

    At this point I think it is a ‘closed issue’ related to SSL incompatibilities in a couple of things most likely not used together all that often.

  9. p.g.sharrow says:

    Well, bright and early this morning Thunderbird had the same issue with Hughes.net email servers. Godaddy certificates were no longer secure enough Mozilla. Not the first time Mozilla has deliberately broken things to force providers to update their server software by inconveniencing down stream users…pg

Comments are closed.