The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Mozilla внедряет CRLite для проверки проблемных TLS-сертификатов

13.01.2020 10:38

Компания Mozilla объявила о начале тестирования в ночных сборках Firefox нового механизма определения отозванных сертификатов - CRLite. CRLite позволяет организовать эффективную проверку отзыва сертификатов по базе данных, размещаемой на системе пользователя. Развиваемая в Mozilla реализация CRLite опубликована под свободной лицензией MPL 2.0. Код для генерации БД и серверные компоненты написаны на Python и Go. Добавленные в Firefox клиентские части для чтения данных из БД подготовлены на языке Rust.

Применяемая до сих пор поверка сертификатов с привлечением внешних служб на базе протокола OCSP (Online Certificate Status Protocol) требует наличия гарантированного сетевого доступа, приводит к возникновению ощутимой задержки на обработку запроса (в среднем 350мс) и имеет проблемы с обеспечением конфиденциальности (отвечающие на запросы серверы OCSP получают сведения о конкретных сертификатах, по которым можно судить о том, какие сайты открывает пользователь). Существует также возможность локальной проверки по спискам CRL (Certificate Revocation List), но минусом такого метода является очень большой размер загружаемых данных - в настоящее время БД отозванных сертификатов занимает около 300 МБ и её рост продолжается.

Для блокирования скомпрометированных и отозванных удостоверяющими центрами сертификатов в Firefox с 2015 года используется централизованный чёрный список OneCRL в сочетании с обращением к сервису Google Safe Browsing для определения возможной вредоносной активности. OneCRL, как и CRLSets в Chrome, выступает промежуточным звеном, который агрегирует CRL-списки от удостоверяющих центров и предоставляет единый централизованный OCSP-сервис для проверки отозванных сертификатов, дающий возможность не отправлять запросы непосредственно в удостоверяющие центры. Несмотря на большую работу по повышению надёжности сервиса online-проверки сертификатов, данные телеметрии показывают, что более 7% запросов OCSP завершается таймаутом (несколько лет назад этот показатель составлял 15%).

По умолчанию, в случае невозможности осуществить проверку через OCSP, браузер считает сертификат корректным. Сервис может быть недоступен как из-за сетевых проблем и ограничений внутренних сетях, так и блокирован атакующими - для обхода проверки OCSP в ходе MITM-атаки достаточно просто заблокировать доступ к сервису проверки. Частично для предотвращения подобных атак реализована техника Must-Staple, позволяющая трактовать ошибку обращения по OCSP или недоступность OCSP как проблему с сертификатом, но данная возможность опциональна и требует специального оформления сертификата.

CRLite позволяет свести полные сведения обо всех отозванных сертификатах в легко обновляемую структуру, размером всего 1 MB, что даёт возможность хранить полную базу CRL на стороне клиента. Браузер сможет ежедневно синхронизировать свою копию данных об отозванных сертификатах, и эта БД будет доступна при любых условиях.

CRLite объединяет сведения из Certificate Transparency, публичного лога всех выданных и отозванных сертификатов, и результатов сканирования сертификатов в интернете (собираются различные CRL-списки удостоверяющих центров и агрегируется информация о всех известных сертификатах). Данные упаковываются с использованием каскадных фильтров Блума, вероятностной структуры, допускающей ложное определение отсутствующего элемента, но исключающей пропуск существующего элемента (т.е. с определённой вероятностью возможно ложное срабатывание на корректный сертификат, но отозванные сертификаты гарантированно будут выявлены).

Для исключения ложных срабатываний в CRLite введены дополнительные корректирующие уровни фильтра. После генерации структуры осуществляется перебор всех исходных записей и определение возникших ложных срабатываний. По результатам данной проверки создаётся дополнительная структура, которая каскадно накладывается на первую и корректирует возникшие ложные срабатывания. Операция повторяется до тех пор, пока ложные срабатывания при контрольной проверке не будут полностью исключены. Обычно для полного покрытия всех данных достаточно создания 7-10 слоёв. Так как состояние БД из-за периодической синхронизации немного отстаёт от актуального состояния CRL, проверка новых сертификатов, выписанных после последнего обновления БД CRLite, осуществляется при помощи протокола OCSP, в том числе используя технику OCSP Stapling (заверенный удостоверяющим центром ответ OCSP передаётся обслуживающим сайт сервером при согласовании TLS-соединения).

