... США отозвали SSL-сертификат (т.е. сертификат безопасности) у официального сайта ФСБ.
Об этом в интервью украинскому пропагандисту Дмитрию Гордону с гордостью сообщил) американский IT-бизнесмен Майкл Талан.
Он отметил, что, по мнению американцев, которые «знают всё», Москва применяла «грязные методы, используемые черными хакерами на службе у Кремля», поэтому Россию решено было наказать.
Еще раз: SSL - это сертификат, удостоверяющий подлинность сайта.
Проблема заключается в том, что Россия не входит в так называемый «клуб», который выпускает сертификаты, признанные всеми производителями браузеров, поэтому любая компания использует либо бесплатные ключи Let’s Encrypt, либо платные от западных производителей.
Так вот, по информации Талана, руководство США настолько «устало» от нашего поведения, что отозвало сертификаты у 35 официальных российских организаций, по мнению американцев, «управляющих страной».
Ниже есть продолжение.
В качестве примера одного из последних отключений от SSL-сертификации, Талан привёл официальный сайт Президента РФ и сайт ФСБ России.https://cont.ws/@gros59/1785813
Теперь они доступны пользователю по стандартному протоколу //, сохраняя сообщение в браузере о том, что эти сайты небезопасны, иначе говоря, трафик не зашифрован.
По информации бизнесмена, США намерены также отозвать сертификаты SSL и у таких российских IT-гигантов, как Яндекс и «Mail.Ru».
Точно знаю, что в прошлом году была попытка лишить SSL-сертификата сайт Общественной палаты России. Да и, думаю, про другие попытки мы просто не знаем.
Талан добавил, что такой шаг - это беспрецедентная демонстрация того, на что готов пойти Вашингтон, если «Москва не выполнит требования США»...
Началась фрагментация интернета.
So how does your browser ensure that the site being visited is who they say they are?...A Certificate Authority (CA) is the trusted organisation that will issue a certificate once you (or your company) have met the criteria listed above. They are the trusted third party between the browser (user) and the server (website). When communicating with a server we want to make sure that they are who they say they are...When using HTTPS (as is increasingly common for websites and is a recommended best practice), the connection must be setup and secured cryptographically. The method of encryption and which keys to use are negotiated during the TLS handshake, which must happen before a HTTPS connection can be established. Before any application data can be sent over the connection, the HTTPS connection must be established...https://nooshu.github.io/blog/2020/01/26/the-impact-of-ssl-certificate-revocation-on-web-performance/
There are times where the trust between browser and server can be broken. It could be that a certificate has been compromised, and when this happens there needs to be a way to let the browser know about it. If the certificate has been compromised, you don’t want a person with malicious intentions to be able to mimic a trusted website. That would be incredibly damaging to users, the website, and the Certificate Authority involved. To allow this to happen, ways to revoke certificates have been invented:
Certificate Revocation List
A Certificate Revocation List (CRL) is exactly what the name suggests. It is a large list containing the serial numbers of revoked certificates. Each and every CA updates this list regularly, and the list is shared with browsers. Now as you can imagine, the web has a lot of certificates, and therefore there’s going to be a lot of revoked certificates. So this list will continue to grow and grow. Thankfully expired certificates aren’t revoked as there’s no need too, and their serials are often trimmed from the CRL’s.
To use the list, a browser must download it in its entirety, and loop through each serial number to check and see if the specific certificate they are examining has been revoked. This takes both time and resources, which can slow down the TLS handshake. And what happens if the browser can’t update the CRL? Does it just assume that the certificate it has been sent hasn’t been revoked, then proceed as normal hoping there isn’t an issue with it? (this is known as a ‘soft-fail’). Given that the vast majority of certificates are NOT revoked, a ‘soft-fail’ is really the only viable option. Unfortunately a ‘soft-fail’ strategy has a critical security flaw, as described here. How a ‘soft-fail’ is handled depends entirely on the browser being used.
...
Online Certificate Status Protocol
So if CRL doesn’t work particularly well, what else can we use? This is the reason the Online Certificate Status Protocol (OCSP) was created. Essentially, it allows a browser to send information about the certificate it is verifying to an OCSP responder, and the responder will send a message back saying either: Good, Revoked or Unknown. The payload is small and looping through a huge list of revoked certificate serials isn’t required. Sounds better doesn’t it?
So with the creation of OCSP has the problem of certificate revocation been solved? I’m afraid not. OCSP also comes with a number of issues:
* Checking requires a TCP connection to the OCSP responder - This network overhead takes time to establish and adds latency to the SSL negotiation.
* OCSP slows down the TLS handshake - The SSL negotiation cannot fully complete until a response is received from the OCSP responder. (there is a fallback which I mentioned earlier: ‘soft-fail’)
* An OCSP responder can sometimes fail - What happens if the browser doesn’t get a response? It can either blindly trust the certificate is still valid (‘soft-fail’), or terminate the connection (‘hard-fail’).
* Privacy concerns - By contacting the responder, the browser is leaking what website a user is accessing to the CA. Sounds like a potential method to track a person across the web that they don’t know about or opt-out of.
Proprietary systems
Due to the issues with both CRL and OCSP, browser vendors and Operating System (OS) manufacturers have come up with their own proprietary systems for handling certificate revocations:
* Chrome (Chromium) uses CRLSets
* Firefox uses OneCRL
* Safari is handled at the OS level
* Edge(Chromium) uses CRLSets
* Edge(EdgeHTML) handles it at the OS level
* Internet Explorer handles it at the OS level
* Mobile browsers... could be OS level, I’m not 100% sure.
This is my current understanding from lots of searching. If anyone has any information on how mobile browser revocation works I’d love to know. I’ve struggled to find any definitive answers.
No comments:
Post a Comment