b 3347 does not recognise valid/authentic VeriSign Class 3 SSL certificate

b 3347 does not recognise valid/authentic VeriSign Class 3 SSL certificate

system WIN 7 Ultimate 64 bit

Opera on https://www.gmx.net

opera.png

other browser, e.g. minefield is just peachy with it

minefield.png

and yes, TLS is enabled in opera, just in case

opera tls enabled.png

Hmm, no problem here. Shouldn't happen. Perhaps an upgrade problem? Or is this a fresh install?

gibson

Wel I see it to, but I think it's a site problem and not Opera's.

The same certificate is working perfectly on Verisign own site

Originally posted by ytsmabeer:

Wel I see it to, but I think it's a site problem and not Opera's.

The same certificate is working perfectly on Verisign own site

Don't concur. All other mainstream browsers do not have this issue and also Opera did not prior the last beta either.

Originally posted by gibson:

Hmm, no problem here. Shouldn't happen. Perhaps an upgrade problem? Or is this a fresh install?

gibson

upgrade from b 3344, seems like a regression

Originally posted by vtol:

Don't concur. All other mainstream browsers do not have this issue and also Opera did not prior the last beta either.

While other browsers really don't have high standerts on such things, if it worked on Opera prior to 3344 than, please report it to Opera and place the bug# number here

I think Opera security manager would like it

http://my.opera.com/community/forums/findpost.pl?id=4738191

Originally posted by yngve:

http://my.opera.com/community/forums/findpost.pl?id=4738191

even if that true, the loss of data in that file, it is related to the development of this browser since other browsers do not suffer from such loss of memory...

also, this is a certificate rooted/issued by Verisign, one of the major issuers, and not something fancy/phony I had accepted somehow before. Opera should not fail under any circumstance to recognise such a class 3 certificate, else I would start wondering about the reliability and safety of this product. Or perhaps, I should already, considering the workaround given by a senior developer.

Anytime data is stored outside the application, in files on the disk drive, and not hardcoded in the application, there is the potential for dataloss of this kind. It is part and parcel of giving the user the opportunity to adjust settings.

The most likely cause for a loss of data is a crash, but a full disk drive is also a possibility, which probably truncated the file containing the certificate. As long as that file is even partially present on the system it will not be replaced because to do otherwise could destroy your own settings (which might conceivably have included manually and intentionally deleting those certificates).

We are, however, investigating what is causing this, but we need more information. For example: Did Opera crash for you sometime before the problem developed? If so, did you use the built-in crashlog system to file a crashlog? And further, if you did, did you include any identifying information in the log so that we can locate it?

thanks for the feedback/explanation.

got a hdd with total 3 partitions, the least amount of free space reads 60 GB, hence that cannot be the issue.

opera did not crash either, hence do not see the causality here.

my bank is using also using a class 3 certificate of Verisign, so does Paypal, no problem on either site...

as mentioned earlier my bet is that the upgrade to b 3347 broke it, but I am just a user.

and forgive my ignorance, but even if a crash would be the cause this is still not supposed to be happen, other browsers may crash also from time to time, damaging caches or whatever files they rely on, but that a valid class 3 certificate by Verisign is not recognised is news to me. In particular for no other reason that if the file in question is corrupted it may open the the door for malicious certificates not getting recognised as such

Originally posted by ytsmabeer:

While other browsers really don't have high standerts on such things,

I think Opera security manager would like it

you made me curious, which of the main browsers are suffering low standards on certificate recognition and in which way?

seems there is senior developer interested in the matter and willing to look into it, hopefully that will get fixed sometimes soon

maybe there is more to this issue

http://my.opera.com/community/forums/topic.dml?id=446211

I just went to linux and discover there the same issue with https://www.gmx.net

after digging around a bit I have to admit that there could be also the chance that the SSL certificate on this site is forged by an unknown party and Opera is actually right about it by not recognising. It is quite scary though to consider that VeriSing's class 3 SSL certificates are actually forged that well that it would be difficult to discover the man-in-the-middle attack. is it somehow possible to verify the actual authenticity of certificate on gmx.net or whether it is an actual bug in Opera? Though the chance would rare it would make a lot of sense for either cybercrime or surveillance bodies to monitor such a large email provider by breaking into the SSL chain.

article

http://www.wired.com/threatlevel/2010/03/packet-forensics/

research paper

http://files.cloudprivacy.net/ssl-mitm.pdf

Actually, forget my suggestion above.

