Do more on the web, with a fast and secure browser!

Download Opera browser with:

  • built-in ad blocker
  • battery saver
  • free VPN
Download Opera

Opera 12 - Check for Update resets settings for TLS 1.1 and 1.2

  • 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. 😞

  • 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:

    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.

  • Do you recommend to disable TLS 1.0 ?

  • 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.

  • 17 . opera:config#UserPrefs|DisableOperaPackageAutoUpdate = on

  • @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.

  • 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.

  • 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.

  • @blackbird71 : Thank you for such a detailed answer. This enlightens me enough to make a rational choice. I really appreciate it.