dxdt.blog: занимательный интернет-журнал

Шумная история: после обновления iOS, некоторые аппараты iPhone, которые ремонтировались в неавторизованных мастерских, оказались нерабочими (вроде бы, причина – замена сенсора-считывателя отпечатка пальца). Есть множество историй, в которых “выкатка” обновления ПО убивает то или иное устройство. Но в этот раз опять вспомнили о том, что системное программное обеспечение используется и при управлении различными производствами (набравшая наконец популярность тема безопасности АСУ ТП). А раз “внешний” владелец ПО может отключить iPhone, то почему бы не проделать то же самое и с промышленными системами? Про станки, которые дистанционно получают обновления, а также могут быть дистанционно заблокированы разработчиком, если, например, не продлён срок договора обслуживания, – давно известно. Но ещё старше предлагаемое решение: мол, давайте отключим станки и оборудование от Интернета (а программное обеспечение, стало быть, всё равно оставим без изменений), чтобы обезопасить систему управления от отключения извне. В современной ситуации – неправильное решение, и очень наивное.

Зловред Stuxnet, портивший иранские центрифуги на урановом производстве, был занесён в промышленную сеть на “флешке”. Реальность информационной безопасности на производствах, в типичных корпоративных сетях, такова, что если сеть вообще работает, то сейчас для проведения атаки не так уж и важно, подключена она к Интернету или нет. Главное, чтобы компьютеры были соединены между собой, а точка проникновения через наивный “воздушный зазор” (air gap) – найдётся. На практике, из-за человеческого фактора, отсутствие подключения к Интернету и массовое перемещение “флешек” – делают ситуацию хуже, потому что для атаки со стороны USB системы гораздо более уязвимы, чем для атаки из Интернета. (Интернет, кстати – всё равно всегда находится рядом, буквально в одном “хопе”: будь то смартфон или “нелегально” пронесённый 4G-модем, который подключен к компьютеру на рабочем месте. Поделать с этим ничего нельзя, так как отказываться от глобальной Сети, мягко говоря, невыгодно в стратегическом смысле.)

Конечно, не следует делать вывод, что нужно все производственные системы подключить напрямую к Сети. Нет, подключать не нужно. Но в современной ситуации рассчитывать на то, что отсутствие такого подключения как-то защищает “чужую” систему от отключения в критической ситуации – наивно. От легитимного отключения, реализованного банально – да, защитит. Но уже чуть более продвинутое решение, подразумевающее закладку в оборудовании, срабатывающую по времени отсутствия обновлений, вопрос с таким отключением полностью снимает. Кроме того, если говорить о промышленных системах, там передача сигналов возможна иными методами. Если аппаратура, техпроцесс, или управляющее программное обеспечение, хотя бы один из этих элементов – что-то вроде чёрного ящика для тех, кто оборудование использует (а это, обычно, так, к сожалению), то “отключающая закладка” может быть активирована при помощи сигнала, полученного через тот или иной датчик, или, если хотите, даже через изменение химического состава сырья. Или производство останавливается из-за того, что смартфон одного из рабочих “пропищал” своим динамиком кодовую последовательность на высоких частотах, её принял ультразвуковой дальномер, измеряющий уровень масла в котле-смесителе, принял – и просигналил в центральную автоматическую систему управления, которая быстренько сломала весь цех и сама вырубилась (на всякий случай, вместе с телефонией и электричеством). Кажется фантастикой. Но это только кажется, да и казаться будет не долго: потому что к популярной теме “кибербезопасности” АСУ ТП подходят с навыками защиты офисного “домена Windows”, а с промышленными системами ситуация сложнее.

Кстати, что касается Windows XP, которая, якобы, “управляет британскими подводными лодками с ядерным оружием”: возможно, эта система и работает на каких-то компьютерах, находящихся на борту, но вряд ли чем-то на лодке управляет. Дело в том, что Windows XP – не является системой реального времени: с ней всегда были проблемы при попытках управления тем или иным оборудованием. Соответственно, встроенные системы используют другие ОС, обычно, это UNIX-подобные (из-за POSIX, но это детали) ОС реального времени.