This turns out to be a different problem discovered and fixed a month ago, but it is caused by the incorrect certificate configuration of the gmx server. The server does not send the intermediate CA certificate needed to complete the chain to the root. Opera is able to retrieve the missing certificate, but due to an error in the code handling the retrieved certificate it is not used. The site can fix this easily by adding the intermediate CA certificate "VeriSign Class 3 Extended Validation SSL SGC CA" to the certificates sent by the server, and strictly speaking the server is required to send it by the TLS standard.

Originally posted by yngve:

Actually, forget my suggestion above.

This turns out to be a different problem discovered and fixed a month ago, but it is caused by the incorrect certificate configuration of the gmx server. The server does not send the intermediate CA certificate needed to complete the chain to the root. Opera is able to retrieve the missing certificate, but due to an error in the code handling the retrieved certificate it is not used. The site can fix this easily by adding the intermediate CA certificate "VeriSign Class 3 Extended Validation SSL SGC CA" to the certificates sent by the server, and strictly speaking the server is required to send it by the TLS standard.

thanks for the follow up.

so basically GMX is in violation of SSL handling?

any chance that you get in touch with gmx? I will see to it from my end

Originally posted by vtol:

so basically GMX is in violation of SSL handling?

Yes, specifically section 7.4.2 of RFC 2246 (and newer versions)

certificate_list
This is a sequence (chain) of X.509v3 certificates. The sender's
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the
root certificate authority may optionally be omitted from the
chain, under the assumption that the remote end must already
possess it in order to validate it in any case.

As mentioned, we do have code to retrieve it (which suffered a regression), but AFAICT this missing certificate is causing similar problems in a default installation of Firefox 3.5, at least.

Originally posted by yngve:

but AFAICT this missing certificate is causing similar problems in a default installation of Firefox 3.5, at least.

