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:
YAHOO! Forbidden 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:
SSL 3.0 Protocol Vulnerability and POODLE Attack
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. 
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…