The My Opera forums have been replaced with forums.opera.com. Please head over there to discuss Opera's products and features
See the new ForumsYou need to be logged in to post in the forums. If you do not have an account, please sign up first.
Insecure SSL-connection on the web-site
Hi! I use Opera 11.52.On web-site https://money.yandex.ru/


On web-site https://passport.yandex.ru/


In other browsers such as IE or Firefox all connections are secure! What is the problem?
Can anybody check connection to the https://money.yandex.ru/ or https://passport.yandex.ru/ and post a screenshots for SSL-connection's details?
In most such situations the reasons is that the site has, by accident or design, included unsecure resources in the document, although less often it is due to a failure to obtain revocation information (if the revocation check fails to obtain valid information the padlock is removed as the security of the resource and the containing document cannot be ensured).
In this case the reason for the the document to be considered secure is that there is a failure regarding the retrieval and processing of the CRL for (at least) https://clck.yandex.ru/ , which is using a certificate and CRL (in this case http://zanzibar.ld.yandex.ru/CertEnroll/YandexExternalCA.crl which does not respond to queries) issued and maintained by Yandex itself, using a CA issued by a third party CA.
Yandex, as a Certificate Authority has taken upon itself the responsibility to ensure that their CA maintain a 24/7/465 online revocation service, with 100% (or as close as possible, 99.999+%) uptime and correctness.
As opposed to many other browsers, Opera includes CRLs in its revocation check, and as opposed to most others treat a failure to obtain valid revocation data as a failure to provide a secure connection, a failure that affects the security of the entire document.
You will have to contact Yandex about their failing CRL server.
In this case the reason for the the document to be considered secure is that there is a failure regarding the retrieval and processing of the CRL for (at least) https://clck.yandex.ru/ , which is using a certificate and CRL (in this case http://zanzibar.ld.yandex.ru/CertEnroll/YandexExternalCA.crl which does not respond to queries) issued and maintained by Yandex itself, using a CA issued by a third party CA.
Yandex, as a Certificate Authority has taken upon itself the responsibility to ensure that their CA maintain a 24/7/465 online revocation service, with 100% (or as close as possible, 99.999+%) uptime and correctness.
As opposed to many other browsers, Opera includes CRLs in its revocation check, and as opposed to most others treat a failure to obtain valid revocation data as a failure to provide a secure connection, a failure that affects the security of the entire document.
You will have to contact Yandex about their failing CRL server.
Sincerely,
Yngve N. Pettersen
Yngve N. Pettersen
Thank you for answer, I understood about https://money.yandex.ru/ and will write email to Yandex Support.
But what about https://passport.yandex.ru? If Opera can't get CRL it can write "insecure connection" as warning, but for https://passport.yandex.ru it writes "Unencrypted connection" while other browsers such as IE or Firefox report that "All is ok"? Why?
But what about https://passport.yandex.ru? If Opera can't get CRL it can write "insecure connection" as warning, but for https://passport.yandex.ru it writes "Unencrypted connection" while other browsers such as IE or Firefox report that "All is ok"? Why?
Both sites include resources from the same server that I mentioned above, so if there is a problem on one, it is a problem for both. Also, once a problem is detected, that revocation server is not checked again for 24 hours, in that same session, and the connection marked as if the retrieval failed. The difference may change what information is indicated, and there may also be other issues involved, such as mixed security (and it is known that Javascript based redirects from unsecure pages can cause further lowering of the security level; in these cases a reload will tend to straighten out things).
As mentioned: Opera is stricter, erring on the side of caution, about what it considers a "Secure" connection than most (AFAIK) of the other browsers, most of which will NOT show any information as a reaction to a revocation lookup failure.
As mentioned: Opera is stricter, erring on the side of caution, about what it considers a "Secure" connection than most (AFAIK) of the other browsers, most of which will NOT show any information as a reaction to a revocation lookup failure.
Sincerely,
Yngve N. Pettersen
Yngve N. Pettersen
Yandex Support answered and I checked that server's certificate for https://clck.yandex.ru/ has 2 URLS in CRL Distribution Point:
URL=http://zanzibar.ld.yandex.ru/CertEnroll/YandexExternalCA.crl
URL=http://crls.yandex.ru/YandexExternalCA/YandexExternalCA.crl
And so the second URL is always accessible. Why Opera need to check ALL CRLs in the CDP? I think if one URL is good, that is enough! Because another one is most likely a double of the first.
URL=http://zanzibar.ld.yandex.ru/CertEnroll/YandexExternalCA.crl
URL=http://crls.yandex.ru/YandexExternalCA/YandexExternalCA.crl
And so the second URL is always accessible. Why Opera need to check ALL CRLs in the CDP? I think if one URL is good, that is enough! Because another one is most likely a double of the first.
Opera would probably have checked both, but in sequence, not parallel (some CRLs can be hundreds of KB), IF the failure had been due to the server sending a "not found", instead of timing out due to not being able to establish a connection.
There is a 10 second timeout for the entire operation.
OTOH the backup CRL URLS are only for intermittent failures, not permanent failures. Backup URLs also complicates the logic of checking the certificates. If a server will be permanently offline, then the CA should reissue all certificates that mention it, or even better, make the DNS record for the server point at the alternative server and configure it to serve the same files..
There is a 10 second timeout for the entire operation.
OTOH the backup CRL URLS are only for intermittent failures, not permanent failures. Backup URLs also complicates the logic of checking the certificates. If a server will be permanently offline, then the CA should reissue all certificates that mention it, or even better, make the DNS record for the server point at the alternative server and configure it to serve the same files..
Sincerely,
Yngve N. Pettersen
Yngve N. Pettersen
1. November 2011, 18:23:45 (edited)
I don't understand why you need to check both URLs in the CDP? They are identical, have the same filename YandexExternalCA.crl, and more than one URL in the CDP is only for reliability. For example for our situation - when one URL is not valid because of the timeout another is valid and can be always accessible.
Why only because of the CRL Opera informs the user that connection is "Unencrypted"? Or there is another reason for this?
Other browsers(IE, Firefox), that don't check mandatory all CRLs in the CDP(one is enough) inform that connection to these web-sites is secure.
Why only because of the CRL Opera informs the user that connection is "Unencrypted"? Or there is another reason for this?
Other browsers(IE, Firefox), that don't check mandatory all CRLs in the CDP(one is enough) inform that connection to these web-sites is secure.
The CRLs are checked, one at a time, in the specific order they are listed in the certificate. The server of the first one in this case does not respond when connected to (possibly it is offline), causing a timeout which terminates the entire operation for that certificate, and thus the second is never tested since there is no time left to do so.
In the case of "passport" I see that there is also a CRL failure for the main document, which causes the entire document to be considered unencrypted (since this is the main document, and not an inline resource). That may be due to the fact that it is relying on one of the same URLs as the one above, and given the timeout triggering it have probably been marked as "failed, try again in 24 hours".
By specifying two URLs Yandex have promised to keep both those servers active and available 24/7/365. At present they are not doing so, and that is bound to cause issues, particularly when the server does not respond at all when a connection is attempted, causing a timeout.
As I said, Yandex will have to fix their CRL server, or they will have to fix the certificate.
In the case of "passport" I see that there is also a CRL failure for the main document, which causes the entire document to be considered unencrypted (since this is the main document, and not an inline resource). That may be due to the fact that it is relying on one of the same URLs as the one above, and given the timeout triggering it have probably been marked as "failed, try again in 24 hours".
By specifying two URLs Yandex have promised to keep both those servers active and available 24/7/365. At present they are not doing so, and that is bound to cause issues, particularly when the server does not respond at all when a connection is attempted, causing a timeout.
As I said, Yandex will have to fix their CRL server, or they will have to fix the certificate.
Sincerely,
Yngve N. Pettersen
Yngve N. Pettersen