Вообще, если речь идёт о системах из 90-х годов прошлого века (это означает, что разрабатывались-то они в конце 80-х), можно было бы поверить, что на борту есть управляющие вычислительные машины, работающие под MS-DOS. Это маловероятно, но такое можно представить, потому что под MS-DOS приложения реального времени работают хорошо, мне, в 90-х, приходилось такие видеть лично. Но XP – это что-то журналисты напутали (особенно, если учитывать, что система выпущена в 2001).

Появился новый робот, быстро собирающий кубик Рубика – он справляется примерно за секунду (по ссылке с картинки – видео на Youtube.com):

Конкретно это решение можно, конечно, покритиковать: там четыре камеры; нужен специально подготовленный кубик (насадки на валах электродвигателей входят в механическое зацепление с центральными элементами сторон кубика); кубик устанавливается в заранее заданном положении (манипуляторы размечены по цветам) и так далее, и тому подобное. Однако интереснее подумать, насколько вообще можно улучшить результат. Вычислительные мощности доступны, поэтому механическая составляющая робота оказывается важным фактором, устанавливающим границы.

Если я не путаю, то сейчас известно, что из любой конфигурации кубик (3×3) собирается не более, чем за 26 ходов, если ходом называется поворот грани на 90 градусов. При этом большинство конфигураций лежат на два-три хода ближе к собранному кубику. Для оценки точное число ходов не так важно. Примем, что типичная сложная конфигурация – 25 ходов. То есть, если поворачивать грань за 10 миллисекунд на 90 градусов, то с преобразованиями конфигурации можно уложиться в 250 мс (плюс затраты на “переключение” граней – но не будем их учитывать). 10 мс – это 9000 градусов или 25 оборотов в секунду. Сама по себе, скорость вращения не очень большая, добротный кубик её наверняка выдержит. Заметные потери времени при “миллисекундном разрешении” будут связаны с разгоном грани – отсюда и идеи с механическим зацеплением. Для немодифицированного кубика быстрый разгон при начале вращения грани составит серьёзную техническую проблему.

Работа робота сводится к определению начальной конфигурации кубика, вычислению оптимального (или близкого к оптимальному) пути из этой конфигурации к собранному кубику, выполнению ходов. Интересно, что оптимальный путь здесь не обязательно кратчайший. Дело в том, что оптимизировать нужно с учётом исполнительного механизма, а он может какие-то ходы выполнять быстрее, а какие-то – медленнее. Например, очевидно, что все повороты должны осуществляться в одну сторону, что некоторые ходы поддаются механическому “распараллеливанию”, а некоторые – нет, и так далее. Изображение кубика требуется получить только один раз, для определения начальной позиции. Причём это изображение может быть низкого разрешения и известной геометрии, так что сколь-нибудь заметного времени на передачу и распознавание не потребуется. Основное вычислительное время – поиск оптимального пути сборки. После того, как получен список ходов – он отправляется в контроллер механизма, который максимально быстро выполняет их, передавая команды исполнительным механизмам. Логично использовать простейший контроллер, а максимум вычислений проводить на управляющем компьютере: результатом работы программы будет являться набор команд на поворот валов электродвигателей, который и передаётся в контроллер (алгоритм выполнения команд должен учитывать параллельное выполнение, так что контроллеру потребуется память и логика, позволяющая одновременно управлять несколькими двигателями).

В общем, тема эта весьма интересная, а особенное техническое развитие она получает после преодоления секундного барьера. (Человеческий рекорд, кстати, чуть менее 5 секунд.)

Сейчас в СМИ очередная волна сравнения различных программных систем по числу обнаруженных уязвимостей. При этом во многих публикациях системы, с меньшим числом обнаруженных уязвимостей называют “более безопасными”, сравнивая их с теми системами, где уязвимостей нашли больше. Однако это неправильно. Такой показатель, как число обнаруженных за некоторый промежуток времени уязвимостей – очень слабо связан с реальной безопасностью использования той или иной системы, даже в случае, если речь идёт о ситуации “при прочих равных”, например, когда сравнивают два распространённых браузера. Число обнаруженных уязвимостей может, разве что, косвенно свидетельствовать о том, какая система более популярна у исследователей. (Это если опустить тот факт, что корректное определение понятия “безопасности” вообще весьма сложно для программного продукта.)

