Security @ Opera

Once again, Opera Software ASA proves that its browser is safer than any other open-source (or not ) browser.
I just want to say : "Who's your dad ?"

Originally posted by earth01:

is safer than any other open-source (or not ) browser.

Both Mozilla and Chrome support revocation lists.

Originally posted by xErath:

Both Mozilla and Chrome support revocation lists.

Afaik, neither has protection against blocked revocation responses.

Firefox does have an option (notably off by default) to fail as unsecured when OCSP fails — I have no idea if this also applies to the older CRL system?

A fail on Microsoft side is that the certificate list in Microsoft Update is an optional one..


Safari on Mac will use what ever settings are in the keychain afaik http://blog.intego.com/2011/03/24/protect-safari-from-fraudulent-digital-certificates/

If Opera took care of the DigiNotar issue, why does this page display as trustworthy albeit being certified by DigiNotar? And why does DigiNotars certificate show up in the certfificate manager afterwards?

https://www.polisdirect.nl/

Edit: I used this strange behaviour to set Opera up to display a warning whenever a site uses DigiNotar.

Originally posted by xErath:

Both Mozilla and Chrome support revocation lists.

Nope, thats why they both had to rush out emergency versions to cater for this...

Only Opera does the full-deal.

Hans: We have not, at present, changed anything regarding DigiNotar; if it is not in your repository when you visit a site it will be installed from the online repository. The problem is currently handled by the standard revocation systems, OCSP and CRLs. We are continuing to evaluate the situation regarding DigiNotar, and may take steps regarding the trust settings for this Root.

Originally posted by Ganiscol:

If Opera took care of the DigiNotar issue, why does this page display as trustworthy albeit being certified by DigiNotar? And why does DigiNotars certificate show up in the certfificate manager afterwards?

Because they havn't blacklisted DigiNotar, they are using the revoke feature to block the specific certificates that were hacked.

Alright, thanks for clearing that up.

I just read at a german news site (heise.de) that DigiNotar detected an intrusion in mid july. They revoked most of the certificates generated by the intruders but "overlooked" some until recently. Those were not revoked until DigiNotar was notified by Govcert about the issue.

Doesnt sound like they take their business all too serious...

Because of this, for the time being, I'll keep the warning about sites using DN on.

Originally posted by clashcityrocker:

Because they havn't blacklisted DigiNotar, they are using the revoke feature to block the specific certificate that was hacked.

Just that it looks like nobody, not even DigiNotar, can tell for sure how many more fake certificates are floating around.

Obvious it's all about balance. The balance of users security vs the buisness of the CA.

Blacklisting all Diginotar's certificates could be a rather extreme measure, cause LOTS of user problems, and perhaps even open Opera upto to legal problems with the CA.

At the same time, they have to balance Opera users security.

The best approach is to monitor it closely and be prepared to react (which likely means just mirroring what the big boys - Google, Microsoft do).

The important thing is, whatever way it goes, Opera has the technology inplace to revoke individual certs or block the entire CA automatically.

So really just let them deal with it.

A problem with Opera's approach is that you can't 'distrust' a CA before you've actually downloaded it (by visiting a site that uses it). The advantage is that if a CA is actually known to be not trustworthy anymore, it is trivially simple to prevent new users from getting this certificate, by removing it from the online rootstore. So it doesn't matter if you are on a network from a corrupted ISP, intrusive government or malicous wifi.

At least, that's my understanding so far, I'm not a security expert, and not working on this matter for Opera!

What about cases like the ESET Smart Security HTTPS Proxy option? I was having the devil of a time importing this certificate and getting the Opera browser to use it.

I understand that this bypasses and mitigates the new trust framework in Opera, but in exchange the antivirus can scan all incoming HTTPS traffic in its raw (unencrypted) form. Traffic between the antivirus and browser is also still encrypted so the interprocess communication is not easily snooped.

Originally posted by Ganiscol:

Just that it looks like nobody, not even DigiNotar, can tell for sure how many more fake certificates are floating around.

Originally posted by clashcityrocker:

The best approach is to monitor it closely and be prepared to react (which likely means just mirroring what the big boys - Google, Microsoft do).

The important thing is, whatever way it goes, Opera has the technology inplace to revoke individual certs or block the entire CA automatically.

Actually, in the DigiNotar case, if all systems work as intended, we don't need to do anything. Known fraudulent certificates are already blocked. If there should be unknown fraudulent certificates being abused, there are two possibilities:

