Opera 12 - Check for Update resets settings for TLS 1.1 and 1.2
-
Deleted User last edited by
I have enabled TLv1.1 and TLSv1.2 on my Netbook and PC. If i check for updates manually, teh protocols are disabled after update check.
- Open Opera settings with Alt P
- Select Tab Advanced -> Security
- For Auto-Updates select "Do not check for updates"
- Confirm with OK
- Open Opera settings
- Select Tab Advanced -> Security
- Select Security Protocols...
- Enable Security Protocols TLS 1.1 and TLS 1.2
- Confirm with OK
- Confirm with OK
- Select Opera menu button
- Select Help -> Check for Updates
- If a Window with information for new Updates occurs, close it
- Open Opera settings
- Select Tab Advanced -> Security
- Select Security Protocols...
TLS 1.1 and TLS 1.2 is deselected!
Thats means protocol TLS 1.1 and 1.2 is not enabled.Bug reported as DOA-827
-
blackbird71 last edited byI noticed this too a while back. I believe it's a consequence of how Opera addresses the Poodle vulnerability in a patch they repeatedly push to Presto Opera versions via each use of the updater function (scheduled or manual). Since I have every intention of sticking with Opera 12.14 for my secondary browser (because of the default search engine 'lock' on higher versions), I elected to disable the updater file itself by replacing it with a blank file of the same name, and simply forgo further 12.xx update checking by that route. Since I visit these forums continually, I choose to inform myself about any further Presto updating by this route instead.
With the updater file disabled, the settings can be re-applied manually and they will at least remain checked in the settings panel. As to whether/how that affects the TLS negotiation sequence compared to what it did before, I'm uncertain. If updating is manually attempted, a simple error message now results. In the future, if I should elect to revisit the updater process for some reason, I can always re-enable the updater file for that purpose, then go back and re-disable it and re-select the TLS boxes you noted.
-
Deleted User last edited by
Well, i know i can diasbele automatic update and reenable TLS v1.1/1.2. And never check for updates again.
Automatically downgrading to TLS 1.0 is not much secure because of BEAST attac.
-
rseiler last edited by admin
Reference thread:
https://forums.opera.com/topic/5826/unable-to-access-a-particular-site-since-yesterday -
blackbird71 last edited by
Thanks for the link, @rseiler... I lost track of that thread somewhere along the way. Since I only use Opera 12 as my secondary browser, I haven't run into the crashing (yet?) which some users noted in that thread when TLS 1.1 and 1.2 were enabled with SSL3 disabled. From the sound of things, it sounds as if there's some kind of problem in the downward protocol/encryption negotiations in Presto Opera for certain sites - perhaps those trying to use SSL3.
To make matters worse (if that's even possible), there's some indication now that certain implementations of TLS protocols also exhibit Poodle-like weakness:
https://isc.sans.edu/forums/diary/POODLE+Strikes+Bites+Again/19041.And, as @angiesdom points out, TLS 1 itself remains subject to Beast attacks... which makes the Opera update-pushed "fix" somewhat problematic in that regard.
-
-
blackbird71 last edited by
Do you recommend to disable TLS 1.0 ?
I apologize in advance for the length of this, but I know of no short way to explain it all... and, long though it is, it necessarily leaves out a number of security elements that have a bearing on things.
For access of a secure website, the browser and server must agree on a communications protocol and on the encryption type/level of the certificates and traffic. Ordinarily, the server sets the pace by initially suggesting to the browser whatever is programmed to be its highest-security protocol. If the browser is set to not accept that type of protocol, a downward negotiation is then supposed to occur to determine the highest-security mutually-acceptable protocol for both server and browser. The result is "secure" communications at the highest level of protocol and encryption that can be mutually handled by both ends of the path.
However, higher-security protocols and a coherent negotiation process require extra coding at the server and its software... and coding costs resources. So quite a number of sites initially offer a browser the lowest-security protocols (SSL3, TLS1) to avoid the extra coding/setup costs and complexity. Unfortunately, if a browser has deselected SSL3 and TLS1, then an agreeable protocol between that browser and such a server cannot be found (since the negotiation is initiated at the lowest level already and thus fails), hence secure communications between the site and browser cannot be set up. That is, the site "breaks".
As a result, typical advice for setting browser protocols used to be to allow TLS 1.2, 1.1, 1 and SSL3 and hope that the site server is using a higher-security protocol (ideally 1.2), but if not, then the browser would negotiate downward and an agreement with the server protocol could ultimately be found. When TLS1 was deprecated because of the BEAST vulnerability, that advice was altered to deselect the TLS 1 protocol. With the onset of the POODLE vulnerability, the initial thinking was to deselect SSL3 as well, leaving just TLS 1.2 and 1.1 protocols selected. However, that also meant that with 'most' websites initially offering the SSL3 protocol for their secure https sites, 'most' https websites were thus "broken"... and browser makers really don't want a lot of "broken" sites showing up in their browsers.
On top of all this is the reality that the certificates presented by the sites for secure communications must match up in detail for the protocols used, and for a lot of sites, there were gaps or holes in some of the certs for various protocols... which meant cert rejections showing up in the browser for what might otherwise be an acceptable security-level protocol. To further complicate things, not all negotiation implementations in the servers and browsers are necessarily "created equal"... and that can be yet another source of hiccups in establishing a secure communications path. Bottom line: it's all currently a genuine mess!!
At the end of the day, a user has to decide what he really wants. If he demands the most secure paths, then he should only allow TLS 1.2 and 1.1... but that means he may encounter a lot of broken comm-paths and certs.
Note: this all assumes that the SSL/TLS negotiation within Presto Opera obeys the typical flow for such things without crashing. Whether that's true, especially after the Opera update-pushed SSL3 patch that "unchecks" all the protocols in Opera except TLS 1, I simply do not know. I have some question about that, in part because some users reported (in @rseiler's link above) Opera stability problems when all the TLS protocols were checked but SSL 3 was unchecked... and that may indicate "irregularities" in the negotiation procedures.
-
-
Deleted User last edited by
@stng Yes, this disables and removes Autoupdate setting completely in Operas User Interface.
Disabling secure newer TLS protocols without any notice by Opera ASA is n no-go. Crashers with TLS v1.1 and v1.2 are serious bugs and should be fixed, but disabling protocols is more a Microsoft-like-"bugfixing". Making someones browser more insecure in such hidden mannor is "Security" enhanced by obsucre techniques.
So i have to check all Opera 12 installations, on Linux, Mac and Windows PCs.An other problem is: Opera has some weak ciphers as MD5 and SHA with TLS.
-
A Former User last edited by
Even with TLS 1.2 enabled, Opera 12 does not support AES-GCM. AES-CBC is weak. RC4 is broken.
Time to upgrade to stay secure.
-
Deleted User last edited by
Opera 12 has old/some weak ciphers.
Upgrade to Opera 26 or other browser should be better, but on some 32bit OS like Linux no Opera 26 exists at this time.
-
migorr last edited by
@blackbird71 : Thank you for such a detailed answer. This enlightens me enough to make a rational choice. I really appreciate it.