Почему это так? Прежде всего потому, что процесс обнаружения уязвимостей – нестабильный, а сами уязвимости – весьма различны по своему влиянию на степень безопасности использования программной системы. Более того, у разных разработчиков – разные методики и планы реагирования на обнаружение уязвимости. А также – не существует универсального “закона сохранения уязвимостей”. Другими словами: то, что в браузере “Имярек” обнаружили лишь десять уязвимостей, приводящих к отказу в работе, не означает, что в этом браузере нет ещё одной, но уже позволяющей удалённо выполнить произвольный код. А то, что в операционной системе “Имярек-2” обнаружили тысячу уязвимостей, скорее всего никак не повлияло на наличие или отсутствие уязвимостей в другой, не менее распространённой, операционной системе, в которой уязвимостей нашли пока что только сотню. (Хотя, в последнем случае можно предположить, что разработчики второй системы чему-то научились на опыте авторов первой, да и залатали дыры заранее; но, к сожалению, практика показывает, что это скорее фантастика, чем реальность.)

Получается непрерывная серия записок про TLS и связанные технологии, но, тем не менее, продолжу. Добавил на dxdt.ru поддержку технологии под названием HPKP – HTTP Public Key Pinning. Key Pinning – это привязывание публичного ключа к сетевому ресурсу (по имени или по адресу) на стороне клиента. Принцип хорошо известен из практики использования SSH: здесь отпечатки, идентифицирующие серверы, при первом контакте сохраняются на клиенте; в дальнейшем, изменение отпечатка позволит обнаружить возможную подмену ключей в рамках атаки “человек посередине”. Для HTTP предложена технология (RFC 7469), базирующаяся на той же идее.

Веб-сервер передаёт специальное поле в составе заголовков HTTP. Поле содержит отпечатки (значение хеш-функции) публичных ключей, которые используются данным сервером при установлении TLS-соединения, а также время, в течение которого клиенту следует помнить отпечатки. Браузер (то есть, клиент HTTPS), впервые обнаружив отпечатки ключей, запоминает их. При следующих обращениях к данному ресурсу – отпечатки сверяются с переданными ключами: если обнаружено расхождение, то браузер не устанавливает соединение и выдаёт предупреждение системы безопасности. HPKP поддерживается, например, в Chrome и Firefox.

Метод позволяет обнаружить подмену ключей, например, в схеме с выпуском “перехватывающего” сертификата для заданного доменного имени. Дело в том, что узел, перехватывающий TLS, даже если у него имеется валидный сертификат для атакуемого домена, обычно не имеет оригинального секретного серверного ключа – вместо него он использует свой. Значение отпечатка у этого перехватывающего ключа другое, поэтому браузер сможет обнаружить подмену. Если HPKP не использовать, то перехват пройдёт незамеченным, так как цепочка сертификатов будет валидной.

Посмотрим на реализацию подробнее, на примере dxdt.ru:

$ wget -S -O /dev/null https://dxdt.ru/ 2>&1 | grep ‘Public-Key-Pins:’ | tr -s ‘ ‘ | sed ‘s/\;/\;\n/g’

Public-Key-Pins: pin-sha256=”WXeGHAmPHRPwX7CbyIUCQm9mtStbVAZR2LOvTAAQKNg=”;
pin-sha256=”dj2qz8mxs8NSpJdISrUPRfL86ZGu3QNkJm4hL+opE0o=”;
pin-sha256=”nq9/zIb/QKb+tHd1ZU5keAYkYzrA8zx7tMmVtDDNG0M=”;
pin-sha256=”kkwURRddFrj4gRH7ILMp/Fqrvl6kfO4o2ekBOmiP6B0=”;
max-age=270127;

Поле HPKP называется Public-Key-Pins и, в нашем примере, содержит четыре значения pin-sha256 – это и есть отпечатки ключей (значение SHA-256 от публичного ключа, взятое в Base64). Почему их четыре? Потому что на dxdt.ru поддерживается два типа подписей: ECDSA и RSA, соответственно, нужно публиковать отпечатки для каждого из них; кроме того, стандарт требует указания как минимум одного “запасного ключа”, который отсутствует в цепочке валидации – я решил опубликовать по запасному ключу для каждого типа подписи. Итого: четыре отпечатка. Дополнительные отпечатки, очевидно, требуются для того, чтобы можно было поменять ключи без потери доступности сайта.

