Unable to complete secure transaction - persisting!

  • It has come to my attention, apparently two months later than for everyone else, that Opera has disabled part of its SSL functionality, via a sort of a "back door" where user preferences are downloaded and set automatically. (I discounted the problem as site downtime/issue for a while.) The existence of the back door is terrifying in itself. ("we have disaled remotely...") But I need SSL3 and TLS1, the normal set of options, to get onto a couple sites. So far the other two haven't been needed. In order to rectify this disaster I have blocked in DNS: autoupdate.opera.com certs.opera.com Opera f.u!! The XML where the SSL settings were written is no longer being downloaded. Good. However, the "state" of these two sites has been preserved in my main Opera 12.11 "somwhere". Whenever I visit the site I get the error "Unable to complete secure transaction". Backup installations of Opera 8, 10, 11 work. I have installed Opera 12.11 in portable mode onto another disk: one of the sites work, the other one does not. I have moved out parts of my profile in Opera 12 to do with "crt" and "trust", then the entire profile except for "icons" (huge!), I have cleared my disk cache. Somehow these two sites never work in that main installation, even when it has no profile and has reverted to defaults. I have unticked every checkbox under Security, and rechecked them. This is driving me crazy!?? Where could the state of the SSL connections possibly be kept? If not in the profile? I'm not sure if I should mention the site name here, because it's kinda sensitive.

  • It seems that the sites that do not work are quite a few in number. A quick google search on the subject returned another one.

    How do I restore normal functionality of my browser? I tried reinstalling another "portable/USB" version of Opera 12, and it somehow pulled most of my main profile, including bookmarks into it, and didn't work from the start.

    Opera 12.11 (broken) vs Opera 11.62 (works). Security settings appear to the same on the surface. And still the disablement is rooted into my system somewhere.


  • I sent a bug report about this to Opera and they said that Opera 12 does not support ECDSA certificates. This is trange, because it works in Opera 10.10 for example. This has something to do with CloudFlares new universal certificate - every site that uses it can't be opened by Opera 12. It won't be fixed 😕

    EDIT: This is also in Opera Mobile Classic, here is the full answer:


    Thanks for your bug report.

    Opera Mobile Classic is a legacy browser that is no longer under active development. It is based in Opera Presto, which is also not under active development. Presto has never supported Elliptic Curve Cryptography, and never will. It also does not support GCM, which is used by that certificate.

    Opera Mobile Classic on Android was replaced by “Opera Browser for Android”, since May 2013. This supports Elliptic Curve Cryptography and GCM. Please use “Opera Browser for Android” instead.

    Thanks again for your report.

    Security Group
    Opera Software ASA

  • I'm sorry I was too upset. Looks like the change CloudFlare made and Opera's stunt happened to both coincide in Autumn 2014. Most CloudFlare sites still work.

    Opera 11.62 is somehow negotiating a different kind of encryption from these services:

    Not valid before: 2014-10-11 11:08:00 GMT
    TLS v1.0 128 bit AES (2048 bit RSA/SHA)

    It will probably be only a matter of time before CloudFlare stops making this exception. I am also being frightened by a red shield and skull icon on Opera's GUI because archlinux.org.ru (example) doesn't match the certificate domain (obviously, ssl2000.cloudflare.com).

    The user agent in site preferences don't seem to effect how the SSL connection is set up, probably because HTTP never has a chance to happen. Whatever the negotiation is based upon is something of a lower level. The sites that still do work, get what looks like the same type of RSA connection, but from a different certificate holder (ssl7149.cloudflare.com). Firefox 22 seems to get this "elliptic curve" already.

    All this encryption on public sites like forums and wikipedia is mostly unnecessary, a means to hijack the free internet, and how to send computers into planeed obsolescene. They make sites look broken or illegitimate with these warning dialogs and icons until they pay money for a meaningless certificate. Only last year, most of the popular (and boring) internet stopped being accessible on old PCs because of the 256-bit certificates, and now this.

  • Here is a workaround from the Opera forums: https://forums.opera.com/discussion/comment/15205022#Comment_15205022
    Maybe you can try it?

  • To make an https connection, several things must each happen correctly. The browser must contact the server which will (hopefully) propose back a security protocol (such as TLS1.2, etc) to the browser, along with a proposed encryption scheme supported by both the server and the protocol; the browser examines its own capabilities and its site certificate store, and if everything lines up with what the server proposes, it accepts the proposal and secure https communication with the site occurs. If things don't match up, a lower-security protocol may be proposed (though this doesn't necessarily always occur), and the process repeated until can be found a mutually-agreed set of protocols, encryption methods, and site certificates (linked to both the selected protocol and encryption method in order to be valid). If anything fails at either end (in protocol compliance, encryption methods linked to that protocol, or certs valid for both the protocol and crypto), the site connection will fail and the browser will cough up an error message.

    Since the Beast and Poodle protocol vulnerabilities were disclosed, the SSL3 protocol has been generally deprecated for usage by security experts. TLS1 had already come under attack earlier, and has long been deprecated for usage by security experts as well. Put another way, the https security offered by SSL3 and TLS1 protocols are significantly weaker than other protocols and their associated best encryption methods.

    At present, TLS 1.2 is considered the most secure protocol to use (with appropriately secure encryption methods), but many websites have persisted in either initially proposing or immediately negotiating downward to SSL3 and/or TLS1 protocols and their related crypto methods. Various browser makers have dealt with the deprecations differently, if at all. For example, Opera forced (via Presto Opera's auto-updater) a change to the user settings to shut off SSL3 in the browser; Firefox issued an extension that essentially does a similar thing, and so on. How well various browsers handled these protocol changes vs. a particular site's server operations/negotiations/certs is a matter of ongoing debate. Moreover, inconsistencies between the site cert records stored in a browser (or system, if the browser uses those) and the current server setups of sites offering such certs can readily lead to chaos in getting things matched up.

    Further problems can arise when an aging browser fails to include within itself the linkages to newer appropriate encryption methods that a site wants to use with a given protocol, or when the certificate store of the browser fails to match up completely/perfectly with the protocol and crypto being proposed by the server. This is all compounded by servers that behave differently under different negotiation challenges with such browsers: some may default to the lowest possible security levels, but the browser may have those disabled to guard against Beast and/or Poodle; some servers or browsers may not handle the negotiations equally well and simply "get lost" in the process; some servers may offer a protocol the browser possesses, but demand a crypto method the browser is unequipped to supply; increasing numbers of "universal" certs can confound the negotiations with browsers not designed around them. Any of these can lead to inability to set up secure communications… which a user sees via the dreaded "Unable to complete secure transaction..." message.

    At the end of the day, the only certain remedy is to either run with a modern browser or simply do without use of problematic https sites in an old browser. More important, the whole problem will only get worse for aging browsers, since there is current ferment in the protocol/crypto world: newer crypto methods, evolving protocols, continually changing site certs and cert methodologies, etc. Tricks and work-arounds within aging browsers will only hold up for so long.

  • @Brawl:

    Here is a workaround from the Opera forums: https://forums.opera.com/discussion/comment/15205022#Comment_15205022

    This workaround makes the sites added under the "approved" cateogory: archlinux.org.ru and sceneaccess.eu load, but doesn't work for other sites also going through CloudFlare, such as https://reboot.pro . How is this possible if the encryption method itself isn't known by the browser? How would I obtain/extract a certificate from a frequently visited site and add it under "approved" like they did?

    It seems that most affected sites now allow plain HTTP browsing, so this problem isn't particularly relevant. archlinux.org.ru for some reason feels the need to be "protected".

    The new files contained in that fix were considerably smaller than the ones they replaced. Going to the Opera page, immediately caused a non-fatal SSL error that needed approval from Gravatar, because "Go Daddy Root Certificate Authority - G2" was no longer included in the smaller files.


Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.