A) The attackers block all revocation checking. Opera will not show the page as secure, and the attack fails.
B) The attackers allow revocation checking. This will send the certificate details to DigiNotar, who is monitoring the incoming revocation requests, and can answer "revoked" to any unknown requests. The page will be blocked in Opera, and the attack fails.

Obviously, we are monitoring the situation, and if some systems should fail, we have other options in place.

I am connected to mail.google.com through https. But Opera tells me that is not a secured connection. What does it mean ? Gmail certificates are compromised ?

Regarding to this Forum-Topic: http://my.opera.com/community/forums/topic.dml?id=1085532&t=1314778839&page=1

I'm asking: What should happen to distrust a CA by Opera?

Originally posted by The-Doc:

I am connected to mail.google.com through https. But Opera tells me that is not a secured connection. What does it mean ? Gmail certificates are compromised ?

There are many reasons an otherwise secure connection can be downgraded. As discussed here, if Opera for some reason is not able to check for revocation status, it will be downgraded. Another common way this can happen, is if the site includes http resources inline. If certificates were compromised and revoked, the page would not load, so that is not the case. You can load a single image, js file or css file from the server, and see if that is secure, that will tell you if it most likely blocked revocation requests, or insecure inline resources which is the culprit.

Originally posted by K4m1K4tz3:

I'm asking: What should happen to distrust a CA by Opera?

We will evaluate this on a case by case basis. We will do whatever we can to maintain user's security. DigiNotar have failed at their security, but have revoked all fraudulent certificates, so there should currently be no risk involved in using the CA in Opera.

If you believe DigiNotar is malicious, or fear that they might be successfully attacked again in the near future, despite the amount of extra security review they will go through after this incident, you can disable their root manually in Opera. If we should fear either of these, we will disable the root automatically. We are actively monitoring the situation to evaluate this, and we are already starting to consider what features to add to the next Opera version to protect users against even malicious CAs.

I would really much like to see (maybe optionally, so as not to frighten some users) much more detailed description about *why* the security level has been downgraded. "The server tried to apply security measures, but failed" is not especially helpful...

Originally posted by aspseka:

I would really much like to see (maybe optionally, so as not to frighten some users) much more detailed description about *why* the security level has been downgraded. "The server tried to apply security measures, but failed" is not especially helpful...

Agreed. This is bug report DSK-143997 in Opera's bug tracking system.

Originally posted by Sigbjorn:

B) The attackers allow revocation checking. This will send the certificate details to DigiNotar, who is monitoring the incoming revocation requests, and can answer "revoked" to any unknown requests. The page will be blocked in Opera, and the attack fails.

But Diginotar themselves have no idea which certificates are fraudulent. Besides you can make a lot of dutch people happy completely distrusting diginotar, gives us a valid reason not to do our taxes

Reed this: http://www.f-secure.com/weblog/archives/00002228.html

I'm shocked ... If someone says now DigiNotar is trustful he lives in another world.

@K4m1K4tz3

I was going to say the same but that link sums it up quite nicely.

Turns out that other browser authorities are right when they distrust DigiNotar as a whole. I dont think what Opera does is enough in this matter.

Originally posted by K4m1K4tz3:

Reed this: http://www.f-secure.com/weblog/archives/00002228.html

I'm shocked ... If someone says now DigiNotar is trustful he lives in another world.

the dutch government definitively lives in another world then but then again this is no news to me or most dutch, we have known this for years

What happens if they decide to redirect the CRL address to a fake one?

Couldn't that bypass your entire security system?

I don't think that very small color change is enough to protect people. I often don't notice it unless it turns green.

Perhaps you should switch the yellow to blue, and use a red background and a warning sign to signify an insecure https connection. And an error page with a simple message once per session would be advisable.

For major websites it would be advisable to prevent connection when an unexpected certificate change happens.

I thought Opera was able to update the certificates remotely? Would Opera know if someone tampered with the certificates stored in a user writable directory?

Opera is popular in Iran and people can loose their lives over this.

Originally posted by toyotabedzrock:

What happens if they decide to redirect the CRL address to a fake one?

CRLs and OCSP responses are digitally signed by the issuer of the certificates, and they have a validity period (OCSP for a few days, CRLs for at least a week, usually several; Opera uses OCSP for site certificates, if specified). An attacker can only replay a currently valid but outdated CRL or OCSP response.

