ГОСТовые шифронаборы на сайте Ру-Центра
Dec. 14th, 2018 11:51 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
beldmitНесколько дней назад Ру-Центр стал поддерживать криптонаборы по ГОСТ на своём основном сайте, в API и прочих интерфейсах. Это привлекло внимание ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
schors АКА Фила Кулина, автора проекта по мониторингу интернет-блокировок в России. Внимание было привлечено потому, что УЦ, работающие по ГОСТ, в софте по умолчанию не ставятся, а при выборе шифронабора по ГОСТ требуются. Сайт Ру-Центра, видя предъявленный шифронабор по ГОСТ, его выбирал, клиент не мог верифицировать соединение и API оказывался недоступен. В фейсбуке возникла дискуссия, местами переходящая в срач, на 500 комментов в нескольких тредах с филиппиками в адрес ГОСТа. Лёша Саморуков аккуратно суммировал претензии к ситуации, и я обещал ему ответить. В ФБ я ответил, сюда сохраняю на будущее, чтобы не пропало.
"Когда я скачиваю/конфигурирую клиента tls, я by design, конфигурирую какую либо цепочку доверия. Вот в браузере это ca/bf, например. В клиенте к чешской налоговой - это список CA которым доверяет мвд .cz, и так далее. Обычно у этого множества CA есть некоторый общий регламент и принципы работы. Мы прекрасно понимаем, что добавление даже одного ca с другими политиками приведет к boom, что много раз доказывали авторы антивирусом и прочего стремного софта который добавляет свой рут.
В общем да, но есть нюансы. В части "скачиваю" варианта обычно два: встроенный в клиента набор или встроенный в операционку набор. Вопрос единства критериев - да, правильно.
При добавлении сторонних CA всё немного смешнее. Потому что в хранилище основное ты их часто добавить не можешь в принципе. А из дополнительного хранилища они зачастую обрабатываются немного по-другому. Например, требования CT для явно добавленных в браузерное хранилище проверяться не будут. И это сознательная политика Chrome. То есть тут презумпция разумности пользователя в полный рост.
Соответственно меньше всего я ожидаю от сервера, что он будет выбирать множество ca (заметь, не сам ca, а именно другое множество) исходя из положения звезд на небе и списка шифров, которые умеет клиент. Это - просто бессмысленно и бесполезно, так как в таком решение, на самом деле, плохо все, и технически и административно. И так, собственно, никто и не делает, на всех сервисах, которые работают не от ca/bf всегда свой url и часто отдельная страничка которая и рассказывает о том где и как скачать ca set.
Тут я с утверждениями согласен уже гораздо меньше. Сервер не выбирает CA. Сервер выбирает шифронабор. Если клиент предлагает шифронабор, это значит, что клиент этот шифронабор умеет. Если шифронабор подразумевает сертификаты с конкретными алгоритмами, то клиент должен уметь с этими сертификатами что-то сделать. Например, проверить. Или, например, принимать всегда.
Что касается того, что технически и административно Ру-Центр сделал криво — тут я согласен полностью. Прямо было бы заявить "Ребята, я включаю ГОСТ, корневые сертификаты брать здесь". Отдельную страницу сделать было бы идеально, но вот этого предупреждения было бы достаточно.
Теперь, почему это плохо.
1. Этот автовыбор сломается, как только кто-то еще (неважно кто) заимплементит свой набор ca с gost-ом но другими рутами и политикой. Допускать, что этого никогда не произойдет - стрелять себе в ногу, тем более что n сетов рутов даже в пределах одного государства или даже организации - частое явление. Произойдет при этом именно то, что описано у фила. В итоге, чтобы этого не произошло - гост будут максимально изолировать в песочницы, чтобы ндйбг он не засветился в возможностях клиента )
В смысле - сломается? Пока конфигурирование доверия ГОСТовым сертификатам — процесс полностью ручной, не сломается. При правильном соблюдении процедур. Они не соблюдены, см. выше.
2. Это и административно неумно. Обычно, если мы создаем свой CA - то нас по каким-то причинам не устраивает ca/bf. Таких причин может быть куча, и они часто валидны. Но если сервис одновременно использует на том же ендпоинте ca/bf и нечто совершенно другое - мы просто уменьшаем безопасность, ничего не получая взамен.
Вообще говоря, уменьшаем. В данном случае я склонен полагать, что незначительно.
Причины быть недовольными отечественными шифронаборами у меня есть, и они отнюдь не в том, что злой ФСБ зашил бекдор в параметры. Человек, включающий ГОСТы явно, должен был явно настраивать параметры доверенных УЦ. Человек, включающий ГОСТы неявно (например, скачав браузер Спутник), получит эти УЦ неявно. Если он конфигурирует набор УЦ явно, то у него есть своя процедура добавления надёжности (например, «чтобы сертификат сайта XXX проходил валидацию»). Если неявно — то проблемы у него возможны в том объёме, в котором авторы условного браузера «Спутник» туда положили грабли.
Гост тут и правда ни при чем. Как и любой другой алгоритм. И для любого технаря было бы очевидно, что если мы пришли с клиентом умеющим эллиптику и получили что-то от условной чешской почты, а придя с RSA - получили бы рут от ca/cf - то это косяк и ошибка конфигурации. А с гостом православных связистов начинает клинить, хотя как ты и сам пишешь - он ни при чем. Вот и вся история"
За православных связистов не скажу ничего. Но тут вижу косяк по бизнесу со стороны Ру-Центра, нескомпенсированный техникой со стороны Фила.
Решений для Фила вижу два: отключить ГОСТ при работе с Ру-Центром или добавлять сертификат УЦ КриптоПро в доверенные. Технически оба оправданы одинаково.
schors АКА Фила Кулина, автора проекта по мониторингу интернет-блокировок в России. Внимание было привлечено потому, что УЦ, работающие по ГОСТ, в софте по умолчанию не ставятся, а при выборе шифронабора по ГОСТ требуются. Сайт Ру-Центра, видя предъявленный шифронабор по ГОСТ, его выбирал, клиент не мог верифицировать соединение и API оказывался недоступен. В фейсбуке возникла дискуссия, местами переходящая в срач, на 500 комментов в нескольких тредах с филиппиками в адрес ГОСТа. Лёша Саморуков аккуратно суммировал претензии к ситуации, и я обещал ему ответить. В ФБ я ответил, сюда сохраняю на будущее, чтобы не пропало."Когда я скачиваю/конфигурирую клиента tls, я by design, конфигурирую какую либо цепочку доверия. Вот в браузере это ca/bf, например. В клиенте к чешской налоговой - это список CA которым доверяет мвд .cz, и так далее. Обычно у этого множества CA есть некоторый общий регламент и принципы работы. Мы прекрасно понимаем, что добавление даже одного ca с другими политиками приведет к boom, что много раз доказывали авторы антивирусом и прочего стремного софта который добавляет свой рут.
В общем да, но есть нюансы. В части "скачиваю" варианта обычно два: встроенный в клиента набор или встроенный в операционку набор. Вопрос единства критериев - да, правильно.
При добавлении сторонних CA всё немного смешнее. Потому что в хранилище основное ты их часто добавить не можешь в принципе. А из дополнительного хранилища они зачастую обрабатываются немного по-другому. Например, требования CT для явно добавленных в браузерное хранилище проверяться не будут. И это сознательная политика Chrome. То есть тут презумпция разумности пользователя в полный рост.
Соответственно меньше всего я ожидаю от сервера, что он будет выбирать множество ca (заметь, не сам ca, а именно другое множество) исходя из положения звезд на небе и списка шифров, которые умеет клиент. Это - просто бессмысленно и бесполезно, так как в таком решение, на самом деле, плохо все, и технически и административно. И так, собственно, никто и не делает, на всех сервисах, которые работают не от ca/bf всегда свой url и часто отдельная страничка которая и рассказывает о том где и как скачать ca set.
Тут я с утверждениями согласен уже гораздо меньше. Сервер не выбирает CA. Сервер выбирает шифронабор. Если клиент предлагает шифронабор, это значит, что клиент этот шифронабор умеет. Если шифронабор подразумевает сертификаты с конкретными алгоритмами, то клиент должен уметь с этими сертификатами что-то сделать. Например, проверить. Или, например, принимать всегда.
Что касается того, что технически и административно Ру-Центр сделал криво — тут я согласен полностью. Прямо было бы заявить "Ребята, я включаю ГОСТ, корневые сертификаты брать здесь". Отдельную страницу сделать было бы идеально, но вот этого предупреждения было бы достаточно.
Теперь, почему это плохо.
1. Этот автовыбор сломается, как только кто-то еще (неважно кто) заимплементит свой набор ca с gost-ом но другими рутами и политикой. Допускать, что этого никогда не произойдет - стрелять себе в ногу, тем более что n сетов рутов даже в пределах одного государства или даже организации - частое явление. Произойдет при этом именно то, что описано у фила. В итоге, чтобы этого не произошло - гост будут максимально изолировать в песочницы, чтобы ндйбг он не засветился в возможностях клиента )
В смысле - сломается? Пока конфигурирование доверия ГОСТовым сертификатам — процесс полностью ручной, не сломается. При правильном соблюдении процедур. Они не соблюдены, см. выше.
2. Это и административно неумно. Обычно, если мы создаем свой CA - то нас по каким-то причинам не устраивает ca/bf. Таких причин может быть куча, и они часто валидны. Но если сервис одновременно использует на том же ендпоинте ca/bf и нечто совершенно другое - мы просто уменьшаем безопасность, ничего не получая взамен.
Вообще говоря, уменьшаем. В данном случае я склонен полагать, что незначительно.
Причины быть недовольными отечественными шифронаборами у меня есть, и они отнюдь не в том, что злой ФСБ зашил бекдор в параметры. Человек, включающий ГОСТы явно, должен был явно настраивать параметры доверенных УЦ. Человек, включающий ГОСТы неявно (например, скачав браузер Спутник), получит эти УЦ неявно. Если он конфигурирует набор УЦ явно, то у него есть своя процедура добавления надёжности (например, «чтобы сертификат сайта XXX проходил валидацию»). Если неявно — то проблемы у него возможны в том объёме, в котором авторы условного браузера «Спутник» туда положили грабли.
Гост тут и правда ни при чем. Как и любой другой алгоритм. И для любого технаря было бы очевидно, что если мы пришли с клиентом умеющим эллиптику и получили что-то от условной чешской почты, а придя с RSA - получили бы рут от ca/cf - то это косяк и ошибка конфигурации. А с гостом православных связистов начинает клинить, хотя как ты и сам пишешь - он ни при чем. Вот и вся история"
За православных связистов не скажу ничего. Но тут вижу косяк по бизнесу со стороны Ру-Центра, нескомпенсированный техникой со стороны Фила.
Решений для Фила вижу два: отключить ГОСТ при работе с Ру-Центром или добавлять сертификат УЦ КриптоПро в доверенные. Технически оба оправданы одинаково.