При помощи фильтров Блума декабрьский срез сведений из WebPKI, охватывающий 100 млн активных сертификатов и 750 тысяч отозванных сертификатов, удалось упаковать в структуру, размером 1.3 MB. Процесс генерации структуры достаточно ресурсоёмкий, но он выполняется на сервере Mozilla и пользователю отдаётся уже готовое обновление. Например, в бинарной форме используемые при генерации исходные данные требуют около 16 ГБ памяти при хранении в СУБД Redis, а в шестнадцатеричном виде дамп всех серийных номеров сертификатов занимает около 6.7 Гб. Процесс агрегирования всех отозванных и активных сертификатов занимает около 40 минут, а процесс генерации упакованной структуры на основе фильтра Блума требует ещё 20 минут.

В настоящее время в Mozilla обеспечено обновление БД CRLite четыре раза в день (не все обновления доставляются клиентам). Генерация delta-обновлений пока не реализована - применение bsdiff4, используемого для создания delta-обновлений релизов, не обеспечивает должную эффективность для CRLite и обновления получаются неоправданно большими. Для устранения этого недостатка планируется переработать формат структуры хранения для исключения лишнего перестроения и удаления слоёв.

CRLite пока работает в Firefox в пассивном режиме и используется параллельно с OCSP для накопления статистики о корректности работы. CRLite можно перевести в режим основной проверки, для этого в about:config нужно установить параметр security.pki.crlite_mode = 2.



  1. Главная ссылка к новости (https://blog.mozilla.org/secur...)
  2. OpenNews: В Chrome планируют отказаться от онлайн-проверки сертификатов
  3. OpenNews: Представлено TACK, расширение SSL/TLS для борьбы с MITM-атаками и поддельными сертификатами
  4. OpenNews: Google представил Key Transparency, альтернативу серверам криптографических ключей
  5. OpenNews: Объём HTTPS-трафика с поддельных сертификатов оценен в 0.2%
  6. OpenNews: Представлена централизованная база для проверки подлинности SSL-сертификатов
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/52175-crl
Ключевые слова: crl, cert, crlite, ocsp
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (58) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Lockywolf (ok), 12:56, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    На моём модеме полтора мегабайта качаются полчаса
     
     
  • 2.5, Crazy Alex (??), 13:01, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    14400?
     
     
  • 3.9, Аноним (9), 13:13, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    >14400?

    И все-все-все.

     
     
  • 4.11, Crazy Alex (??), 13:27, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    О, кто-то помнит ещё :-)
     
     
  • 5.14, Аноним (9), 13:35, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Анон ничего не забывает!
     
     
  • 6.21, Аноним (21), 14:34, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А помнишь Чубакку?
     
  • 6.45, pda (?), 20:05, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Анона тогда ещё не было. Где появился 9600... там настоящие имена требовалось указывать. :)
     
  • 4.28, Аноним (28), 16:45, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Модем на 16800 у меня был, но соединялся только на 14400. А вот про "все-все-все" не слышал.
     
     
  • 5.29, Аноним (29), 16:56, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Книжка называется "9600 бод и все-все-все", известная тема
     
  • 2.6, N (?), 13:06, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Зачем тебе тогда Firefox?
     
  • 2.18, Аноним (18), 13:49, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +12 +/
    И зачем ты потратил 5 минут своего модема на бесполезный коментарий?
     

  • 1.2, Невдолим (?), 12:57, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Мне вон до сих пор нотифы с баштела блочит, хотя у них серт вроде непротухший. После этой фигни перестанет или будет ещё лучше?
     
     
  • 2.10, мурзилла (?), 13:24, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • –12 +/
    после этой фигни станет еще круче - любой сайт может оказаться "заблочен" потому что случайно совпал какой-то бредовый код вычисляемый по из пальца высосанным алгоритмам.

    Ну, разумеется, кроме сайтов гугля, гугля и гугля, которые мы на такое совпадение проверяем и добавляем исключение - а васян-сайты должны умереть (так сказал гугль, который нам за это платит)!

     
     
  • 3.12, Crazy Alex (??), 13:29, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Вообще-то фильтры Блума - это вполне скучная и выверенная криптография
     
     
  • 4.24, мурзилла (?), 15:21, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • –6 +/
    главное - свято верить, молиться и поститься, что вываренная криптография от одного своего упоминания волшебным образом решает любые проблемы, и даже шрамы от вскрытия рассасывает.

    А что она не предназначена для употребления подобным образом и никакие костыли и подпорки неспособны исправить этот недостаток - мы скромненько замажем.

     
     
  • 5.31, имя (ok), 17:51, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > и никакие костыли и подпорки неспособны исправить этот недостаток

    Костыль этот прям в новости описан, привет.

     
     
  • 6.39, мурзилла (?), 19:41, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    я и говорю - мы отлично замазали тот факт, что этот костыль достоверным не является.

    Прикладывайте нашу вываренную криптографию так же к чирьям, родимым пятнам и комариным укусам - она и в этом случае отлично поможет, если, конечно, веровать.

     
  • 4.53, bircoph (ok), 02:58, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И каким местом это криптография? Это обычная вероятностная структура данных, предназначенная для уменьшения количества запросов к дорогостоящему и медленному источнику.
     
     
  • 5.55, Аноним (-), 08:27, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Для таких как мурзилла - любой алгоритм сложнее чем 2+2 непонятен. Значит, криптография!
     

  • 1.4, Аноним (4), 12:58, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    И при этом не слово о проверке данных. Т.е. базу может подменить любой желающий?
     
     
  • 2.8, Аноним (8), 13:10, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    И так понято, что CRLite будет проверяться по цифровой подписи, как провереются  загружаемые обновления  и чёрные списки. От подмены на стороне клиента ничего не поможет, с тем же успехом можно настройки изменить, чтобы по OCSP  не лез.
     
  • 2.52, хотел спросить (?), 23:46, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Небольшой офтопик... Я просто оставлю это здесь )) Друг просил ))

    Hello aluzzardi

    They use Psychological Warfare against those who would like to continue pamusb development.

    https://twitter.com/FailDef/status/1216514303416815616

    aledged and known attacking vectors known so far:
    http://hackerscardgame.ch (they will maybe qFire your modem if you access it [see Jacob Applebaum: to protect and infect part 2,
    -> part with Quantum Inserts, TURBINE, TARMOIL

    greetings from a bigger penguin
    Marc jr. Landolt

     

  • 1.7, Аноним (7), 13:07, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Обожаю мозиллу, корпорация добра
     
     
  • 2.13, Аноним (-), 13:32, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Они достигли определенных успехов в нанесении пользы и причинении добра.
     
  • 2.35, Аноним (35), 19:05, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Работают по методичке Гугла, как обычно.

    Хром давно отказался от OCSP, потому что 1) он требует вызовов к сторонним серверам при каждом SSL соединении, а это лишние тормоза 2) OCSP вызывает утечки данных о посещаемых сайтах центрам авторизации (а они у Гугла не в доле). Хром тоже мог бы использовать что-то вроде CRLite, но ему в любом случае нужно стучать на сервера гугла о каждом посещаемом URL, так что им просто нет нужды.

     

  • 1.16, DerRoteBaron (ok), 13:41, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Даже не смотря на сотни мегабайт, это определенно лучше, чем пинок на левые сервера по одному урлу
     
     
  • 2.17, mumu (ok), 13:46, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Обновлять-то всё-равно как-то придётся
     
     
  • 3.26, DerRoteBaron (ok), 15:39, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    При этом через обновления не утекает история посещений, в худшем случае активность
     
     
  • 4.43, Аноним (43), 19:59, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    история продолжит утекать по другим каналам
     
  • 2.46, Аноним84701 (ok), 20:19, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Даже не смотря на сотни мегабайт, это определенно лучше, чем пинок на левые сервера по одному урлу

    То ли я чего-то фатально не понял, то ли там сильно лукавят c "гигабайтами" и размерами БД:
    > Например, в бинарной форме используемые при генерации исходные данные требуют около 16 ГБ памяти при хранении в СУБД Redis, а в шестнадцатеричном виде дамп всех серийных номеров сертификатов занимает около 6.7 Гб
    > ...
    > БД отозванных сертификатов занимает около 300 МБ

    Конечному пользователю не нужно хранить базу быстрого доступа или номера всех 100 млн. активных сертификатов (что и не далается и в сабже).  Т.е. 16ГБ памяти - это сугубо "проблемы мозилы при генерации сабжевой структуры".
    Конечному пользователю нужна только возможность (быстро) проверить, нет ли среди 750 000 отозванных определенного сертификата.
    Для этого достаточно передать список первых 128 или 64 бит или даже 32 (если уж учитывать возможность теста на ложные срабатывания) хеша этих сертификатов.
    А это: 750 000 * 16 = 12МБ или 750 000 * 8 = 6МБ, 750 000 * 4 = 3МБ.
    Однократно.
    В принципе, те же яйца в профиль, но передавая хеши, а не готовую структуру данных, имеем намного меньше проблем с обновлениями. Т.к. в отличие от сабжа (где, насколько я понял, каждый раз генерируется новая структура данных, сильно отличная от предыдущей, так что дельта-обновления "получаются неоправданно большими" ) можно при запросе просто передавать список хешей добавленных после определенной даты сертификатов, который [список] клиент самостоятельно добавит в базу – а не каждый раз заставлять качать полностью новую структуру размером в мегабайт.

     
     
  • 3.61, Гентушник (ok), 20:29, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > даже 32 (если уж учитывать возможность теста на ложные срабатывания) хеша этих сертификатов.

    Но ведь в этом случае, если нашли начало хеша по локальной "урезанной" базе, нужно будет всё равно послать запрос OCSP и убедиться что полный хеш всё же совпадает.

    Это конечно, в целом, сокращает количество запросов OCSP, но проблему атак на блокирование OCSP не решает (описана в новости).
    Так же, небольшая часть данных всё равно будет утекать (по отозванным и "похожим" сертификатам).

    Если же дополнительную проверку по OCSP не делать и верить урезанному списку наслово, то возможны ложные срабатывания. Будет забавно если кто-нибудь этим воспользуется и сделает сертификат с началом хеша как у google.com, а потом отзовёт его.

     
     
  • 4.62, Аноним84701 (ok), 21:01, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> даже 32 (если уж учитывать возможность теста на ложные срабатывания) хеша этих сертификатов.
    > Но ведь в этом случае, если нашли начало хеша по локальной "урезанной"
    > базе, нужно будет всё равно послать запрос OCSP и убедиться что
    > полный хеш всё же совпадает.

    Не-не-не. Я же специально написал об "учитывании возможности ложных срабатываний".
    Т.е. сделать, как в сабже (только "в профиль") -- иметь  доп. список (в новости: "layer") для ложных срабатываний.
    Или использовать вариабельное кол. бит, достаточное для избежания коллизий.
    Там, на первый взгляд, проблема будет только в том, что в давно не обновленном списке какой нибудь новый (валидный) сертификат может попасть под ложное срабатывание (но опять же, можно использовать определенный минимум в те же 32 бит).

    Ну или взять 64/128 (хотя и тут лучше иметь этот самый доп. список) -- все равно через десяток-другой обновлений выходим по траффику в "плюс".

     
  • 2.57, mommy (?), 08:56, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я просто не использую ostp, crtlite тоже можно будет вырубить?
     
     
  • 3.63, DerRoteBaron (ok), 10:42, 15/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну я просто не использую ostp, crtlite тоже можно будет вырубить?

    В Firefox сейчас можно вырубить много что. Даже то, что этот Firefox в конец разломает, и сделает непригодным ни для чего. Так что наверняка да.

     

  • 1.19, Аноним (18), 13:51, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    К этой статье полезно дать ссылку, насколько все плохо с проверкой отозванных сетрификатов: https://habr.com/ru/post/332730/ (если коротко - она не работает).

     
     
  • 2.25, мурзилла (?), 15:22, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    мы сломали, поэтому и не работает.
    Нам, если что, гугель так велел, мы не сами!
     

  • 1.20, Онаним (?), 14:20, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Я помню когда браузеростроители работали именно над браузером. А сейчас что не новость то "блокировка X по умолчанию", телеметрия и сертификаты. Ощущение что за 3 месяца все что там сделали это переключили флаг с false на true.
     
     
  • 2.22, Anonymoustus (ok), 14:59, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Мурзилла портит браузер не для того, чтоб люди его выбирали пользоваться, а чтоб нахваливали хромог и стояли в загончике Гулагеля довольные.
     

  • 1.23, BigBoobs (?), 15:19, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Т.е. каждый день браузер будет обновлять базу, его фингерпринт будет фиксироваться и ... А не будет ли это использованно в качестве метода massive surveillance?

    В каждой новой версии FireFox новые зонды.

     
     
  • 2.27, Сейд (ok), 16:14, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что если обновлять базу из репозитория пакетов дострибутива?
     
  • 2.32, имя (ok), 17:55, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А не будет ли это использованно в качестве метода massive surveillance?

    С OCSP при желании уже сейчас можно отследить куда более интересные данные, если что.

     
     
  • 3.40, мурзилла (?), 19:44, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну и для чего, спрашивается, мы так стремились уничтожить любые CA, кроме letshitcrypt? Гугель, блин - ведь это ты ж нам велел?!
     

  • 1.30, Аноним (30), 17:06, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а что если отозвать все сертификаты, гудбай суверенный интернет?
     
     
  • 2.33, Аноним (43), 18:32, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а ты думаешь, зачем делается централизованный контроль всего? и почему в противовес этому разрабатывают "устойчивый интернет"?
     
  • 2.36, anonymous (??), 19:10, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже об этом подумал. Самое время нашим суверенноинтернетостроителям подумать об удостоверяющих центрах.
     
     
  • 3.37, Ivan_83 (ok), 19:12, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И кто им будет доверять?
     
     
  • 4.41, тов. майор (?), 19:46, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ты и будешь. А не будешь - отключим газ. И интернет. Ой...мы ж уже? Впрочем, "уже" мы не до конца - пока.

    До учета разного рода национал-предателей, вздумавших решать кому они там доверяют, а кому нет - дело дойдет чуть еще попозже.

     
     
  • 5.56, Аноним (-), 08:33, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А когда благодаря всему этому экономика ухнет и станет нечего или не на что жрать - догадайтесь, кто в первых рядах забьет на национал-чтототам и пойдет ларьки крышевать? :)
     
     
  • 6.59, пох. (?), 10:06, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну зачем же забьет? Служба - она и опасна, и трудна.  Очередного нацпредателя на бутылочку насадит, потом неспешно направится собирать дань с собирателей дани с ларьков, а тот пусть пока посидит, подумает, как точнее описать свои мыслепреступления в протоколе.

    И Родине сплошная польза, и ее верным столпам уважение.

    А что холопам жрать станет нечего - ну так они туже затянут пояса и еще теснее сплотятся вокруг Царя-Фюрера. Кто бы им к тому времени ни стал.

     
  • 4.44, Аноним (43), 20:02, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    а никогда не задумывался, зачем какому-нибудь дойчателекому иметь свой CA?
     
     
  • 5.48, дойчтелеком (?), 22:26, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    конечно же мы такие же м..ки как и ваши операторы, и обожаем подделывать чужие сертификаты, а мазила с гуглем ну конечно же не выкинут нас за это из списка доверия при первом же случае, следом за кучей других - а вы, главное, верьте, что у белых людей самолеты тоже из соломы и навоза, а летают - потому что боги так захотели.

    На самом деле мы давно потеряли счет своим железякам с https авторизацией. Включая те что в аренде у пользователей, которые совершенно не оценят визги современных браузеров и отказ открывать статус подключения "аааааа там сертификат self-signed" (да и наши техники тоже не всегда используют единственноверный корпоративный хром). Именно для этой цели нам нужен был полноценный CA. Но мифология вам, конечно же, милее.

     
     
  • 6.51, Аноним (51), 23:38, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Комодо же емнип выдавал валидные фейковые серты на домены и всё ещё доверенный. Есть подозрение, что вся эта движуха с "недоверенными" сертами была задумана с одной целью — выдавить конкурентов с рынка торговцев воздухом.
     
     
  • 7.58, пох. (?), 09:58, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    нет. Что продает _вам_ letshitcrypt? Правильно - ничего.
    А это значит - он продает - вас.

    Что продавал вам startssl? Правильно - премиум сервисы для тех, кто привык им пользоваться и кому они на самом деле были нужны.

    Почему при этом жив и здравствует wosign? Правильно - потому что мгновенно понял урок и ликвидировал  на корню свою конкуренцию летсшиткрипте - поэтому его оставили в покое.

    В результате - сколько там - 90% ocsp запросов приземлялись на сервер такой нужной и полезной компании trendmicro.

    Какая муха их сегодня укусила, что они вдруг решили сами же прикрыть результат всей своей деятельности по развалу структуры множественных trusted ca - пока неочевидно.

     

  • 1.34, Diamond00744 (ok), 18:54, 13/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Я правильно понимаю, что эта "эффективно упакованная база" будет полностью распакованная сидеть в оперативке?
     
     
  • 2.38, Аноним (38), 19:17, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет.

    wiki://Фильтр_Блума

     
     
  • 3.60, Аноним (60), 13:18, 14/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Фильтр Блума может использовать любой объём памяти

    То, что надо!
    Готовся вечно покупать оперативку, потому что для Мозиллы бесконечность не предел! 🦊

     
  • 2.42, Анонимус2 (?), 19:52, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Из этой "упакованной" базы нельзя получить оригинал, только проверить есть ли в оригинале какая-то запись.
     

  • 1.64, Total Anonimus (?), 15:53, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В продолжение темы - статистика по эксперименту от Мозиллы . https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру