В режиме Must-Staple нагрузка на их резолвер становится почти никакой.
OCSP Staple валидно, насколько я помню, в течении нескольких дней, так что в худшем случае на один сертификат будет перезапрашивать его пару раз в день.
И никакой блокировки для клиентов в итоге - вся проверка идёт локально.
Но быстро отозвать сертификат тоже не получится, хотя в случае с CRL то же самое - они тоже кешируются.
Каждый запрос в OCSP содержит сертификат (и, соответственно, по сути, имя домена в большинстве случаев) хоста, куда клиент подключается. И с какого адреса.
А в остальном-то технология отличная, спору нет, лучше этих непонятных списков. Могли бы оставить её в режиме только Must-Staple.
Да, постфактум, но лучше чем ничего. А какие лучше варианты есть с Domain Validation?
Сейчас вот перейдут на TLS-сертификаты без информации о способе проверки статуса
Это о чём речь? Отключение OCSP Stapling? Так Certificate Revocation Lists никуда не уходят вроде бы. Да, проверка CRL во всяких Embedded системах скорее всего никакая, но OCSP Stapling там тем более никогда не было скорее всего.
Ну, от этого в децентрализованной системе никуда не денешься - всегда будут какие-то маргинальные CA, которые чего-то не поддерживают.
В идеале нужно настраивать мониторинг сертификата своего хоста снаружи: проверку что он выдан правильным CA, что занесён в Certificate Transparency Log и так далее.
Ну, в статье речь про LetsEncrypt, который де-факто стандарт. А он закрывает все из этих проблем: юзает DNSSEC, проверяет все авторитативные NS. Возможно не из нескольких точек, но с DNSSEC это и не нужно.
Обновлялся, конечно, только недавно, ничего не отвалилось. Но допускаю что мне просто повезло: точнее я просто жду, обычно, до 1 или 2 сервисного релиза перед обновлением.
Привычка ещё со времён винды - "до 1 сервис-пака не юзать" :)
Если какие-то ioctl или другие вызовы задепрекейтились в 3 ядре, которые юзались - то ой, докер конечно не поможет ибо там ядро-то общее на всех. Только виртуалка.
Насчёт винды соглашусь, а вот насчёт линукса... это вряд-ли.
Как обычные проблемы с зависимостями, так и всякие forward/backward-compatibility с GLIBC.
Единственный надёжный способ - полностью статический бинарник, собранный с MUSL вместо GLIBC. И то до тех пор, пока всякие вызовы ядра вдруг не поменяются (ну это уже маловероятно).
Да плевать они хотели. "Правительство на другой планете живёт, родной" (ц)
Наверное что её можно достаточно легко перейти не привлекая внимания санитаров :)
Ну вы ведь не думаете что реальная причина в блокировке всяких Russia Today?
В режиме Must-Staple нагрузка на их резолвер становится почти никакой.
OCSP Staple валидно, насколько я помню, в течении нескольких дней, так что в худшем случае на один сертификат будет перезапрашивать его пару раз в день.
И никакой блокировки для клиентов в итоге - вся проверка идёт локально.
Но быстро отозвать сертификат тоже не получится, хотя в случае с CRL то же самое - они тоже кешируются.
Ну, для шестидневных сертификатов, может, и действительно нет особенного смысла в CRL.
Но тут, конечно, как всегда вопрос баланса безопасности и сложности...
Они убрали OCSP по одной простой причине - оно убивает приватность.
Каждый запрос в OCSP содержит сертификат (и, соответственно, по сути, имя домена в большинстве случаев) хоста, куда клиент подключается. И с какого адреса.
А в остальном-то технология отличная, спору нет, лучше этих непонятных списков. Могли бы оставить её в режиме только Must-Staple.
Да, постфактум, но лучше чем ничего. А какие лучше варианты есть с Domain Validation?
Это о чём речь? Отключение OCSP Stapling? Так Certificate Revocation Lists никуда не уходят вроде бы. Да, проверка CRL во всяких Embedded системах скорее всего никакая, но OCSP Stapling там тем более никогда не было скорее всего.
Ну, от этого в децентрализованной системе никуда не денешься - всегда будут какие-то маргинальные CA, которые чего-то не поддерживают.
В идеале нужно настраивать мониторинг сертификата своего хоста снаружи: проверку что он выдан правильным CA, что занесён в Certificate Transparency Log и так далее.
Ну, в статье речь про LetsEncrypt, который де-факто стандарт. А он закрывает все из этих проблем: юзает DNSSEC, проверяет все авторитативные NS. Возможно не из нескольких точек, но с DNSSEC это и не нужно.
https://github.com/daanx/mimalloc-bench
Есть много аналогов не хуже вроде mimalloc от Microsoft.
HDD делают точно так же.
Медь на 10Гбит это ад. Трансиверы греются как не в себя. Так что SFP+ удобнее, можно и оптику вставить и DAC.
Терморектальный криптоанализ проводят?
Ку-Клукс-Клановцы
"Дипфейки о российской армии"...
Прочитал "детекторы дикпиков". Долго думал...
Обновлялся, конечно, только недавно, ничего не отвалилось. Но допускаю что мне просто повезло: точнее я просто жду, обычно, до 1 или 2 сервисного релиза перед обновлением.
Привычка ещё со времён винды - "до 1 сервис-пака не юзать" :)
Если какие-то ioctl или другие вызовы задепрекейтились в 3 ядре, которые юзались - то ой, докер конечно не поможет ибо там ядро-то общее на всех. Только виртуалка.
Насчёт винды соглашусь, а вот насчёт линукса... это вряд-ли.
Как обычные проблемы с зависимостями, так и всякие forward/backward-compatibility с GLIBC.
Единственный надёжный способ - полностью статический бинарник, собранный с MUSL вместо GLIBC. И то до тех пор, пока всякие вызовы ядра вдруг не поменяются (ну это уже маловероятно).