Comments 123
По сути, происходит утечка информации. Когда вы отправляете запрос OCSP, вы буквально спрашиваете у центра сертификации:
Сертификат для pornhub.com валидный?
Так что это не идеальный сценарий. Вы теперь выдаёте историю посещённых сайтов некоей третьей стороне
А что если завернуть все запросы к ocsp серверам, например через Tor?
Как вообще к ним происходит запрос, по http? И откуда брать адреса серверов, ocsp.int-x3.letsencrypt.org и т.д. Для разных центров сертификации они разные?
Сначало вы говорите, что у вас украли сертификат затем его отозвали и тут же у клиента был MitM то проблема в отзыве сертификата? ШТА? Я чего то пропустил?
Сертификаты нужны для защиты от MitM, так?
При этом механизм отзыва не помогает против него. Получается, он не работает.
(не увидел, что уже ответили примерно то же самое)
Если сертификат быстро и надёжно отозвать, то количество обманутых клиентов будет минимально. Не ноль, конечно, но ущерб минимизируется.
Это не отзыв не работает, а у Хрома свой, особый подход к работе с PKI, без соблюдения общепринятых стандартов. Всегда можно написать браузер так, чтобы он работал с косяками. Чем в отношении PKI Гугл успешно и занимается.
Добавил ocsp.int-x3.letsencrypt.org с адресом 127.0.0.1 в файл hosts, Firefox всё равно показал предупреждение об отзыве. Он статус сертификата кэширует, что ли?
Сначала заблокировал OSCP-сервер строчкой в hosts, только потом зашёл на сайт — в Edge открылось без проблем. Затем стёр строчку, и после перезапуска Edge стал ругаться на сайт. Повторный возврат строчки уже ничего не менял, сертификат оставался недействительным.
А ещё Firefox можно настроить так, чтобы при недоступности OCSP сайты не открывались. Раньше для этого была галка в настройках, теперь только через about:config: security.OCSP.require = true.
Напишу чуть подробнее. Если не учитывать MitM-атаки, то наилучшим алгоритмом для установления защищенного от прослушивания соединения будет протокол Диффи — Хеллмана, который дает возможность установить общий для двух сторон сессионный ключ без какой бы то ни было информации друг о друге. Вот просто берем и устанавливаем соединение, защищенное от прослушивания, поверх открытого канала.
Получается, единственная причина, по которой асимметричное шифрование до сих пор используется для защиты трафика — это защита от MitM. Соответственно, и сценарии атак надо всегда брать с учетом MitM.
Так же вас могли взломать, вы предприняли все меры (изучение пути взлома, нахождение изначальной дыры, ресетап ОС, восстановление данных из бэкапа и выкатка кода без уязвимости), но сертификат условно-говоря был выпущен «только вчера и на год», и вы не можете препятствовать злоумышленнику в том, что бы использовать ваш сертификат в течении года для атаки на ваших пользователей. Да, злоумышленнику помимо сертификата еще необходим способ «вклиниться между ваши и вашими пользователями», и если «ваш сервер теперь точно не содержит уязвимостей» то сделать это не так просто, нужно иметь возможность либо контролировать ваш интернет-канал, что маловероятно, ведь вы «хоститесь в именитом ДЦ с безупречной репутацией», либо канал выхода в интернет ваших пользователей, что тоже маловероятно, ведь «пользователей миллионы и они раскиданы по всему миру и использует десятки тысяч разных аплинков».
А теперь небольшой финт: представляем что под «злоумышленник» мы имеем ввиду не скрипткидди Васю, который поломал вас через старый FTP-сервер скачав пачку эксплойтов с античата, а например какую-то «спец. службу», которой ваш датацент не может отказать в маленькой просьбе «проксировать ваш трафик через их сервер», или 99% ваших пользователей живут в очередной банановой республике, а единственный провайдер этой республики так же не может отказать в аналогичной просьбе этой самой «спец. службе».
И даже CAA на данном этапе вас никак не спасет, ибо на данный момент не обязателен, да к тому же и легко обходиться подделкой ответа DNS с DNS downgrade attack (в случае если используется DNSSEC
Я осознал свою ошибку. Перестаньте гадить в карму и рейтинг… -20 за два дня :(
Весь этот PKI фундаментально кривой и продолжает обрастать десятками костылей… Но что-то лучшее мне с трудом видится, разве что блокчейн какой-нибудь
Блокчейн медленный вроде, для подобных дел. Проверка должна проходить за 3-7 ms иначе у толковых сайтов (у которых быстрая стартовая страница) начнутся проблемы.
Т.е. вместо доверия к CA у нас доверие к регистратору, который может оказаться недобросовестным.
Получается, по сути, та же иерархия доверия (. -> .net -> vasya.net) как в случае PKI.
Но во-первых, она с одним-единственным корневым CA — "." (ICANN?).
Во-вторых, она естественным образом сцеплена с самим доменом: чтобы подтвердить валидность сайта на домене, я обращаюсь к тому, кто мне выдал этот домен. Никто больше не может подтвердить. Если замечены какие-то проблемы, очевидно, кто виноват (и что делать).
Downgrade? Где? "." подписан, я это знаю заранее. Если в подписанном ответе от "." сказано, что ".com" имеет DNSSEC (а там сказано и он имеет), но мой ближайший ресолвер упорно утверждает, что записей DS и тому подобных для ".com" нет — я сразу знаю, что больше этим ближайшим ресолвером пользоваться нельзя. И далее, раз ".com" утверждает, что «google.com» имеет DNSSEC (а он имеет), то я либо получу от него ответ с подписью, либо — кто-то чудит in the middle.
Downgrade невозможен, потому, что "." подписан и говорит нам, где подписи должны быть.
Сейчас — валидность сайта на домене «a.b» подтверждают совершенно левые конторы, которые к этим доменным именам вообще никакого отношения не имеют и лишь по какому-то недоразумению есть в моём браузере в списке доверенных. Любой может подтвердить валидность любого домена, и для отвода глаз от этой проблемы даже придумали принципиально неработоспособный изврат под названием «certificate transparency» (это замок от честных людей, а если я плохой парень, я просто ничего в этот список заносить не буду).
Но тут тоже свои проблемы — тот же гугл почему не любит DANE? Потому что они хотят отказаться от ключей в 1024 бита, а они в DNSSEC вовсю используются, получается эдакий откат назад в плане безопасности.
. 10800 IN RRSIG NSEC 8 0 86400 20170722050000 20170709040000 15768. CRmIEhuvHuAJAVQQoL20sq/x4pHxnXDGyWF9hEW/UNwO8z1nTe1W7oVN EorQQ28dbwvZ2W8w2spxujZjMT4bTD3B8car2TfBftgsJb8XSUMGfMcC 26mB5usgIMXHOtXAXBxi4Ib6hX+zalFMnCgrN5t9dUCOhC3F1q+1eHrH tmXNjtx7h+azudjtB04901fcdDjg9gkS2PU1ekKdoJRJC/M2dCsHx5U4 q0YfW6duBbPDByoCrP/hfNsudbycpPum+oE9+mDDzlyudHm8Ph+tGoUR EyRwHFTbkHFXW0IwimNJjkeNz+OiuL1kdpYvbQLHooQcD9j+5oFKZDdP fz4vUg==
Это «2048» (на самом деле, [348 *4/3 -2 ] * 8=2072) бит, насколько я могу посчитать. Или я что-то не понимаю?
Тут вступает в противоречие тот факт, что DNS в основном использует UDP (с fallback на TCP), который при использовании ключей большого размера придется фрагментировать на уровне IP, а многие сети нынче вообще запрещают фрагментированные IP-пакеты.
При MTU 1500 и 2048 ключах эта проблема, вроде бы, не особо проявляется, но MTU много где бывает и поменьше (туннели всякие и т.п.)
Интересные ссылки на тему:
https://blog.verisign.com/security/increasing-the-strength-of-the-zone-signing-key-for-the-root-zone/
http://keysizetest.verisignlabs.com/
В теории все хорошо, но для того чтобы это заработало — нужны списки исключений от подобной проверки, и массовое осознание что неправильно настроенный DNSSEC — это так же серьезно как кривой сертификат.
Потому что сейчас достаточно одного важного сайта с кривыми записями DNS, чтобы отвадить его пользователей от попыток включения DNSSEC. Для меня, например, таким сайтом стал ЛК интернет-провайдера: включив проверку DNSSEC я не смогу заплатить за интернет. И настройки "не проверять DNSSEC в зоне такой-то" — нет...
dnssec-enable yes;
dnssec-validation auto;Прочитал что так можно сделать, написал и внезапно обнаружил, что проблемы поддержки DNSSEC в мире теперь оказались моими проблемами — половина сайтов перестала открываться :-)
Но во-первых, она с одним-единственным корневым CA — "." (ICANN?).
Вы полагаете, такая централизация — хорошая идея? Особенно, в случае ICANN — недавно была статья, как путём нехитрой манипуляции целая страна лишилась контроля над собственным географическим доменом. И, хуже того, когда всё выяснилось, ICANN ни как не исправила свою ошибку.
Уж лучше пусть только ICANN, чем ICANN и кто-то ещё.
Нет у них такой функции. У них есть контроль над небольшой группой доменов. И то даже эту функцию они выполняют из рук вон плохо. И если с СА есть хотя бы механизмы и отзывов и признания целых СА недобросовестными, то и ICANNом и механизмов нет и они уже недобросовестные (отказались исправлять собственную ошибку), то есть если они начнут перевыдавать ваши сертификаты мошенникам, вы с этим ничего не сможете сделать вообще.
Они и сейчас могут, теоретически, отобрать у вас ваш домен, после чего злоумышленник получит на свой новый домен сертификат. И вы с этим точно так же ничего не сможете сделать.
И поэтому что? Пусть отбирают ещё более простым способом? Странная логика. Я думал сообщество заинтересовано в нахождении решения проблемы, а тут предлагается её усугубить. Логическим продолжением будет отказ производителей браузеров поддерживать бесполезный механизм вообще.
Почему вы, сравнивая два абсолютно одинаковых способа, находите второй более простым?
Потому что это единая точка отказа.
Ни одной проблемы таким образом не решается, а уязвимость механизма повышается. Зачем?
Ну а сейчас единых точек отказа — две.
Ну, тут только Namecoin или другие блокчейны помогут, распределённая структура.
Ну, это не совсем так. Даже корневых серверов дюжина, это с одной стороны (да и без них система будет работать, к тому же даже они не принадлежат icann). А с другой — СА тоже довольно много. Что-то может отваливаться, но бОльшая часть будет работать и работоспособность отвалившейся части можно оперативно восстанавливать. С единой точкой отказа это не так.
Ненависть здесь не при чём. Существующая структура не по-настоящему распределённая, но, да, куда меньшее зло, чем централизация всего в одном месте. К тому же, изрядно сомнительном.
Имелись в виду организационные точки отказа. Если все перейдут на DANA — то в ICANN кто-то вдруг может принять решение что ваш домен не домен и все перестанет работать.
Сейчас же может произойти то же самое, плюс разработчики браузеров могут принять решение что ваш корневой CA больше не CA. Таким образом, единых точек отказа сейчас две.
И если с СА есть хотя бы механизмы и отзывов
Которые не работают в Chrome потому что Google наср@ть
и признания целых СА недобросовестными
Ага, только за одни и те-же действия CA могут признать или не признать недобросовестным в зависимости от того американский он или китайский
Уж лучше пусть только ICANN, чем ICANN и кто-то ещё.Не лучше.
Куда бы мы не перенесли зону ответственности — она остается точкой отказа.
От пассивного прослушивания мы защищаться научились хорошо, проблема в активном вмешательстве в трафик, а эта возможность есть у всех провайдеров. Можно записать отпечаток сертификата в какой-то DSN-record, чтобы подтвердить, что сертификат не поддельный, но это не поможет, если атакующий подменит DNS ответ. Он может внедрить https-прокси, поддельный DNS, заблокировать трафик проверки и т.д. и т.п.
Решение этой проблемы, тем не менее, есть — распределенная структура. Возможно, что-то на основе блокчейн — изменения в сертификатах происходят все-таки реже, чем переводы денег через bitcoin.
Сейчас каждый сертификат выдается одним CA. Его компроментация, блокирование на уровне провайдера или просто отказ вызывает проблемы. А вот если сертификат подписан десятком СА или блокчейном, то подменить его или заблокировать проверку отзыва уже не получится.
но это не поможет, если атакующий подменит DNS ответ
Поможет, если этот DNS-ответ подписан DNSSEC. Корневая точка доверия в этом случае — зона ".", открытые ключи которой уже есть в каждой ОС.
Безопасность DANE и конкретно TLSA с указанием сертификата, о которых речь, базируется на DNSSEC.
Почему бы домену не иметь возможность самостоятельно отзыва сертификата, например, через DNS. Как в почте: SPF\DKIM\DMARC. Создали запись _invalidSSL IN TXT «идентификатор (слепок) утекшего сертификата;...» и в совокупности с DNSSEC — все будет хорошо. А как закончился срок действия — запись можно убрать.
DNSSEC не так распространнен, как хотелось бы, а просто DNS концептуально ровно тем же уязвимостям подвержен.
но при TLS SNI вы все равно выдаете всем желающим MansITM имя посещаемого домена.
Не всем желающим, а только тем, через кого пойдет трафик. И это можно «вынужденная мера», без которой сложно обойтись. Сравнивать это с «добровольным оповещением разных CA о посещаемых сайтах» несколько некорректно. Ведь и ip-адреса мы «отдаем всем на пути трафика», но при этом передача «на сторону» этих же ip-адресов (клиента и сервера) не приветствуется всеми параноиками мира (мягко говоря).
Проблема с DNSSEC: он мало распространен и подвержен downgrade attack'ам. А избавление от этих проблем сломает обратную совместимость очень многих вещей. Уж легче браузеры (как основные потребители шифрованного трафика на основе публичных сертификатов) допилить, чем полностью перейти на DNSSEC кмк.
Сложно, но совсем не «вынужденная мера», т.к. реализовать один сайт — один IP в IPv6 (который всё никак не взлетит, в этом и сложность) — проблем нет, тогда и SNI не нужен.
но при TLS SNI вы все равно выдаете всем желающим MansITM имя посещаемого доменаЭто предлагают решить таким образом.
Без DNSSEC я (MitM) могу подделать DNS-ответ и вписать TXT с хешем любого сертификата, который подсуну клиенту через веб. А DNSSEC переносит точку доверия в подпись корневого домена ".". Т.е. у нас как бы принципиально один корневой центр сертификации.
dnscrypt как и стандартизированный DNS-over-TLS шифрует сам трафик, что не заменяет механизма цифровых подписей DNSSEC. И если последний в последнее время стал получать активное распространение, то первые два ещё крайне далеки от этого.
Цена довольно высока — это ваша приватность… Если подумать о сути запроса OCSP, это очень конкретный запрос на единственный сертификат HTTPS. По сути, происходит утечка информации. Когда вы отправляете запрос OCSP, вы буквально спрашиваете у центра сертификации:
Сертификат для pornhub.com валидный?
Так что это не идеальный сценарий. Вы теперь выдаёте историю посещённых сайтов некоей третьей стороне, о которой даже ничего не знаете
Это, простите, паранойя в чистом виде и по важности плетется где-то в самом-самом конце всех проблем с PKI. Потому что «некая третья сторона» сидит в списке доверенных корневых сертификатов и, теоретически, способна на несравнимо большие злоупотребления, нежели узнавание имени части хостов, которые вы посетили.
Потому что «некая третья сторона» сидит в списке доверенных корневых сертификатов и, теоретически, способна на несравнимо большие злоупотребления, нежели узнавание имени части хостов, которые вы посетили.
Оно как бы да, но если «несравнимо большие злоупотребления» можно относительно легко отследить через тот же Certificate Transparency (или в скором времени можно будет отследить), то «отследить сливание данных о посещенных вами сайтах» можно будет только по косвенным признакам и то не 100%… еще и в зависимости от того, кому и для чего эти данные будут сливаться. А если посмотреть на историю человечества, то можно легко убедиться что если кому-то дать возможность чем-то злоупотребить, то эта возможность будет использована для злоупотребления, и вопрос только во времени (когда в руководству этими структурами придут «плохие парни», когда данную структуру получиться взломать, когда эти данные окажутся в паблике из-за технической ошибки и еще миллион возможных вариантов).
Решением может быть «дать людям возможность создавать свои сервера проверки отозванных сертификатов» (как это сейчас с DNS-серверами, когда рекурсивный DNS может поднять каждый и использовать его не боясь что он сливает данные куда-то), но в существующей системе это будет выглядеть как костыль, который с одной стороны сложно внедрить, а с другой мало кто будет использовать. Как мне видится лучшее решение: развитие в сторону OCSP Stapling.
А если посмотреть на историю человечества, то можно легко убедиться что если кому-то дать возможность чем-то злоупотребить, то эта возможность будет использована для злоупотребления
Вы на такси когда-нибудь ездили? А права у таксистов проверяете? А машину шмонаете на предмет наличия оружия, а по базе ГИБДД не проверяете, не в угоне ли, а самого водителя не пробиваете — а вдруг преступник? Думаю, нет. А между тем тут на кону ваша жизнь и здоровье, а не просто какой-то там список посещенных вами сайтов. Вот что за выверт в мозгах у части айтишников происходит при переходе из реальной жизни в инет, что включается подобная степень паранойи? И это несмотря на то, что риски в реальной жизни куда выше.
Ну и стоит помнить, что ваш провайдер к вам куда ближе и знает о вашем трафике куда как побольше, чем любой OCSP.
Вот что за выверт в мозгах у части айтишников происходит при переходе из реальной жизни в инет, что включается подобная степень паранойи?Профессиональная деформация. При этом один вопрос более-менее попадает сферу моей проф. деятельности, а второй в нее не попадает совершенно. Естественно что на первый я имею свою точку зрения, а во второй не лезу предлагая решать его профессионалам в данной области (а сам пытаюсь снизить для себя риск не ловя с руки бомбилу, а обращаясь в спец. фирмы предоставляющие услуги перевозок, которые по идеи проверяют таксистов перед тем, как предоставить их услуге мне, а потом еще и онлайн отслеживают перемещения этих таксистов, то есть контролируют их поведения всеми доступными им (фирмам) способами).
Ну и стоит помнить, что ваш провайдер к вам куда ближе и знает о вашем трафике куда как побольше, чем любой OCSP.Не забывайте что в текущих реалиях вы часто можете выбрать себе провайдера самостоятельно. Причем не обязательно что-бы этот провайдер «присутствовал» в вашем доме, районе или даже стране, гнать весь трафик через тот же vpn не так сложно, а единственный недостаток: слегка возросший пинг и по первости youtube неревелантные вещи в топе показывает.
Деформация — да, профессиональная ли — большой вопрос, потому что настолько искаженная оценка рисков является скорее признаком низкого профессионализма, чем высокого. И уж в любом случае — если человек сам понимает, что это деформация, так её исправлять надо, а не аргументировать ей что-либо.
вы часто можете выбрать себе провайдера самостоятельно
А какая разница, если у вас в любом случае нет никакого контроля за тем, что он будет делать с проходящим через него вашим трафиком? ;)
Вы на такси когда-нибудь ездили? А права у таксистов проверяете? А машину шмонаете на предмет наличия оружия, а по базе ГИБДД не проверяете, не в угоне ли, а самого водителя не пробиваете — а вдруг преступник? Думаю, нет.
Ну, как вам сказать. У нас когда-то были такие Ока-такси — маленькие жёлтые машинки. Я тогда как раз ногу сломал и был вынужден пользоваться такси. Один раз ехал на этой ока-такси. Большего страха я в жизни не испытывал :). И больше на таких не ездил. Так, что мимо. Минимально необходимая проверка есть.
А между тем тут на кону ваша жизнь и здоровье
Видите ли в чём дело. На том же кону жизнь и здоровье водителя этого такси. Что слегка нивелирует проблему.
а не просто какой-то там список посещенных вами сайтов.
А вот тут игра в одни ворота. Причём в современных российских реалиях это куда бОльшая потенциальная угроза и здоровью и жизни, которым не способствуют лагеря в которые можно легко залетесть с нашим непредсказуемым законодательством.
Вот что за выверт в мозгах у части айтишников происходит при переходе из реальной жизни в инет, что включается подобная степень паранойи?
Именно так и ни как не иначе. Дело в том, что эта часть айтишников, судя по всему, несколько умнее другой части и способна использовать голову не только для того, чтобы писать пхп уеб сайты, но и для построения прогностических моделей и предпринятия превентивных действий для снижения потенциального ущерба. Да, модели строятся изрядно пессимистичские, но, как показывает практика, не так уж сильно — реальность госдуры уделывает иногда и самые пессимистичные прогнозы. Ну, а программист обязан думать о худших из возможных сценариях. Тем более, в этой сфере достаточно легко защитится чисто технически, чего не скажешь о такси.
Один раз ехал на этой ока-такси. Большего страха я в жизни не испытывал :). И больше на таких не ездил. Так, что мимо. Минимально необходимая проверка есть.
Отлично. Вы очень наглядно этим примером подтвердили мои слова — в жизни вы действуете по правилу "доверяем по умолчанию" (сели же в это такси, правда?), и только в случае возникновения проблем начинаете не доверять. И о чем спорите? :)
Причём в современных российских реалиях
Какое отношение российские реалии имеют к OCSP?
Дело в том, что эта часть айтишников, судя по всему, несколько умнее другой части и способна использовать голову не только для того
Угу. О завышенной самооценке части айтишников тоже сказано немало и в самых разных местах.
Отлично. Вы очень наглядно этим примером подтвердили мои слова — в жизни вы действуете по правилу "доверяем по умолчанию" (сели же в это такси, правда?), и только в случае возникновения проблем начинаете не доверять
Нет, не так. БОльшая часть айтишников несколько умнее одноклеточных, способных действовать исключительно по единственному раз и навсегда заданному сценарию. Когда нет возможности использовать "план А", переходим к "плану Б". Что не так? Обычный условный оператор. Для кого-то слишком сложно? Ну, извините!
Какое отношение российские реалии имеют к OCSP?
Есть российские CA…
О завышенной самооценке части айтишников тоже сказано немало и в самых разных местах
Это не наши проблемы :)
Неа. Просто повезло. Завтра вы сядете в другой ока-мобиль от другого оператора такси. И погибнете в ДТП по причине низкого качества автомобиля и водителя.
Помогла ваша стратегия? Нет.
Если бы увидев ока-мобиль вы бы не сели, то да. Все было бы правильно.
Недавно случай был. Собирались на дачу. Двумя машинами. В одной сидели двое. Во второй все остальные. Просто бойфренд тёщи взял машину дочки, а там ремней на заднем сидении не было. Хотели кого-то с заднего сидения у нас пересадить ибо четыре человека тесно, но нет ремней и нет, ехали вчетвером (два детских кресла, один подросток и его мать) ибо ремней хватало. Да, в следующий раз в этой же машине уже были ремни. Дяденьке было неудобно что дети (т.е. мы) на него ворчали, и он их таки нашел и прикрутил).
В Украине за ремни не штрафуют от слова совсем. И никто не пристегивается. Но там где нет ремней — мы не ездим. И если кто-то садится в нашу машину, то он должен пристегнуться.
С непристегнутыми не ездим. И все знакомые начинают с ворчания и пристегивания если садятся. Уже знают…
И да, мы не излишне правильные, у нас тоже хватает косяков с безопасностью. Я просто про вот эту вот глупость с «я больше не поеду значит защищен».
Они точно так же подписаны неким доверенным центром сертификации, соответственно, принципиально не отличаются от сертификатов. Если для них использовать менее надёжные алгоритмы — мы скомпрометируем сам сертификат, другими словами, нагрузка на серверы CA от потока запросов на OCSP Staple и на получение нового сертификата (пусть даже со старым приватным ключом) не должна сильно отличаться.
Таким образом, можно было бы ограничить сроки действия самих сертификатов, скажем, неделей — и отказаться вообще от использования OCSP и CRL как таковых, полностью решив проблему, описанную в топике.
ограничить сроки действия самих сертификатов, скажем, неделейУвы, это тоже увеличит нагрузку на серверы CA.
Выпуск сертификата чем-то отличается по сложности от выпуска OCSP ответа?
Для демонстрации проблемы и того, насколько она реальна, попробуйте зайти на новый поддомен, который я открыл на своём сайте, revoked.scotthelme.co.uk. Как вы вероятно догадываетесь, к этому поддомену прикреплён отозванный сертификат, и вполне вероятно, что он нормально загрузится в вашем браузере.
Нет браузера кроме Хрома?
Есть, только у них пользователей меньше.
Кстати, я думал что такая проверка идет из Chromium, поэтому проверил сразу и в Хроме и в Опере (46). Так Опера проверила сертификат и не дала зайти на сайт. А у Хрома вполне себе зеленый замочек как у валидного HTTPS.
И даже Edge не позволил зайти
Error Code: ERROR_INTERNET_SEC_CERT_REVOKED
Не туда ответил
На DNS весь интернет завязан, так что это данность. Главная же проблема с ним на сегодня это то, что весь DNS-трафик передаётся в открытом виде что на общем фоне выглядит как неприемлемый анахронизм. Несмотря на наличие стандарта DNS-over-TLS и наличие его поддержки в основном серверном софте активности во внедрении шифрования DNS-трафика как-то не наблюдается.
Ну и собственно если представить что я тогда хотел бы атаковать кого-то из клиентов того регистратора, то я вполне мог подменить НС жертвы на свои, там заменить А запись на свой сервер где проксировал бы все запросы кроме обращений из AS какого-то CA который каким-то образом (ДНС или файл или еще чего) проверял бы мои права на домен перед выдачей мне сертификата.
В принципе ничто не мешало мне и емайл подменить таким образом, но частенько емайл и так привасипротектед так что идентифиткация по мылу тут мало поможет.
Ну а теперь всем хейтерам отзывов через DNS у меня вопрос. Если сейчас И ТАК тот кто имеет доступ к ДНС может провести МИТМ, то в чем проблема сократить количество потенциальных атакующих до списка тех кто имеет доступ к днс/хуиз? CA не защитят от регистраторов, реестров, иканн и т.п. Но тоже могут атаковать…
Конечно, блокчейн, но и там ведь есть угроза 51%…
Ес-но хостер, на чей IP указывает домен, гипотетически может; и любой, кто получит доступ к NS домена.
А вот если вы найдете дыру в сайте и сможете загружать файлы, то можно разместить подтверждение (в ручном режиме тоже есть возможность получить сертификат LetsEncrypt) в /.well-known/acme-challenge и получить сертификат. Но зачем так делать для «сайта мелкого пошиба»…
Однажды разрабатывал механизм для проверки отозванных сертификатов в одном коробочном продукте для управления Active Directory. Помимо проблем с доступностью и обновлением списков CRL, винда по умолчанию ещё и кэширует эти списки, как на уровне машины, так и на уровне .NET процесса. В самом худшем случае, может пройти неделя прежде чем пользователь узнает об отзыве сертификата.
Даже не знал, что ssl сертификат помогает продвижению сайта в гугле. но набрел на интересный пост, правда на английском Увеличение Ранка в результатах поиска. Многие вещи в безопасности сайта мы вообще не знаем и не понимаем пока случайно о них не прочтем.
Есть незначительный плюс за счет поведенческого ибо сейчас давление на хттп-сайты с зачеркнутыми замочками и т.п. Соответственно ПФ при переходе улучшается. Итого — миф о позициях + упоминание платного сертификата в контексте где уместен бесплатный. Смущает, да.
В таком случае «злоумышленнику» придется скомпрометировать всю мою подсеть и какое-то одно рандомное устройство из нескольких миллиардов.
Опять-же что касается скорости: скорость каналов связи растет, количество каналов тоже. Объективно сейчас нет проблем со скоростью доставки информации. Скорее теперь уже компьютеры «на местах» не успевают обрабатывать полученное т.к. не все ежегодно апгрейдятся.
Медленно в блокчейне не запрос, а добавление/обновление записей. Запросы делаются фактически локально, обновление/добавление — требует сетевого консенсуса, который набирается путём выстраивания цепочки блоков. Новый блок в среднем добавляется раз в десять минут, считается, что для уверенности нужно набрать шесть блоков; таким образом, минимальное время обновления/добавления (лаг) — час. Для HA-сервисов средствами DNS точно не подходит.
Кроме того, объём блока ограничен, кажется, 1 мб. Если средний размер транзакции 500 байт (для неймкоин), это значит, что за десять минут вся сеть может сделать максимум 2000 изменений. Представьте себе, что весь DNS в мире обновляется со скоростью 3 изменения в секунду. Медленно.
Есть у неймкойн средства несколько облегчить проблему, но суть не меняется. А именно, можно грубо говоря там только делегировать домен на традиционный DNS-сервер с DNSSEC, и все быстрые динамические изменения производить уже на нём. Таким образом, якоря доверия будут находиться в блокчейне, а далее — одно-два звена по цепочке DNSSEC.
Как объяснял «на пальцах» один уважаемый (мною) человек суть сертификатов: «В какой-то момент ушлые парни решили, что надо сделать бизнес на том, что поручаться за надежность того или иного ресурса и брать с хозяина ресурса плату». А кто сказал, что этим поручителям изначально можно верить? Историю с WoSIgn все помнят?
При чем тут шесть подтверждений?
Вы путаете блокчейн с конкретной реализацией (биткоин?).
Закладывайте ту частоту которая вам реально нужна. Используйте не подтверждение работой а другой алгоритм. Указывайте тот размер блока какой вам нужен. Это совсем не ограничение блокчейна а лишь конкретной реализации.
Далее — ожидание дести подтверждений тут вообще не в тему. Зачем нужны подтверждения? Чтобы избежать двойной траты. Если же мы говорим о транзакциях «сертификат недействителен» или «новый NS домена такой-то» или даже напрямую новое значение А-записи такое-то, то зачем нам ждать? Транзакция подписана? Подписана. Авторизованным отправителем? Авторизованным (владельцем домена, администратором CA, не суть). Всё. Опасности что он выпустит другую конкурирующую информацию тут нет, ибо в деньгах у нас двойная запись — ушло из одного места, пришло в другое. Вот это ушло работает только когда там что-то есть, поэтому мы боимся двойных трат. А тут запись одинарная, ничего нигде не уходит, так что одного подтверждения более чем достаточно. Более чем. А реально хватит и нуля.
Подтверждения нужны для передачи владения (например смены подписи владельца) и других операциях где потенциальная отмена операции в связи с непопаданием в блок или форком — может вызвать проблемы.
А операции отзыва сертификата можно брать сразу из ожидающих транзакций, что в зависимости от вашей связности может занять от секунд, до времени ожидания подтверждения (Которое можно сделать допустим в минуту).
Изменение ДНС/IP — тут уже от доверия зависит. Если протокол шифрованный, имеет доверенный сертификат (из того же блокчейн), то нет проблем и сырое брать. Если не шифрованный, то можно слегка сомневаться, но тоже сомнения очень иллюзорны.
Вы путаете блокчейн с конкретной реализацией (биткоин?).
Я же прямо написал, что указанное касается именно namecoin. От биткойна считай отличается только тем, как ведёт себя с «намайненными» средствами и требованием уникальности.
Давайте и вы напишете, какую вы конкретно реализацию имеете ввиду, в которой нет всех этих особенностей.
Я лишь озвучил что все названные вами ограничения являются не ограничением блокчейна, а именно конкретной реализации.
Существуют например блокчейны с декларативным доверием где не просто другой тип подтверждения отличный от PoW а просто нет подтверждения. Я говорю о блокчейнах внутри одной компании и ее партнеров. Например блокчейны для контроля целостности распределенной базы банковских филиалов.
В нашем случае ноды могут быть подконтрольны ИКАН и им не нужно будет конкурировать за право подписи. Что заметно уменьшит нагрузку. Но даже если система полностью децентрализованна — все константы типа размера блока, частоты его выпуска и т.п. — просто константы, а не ограничения протокола. Ничто не мешает сделать форк неймкоина с блоков в 10мб.
https://crt.sh/?q=revoked.scotthelme.co.uk
Я лишь озвучил что все названные вами ограничения являются не ограничением блокчейна, а именно конкретной реализации.
Существуют например блокчейны с декларативным доверием где не просто другой тип подтверждения отличный от PoW а просто нет подтверждения. Я говорю о блокчейнах внутри одной компании и ее партнеров. Например блокчейны для контроля целостности распределенной базы банковских филиалов.
В нашем случае ноды могут быть подконтрольны ИКАН и им не нужно будет конкурировать за право подписи. Что заметно уменьшит нагрузку. Но даже если система полностью децентрализованна — все константы типа размера блока, частоты его выпуска и т.п. — просто константы, а не ограничения протокола. Ничто не мешает сделать форк неймкоина с блоков в 10мб.
Скажите, я правильно понимаю что протокол Certificate Transparency позволяет любому скачать полный лог всех сертификатов, без всяких специальных доступов и т.п.?
Who is going to be running the logs?faq
Google is currently running a Certificate Transparency log. We welcome others who want to run logs. But keep in mind, anyone can run a log, since the log does not have to be trusted — the verification protocols make sure of that.
Who is going to be running the monitors?
We believe most CAs will want to do some monitoring, mainly to track their own certificates, but also to track other CAs’ certificates and watch for missteps. However, anyone can create a monitor and provide subscription monitoring services. Google will likely offer a monitoring service at some point.
То есть, судя по FAQ, любой (в том числе и вы) можете поднять свой «лог-сервер» и следить за всеми сертификатами, которые добавлены в этот лог. А если не хотите морочится, то можете воспользоваться любым сервисом, которому лично вы доверяете… когда они появятся.
а еще конкретнее — список доменов у которых есть/был SSL.
А еще конкретнее — список доменов… у многих зон список доменов — закрытая информация, которая недоступна даже регистраторам. Такой большой список доменов (при все возрастающем покрытии доменов HTTPS) значительно улучшит любую базу доменов.
Я сторонник того чтобы списки доменов были публичные (или условно доступные как у доткома, где на публику не выкладывают но у всех кому надо они есть). Так что прям потенциальной уязвимостью я бы не назвал, а вот полезной инфой…
15 минут гуглежа внятного ответа не дали, только общие фразы.
Мне много не надо. Для начала и пары бит ответа хватит. Типа:
1) Да, можно скачать лог любому человеку. В логе читабельный формат или бинарный но имена доменов не шифрованы.
2) Нет, скачать можно, но криптографически сделано так что нужно знать домен чтобы найти соответствие ему (например везде мд5 от домена идет)
3) Нет, скачать нельзя. Только запросы.
4) Нет, скачать можно, но не всем а только избранным.
Ну как-то так.
(нашел через https://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/ "EDIT September 27, 2014: Actually, that is not true. Auditors are not shown the most recent cert for any arbitrary domain. Verifying that no fraudulent certificates have been issued by a rogue CA is the responsibility of Monitors, who continuously poll logs and download their contents." и https://isc.sans.edu/forums/diary/The+Dark+Side+of+Certificate+Transparency/21329/)
Предлагали такое — https://www.ietf.org/proceedings/90/slides/slides-90-trans-2.pdf#page=8 — Private Domain Labels — некоторые пользователи, получившие сертификат желают скрыть часть доменного имени из лога — https://tools.ietf.org/id/draft-strad-trans-redaction-01.html "Domain Label Redaction"
По https://www.ietf.org/rfc/rfc6962.txt клиенты проверяют подпись записи в логе "TLS clients are not directly clients of the log, but they receive SCTs alongside or in server certificates.… they should validate the SCT by ..verifying the signature, using the corresponding log's public key." а мониторы скачивают сегменты лога "Monitors watch logs… It may also want to keep copies of entire logs.… 3. Fetch all the entries in the tree corresponding to the STH (Section 4.6).… 4.6. GET https:///ct/v1/get-entries… start: 0-based index of first entry to retrieve… end: 0-based index of last entry to retrieve, in decimal."
https://security.stackexchange.com/questions/167366/how-can-i-access-the-certificate-transparency-logs
Т.е. как я понял ответ 1 — скачивается (плюс думают о некотором редактировании части доменного имени).
Парсер https://github.com/agl/certificatetransparency/blob/a306835b12ca1a49506e96b6706431dc7f296af9/db.go#L255 — вроде внутри должны быть сертификаты или пресертификаты, содержащие доменное имя (пару логов проверил — имена есть)
Некоторые мониторы (google — transparencyreport, comodo — crt.sh) могут предоставлять поиск доменов по своей базе, например, у гугла в мониторе 1 млрд записей (суммарно — где-то порядка 5-10 ТБ логов)
https://transparencyreport.google.com/https/certificates "As of Feb 6, 2018, there have been 1,055,263,459 entries made to the set of Certificate Transparency logs that Google monitors." (у них удобно найти индекс в логе, они умеют искать поддомены)
Пример — https://transparencyreport.google.com/https/certificates/oem3lryE3lanDDDtAvbK%2B3C8w1O8GJBmz7AFdHxdX3M%3D rocketeer 184646004
запись в логе ct.googleapis.… .com/rocketeer/ct/v1/get-entries?start=184646004&end=184646004 — leaf_input — base64 decode — u.tmtm.ru
С появлением Let's Encrypt всё больше хостеров включает SSL сертификат от них как бесплатную услугу, даже в простейших пакетах, типа сайта-визитки, идущего в комплект к покупке домена.
И некоторые, как оказалось, заказывают и получают эти сертификаты самостоятельно, без участия клиента.
Сейчас проверил парочку своих доменов, которые регистрировал через OVH, на вышеупомянутых сайтах по проверке Certificate Transparency — упс, сюрприз… Где-то с мая 2016 и по н.в. для них выпускаются сертификаты от Let's Encrypt. Причём заказывал их явно не я. Да там и по http ничего не отдаётся-то, кроме дефолтной заглушки.
Я уже привык что везде как у HostingManager — после регистрации, апрува хостинга, нужно не забыть написать тикет «включите мне Летсенкрипт», а то потом надо будет полчаса ждать пока включат.
А после того как поставишь сертификат еще нужно просить DH пропатчить, а то по умолчанию B по ссслабу у многих хостеров. Вчера я аж удивился, что у ua-hosting.company не надо было просить настройки править — тикет на включение летсенкрипта да, а вот ссллаб сразу А+ дал. Непривычно).
Отзыв сертификатов не работает