Security @ Opera

Originally posted by Ganiscol:

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?

Just saying the page is "trustworthy" cause they are using a different certificate now .

And the next chapter in the DigiNotar debacle - it might be the last chapter *for* DigiNotar:

https://www.govcert.nl/english/service-provision/knowledge-and-publications/factsheets/factsheet-fraudulently-issued-security-certificate-discovered.html

Summary: Govcert took over control of DigiNotar.

I'd say not trusting DigiNotar at all was and is justified...

Originally posted by Ganiscol:

And the next chapter in the DigiNotar debacle - it might be the last chapter *for* DigiNotar:

https://www.govcert.nl/english/service-provision/knowledge-and-publications/factsheets/factsheet-fraudulently-issued-security-certificate-discovered.html

Summary: Govcert took over control of DigiNotar.

I'd say not trusting DigiNotar at all was and is justified...

Looks like DigiNotar would be bye bye. Hope the Dutch government operates DigiNotar better than DigiNotar themselves...

For a preliminary analysis of the DigiNotar hack:
http://www.rijksoverheid.nl/bestanden/documenten-en-publicaties/rapporten/2011/09/05/fox-it-operation-black-tulip/rapport-fox-it-operation-black-tulip-v1-0.pdf

In short: DigiNotar`s Window servers were unpatched, had no anti-virus scanners, their certificate system was not sandboxed, and they used weak passwords. Their admin password was cracked by brute force, and hackers had administrator rights.

Furthermore the hack was EXACERBATED by weak implementations of certificate revocation behaviour of ALL browsers EXCEPT Opera
http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html

But DigiNotar's security implementation was lacking here completely:
`If a certificate serial number is presented to the OCSP-responder and no record of this serial is found, the normal OCSP-responder answer would be „good‟.`
which makes Opera's standard OCSP checking worthless, but makes sense to Opera's point of view that there is no need of blacklisting DigiNotar certificates, now DigiNotar's OCSP responder has been corrected.

I followed the issue in mainly Dutch Press, I haven't seen then name of browser vendor Opera anywhere, they only talked about Google, Mozilla and Microsoft.
Is Opera's PR department on holiday?

Originally posted by JanGen:

I followed the issue in mainly Dutch Press, I haven't seen then name of browser vendor Opera anywhere, they only talked about Google, Mozilla and Miocrosoft.
Is Opera's PR department on holiday?

That's because Opera has not done anything drastic as revoke DigiNotar complete like Microsoft (NOT Miocrosoft), Mozilla, and Google have done (read the second last paragraph of my blog post.

Diginotars OCSP url is:
OCSP - URI:http://validation.diginotar.nl

I guess OCSP is always checked securely (encrypted), but the report says:
`Note that advanced methods for misusing the rogue certificates are possible by which a thorough attacker can circumvent our detection method.`
that sounds like their is a way to circumvent OCSP checking.

FYI: a reaction from the hacker
http://pastebin.com/1AxH30em
see also: http://www.f-secure.com/weblog/archives/00002231.html

Originally posted by JanGen:

I guess OCSP is always checked securely (encrypted), but the report says:
`Note that advanced methods for misusing the rogue certificates are possible by which a thorough attacker can circumvent our detection method.`
that sounds like their is a way to circumvent OCSP checking.

The connection to the OCSP responder can be blocked by the attacker, it is also possible (within a limited time) to replay an unexpired, but Good, OCSP reponse.

OCSP responses are usually unencrypted (using encryption can cause a cascade of OCSP requests, at least at present. And in in the case of a MITM attack like this one, guess what? Getting a cert for the OCSP responder would be high on the list), but Good/revoked responses are digitally signed (error codes aren't).

Am I misunderstanding something or is Operas concept based on whether or not DigiNotar has revoked all compromised certificates?

How can one rely on this practice if the number of compromised certificates started at *.google.com, increased to 257 and now stands at a (preliminary) grand total of 531? DigiNotar didnt know (or care) what the hell was going on and it lead to the dutch government taking control of DigiNotar. Thats really not a good foundation for trust.

If I'm getting this right, then it appears to me that the approach of completely revoking all DigiNotar certificates was the right choice...

Originally posted by yngve:

And in in the case of a MITM attack like this one, guess what? Getting a cert for the OCSP responder would be high on the list), but Good/revoked responses are digitally signed (error codes aren't)

Do you mean it's quite easy to fake a digitally signed `good` OCSP repsonse for MITM?

Originally posted by yngve:

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.

These risks are something that I understand, and I am willing to accept. The ESS replaces core Windows network functionality, occupying the same place that a local MITM would attempt to use. Hence, tampering should completely break internet access. Each installed copy has its own master key, generated locally on the host PC. Thereby, all data sent and received through encrypted channels will be scanned for malicious payload before it can even hit the Windows network stack. I'll check it again, but Opera seems to complain a lot when you actually try to use an imported certificate authority.

Originally posted by JanGen:

Do you mean it's quite easy to fake a digitally signed `good` OCSP repsonse for MITM?

Depends entirely on how good access the attacker gets to the CA, and how separated the two operations, issuing certificates and issuing OCSP responses are. The point, though, was that a HTTPS based OCSP responder is not immune against replay attacks by an attaker that is able to get fraudulent certificates.

Originally posted by hellspork:

I'll check it again, but Opera seems to complain a lot when you actually try to use an imported certificate authority

You might want to check two things: The settings for the certificate, and what the generated site certificate presented from proxy says, and what Opera says is the problem with the certificate.

I would suggest to kill SSL as we know it nowadays. The concept is to trust into CAs which have no interest into their own security. Because they think: "We are to big to fail".

I would like to see a new concept. A better one - more secure.

Maybe this video helps: http://www.youtube.com/watch?v=Z7Wl2FW2TcA

Originally posted by K4m1K4tz3:

I would like to see a new concept. A better one - more secure.

Which would have its own share of security problem, and people clamoring for "something more secure" because that system is a "total failure".

BTW: SSL/TLS does NOT require certificate authorities to work, it it just at present the most scalable method that allows people that do not know each other to communicate securely.

There are other alternatives available in the protocol, though they are not supported by many implementations, at present, such as :

PGP: http://www.rfc-editor.org/rfc/rfc6091.txt
Passwords: http://www.rfc-editor.org/rfc/rfc5487.txt

https://blog.torproject.org/blog/diginotar-damage-disclosure
https://blog.torproject.org/files/rogue-certs-2011-09-04.csv

While reading the report about the DigiNotar incident I have become concerned because it appears that it is at least possible, if not likely, that one or more private root keys were compromised.

I say this because of the lack of evidence of deleted entries to match some of the rogue certs found in the wild. Such a lack could be explained by the rogue cert being generated outside of the CA's systems. Generation of a rogue cert outside of the CA’s system would not be practical unless the attacker got the actual root cert.

See section 2.3 in:

http://www.scribd.com/doc/64011372/Operation-Black-Tulip-v1-0

They tip-toe around the possibility that a root cert may have been compromised by speculating

It might be possible that these serial numbers have been temporarily generated by the CA software without being used. Alternatively, these serials were generated as a result of a bug of the software. However, we cannot rule out the possibility that these serial numbers relate to rogue certificates.

In this case they meaning of “rogue certificates” must include the disclosure of a private root CA cert, not just the garden variety rogue cert for a website.

If one or more root certificate has been compromised, whoever has access to them could forge certs with a revocation URL of their choice and run their own server at that address. Then, to the best of my knowledge, nothing in SSL or HTTPS would tell the user that something fishy was going on.

What if the bogus certs generated at COMODO are a smoke-screen for an attack that actually got one of the root certs? Is the whole game over for SSL?

Private keys for CAs are stored in Hardware based cryptographic modules.

As the proposed CABForum Basic Requirements for CAs (http://cabforum.org/Baseline_Requirements_Draft_35.pdf ) says:

The CA MUST protect its Private Key by housing it in a FIPS 140-1 level 3 (or equivalent or higher) cryptographic module

As for the Root certificate private key, it is usually not just off-line, but using it requires several people physically present to operate.

"Rouge certificates" refer to certificates that have been fraudulently issued, and for which one have no log or archive information that can be used to revoke it or know what they are targeted at.

If somebody had obtained the Private Key of a CA, the term used would be "private key compromise", and is reason for immediate revocation of the affected CA certificate. An example of a Private key compromise was the Debian Weak Keys.

Is OCSP checking slowing down the loading of resources. is their an estimate by how much?

A normal OCSP check will take less than a second. There are timeouts involved just in case, though, which would normally shut down a waiting request after 10 seconds. OCSP responses are cached for their validity period, usually 4 days.

What can sometimes cause delays are really big (>300KB) CRL files (CRLs are cached for their validity time, usually a week or more), when the user have a slow connection. There are timeouts for this as well, but as long as it does not become idle and there is data streaming, the CRL is allowed 60 seconds.

In both cases slow DNS can cause the the timeout to trigger after 10 seconds.

How does this affect Mobile products? (Opera Mobile, Opera Mini)?

Can someone from Opera comment please...

Hello,

Yngve Nysæter Pettersen wrote:
“CRLs and OCSP responses are digitally signed by the issuer of the certificates”
-> not entirely true, the key that signs a certificate's status information is usually not the same key that signed the certificate; the (cert issuing) CA issues a cert for an OCSP signing authority.
This cert is normally not checked for revocation status as it has set a special OCSP no revocation check bit; it may not even contain any revocation links(CRL, OCSP).

Yngve Nysæter Pettersen wrote:
“validity period OCSP for a few days, CRLs for at least a week, usually several”
-> not entirely true; it may be quite normal for CAs(including major ones) to have the same validity periods for CRL and OCSP for end certs.
+
Yngve Nysæter Pettersen wrote:
“intermediate CAs issued by another CA, either an intermediate or a Root, which can be revoked in CRLs by their issuer”
-> for the “regular” interm CAs the validity of CRLs and OCSP responses can be up to an year, usually lasts at least a few months; replay heaven. The situation may differ for EV chains where they may have a shorter lifespan.

Regarding what Opera does:
According to the report issued so far by Fox-it the hackers had admin access including to the root CAs.
This may mean that they were able to issue an intermediate CA cert + an OCSP signer cert.
If that would have been the case, Opera does not have, as writing, any, possibilities to block/detect MITM attempts using DigiNotar trust.
However, the same report also indicates that so far there is no evidence of such certs.
Also, please correct me if I'm wrong, but by default Opera shows the padlock when the cert has no revoc info(OCSP, CRL links); plus works just fine to MITM the Opera update query with such such a cert.

OCSP and CRL are reactive protections, post-attacks ones; and they have limited use in cases when the CA network is so badly compromised as in DigiNotar’s case.

Given the current ambiguous situation and the fact that it seems that all sites using DigiNotar certs have been contacted:
https://docs.google.com/spreadsheet/ccc?pli=1&key=0AtLNtYDDyKsudG1lc2xmRDZRNTBkdXR1M0gzelZ3MkE&hl=en_GB#gid=21
and that all the DigiNotar CAs have been identified, it’s unclear what stops Opera to blacklist DigiNotar from the CA business as it rather exposes its users to an unnecessary theoretical threat.
Perhaps waiting as MS in Netherlands due to a Ducth gov request:
http://blogs.microsoft.nl/blogs/windows/archive/2011/09/06/software-update-vanwege-onbetrouwbare-certificaten-diginotar.aspx

Thanks,
Adrian

Originally posted by adimcev:

According to the report issued so far by Fox-it the hackers had admin access including to the root CAs.

As far as I know the Root could not be used, since it require multiple people to enable it, and is according to my information "strictly offline". The mentioned serial numbers in the document may have been generated as an attempt to get a certificate, but does not necessarily indicate that the certificates were issued.

Policies regarding revocation requirements are being discussed. However, getting too strict might break sites using certificates generated by local CAs that have not implemented a revocation scheme.

Originally posted by adimcev:

it’s unclear what stops Opera to blacklist DigiNotar from the CA business as it rather exposes its users to an unnecessary theoretical threat.

Read http://my.opera.com/rootstore/blog/2011/09/06/diginotar-first-step-disabling-the-root yet?

Originally posted by yngve:

You might want to check two things: The settings for the certificate, and what the generated site certificate presented from proxy says, and what Opera says is the problem with the certificate.

http://www.wilderssecurity.com/showthread.php?t=287101
http://www.wilderssecurity.com/showthread.php?t=284908
Looks like the issue apparently is now complicated by TWO warnings. Or something.

I'll play with it anyway, there may be something I can do to prevent Opera from continually panicking on each new domain. The big thing I encountered previously was that importing the certificate root did not stop Opera from panicking on each new domain, which had to be approved and remembered manually. Further, the various cloud services built into Opera did not honor the certificate and did not display any error messages - they simply didn't work because they didn't like the unexpected CA. I guess it is good if Link is hardened to expect specific certificate behavior, but that also presents a specific target for outsiders to compromise.

It would be nice if ESET and Opera could reach an agreement to establish the proper trust chain in Opera's root store.

Originally posted by hellspork:

The big thing I encountered previously was that importing the certificate root did not stop Opera from panicking on each new domain, which had to be approved and remembered manually.

Make sure that was actually a Root, and not an Intermediate CA certificate. You can tell by which tab it is stored in. Also make sure the "Warn" flag is disabled.

AFAICT the warning mentioned in the referenced thread was for a configuration where the Root had not been installed in the browser.

It might be helpful if I could see the entire XML source of the report from the Certificate display linked from the Info panel (via the TLS 1.x security link). The related Root would also be needed.

Originally posted by hellspork:

Further, the various cloud services built into Opera did not honor the certificate and did not display any error messages

At least some of those, e.g. the Rootstore update, are intentionally designed to refuse connections that does not establish a secure connection that would show "Secure", and they are also designed to discard connections that would have displayed dialogs, whatever the reason to avoid annoying the user (we know that we do not want to connect to a site that is producing warnings, because these are not supposed to trigger warnings).

Originally posted by yngve:

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.

I don't agree. A self issued certificate brings protection to MITM, it's more secure then sending passwords in plain text.
Google`s way of thinking makes more sense to me:
http://www.google.com/support/chrome/bin/answer.py?answer=95617

