Иногда хочется mTLS. Если совсем грубо, то это когда не только сервер предъявляет клиенту свой X509-сертификат, но и клиент серверу (на самом деле это только частный случай, но обычно делают именно так).
В разных браузерах хранилище пользовательских сертификатов реализовано по-разному. Например, у Mozilla Firefox оно своё собственное, а всякие там Edge и прочие Chrome используют system-wide хранилище.
ЧитатьВот странная ошибка, на мой взгляд.
По логике, это должно означать, что wordpress, не смог средствами операционной системы в которой он установлен проверить валидность сертификата, и соединяться не стал. Но нет. Средствами ОС он этого сделать не может, и что бы оставить движек максимально простым в использовании, разработчики пошли на не совсем простой шаг. Встроили проверку сертификата вместе с хранилищем сертификатов в сам wordpress.
Если вы попали сюда из поисковика, в поиске решения этой ошибки, то лечится она легко:
Достаточно в директорию wp-includes/certificates положить файл http://curl.haxx.se/ca/cacert.pem под именем ca-bundle.crt
А теперь, чем меня насторожило такое решение. Дело в том, что движки подобные wordpress легко ломаются, всегда найдется пара не пропатченных багов. А загрузка файлов через SSL не стартует без проверки подлинности, на случай, если нам пытаются подсунуть левый контент посредством атаки Men in middle.
Получается, что проверку подлинности сервера можно легко отключить, путем замены файла ca-bundle.crt на свой, где будет добавлен сфабрикованный корневой сертификат которым будет подписан сертификат узла men in middle.
UPD: Как показала практика, не везде можно решить проблему таким образом.
На сайте разработчиков curl нашел вот что: http://osdir.com/ml/web.curl.php/2007-02/msg00008.html
Суть в том, что если у вас установлена версия curl из перечисленных:
>libcurl/7.10.3 OpenSSL/0.9.6g
> libcurl/7.12.1 OpenSSL/0.9.7a
> libcurl/7.11.2 OpenSSL/0.9.7c
То без обновления curl не обойтись.
На прошедшей конференции Black Hat была обнародована информация о новом виде атаки BREACH, позволяющем восстановить содержимое отдельных секретных идентификаторов (например, сессионные cookie и CSRF-токены), передаваемых внутри зашифрованного HTTPS-соединения, сообщает opennet.ru. Метод атаки BREACH практически идентичен представленной в прошлом году атаке CRIME (Compression Ratio Info-leak Made Easy), за тем исключением, что атака оперирует особенностью изменения характера потока при сжатии на уровне HTTP, а не при сжатии на уровне TLS/SSL, как в случае с CRIME. Для организации атаки требуется получение контроля за трафиком на промежуточном шлюзе и выполнение на стороне браузера клиента JavaScript-кода злоумышленника (в случае получения контроля над транзитным шлюзом, осуществить подстановку JavaScript-кода в незащищённый трафик не составляет труда). Читать