Стандарт позволяет использовать любые ключи, участвующие в цепочке валидации. То есть, можно было указать ключи из промежуточных сертификатов. Но я выбрал серверные ключи, в основном потому, что они под рукой и промежуточные сертификаты могут относительно легко поменяться.

Параметр max-age – определяет (в секундах) время, в течение которого браузер должен сохранять отпечатки. Я, пока что, установил довольно осторожное значение: около трёх суток.

Кроме того, поле Public-Key-Pins позволяет использовать ещё пару параметров: includeSubdomains – это флаг, распространяющий действие отпечатков на поддомены; report-uri – адрес, на который браузер будет передавать сообщения об ошибках. Последний параметр особенно интересен. Он позволяет поднять сервер, который будет получать сообщения от клиентских браузеров, которые натолкнулись на ошибки в работе HPKP – это позволяет обнаруживать атаки “человек посередине”, что называется, в дикой природе. Сообщение содержит детали контекста, в котором возникла ошибка. Эту функцию уже реализует Google Chrome. Естественно, для приёма сообщений нужен отдельный домен. Создание такой точки приёма для dxdt.ru – следующий шаг: нужно выделить сервер и запрограммировать обработчик сообщений.

Addon:

Как получить отпечатки ключей? Достаточно просто, если воспользоваться OpenSSL (я использовал файлы секретных ключей).

Для RSA:

openssl rsa -pubout -in rsa-private.pem -outform DER | openssl dgst -sha256 -binary | openssl enc -base64

Для ECDSA:

openssl ec -pubout -in ec-private.pem -outform DER | openssl dgst -sha256 -binary | openssl enc -base64

В OpenSSL теперь будет ГОСТ (2012) для TLS:

“Специалисты Технического центра Интернет (ТЦИ) достигли договоренностей о включении поддержки российских криптографических алгоритмов цифровой электронной подписи и хеширования 2012 года ГОСТ Р 34.10-2012 и ГОСТ Р 34-11.2012.”

Силами Дмитрия Белявского. Замечательно. (Соответствующий commit в Git OpenSSL.)

Сообщают, что приложение “Яндекс.Навигатор” записывало звук в потоковом режиме, фактически, работая диктофоном. “Яндекс” признаётся, что такая “недокументированная функция” – всего лишь следствие принятого в компании метода разработки программных продуктов (это что-то вроде варианта Agile, как я понимаю, но когда “в продакшн” вываливают всё что угодно, лишь бы взятый с потолка срок сдачи не подвинуть). Между тем, интеллектуальный диктофон, активирующий запись по ключевым словам (а яндексовское приложение, как они сами говорят, использует запись звука для получения голосовых команд) – очень удобная шпионская штука: пишет только то, что заказывали. Список актуальных ключевых слов может скачиваться с сервера.

Если на клиенте есть словарь и хорошая функция распознавания речи, то результат записи можно передавать в центр сбора и обработки не в виде бинарного потока звукозаписи, а в текстовой расшифровке. Текстовое представление, при условии использования синхронных словарей на клиенте и сервере, позволяет эффективно кодировать записанные фразы. Получается что-то вроде телеграммы, для передачи которой требуется буквально несколько байтов. Эти байты легко спрятать в легитимном трафике. Сложности составляет маскировка словаря на клиенте. Вдруг, кто-то разберёт приложение и обнаружит подозрительный словарь, содержащий не только голосовые команды. С другой стороны, такие “пользовательские разоблачения” сейчас не особенно беспокоят даже самих пользователей, что уж говорить о компаниях-разработчиках, которым вообще всё равно.

Отдельная полезная функция – известно, где находится говорящий в данный момент. Такая замечательная система смогла бы отвечать на следующие запросы: “где находятся пользователи, обсуждающие пролёт НЛО?”. “Пролёт НЛО” отдельно описывается в виде “семантического фильтра”, с набором слов и грамматических конструкций. Естественно, НЛО можно заменить на другие интересные объекты и явления.

Частота появления новых записок на dxdt.ru снизилась, и вот почему: я за это время написал большой текст про TLS, рассказывающий как этот протокол работает в подробностях. Несмотря на то, что изложение начинается с истории разработки TLS – это технический, ориентированный на специалистов, текст, подразумевающий некоторую подготовку у читателя: местами протокол разобран буквально до байта (в качестве примеров я рассматриваю дампы TLS-сессий). Подробных русскоязычных описаний для TLS очень мало, а протокол этот получает всё большее распространение – неправильное понимание принципов работы TLS ведёт к неприятным ошибкам в реализациях сервисов, которые его используют. Поэтому, думаю, такое описание будет полезно.

