Message: "The server attempted to apply security measures, but failed."

  • Using: Opera 12.01, Win 7 home premium, 64-bit (boo).

    Every time (without exception) I connect to an https URL, if I click on the round icon to the left of the URL (where the padlock would be if there were one), then select the "details" tab, I get that message. Other browsers connect securely to the same sites. Again, this happens with every https URL.

    Any idea what's the problem?

    bb.

  • >> May be Missing Certificate, wrong SSL/TLS protocol.
    >> I cant guss which server.

    >> Can you please supply a URL?

    All servers. All https URL's.

    Other browsers have no problem with the same servers.

    Sure looks like it's not the server.

  • GwenDragon said:

    >> Did you try it with Opera 12.16?
    >> Which Protocols are active?
    >> Do you have Opera Turbo activated?
    >> Do you use a Desktop firewall or Antivirus scanner scanning port 443?

    Normally, I have all inbound connections blocked in the firewall, AVG and MBAM active, Opera Turbo may be on or off (though it automatically turns off when Opera tries to apply encryption, so that shouldn't make a difference), and SSL and TLS 1.0 enabled.

    For testing, I turned off the inbound firewall block. Then I turned it back on and shut down the scanners, enabled TLS 1.1 and 1.2, and disabled Opera Turbo. None of these changes had any effect.

    Running Opera 12.01 on another computer had the same problem, which is suggestive.

    I was hoping to find the cause of the problem (a known problem with a known solution would have been ideal) rather than just move to another version and hope it doesn't recur because I don't know what causes it or what to do about it. But at this point, pinning it down is looking like it may not be efficient. And since 12.16 is the last and presumably greatest version of Opera, I would be getting it sooner or later.

    Thanks for the help.

    BB

  • >> Seems tha was a bug in 12.01 which was fixed in 12.10

    >> Unable to complete secure transaction (with an error) under certain conditions
    >> Opera isn't connecting to some secure pages correctly
    >> See http://www.opera.com/docs/changelogs/unified/1210b/bugfixes/

    Thanks. That's comforting. There wouldn't happen to be
    more about this? Don't bother looking around -- I'll do that
    myself if need be.

    Strangest thing -- I couldn't find anything that made a
    difference. Then, on one machine, I ran my routine cleaning
    -- wipe cookies and flash cookies, clear history, reset the
    LSO settings, etc., and Opera started doing https again. So
    I figured at least I had the problem on the other machine,
    for testing. And indeed, I found that mounting and
    dismounting the drive with the Opera data files on it did the
    trick. I could turn the problem on and off at will. But
    then I unthinkingly dismounted the drive while Opera was
    running before exiting. When I put everything back together,
    the https problem was solved, and I could no longer duplicate
    it. Since then, the problem has come and gone, and I'm
    beginning to narrow down when it happens, but not yet narrow
    enough.

    >> Why don't you update Opera to 12.16?

    I plan to. However, at the moment, the rattle may be at bay,
    but the part that caused it is still loose. Updating now may
    solve the problem once and for all, but maybe not. Unless it
    returns, how would I know?

  • Originally posted by bbadonov:

    ...Updating now may solve the problem once and for all, but maybe not. Unless it returns, how would I know?

    If it doesn't return after installing a different version, why would it matter... or do you mean something else? Just continue keeping an eye on that security icon (which you indicate you do anyhow)... as you've already seen, if something is amiss with Opera being able to connect securely, it will let you know.

  • >> If it doesn't return after installing a different version, why would it matter... or do you mean something else? Just
    >> continue keeping an eye on that security icon (which you indicate you do anyhow)... as you've already seen, if
    >> something is amiss with Opera being able to connect securely, it will let you know.

    Yes, I sort of mean something else, though I do understand what you're saying. I'll try to clarify.

    It's counterintuitive. The instinct is to try one thing after another until the problem goes away and then consider it solved. But the best thing to do first is the opposite -- be able to reproduce it on demand.

    Suppose I try something and the problem goes away. If the problem shows itself again, I know for sure it wasn't solved. But if it doesn't show, is it solved? Maybe it just won't show for a week. Or months. When I cleared out the data, the problem did indeed go away for a week, but it wasn't solved. Another example: The date on my 12.01 download is August of 2012, and my query in the forum was in January of 2014. The problem didn't show for well over a year, but it existed all that time.

    Yes, I can keep my eye on the security icon, but humans are bad at maintaining vigilance watching for something rare. That's why personnel at security checkpoints routinely fail field tests. They're not incompetent. Humans just aren't suited for that kind of job. In fact, my problem may have happened sporadically during the year and a half before I noticed it, despite the fact that I am good at watching for security problems.

    Now, suppose instead of trying things until I no longer see the problem, I first find out how to reproduce it and turn it off at will. Then I apply a solution. Right away, I try to reproduce the problem. If I can (and I confirm it by using my verified method for turning it off), I know it's not fixed. If I can't, then I know the problem is fixed -- not just that it hasn't shown itself yet. It's really fixed. Note that once I try a possible permanent solution without knowing how to test it, I forfeit being able to know for sure that it actually got rid of the problem. Not to mention the obvious fact that knowing how to trigger a problem may be all I need to know in order to prevent it.

    Still, after all the wordiness, I may eventually decide not to spend more time on the problem. But I'm in no hurry. I'm not painted into a corner and desperate. I have plenty of alternatives. And I can switch strategies any time I want. I may decide not to bother further, and just upgrade and hope for the best. If my choice affected others, that would be irresponsible, but as it is, it's just my problem.

    I hope this is clearer than my previous post. Thanks to those who have looked at the problem, and especially those who have responded.

    BB

  • OK, now I understand what you meant. Unfortunately, getting a yes-no answer about whether what you occasionally see in 12.01 is possibly an intermittent flaw for that version, as noted in the change-log for a later browser version in the series (a series no longer being actively developed and with its designers scattered to the four winds), is going to be harder than impossible. About the best you might hope for is to use both the problematic version (12.01) and a supposedly "non-problematic" (12.10 or later) side-by-side and interchangeably for an extended time period. If the problem never appears in the non-problematic version, but does occasionally recur in the problematic version, then you'll have as "solid" a confirming answer as you're probably ever going to get. Otherwise, just live with a diminishing residue of uncertainty, as long as the problem stays gone with a newer version. 😉

  • Sayeth blackbird71:

    >> ... If the problem never appears in the non-problematic version, but does occasionally
    >> recur in the problematic version, then you'll have as "solid" a confirming answer as
    >> you're probably ever going to get. Otherwise, just live with a diminishing residue of
    >> uncertainty, as long as the problem stays gone with a newer version. wink

    One perfectly good approach, albeit probabilistic. The alternative is to find out how to trigger the problem first, then use that to test any proposed solution. Could take longer, or could immediately point to the solution. Either way, once it's fixed, I know it's fixed.

    A good example: We had a computer with a monitor that blinked on and off. So a technician comes out and replaces the boards most likely to cause the problem. (The monitor was in the box with the motherboard.) Everything works fine, if only because it's an intermittent problem. He leaves, and all's fine for a day or two.

    Problem comes back, so this time they send out a guy in a three-piece suit with leather briefcase full of boards and tools. He replaces more boards, and the problem stops again. For a few days, and then it's back.

    Third time, they send out the big gun -- girl in baggy sweatshirt. She opens the box with the power on, sticks a screwdriver in there and starts poking things. In less than a minute, the monitor goes off. She reaches in and shows me a loose wire. At that point, the problem is solved, even though it still isn't fixed. She tightens the wire down. Fixed for good.

    This was back in the days when desktop computers were expensive. Replacing all those boards, plus the cost of two technician visits, had to cost plenty. Wasted, because the first two technicians tried to find the solution without first finding the cause.

  • Originally posted by bbadonov:

    Sayeth blackbird71:

    >> ... If the problem never appears in the non-problematic version, but does occasionally
    >> recur in the problematic version, then you'll have as "solid" a confirming answer as
    >> you're probably ever going to get. Otherwise, just live with a diminishing residue of
    >> uncertainty, as long as the problem stays gone with a newer version. wink

    One perfectly good approach, albeit probabilistic. The alternative is to find out how to trigger the problem first, then use that to test any proposed solution. Could take longer, or could immediately point to the solution. Either way, once it's fixed, I know it's fixed. ...

    And, since you're apparently the only one with the 12.01 problem at the moment, the ball would be squarely in your court to find out how it's being triggered.

    As noted earlier, others using 12.01 had 'https' problems perhaps similar to yours, at times... the developers thought they solved those problems with some unknown code changes that were incorporated into 12.10, according to change logs from that era. At this present point in time, any remaining 12.01 users are either not having the problem or are living with it; any Presto developers still around who might be familiar with the problem are gainfully employed doing other things - in any case, they don't seem to be reading this thread. And, of course, there's no way of telling now whether the other 12.01 users' https problems were actually the same as your https problem.

    So at this point, you're stuck using a browser version having a known https problem supposedly fixed in a later coding update, but unsure whether your https problem is that https problem or whether the "fix" was really adequate. I realize curious minds would love to get a solid yes-no answer to all of this... but that's extremely unlikely to happen, given the age of the versions and all that has since flowed over the coding spillway within Opera ASA in the past couple of years. It seems to me that the simplest approach to dealing with this Gordian knot is to use Alexander's approach and, rather than spend untold effort trying to untangle it, simply cut the knot in two: try a later version (12.10 or above) and use it over time to see if your problem has been fixed. If it remains, that at least gives you some information to help isolate what is causing it, since if it persists into very recent Old Opera versions, other users haven't been reporting it... so it then ought to lend itself to solution apart from the intractable 12.01 version issue, with the help of some of those later-version users.

  • >> It seems to me that the simplest approach to dealing with this Gordian knot is to use Alexander's approach and, rather than spend
    >> untold effort trying to untangle it, ...

    Well, this is getting nowhere, isn't it? Mind set, perhaps. It's not a horrendous technical conundrum. I don't want to fix Opera or find why the problem is happening. At this point, all I'm asking is when it happens and when it doesn't.

    This requires no effort. I use the computer as usual, note when the problem comes and when it goes. Doing that (and about three minutes' extra work doing things to narrow it down like changing the cache size, and changing when I run CCleaner and wipe the LOS's and all), I have a good idea of what triggers the problem. Not the ultimate cause, just the proximate one (the circumstances).

    I pretty much know when the problem happens now, and I can turn it off at will. I'd rather narrow it down more (remember, the goal is to be able to turn the problem on, not off), but that will come, and I'm in no hurry. Then I can immediately and conclusively confirm any proposed fix. All pretty much effortless. That confirmation step is the important difference between a problem that's solved and one that's known to be solved.

Log in to reply
 

Looks like your connection to Opera forums was lost, please wait while we try to reconnect.