Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

145 Страницы«<1415161718>»
Опции
К последнему сообщению К первому непрочитанному
Offline basid  
#151 Оставлено : 6 августа 2018 г. 20:58:24(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,037

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 140 раз в 126 постах
Автор: Дмитрий Пичулин Перейти к цитате
Использование поля common name сертификата для сопоставления с именем сайта отмечено deprecated в 2000 году: https://tools.ietf.org/html/rfc2818#section-3.1
Это всё, конечно, здорово, но статус RFC2818 - информационный.
Превращать рекомендацию в навязанное требование - не есть хорошо.

P.S.
Лично я организовал MiTM на своём компьютере просто для того, чтобы антивирус мог проверять всю ту фигню, которая пропихиватся сайтами.
Offline Дмитрий Пичулин  
#152 Оставлено : 6 августа 2018 г. 22:46:36(UTC)
pd

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 1,442
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 31 раз
Поблагодарили: 412 раз в 306 постах
Автор: basid Перейти к цитате
Это всё, конечно, здорово, но статус RFC2818 - информационный.
Превращать рекомендацию в навязанное требование - не есть хорошо.

P.S.
Лично я организовал MiTM на своём компьютере просто для того, чтобы антивирус мог проверять всю ту фигню, которая пропихиватся сайтами.

Разработчики браузеров навязывают безопасность, это плохо?

Все заинтересованные лица были предупреждены об этом поведении минимум за год. Плюс навязывание обоснованно, ссылки по дискуссии приведены выше, вот например комментарий 28: https://bugs.chromium.or...id=700595&desc=2#c28

Ждём когда антивирусы научатся делать MiTM на ГОСТ ;)
Знания в базе знаний, поддержка в техподдержке
Offline basid  
#153 Оставлено : 7 августа 2018 г. 0:01:46(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,037

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 140 раз в 126 постах
Автор: Дмитрий Пичулин Перейти к цитате
Разработчики браузеров навязывают безопасность, это плохо?
В данном конкретном случае навязывается отнюдь не безопасность.
CN - одна-единственная запись одного типа.
SAN - может быть и много записей и разных типов.
"Внимание вопрос!" - задлянафига мне SAN если у меня единственный сервис для каждого хоста?
Тем более, что в RFC2818 внятно прописано - "нет SAN, смотрим CN". Там ни разу нет "... и ругаемся, если не нашли SAN".
Это во-первых.

Во-вторых, "deprecation" из информационного RFC - частное мнение какого-то сотрудника "ЧАВО Инк."

В-третьих - пример с Netflix-ом, опять-таки, мимо кассы, поскольку среда, в которой они развёртывают TLS, требует SAN.

Ну и в качестве десерта.
Насколько я понимаю, площадные бомбардировки РКН были вызваны тем, что Telegram эксплуатировал багу на стороне CDN.
Если бы те, кто "типа заботятся" о клиентах больше думали о брёвнах в собственных глазах - мир был бы лучше.

P.S.
Истерия вокруг TLS нужна, в основном, для защиты пищевого ресурса корпорации добра.
Всё остальное - полностью вторично.
Offline Sergey A.  
#154 Оставлено : 7 августа 2018 г. 5:25:42(UTC)
Sergey A.

Статус: Новичок

Группы: Участники
Зарегистрирован: 07.08.2018(UTC)
Сообщений: 8
Российская Федерация
Откуда: г. Биробиджан

Сказал(а) «Спасибо»: 4 раз
Здравствуйте. Благодарю за продукт.


Захожу на сайт налоговой, в личный кабинет ИП - выбираю ЭЦП, работаю. Всё что мне нужно - работает. Завершаю работу. Вроде бы всё хорошо, НО..

Теперь мне нужно зайти под другим ИП - то есть выбрать другую ЭЦП, но "выход" из ЛК и закрытие вкладки - не помогает. При открытии новой вкладки ЛК "вспоминает" ранее выбранную ЭЦП и не предлагает выбрать другую. Что удобно, но в прочем не всегда - я ведь не восстановил закрытую вкладку, а именно открыл новую!

Вопрос к тем, кто знает - как заставить Хром-гост запрашивать ЭЦП снова?