Описание я планирую дополнять, потому что, несмотря на объём, охвачены ещё не все аспекты, которые хотелось бы рассмотреть. Сейчас в деталях рассмотрены такие ключевые моменты, как установление соединения (Handshake) и логика построения обмена сообщениями – это основа основ TLS. В ближайших планах: раздел, разбирающий современные шифры (в различных режимах работы), пояснения про использование криптографии на эллиптических кривых. Вероятно, будут исходники на С, поясняющие некоторые моменты реализаций. Конечно, нужен структурный путеводитель по RFC, имеющим отношение к TLS (их великое множество). Для того, чтобы получился полноценный тематический сайт я выделил проекту отдельный адрес: https://tls.dxdt.ru/. (Правда, пока там многое нужно оформить.)

Если есть какие-то поправки, уточнения, пожелания по новым темам (про что написать подробнее) – сообщайте, пожалуйста, либо мне почтой, либо в комментарии к этой записке.

Сам текст:

Ключи, шифры, сообщения: как работает TLS

В продолжение предыдущей записки о системе от Wolfram-а, распознающей образы на изображениях. Интересно, что ImageIdentify работает весьма хорошо даже с очень сложными сценами. Запутать систему, отогнав её на подобающую сторону теста принадлежности к роботам, конечно можно, особенно, если вы понимаете математические основы “компьютерного зрения”, но результаты всё равно впечатляют. Возьмём для примера разные картинки велосипедов и отправим их на сервис ImageIdentify.com. Опознать что-то общее (“велосипедное”) на этих картинках человеку несложно, у автомата – сложности возникают, капчу он бы не решил.

Надо заметить, что обработка произвольных файлов изображений сама по себе трудна; многие проблемы кроются в приведении файлов к представлению, пригодному для дальнейшей обработки. Если бы некий робот имел возможность посмотреть на те же сцены своими камерами, то результаты были бы значительно лучше.

Предположим, что некоторый пользователь онлайн-игры использует несколько аккаунтов (такое часто случается). Если администрации игры требуется сгруппировать такие аккаунты – а это просто необходимо для вычисления различных “маркетинговых” характеристик, – то для этого хорошо подходит механизм “профилирования” на основе активности пользователя в игре.

Понятно, что можно попробовать связать аккаунты на основе IP-адресов, но, при существующем распространении NAT, за одним адресом могут оказаться сотни различных пользователей. Если игра использует специальный клиент, идентификатором может послужить некий уникальный номер клиентской программы, но ведь и компьютер может быть общим, так что тоже возникает погрешность. А вот изменить поведение в игре – игроку крайне сложно, скорее, невозможно, если вести речь не о крупных чисто игровых действиях, а о базовых интерактивных элементах: о манере передвижения мышки, управления движением персонажа, использования меню и настроек в игре.

Для записи таких характеристик придётся вести подробные логи. Но дисковое пространство сейчас стоит недорого, да и сбор нужных параметров (которые неплохо “сжимаются” при использовании правильного кодирования) не отнимет заметной полосы пропускания канала доступа к Интернету. Зато можно быть уверенным, что уже на небольшом числе элементов идентифицирующей последовательности множество записей в логах расщепится на уникальные группы, соответствующие отдельным игрокам. Что может представлять собой идентифицирующая последовательность? Например, вот такой набор характеристик: средняя скорость перемещения курсора мыши; соотношение вертикальной и горизонтальной скорости курсора; частота следования сообщений в игровом чате; число уникальных слов, используемых в чате; частота нажатия кнопок управления персонажем (или игровым процессом, не важно) и т.д., и т.п. Чем больше параметров, тем точнее будет разделение пользователей.

Поведенческая идентификация несравнимо качественнее, чем идентификация по техническим параметрам (IP-адрес, скорость канала, тип оборудования и т.п.). Причина в том, что технические параметры характеризуют компьютер, а поведенческие – того, кто компьютер использует. Преимущество онлайн-игр перед другими системами (типа интернет-банков или веб-сайтов) в том, что пользователь здесь взаимодействует с системой гораздо более активно, совершая за малое время большое число измеримых действий.