Just checked on firefox 3.6 and indeed there are same problems with certificate, but(that's probably the regresion) there are all certificates loaded

Thanks for the info Yngve

Originally posted by yngve:

Originally posted by vtol:

so basically GMX is in violation of SSL handling?

Yes, specifically section 7.4.2 of RFC 2246 (and newer versions)

certificate_list
This is a sequence (chain) of X.509v3 certificates. The sender's
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the
root certificate authority may optionally be omitted from the
chain, under the assumption that the remote end must already
possess it in order to validate it in any case.

As mentioned, we do have code to retrieve it (which suffered a regression), but AFAICT this missing certificate is causing similar problems in a default installation of Firefox 3.5, at least.

Been in touch with GMX support, their response basically stating that their is no foul-play their end. Is in German, if you feel like translating:

Unsere Entwikler haben den von Ihnen geschilderten Sachverhalt geprüft
und konnten keinen Fehler feststellen. Die Zertifikate werden von uns
korrekt ausgeliefert. Somit ist ein Fehler von GMX ausgeschlossen.

I am at b 3366 now, still this problem is persistent, indicating that this not being worked on.

I am ditching Opera, cannot not trust it anymore, besides the buggy reality and stiff upper-lip to blame things an everybody else than their own development

Originally posted by vtol:

I am ditching Opera, cannot not trust it anymore, besides the buggy reality and stiff upper-lip to blame things an everybody else than their own development

I think that you maybe should not trust GMX anymore.

Just tested the site with Fx, Chrome, Opera, and IE and only IE indicates that all is OK
So I gues you're gonna go to IE

Right, again pointing to anybody else but ...

as mentioned and shown at the beginning of the thread FF Minefield does not have any trouble with the site and reports certificate in order.

Safari 4.0.5 - no problem safari.png

Chrome 5.0.342.9 - chrome 5.0.342.9.png

So that makes it 4 major browsers not having trouble with this certificate, leaves me puzzled:

1. you stating wrong facts - why would you do that?
2. all those 4 browsers are that buggy coded by handling SSL certificate wrong, except for Opera?
3. pointing again at a 3rd party to blame for something not going the right way with Opera, do you believe this the right path to higher merits in the browser heaven? well, that was rhetorical, as it obviously seems to be that way.

So, what we are looking at? 4 mainstream browsers not having trouble with the certificate, statement from GMX vs statement from Opera. Holds my assessment that Opera is not trustworthy by mishandling SSL certificate, unless you can prove and convince reasonably/rationally that GMX is a fraud supported by those 4 others browsers.

Ahem, why this only started to happen during the course of beta 10.52 but not prior? The certificate did not change meantime, but prior 10.52 Opera did not have trouble with site/certificate at all, coincidence - if so coinciding with what?

Originally posted by ytsmabeer:

Now Opera, Opera has an regression, as Yngve allready stated, which would normally retrieve the certificate, but that's why it's an regression it doesn't do that now.

Looks like GMX has some stuff fixed allready because Chrome is now accepting gmx as EV certificate, looks like they are learning.

so, gmx fixed then stuff, without you being specific what stuff, since your last post? interesting!

look, do not be offended, but I am posting here for getting it fixed, and not just for the sake of posting. would appreciate if you do not strain the thread with comments beyond your knowledge, which obviously is the case here

Originally posted by ytsmabeer:

What GMX fixed is less http links
A https page may not have any http links cause http link to unsecure pages and are therefore not secure.
If an https page has http links than Opera doesn't display an padlock but an ? like in Opera 10.10
So less http Links is more secure. Well they aren't there yet!!!!

see, you do not know what this thread is about, what you are writing is correct though but besides the topic - please do not spoil it

File it https://bugs.opera.com/wizard and place the bug# here
also don't forget to name in the bugrapport that https://service.gmx.net/ works like it should

can you please just leave it alone, there has been an opera developer on this thread, so they are obviously aware but it seems questionable whether anything is done about it, although hiking for the next rc/rtm of 10.52

and most users would not dig into the bug list but rather read it in the forums.

just begging you! it is totally uncool what you are doing here, killing the matter with nonsense

Originally posted by yngve:

Originally posted by vtol:

so basically GMX is in violation of SSL handling?

Yes, specifically section 7.4.2 of RFC 2246 (and newer versions)

certificate_list
This is a sequence (chain) of X.509v3 certificates. The sender's
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the
root certificate authority may optionally be omitted from the
chain, under the assumption that the remote end must already
possess it in order to validate it in any case.

As mentioned, we do have code to retrieve it (which suffered a regression), but AFAICT this missing certificate is causing similar problems in a default installation of Firefox 3.5, at least.

10.53 and still persistent....

Just discovered and been wondering since then why Opera is injecting its own certificate into the SSL communication with the server? That is basically a violation of every SSL/TLS standard and as such posing a Man in the Middle! That is not trustworthy at all!sitecheck2.opera.png

sitecheck2 is the fraud protection server, over a separate connection

Originally posted by yngve:

sitecheck2 is the fraud protection server, over a separate connection

what I thought, except it is hard to trust that it is not being injected

If you are looking at the network traffic and are not already using it, you should use a tool like Wireshark

Originally posted by yngve:

If you are looking at the network traffic and are not already using it, you should use a tool like Wireshark

Alright then, what about the regression bug you mentioned earlier, it was introcuded somewhere alonfg the line from .51 to .52 and is still there in .53?

In the latest snapshot the retrieval is fixed.

Originally posted by ytsmabeer:

In the latest snapshot the retrieval is fixed.

indeed. good, then let us hope it stays that way

The regression was introduced in 10.50, and the fix has AFAIK not been integrated into 10.5x yet (it is bundled with several other fixes).

It is possible that it looked like a .51->.52 regression because something happened at that time on the server. Perhaps they upgraded it, and the certificate chain was modified? (Though it does not look like they have patched the TLS renego vulnerability yet).

In any case, according to my information, GMX is reported to have escalated the issue, and are working to fix it.

As for the above conflicting information about Firefox, it seems that in FF 3.5 Mozilla did something they strictly speaking should not have had to do: Included the intermediate CA certificate that GMX is missing in the binary. Roots are actually the only certificates a browsers should need to install (there are special exceptions), intermediate CA certificates are 20 on the dozen, supposed to be replaced every few years.

Originally posted by yngve:

The regression was introduced in 10.50, and the fix has AFAIK not been integrated into 10.5x yet (it is bundled with several other fixes).

It is possible that it looked like a .51->.52 regression because something happened at that time on the server. Perhaps they upgraded it, and the certificate chain was modified? (Though it does not look like they have patched the TLS renego vulnerability yet).

In any case, according to my information, GMX is reported to have escalated the issue, and are working to fix it.

As for the above conflicting information about Firefox, it seems that in FF 3.5 Mozilla did something they strictly speaking should not have had to do: Included the intermediate CA certificate that GMX is missing in the binary. Roots are actually the only certificates a browsers should need to install (there are special exceptions), intermediate CA certificates are 20 on the dozen, supposed to be replaced every few years.

Well, it either another coincidence that GMX fixed their problem the same moment the Opera snapshot is out, or latter just got fixed by

CORE-29076 (Missing TLS 1.2 Client Auth support)

Opera seems to be recognising the certificate as it is supposed to be and reporting, according to your earlier comments then correctly, that the server is not supporting secure TLS renegotiations, hence marking the site unsafe.

BTW, I had quite a bit a quarrel with GMX about that matter, not that they let me feel doing something about it, they just did the same as most vendors do these days - pointing to finger to just another stupid user... ...but I am glad to hear that you have heard otherwise.

CORE-29076 is the task the fix was included in.