У меня десяток ЭЦП (ИП), и когда по всем по ним, нужно что-нибудь быстро проверить, приходится использовать IE =(


Offline two_oceans  
#155 Оставлено : 7 августа 2018 г. 7:06:43(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Цитата:
Всё остальное - полностью вторично.
Я вот тоже совершенно не понимаю, как использование CN снижает безопасность, доверие не может быть наполовину: если УЦ доверенный, то должен проверять, чего он пишет в CN сертификатов и тогда ему доверяем целиком. А если он не проверяет, то просто выкинуть такой УЦ из доверенных и сказке конец. Разработчики браузеров уже немного "достали" своими странными понятиями о безопасности (надеюсь, не принимите на свой счет), которые не плохи сами по себе, но заходят слишком далеко. Я даже не говорю про плагины, подход к которым кардинально меняется каждые 15-20 версий браузера.

Вспомним историю. Сначала они вводили защиту от cross-site-scripting после эпидемии в социальных сетях (лично мне абсолютно все равно на социальные сети США), но почему-то ввели так, что и из локальной сети тоже нельзя скрипты подгрузить. Замечательно, у нас в локалке парочка социальных сетей и самые злобные хакеры сидят, ага. А уж на локалхост вообще зверюги - палец в рот не клади. Потом еще изображения до кучи заблокировали. Объяснили дескать, чтобы нельзя было чего нибудь удалить на сайте локальной сети при открытии сайта интернет. Вот только отправку POST запросов в локальную сеть не заблокировали и если бы кто-то хотел что-то удалить - никаких проблем, зато серьезно нарушили синхронизацию зеркала моего сайта в локальной сети с моим же сайтом в интернете. Пришлось сопоставлять в hosts IP локальной сети на DNS поддомена того же домена, что сайт в интернете.

Сейчас разработчики браузеров втюхивают TLS везде - ну серьезно, какой вред от того, что кто-то узнает в каком городе я смотрел прогноз погоды или какую новость прочитал. В тоже время на большинстве сайтов зарубежное 128-битное шифрование. Серьезно, оно от любого суперкомпьютера не защитит. В продолжение сумасшествия сейчас еще и на всех сайтах внутри локальной сети выводится предупреждение об незащищенных данных. Да, в локальной сети так и продолжают сидеть злостные хакеры по их понятиям. На 127.0.0.1 - окончание криптотуннеля, но браузер об этом не знает и выводит предупреждение! Как ни посмотри - разработчики браузеров зашли слишком далеко, считая пользователей несмышленными птенчиками.

Сейчас новая волна с обязательностью SAN - для теста выпустил на внутреннем УЦ сертификат с 8 записями SAN для сайта локальной сети (четыре DNS адреса, три внутренних IP, один внешний IP), добавил УЦ в браузеры и половина новейших браузеров не может переварить сертификат с SAN: "имя в сертификате не соответствует имени сайта". Кому от такой "безопасности" стало лучше? Согласен, самое безопасное вообще от интернета отключиться, но тогда и браузеры не нужны.

Хорошо, не берете на себя ответственность - достаточно списка сайтов-исключений, чтобы пользователь смог взять ответственность на себя.
Цитата:
Ждём когда антивирусы научатся делать MiTM на ГОСТ ;)
По этому поводу я переписывался с лабораторией Касперского, они пояснили, что дело не в ГОСТ. Перехват соединений на государственные сайты все равно работать не будет, так как они запрашивают аутентификацию по сертификату. Получается (это уже мой вывод) антивирус должен сертификат для предъявления сайту запросить у пользователя, но производители антивирусов не берут на себя ответственность за использование сертификата и связанного с ним закрытого ключа и потому принципиально не делают MiTM на сайтах, которые запрашивают аутентификацию по сертификату. Среди сайтов с ГОСТ как раз большинство сайтов с аутентификацией по сертификату.

Отредактировано пользователем 7 августа 2018 г. 7:34:53(UTC)  | Причина: Не указана

Offline Дмитрий Пичулин  
#156 Оставлено : 7 августа 2018 г. 9:36:45(UTC)
pd

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 1,442
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 31 раз
Поблагодарили: 412 раз в 306 постах
Краткое изложение дискуссии по отказу от сопоставления с полем common name при проверке сертификата сайта.

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

Со стороны разработчиков же всё наоборот. Они не понимают как в мире безопасности и строгих проверок может существовать MAY и каскад нестрогих условий его применения (RFC 5280 и 6125).

Суть претензий разработчиков касается исключительно функционала сопоставления common name, в какой-то момент количество условий для реализации данного функционала начало превышать критическую массу.

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

Исторически common name никогда не являлся носителем смысла имени хоста, этот смысл был «навязан» Netscape или вообще внесён по ошибке, но реалии не позволяли от него избавиться по причинам обратной совместимости с существующими де-факто многочисленными клиентами. Поэтому приходилось протаскивать наряду со строгими проверками, вереницу проверок common name.