Originally posted by JanGen:

A self issued certificate brings protection to MITM, it's more secure then sending passwords in plain text.

Assuming that the user actually checks that the certificate is the correct one, by phoning the system administrator (using a properly verified phone number) to verify the SHA-1 or SHA-256 fingerprint of the certificate, and does not immediately click OK. As far as I know most users just click OK, which means they are NOT protected against a MITM, because they do not (really) know who they are talking to.

The best way to avoid that hassle is to install a (properly verified) Root certificate in the browser and issue site certificates from it. In which case there will be a "secure" indication.

Originally posted by yngve:

The best way to avoid that hassle is to install a (properly verified) Root certificate in the browser and issue site certificates from it. In which case there will be a "secure" indication.

Thx Yngve,
In this case I'm the system admin, and it's true, according to my wife, sometimes I can't be trusted.

Is there a simple howto somewhere for adding Courier generated IMAPS certificates to my Opera-browser?

Originally posted by JanGen:

Is there a simple howto somewhere for adding Courier generated IMAPS certificates to my Opera-browser?

Import button in the Authorities panel of the Certificate manager (require the certificate to be Selfsigned)

Originally posted by yngve:

Import button

Would be nice if we could limit (self-signed) certificates to certain domains.

More fuel to the fire

Hackers break SSL encryption used by millions of sites

@Yngve (http://my.opera.com/securitygroup/blog/show.dml/34693632#comment69203312):
> Downgraded sites are treated just the same as unencrypted HTTP pages: no indication that they are secure.

Again, you aren't protecting anyone by doing this. Under the same-origin policy, you would have to turn off the badge at the first downgraded connection until all browser state pertaining to the site is cleared, and even then, irrevocable harm may occur before the user has a chance to stop it.

> The only real alternative would be to refuse to display the page.

Yep, that's what you have to do if you want to claim better security.

"So safe, 90% of all https domains won't work!"

There are upper boundaries to the pressure that one company may exert against the system, especially when its market share is not monopolistic.

I have not seen many tls 1.1 or 1.2

Righto, didn't Opera turn 1.2 off again because many servers lied about their support level? (Protocol check, 1.2 supported; use 1.2->garbage output->full stop->page broken->blame Opera)

Would be nice if there were some graceful way to back off and retry with lower version TLS.