(In this case I am ignoring the possibility that the issuing key has been completely compromised: that would be cause for revocation of that CA. Please note that most issuing CAs are NOT Root CAs, but intermediate CAs issued by another CA, either an intermediate or a Root, which can be revoked in CRLs by their issuer, the Roots are now mostly offline and require sneakernet transfer and 4+ people to use)

Originally posted by toyotabedzrock:

For major websites it would be advisable to prevent connection when an unexpected certificate change happens.

This was discussed during the work with the W3C Web Security Context work, and it was eventually deemed to be unworkable.

The fundamental problem is that certificates changes frequently, and they also change CAs at times (even Google's Chrome CA pinning for their domain authorizes a group of CAs, not a single CA). Given that you are probably encountering hundreds of secure sites during any significant time period, it is very likely that you would encounter a server that have changed its certificate several times a week. The result of such a warning would be that users would blindly click "OK".

There are several proposals being put forward to use DNSSEC to allow site administrators to indicate which certificates or CAs are permitted to be used for their sites. None of them are complete yet, and there are IMO possible issues about how well they would work for web clients.

Originally posted by toyotabedzrock:

I thought Opera was able to update the certificates remotely? Would Opera know if someone tampered with the certificates stored in a user writable directory?

We can update certificates that are in our online repository, and we occasionally download intermediate (not roots) CA certificates into the database.

OTOH users can also add their own certificates if they need to, and this is indistinguishable from somebody hacking into your PC to add certificates (or changing the executable to include such certificates).

There is no way (short of what is called "Trusted Computing", which uses chips installed in your computer to secure data, and which many security and privacy experts are critical of due to aspects of the functionality) to prevent anybody with access to your computer and your applications' configuration files from updating your settings, including adding new trusted Roots. If the configuration is hardcoded, the executable could be compromised instead. Therefore, secure your computer system properly.

...and this is why I'm asking about the CA root that ESET Smart Security needs me to install for each program whose secure traffic is routed through the scanner. Well hang it, perhaps I should go through the whole procedure again myself.

Mozilla addons site targeted in same attack that hit Google
http://www.theregister.co.uk/2011/08/31/more_site_certificates_forged/

HAA-ha~

I don't believe El Reg mentioned yet that Opera fixed this without needing to push an update to the browser itself?

Cutting Spoon: If you install and configure such a Root whose whole purpose is to produce site certificates on the fly for every site you visit, that is, and authorized MITM attack, then the key for that Root had better be created locally, and not be shared with other installations used by other users. Or you have to make very sure that you disable that certificate when you disable the proxy.

Also, when you install such a certificate it becomes the proxy's job to check revocation (OCSP, CRL, blacklists); the client (Opera, FF, MSIE, etc.) cannot do so since it no longer see the real certificate.

Yngve: Any CA that does allow creation of certificates for Alexa Top500 sites without consent of at least two CA administrators (not just regular users or auditors) is broken.
If the attackers were able to circumvent such measures in software only makes the situation more grim: they could have created a subCA certificate that is not listed in the CA database (the fact that the DigiNotar doesn't know which or how many rogue certificates have been created only confirms that). That is, in practice, private key compromise (it doesn't matter for Opera, as it checks for OCSP responses, it does for every other browser)

Please, remove this CA permanently, they have proven their incompetence enough.

"Opera will downgrade the security level of the site to the same as any other regular web page in such unverified cases, which means that once a certificate is revoked by the issuer, it cannot be abused in Opera, even if the revocation URL is blocked. The most an attacker can do, is the same as he could without a certificate."

This is useless. Read https://bugzilla.mozilla.org/show_bug.cgi?id=327181#c14 .

mattmccutchen: Not so sure about that, at least when it comes to Opera users, see http://my.opera.com/yngve/blog/show.dml/2272108

http://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up/

For What The Hell are you waiting for ?

@Yngve: Indeed, turning off the SSL badge is a great way to get users to report problems, but it's nearly useless at preventing attacks in real time. Disappearance of the badge in the middle of a transaction is not likely to persuade the average user to stop and contact the admins. Even if it does, irrevocable harm may already have been done (e.g., compromise of session cookies or confidential form fields). And there are attacks that turn off the badge only for a fraction of a second (immediate redirect to a look-alike site with valid SSL) or not at all (hit the site from an iframe in another window, inject malicious content, and then tamper via the same-origin policy). So please don't make false claims that your users were protected.

A few questions:

I visited https://as.digid.nl/aselectserver/server. A dutch governemnt site with Diginotar certificate. Clicking on the security badge Opera says the connection is unencrypted. Is that true? Clicking on information gives a OSCP and tls renegotiation error, but says TLS encryption. Isn't the message `not encrypted connection` misleading?
(Funny thing Chromium says the site is completely save eg green padlock while Opera says it's completely unsave)

My profile page: https://my.opera.com/JanGen/account/about.dml is according to my Opera browser insecure. I even get a red skull. Clicking on the information button gives this message. `Server attempted to apply security measures, but failed.` What's wrong here? Is it not save to use my.opera?

Sometime I get a green padlock in Opera's address bar. What's the difference in security between a green and a yellow? Why isn't that explained on the help pages?

And why aren't the red skull / blue trusted security icons explained and all the possible security messages explained anywhere on the help pages? How many security icons are there?

I agree with Jim that a downgraded secure connection should have a red background. A visual warning sign is definitely missing, furthermore the help pages are lacking,

UPDATE: there is some info about green/yellow badges on the fraud malware page, I have that disabled BTW.

as.digid.nl: The OCSP response has expired. At present my time is Sep 3, 22:49 UTC, the next update "expiration date" for the response is Sep 3, 18:30. That means that DigiNotar have not updated the responses on the server for at least the past 6 hours, perhaps longer. This could have something to do with a recent turn of events (last evening), with the Dutch Government initiating steps to migrate all Diginotar issued certificates under their PKI Overheid Root to another CA, and to revoke DigiNotar's subCA under that Root; This is an operation that will also require the revocation of all the previous certificates in the DigiNotar subCA as they are being migrated to the new CA.

As for the my.opera page you mention, it looks like something, probably an image, is lowering the security level.

The "Green Bar" is the Extended Validation indication, indicating that the identity of the website owner have been more thoroughly checked than it would have been for a normal certificate. See http://help.opera.com/Windows/11.50/en/fraudprotection.html and http://www.opera.com/browser/tutorials/security/

Downgraded sites are treated just the same as unencrypted HTTP pages: no indication that they are secure. The only real alternative would be to refuse to display the page. Most of the time, the reason for downgraded security is design issues in the displayed page, or stability problems at the revocation servers (such as at the above mentioned digid.nl site), not due to anything malicious happening.

Ynge thx.

as.digid: But is the connection now encrypted or not? Opera says it's not, Chromium says it is.

my.opera: Yesterday the page (logged out) was not secure, today it is!?
Logged-in the page is still insecure, due to a picture (avatar) on http. Opera says don't enter sensitive data, so I guess I better do not fill out the forms? I know cookies are send to unencrypted image urls, but when I send personal info through the forms is that send unencrypted?

help: the help buttons on the Opera dialogues only link to http://help.opera.com/Linux/11.50/en/security.html#dialog. Linking to the url you mention should be more helpful.

downgraded sites: I have a server myself, set up certificates myself with bogus issuer. I approved the certificate. Still opera claims it's not secure:
1 server name is wrong
2 not trusted authority
Both right, as I know, does that still mean the connection isn't encrypted and it is insecure to use it? I suppose it's more secure then a not encrypted connection for `man in the middle` attacks

How about Opera Mobile (android)? How do I check security?

Manually accepted certificates are still considered less secure than is desirable, since they have issues with the validation checks, and may not be traced to a trusted Root; you are just getting an automatic click of OK on the dialog. This means that you must make up your own mind about the site after making sure that you really are talking to a site presenting the right certificate.

If you want a site with a selfproduced certificate to show as "secure" you must issue it from a Root certificate that you have imported as a Trusted Authority. That Root and its private key MUST, however, be kept very secure, since, if somebody gets hold of it, they can issue any certificate and pretend to be any site you, personally, want to visit, e.g. Google.

as.digid: The connection is not properly encrypted since it did not pass all the required checks for it to be considered secure, so it is considered unencrypted.

The My Opera people are looking into the issue, and it only applies when you are logged in AFAICT.

The padlock indicator advise is general for such situations, there are some cases where it is unsafe to use a page with unsecure resources, such as when the unsecure resource is an external Javascript file (Those can take complete control over the page). Even if the unsecure resource is "just" an image it might leak information about what you are doing.

Any news about DigiNotar?

@K4m1K4tz3
http://www.nrc.nl/nieuws/2011/09/04/gratis-e-maildiensten-cia-mossad-en-oppositie-doelwit-iraanse-hack/

Originally posted by yngve:

The My Opera people are looking into the issue, and it only applies when you are logged in AFAICT.

my.opera: No, https://my.opera.com/community/login/ isn't marked secure on my main Opera 11.51, but it is on Opera next. Dunno why or how, deleted all cookies etc, enabled/disabled fraud protection, restarted.

as.digid:Shouldn't Opera make a difference between not encrypted and not properly encrypted. An encrypted connection with a a self issued certtificate is safer than a not encrypted connection to my server IMHO.

Originally posted by yngve:

That Root and its private key MUST, however, be kept very secure, since, if somebody gets hold of it, they can issue any certificate and pretend to be any site you, personally, want to visit, e.g. Google.

For that, don't they need control of the DNS server?

Can I limit self issued and imported root certificates to some domains?

Originally posted by yngve:

such as when the unsecure resource is an external Javascript file (Those can take complete control over the page).

But also secure third party javascript resources take control.
To get it right, you mean that the avatar image on http://my.opera can be hacked in the middle (replaced with a javascript file) and an image on https://my.opera can not be hacked?

Originally posted by JanGen:

as.digid:Shouldn't Opera make a difference between not encrypted and not properly encrypted

No, because the security of an improperly secured channel cannot be assured, it is better to treat it as a completely unsecure channel. Keep in mind that the way to abuse the fraudulent certificates past the time they have been revoked is to prevent the client from checking all the details, which in Opera lowers the security level, removing the secure indication (it does not in most other browsers).

Originally posted by JanGen:

An encrypted connection with a a self issued certtificate is safer than a not encrypted connection to my server IMHO

Only if you insert the Root certificate for that certificate into the trusted certificate repository.

It is generally too easy to just click OK on the dialog, rather than manually validating the certificate with the issuer. (Maybe it would be an idea to require the user to type the SHA-1 or SHA-256 fingerprint of the certificate before they can manually accept a certificate?)

Originally posted by JanGen:

For that, don't they need control of the DNS server?

No, they only need control of a router that your network traffic passes through (think somebody hooking into your phone connection somewhere between you and the phone central, modifying what you and the other are talking about). Having control of the DNS would allow them to redirect traffic to an IP address without needing the router control, but that is strictly speaking not needed, and can be done at the router level.

Originally posted by JanGen:

Can I limit self issued and imported root certificates to some domains?

Not at present.

Originally posted by JanGen:

But also secure third party javascript resources take control.

But it cannot be replaced in transit by a MITM (except with a fraudulent certificate) due to the encryption.

Originally posted by JanGen:

To get it right, you mean that the avatar image on http://my.opera can be hacked in the middle (replaced with a javascript file) and an image on https://my.opera can not be hacked?

As that is an image tag, not a script tag, it cannot be replaced in that fashion, but a MITM could replace the image with another image. Generally speaking, though, an image can tell an observer what you are doing, e.g. which stocks you are investigating in the stock trading site.

https://www.kia.com/international/ isn't secure in Opera 11.51 with `enable plugins only on demand` checked but is secure when unchecked.

Is that a bug?

Furthermore it's also unsecure with plugins disabled but `enable plugins only on demand` checked.

How can a user preference like this influence the security of a site?

Originally posted by yngve:

improperly secured channel cannot be assured, it is better to treat it as a completely unsecure channel.

But isn't a not encrypted connection open to any MITM, while a encrypted connection is `only` vulnerable to MITM with fraudulent certificates.

Originally posted by JanGen:

my.opera: No, https://my.opera.com/community/login/ isn't marked secure on my main Opera 11.51, but it is on Opera next.

Yesterday it wasn't, today it's marked as secure. Can that be a result of corrupted(?) session data, although I restarted Opera yesterday a couple of times.

Originally posted by Ganiscol:

If Opera took care of the DigiNotar issue, why does this page display as trustworthy albeit being certified by DigiNotar? And why does DigiNotars certificate show up in the certfificate manager afterwards?

https://www.polisdirect.nl/

Edit: I used this strange behaviour to set Opera up to display a warning whenever a site uses DigiNotar.

Cause they used a different certificate now...

The story goes on:

https://blog.torproject.org/blog/diginotar-damage-disclosure

Originally posted by wikipedian:

Originally posted by Ganiscol:

If Opera took care of the DigiNotar issue, why does this page display as trustworthy albeit being certified by DigiNotar? And why does DigiNotars certificate show up in the certfificate manager afterwards?

https://www.polisdirect.nl/

Edit: I used this strange behaviour to set Opera up to display a warning whenever a site uses DigiNotar.

Cause they used a different certificate now...

It took them ~3 days to get rid of the DN certificate - whats your point?