Хэш-функция SHA-1 уже несколько лет считается недостаточно стойкой для использования в подписях SSL-сертификатов. Сейчас идёт процесс вытеснения этой функции из действующих сертификатов, но пока что таких сертификатов много, они встречаются сплошь и рядом. Использование SHA-1 приводит к “неожиданным” эффектам в браузерах. Посмотрим на один из примеров – сайт nic.ru.

На сервере, где расположен nic.ru, установлен валидный сертификат с расширенной проверкой (EV). Однако если зайти на сайт при помощи браузера Chrome (42.0.2311.90 – актуальная на момент написания заметки версия), работающего в среде операционной системы Windows (версии 8.1, например), то в адресной строке браузера появляется предупреждение о том, что сайт использует устаревшие технологии безопасности. Выглядит это так:

Естественно, ожидается, что корректно установленный EV-сертификат приведёт к другому эффекту, отобразив “доверенную” адресную строку. Так происходит в браузере Internet Explorer 10, на той же тестовой машине:

А если воспользоваться браузером Mozilla Firefox, то эффект тоже положительный:

Впрочем, положительный эффект в Firefox имеет под собой другую почву, нежели случай IE. Что происходит, почему браузеры ведут себя именно так?

Посмотрим на набор сертификатов, возвращаемых сервером. Здесь есть три сертификата: серверный и два промежуточных; вот их свойства, указанные в полях Subject (s, предмет сертификации) и Issuer (i, удостоверяющая сторона):

0.
s:O=JSC ‘RU-CENTER’/OU=Project Department/CN=www.nic.ru
i:O=GeoTrust Inc./CN=GeoTrust EV SSL CA – G4

1.
s:O=GeoTrust Inc./CN=GeoTrust EV SSL CA – G4
i:O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority

2.
s:O=GeoTrust Inc./CN=GeoTrust Primary Certification Authority
i:O=Equifax/OU=Equifax Secure Certificate Authority

(Имя nic.ru без www. указано в расширении SAN сертификата, так что адреса на скриншотах – корректны.)

Проблемным является сертификат под номером 2 (выпущенный для GeoTrust Primary Certification Authority), так как он использует SHA-1 в составе алгоритма генерации подписи. Согласно политике Google Chrome, если в цепочку сертификатов (исключая корень) входит хотя бы один, подписанный с использованием SHA-1, то в адресной строке выводится предупреждение. Посмотрим на цепочку:

Всё сходится – промежуточный сертификат с SHA-1 входит в цепочку сразу после корня. (Обратите, кстати, внимание на то, что корень обозначен как GeoTrust, хотя сам корневой сертификат содержит название Equifax, в чём можно убедиться, если посмотреть внутрь его полей. Это следы маркетинга: бизнес по продаже цифровых сертификатов Equifax был продан компании, оказывающей эти услуги под брендом GeoTrust.) IE использует тот же набор корней, однако политика этого браузера позволяет даже EV-сертификатам быть подписанным по цепочке, включающей SHA-1, поэтому здесь всё хорошо.

А вот Firefox использует собственный набор корней, поэтому цепочка валидации тут иная:

Firefox содержит доверенный корень, обозначенный как GeoTrust Primary Certification Authority, от которого подписан промежуточный сертификат GeoTrust EV SSL CA – G4. То есть, те же сертификаты уже выстраиваются в цепочку, которая не содержит SHA-1, поэтому данная ситуация не может вызвать предупреждения, даже если бы такое предупреждение поддерживалось Firefox. Аналогично устроен и Google Chrome под Linux – там тоже встроен корень, позволяющий избежать использования промежуточного сертификата с SHA-1.

Выше я упомянул о том, что присутствие SHA-1 не учитывается для корневых сертификатов (встроенных в браузеры). Почему? Причина в том, что корневые сертификаты самоподписанные (по определению), а браузер доверяет не подписи, а открытому ключу, связанному с корневым сертификатом, и имени удостоверяющего центра, которое указано в сертификате. Раз подпись не играет ключевой роли, то и использованием SHA-1 в корневом сертификате можно пренебречь: оно никак не влияет на уровень доверия.

Что нужно делать веб-сайтам? Нужно перевыпускать сертификат в цепочке, которая не использует SHA-1.