Именно от сложности кода, который вносит функционал сопоставления common name, и было решено отказаться, устранив причину, то есть, убрав этот код, тем самым отказавшись полностью от сопоставления с common name.

Желающим ещё подискутировать на данную тему предлагается обосновать присутствие проблемного функционала, а именно доказать, что необходимость сопоставления common name и наличие проблемного кода перевешивают необходимость использования только стандартизированных полей для сопоставления и отсутствие проблемного кода.

Отредактировано пользователем 7 августа 2018 г. 10:12:24(UTC)  | Причина: Не указана

Знания в базе знаний, поддержка в техподдержке
Offline Дмитрий Пичулин  
#157 Оставлено : 7 августа 2018 г. 9:45:44(UTC)
pd

Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 1,442
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 31 раз
Поблагодарили: 412 раз в 306 постах
Автор: Sergey A. Перейти к цитате
Вопрос к тем, кто знает - как заставить Хром-гост запрашивать ЭЦП снова?

У меня десяток ЭЦП (ИП), и когда по всем по ним, нужно что-нибудь быстро проверить, приходится использовать IE =(

Суть в том, что браузер кэширует выбор сертификата для текущего пользователя.

Поэтому в браузере необходимо либо завести несколько пользователей, либо открывать режим инкогнито.
Знания в базе знаний, поддержка в техподдержке
thanks 1 пользователь поблагодарил pd за этот пост.
Sergey A. оставлено 07.08.2018(UTC)
Offline basid  
#158 Оставлено : 7 августа 2018 г. 13:31:44(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,037

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 140 раз в 126 постах
Автор: Дмитрий Пичулин Перейти к цитате
Со стороны разработчиков же всё наоборот.
Они не понимают как в мире безопасности и строгих проверок может существовать MAY и каскад нестрогих условий его применения (RFC 5280 и 6125).
А я не понимаю почему разработчики высасывают проблему из пальца.
"MAY" из RFC означает "имеет право". И пока стандарт PKI-инфраструктуры не примет запрет на использование CN - я вправе воспользоваться своим правом.

А во-вторых, лично мне вообще плохо понятна суть претензий ...
Есть SAN - сопоставляем хост (только) с записями этого типа.
Нет SAN - сопоставляем хост с CN.
В каком месте возникают какие-то неоднозначности и нестрогие условия???

Может ли конкретный сайт обойтись CN или обязан использовать SAN?
А клиент тут причём? Есть конкретный запрос и валидация конкретного поля запроса по записям сертификата.
Алгоритм и, главное, результат валидации не зависит от наличия или отсутствия SAN.

P.S.
При всём уважении к Eric Rescorla, но RFC2818 не удалось преодолеть статуса черновика стандарта и опубликован он как информация.
Т.е. квалицированный человек пояснил некоторые аспекты работы с HTTP поверх TLS.
И даже это информация превратно истолкована по короткому и совершенно немотивированному предложению.

Отредактировано пользователем 7 августа 2018 г. 13:32:33(UTC)  | Причина: Не указана

Offline two_oceans  
#159 Оставлено : 8 августа 2018 г. 11:22:56(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Если действительно доверяем УЦ, то непонятно зачем потом сертификат под микроскопом разглядывать и создавать себе лишнюю работу. УЦ уже проверил сервер и не выявил несоответствий. Наличие ключа соответствующего сертификату необходимо для установления успешного соединения. Подпись сертификата сервера проверена по сертификату УЦ. То есть проверив цепочку сертификатов мы знаем, что владелец сервера правомерно получил сертификат в доверенном УЦ и имеет ключ, соответствующий сертификату. Чего еще надо? Чтобы влезть в середину и не спалиться на самой цепочке сертификатов мошенники должны либо подкупить доверенный УЦ либо добавить свой УЦ в доверенные либо украсть закрытый ключ сервера либо украсть закрытый ключ доверенного УЦ. Антивирусы с MiTM на этом и палятся.

Но тем не менее браузеры все равно сомневаются в каждом конкретном сертификате и после проверки цепочки, а вдруг назвались кем-то другим. Да пусть сервер мошенников хоть горшком назовется, если у нас DNS/hosts на него не указывает, то "кина не будет". Если соединение есть, то DNS нам уже указал на конкретный IP. И если мошенники украдут ключи или пропишут свой УЦ доверенным, то уж подделать ответ DNS или вирусом прописать адрес в hosts им труда не составит. Поэтому проверки CN и SAN браузером фундаментально просто подстраховка "на всякий случай", нет существенного смысла писать длинные и детальные проверки имени сервера. Проверка политик УЦ и назначения сертификата гораздо важнее чем соответствие имени. Проверки цепочки доверия, подписей сертификатов в цепочке, проверка отзыва сертификатов - это максимум чего браузер может реально проверить и гарантировать. Все остальное - куча условностей и реклама "вот мы такие супер-безопасные, у нас 100500 проверок".

Приведите, пожалуйста, пример ситуации в котором браузер действительно отклонил сертификат мошенников, прошедший проверку цепочки сертификатов? Ошибки конфигурации (когда зашли на сервер по адресу не включенному в CN/SAN) не считаем. Совсем наглые MiTM, палящиеся на проверке цепочки сертификатов тоже. За примерами, в которых браузеры отклонили правомерный сертификат сервера, ходить далеко не надо - сами видите сколько возражений пользователей. Для интереса можно бы составить матрицу и посчитать коэффициент корреляции. Логически приходим к выводу, что можно выкинуть не только "проблемный" код, проверяющий CN, но "безупречный" код, проверяющий SAN. Так будет еще проще для разработчиков браузеров - просто всегда ОК.

Ну хорошо если с проверками CN и SAN "безопаснее" - пусть будут. Мне что-то тоже не понятно про какие именно нестрогие проверки CN идет речь, тем более об их большом объеме. На самом деле, если смотреть в код почти любой программы, то 40% кода тупые базовые функции, написанные в самых первых версиях (не учитывающие нюансы, но охватывающие 80-85% случаев), а 60% кода это уточнения даталей, добавленные в следующих 100500 версиях (для 15-20% экзотических случаев). Если так важно упрощение, то можно выкинуть неиспользуемые большинством детали. Согласитесь, мало серверов реально использует все формы записи IP, маски IP и т.д. Проверки десятичного IP, обработки звездочки в имени сервера и строго соответствия имени сервера достаточно для проверки большинства сертификатов серверов.

Я бы выстроил алгоритм так:

Какие-то интересные требования по обоснованию, с точки зрения разработчиков, будто они одни в мире. Пользователей и владельцев серверов намного больше - меньшинство диктует большинству?
1) Перевыпуск сертификата требует материальных затрат со стороны владельцев серверов. Из-за повального распространения хостингов, сертификат заменить порой не так уж и просто. Поэтому перевыпуск сертификатов серверов идет со скрипом и года явно недостаточно. Легко представить, что причиной отключения CN были не сложности проверки и заботы о безопасности, а просто проплата со стороны группы УЦ в Гугл и ключевым разработчикам мозиллы.
2) Что касается отечественных УЦ, то они все еще ссылаются на неведомые требования, которые им не дают выпустить с SAN. Пересмотрел указ ФСБ и не нашел там запрета указания лишних полей в SAN. Однако пока "свыше" не придет разъяснение УЦ не станут чего либо выпускать по-другому, ведь это требует изменения регламента УЦ и либо переаккредитации либо потенциального риска что УЦ просто прикроют. Бог с остальным миром, но наверно надо учитывать российские реалии при выпуске браузера с ГОСТ.
3) Как бы не были хороши "стандартизированные поля" SAN, браузеры их все еще не могут полноценно обработать при наличии большого количества таких полей в сертификате. Предлагаю эксперимент - создать сертификат с 8-10 SAN и попробовать зайти на сайт по каждому из указанных в SAN адресов/айпи. В моем случае такой сертификат от внутреннего УЦ с использованием адресов локальной сети и доменов .LOCAL - такие элементы SAN недопустимы для общепризнанных доверенных УЦ и потому сертификат наверно не годится для чистого эксперимента. Мозилла 60 не смогла признать все адреса, ХромиумГост еще не тестировал по всему списку.

Отредактировано пользователем 8 августа 2018 г. 12:21:54(UTC)  | Причина: уточнение

Offline basid  
#160 Оставлено : 8 августа 2018 г. 13:14:13(UTC)
basid

Статус: Активный участник

Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,037

Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 140 раз в 126 постах
Автор: two_oceans Перейти к цитате
Если действительно доверяем УЦ, то непонятно зачем потом сертификат под микроскопом разглядывать и создавать себе лишнюю работу.
Вас немного не туда заносит.

RFC2818 - про соответствие полей сертификата сервера и полей HTTP-запроса.
"Наглое поведение разработчиков хрома" - некорректная интерпретация этого сАмого RFC этими самыми разработчиками.

Делать "корректный MiTM" RFC2818 не мешает - у меня включена проверка шифрованного трафика антивирусом, поэтому я "несколько в теме" Angel
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest (4)
145 Страницы«<1415161718>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.