В целом, все неплохо, есть несколько необычных функций, хотя сам телефон революционным сложно назвать. Его недостатки — отсутствие порта для наушников, проблемы с камерой, плюс нет защиты от воды.
Скачать в txt формате пожатые зипом, разложенные по зонам, списки доменов, а не их сертификатов и все такое — сильно сомневаюсь. Либо сами парсите логи, общественно доступные логи, либо покупаете у тех, кто это для вас уже сделал.
Скажите, я правильно понимаю что протокол Certificate Transparency позволяет любому скачать полный лог всех сертификатов, без всяких специальных доступов и т.п.?
Who is going to be running the logs?
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
То есть, судя по FAQ, любой (в том числе и вы) можете поднять свой «лог-сервер» и следить за всеми сертификатами, которые добавлены в этот лог. А если не хотите морочится, то можете воспользоваться любым сервисом, которому лично вы доверяете… когда они появятся.
В этом случае у клиента должны быть PI адреса, BGP-сессии с обоими аплинками и никаких проблем в фильтрации тут нет.
Если же клиент использует PA адреса одного провайдера, но трафик пускает через другого провайдера, то второй провайдер может спокойно блокировать этот трафик и на любой вопрос в саппорт ответит «это не ваши адреса, мы выделили вам другие, используйте их» и будет на 100% прав.
нужен не UPnP, а UDP. HTTP работает по TCP и прежде чем запросить какой-то более-менее большой «кусок данных» нужно установить соединение в понятии tcp(handshake или рукопожатие). В этом случае клиент (тот, кто начинает соединение) отправляет серверу syn (запрос на установку соединения), сервер отвечает syn+ack (подтверждение в получении первого syn), после этого клиент отвечает ack (подтверждение получения от сервера syn+ack) и только после этого клиент может запросить у сервера «большой объем полезной нагрузки» (например страницу сайта по http).
syn и ack — имеют свои порядковые номера, но начинаются не с единицы (или нуля), а генерируются рандомно.
Атакующие подделывают ip-адрес отправителя(вместо своего реального IP-адреса они в качестве «адреса отправителя» указывают адрес сервера, который ддосят в данный момент), поэтому если атакующий будет использовать tcp, то первый ответ от сервера, который syn+ack уйдет сразу «жертве ддоса», жертва ответит на него rst (reset, сброс соединения), сервер увидев вместо ack-пакета rst пакет пойдем что «что-то пошло не так» и не будет пытаться что-то отправлять в сторону «жертвы».
То есть вроде как произойдет примерно тоже самое, но не получиться такого сильного «усиления атаки», на один пакет злоумышленника «syn» промежуточный сервер сформирует один пакет «syn+ack» примерно равный по размеру изначальному syn-пакету.
В UDP же нет понятия «установки соединения», и поэтому одним маленьким пакетом (без установки соединения syn — sync+ack — ack, просто первым пакетом сразу отправляется запрос какой-то информации) можно получить относительно большой ответ. И за счет этого получается «усиление», когда злоумышленник тратит 5Гб\с на запросы (так же указывая в качестве адреса отправителя не свой реальный IP, а IP жертвы), а промежуточные сервера (сторонних людей, которые подвержены этой атаке) формируют ответов на 100Гб\с, и все ответы уходят жертве.
Вообще стоит разобраться (хотя бы в общих чертах) в механизмах работы tcp и udp и все сразу станет очевидно. Проблема не только в UPnP, раньше для того же самого широко использовались DNS и NTP протоколы, (которые тоже работают через UDP), но это стало неэффективным потому что большинство администраторов столкнулись с тем что «DNS сервер внезапно стал генерировать большой трафик в интернет», разобрались с тем, что происходит и закрыли DNS и NTP сервера фаерволами. Те, кто разумнее — заодно прикрыли и остальные сервисы работающие по UDP, поэтому видим что злоумышленники переключились на «домашних пользователей» в качестве «промежуточных серверов усиления». Со временем UPnP тоже позакрывают(зами пользователи или администраторы провайдеров) и атакующие будут искать другие способы усиление трафика (другие протоколы, или вернуться к комбинации DNS+NTP+UPnP+что-там еще есть, рассчитывая на то, что появились новые сервера с этими сервисами, которые забыли закрыть фаерволом или обновить).
Вот что за выверт в мозгах у части айтишников происходит при переходе из реальной жизни в инет, что включается подобная степень паранойи?
Профессиональная деформация. При этом один вопрос более-менее попадает сферу моей проф. деятельности, а второй в нее не попадает совершенно. Естественно что на первый я имею свою точку зрения, а во второй не лезу предлагая решать его профессионалам в данной области (а сам пытаюсь снизить для себя риск не ловя с руки бомбилу, а обращаясь в спец. фирмы предоставляющие услуги перевозок, которые по идеи проверяют таксистов перед тем, как предоставить их услуге мне, а потом еще и онлайн отслеживают перемещения этих таксистов, то есть контролируют их поведения всеми доступными им (фирмам) способами).
Ну и стоит помнить, что ваш провайдер к вам куда ближе и знает о вашем трафике куда как побольше, чем любой OCSP.
Не забывайте что в текущих реалиях вы часто можете выбрать себе провайдера самостоятельно. Причем не обязательно что-бы этот провайдер «присутствовал» в вашем доме, районе или даже стране, гнать весь трафик через тот же vpn не так сложно, а единственный недостаток: слегка возросший пинг и по первости youtube неревелантные вещи в топе показывает.
Потому что «некая третья сторона» сидит в списке доверенных корневых сертификатов и, теоретически, способна на несравнимо большие злоупотребления, нежели узнавание имени части хостов, которые вы посетили.
Оно как бы да, но если «несравнимо большие злоупотребления» можно относительно легко отследить через тот же Certificate Transparency (или в скором времени можно будет отследить), то «отследить сливание данных о посещенных вами сайтах» можно будет только по косвенным признакам и то не 100%… еще и в зависимости от того, кому и для чего эти данные будут сливаться. А если посмотреть на историю человечества, то можно легко убедиться что если кому-то дать возможность чем-то злоупотребить, то эта возможность будет использована для злоупотребления, и вопрос только во времени (когда в руководству этими структурами придут «плохие парни», когда данную структуру получиться взломать, когда эти данные окажутся в паблике из-за технической ошибки и еще миллион возможных вариантов).
Решением может быть «дать людям возможность создавать свои сервера проверки отозванных сертификатов» (как это сейчас с DNS-серверами, когда рекурсивный DNS может поднять каждый и использовать его не боясь что он сливает данные куда-то), но в существующей системе это будет выглядеть как костыль, который с одной стороны сложно внедрить, а с другой мало кто будет использовать. Как мне видится лучшее решение: развитие в сторону OCSP Stapling.
но при TLS SNI вы все равно выдаете всем желающим MansITM имя посещаемого домена.
Не всем желающим, а только тем, через кого пойдет трафик. И это можно «вынужденная мера», без которой сложно обойтись. Сравнивать это с «добровольным оповещением разных CA о посещаемых сайтах» несколько некорректно. Ведь и ip-адреса мы «отдаем всем на пути трафика», но при этом передача «на сторону» этих же ip-адресов (клиента и сервера) не приветствуется всеми параноиками мира (мягко говоря).
Проблема с DNSSEC: он мало распространен и подвержен downgrade attack'ам. А избавление от этих проблем сломает обратную совместимость очень многих вещей. Уж легче браузеры (как основные потребители шифрованного трафика на основе публичных сертификатов) допилить, чем полностью перейти на DNSSEC кмк.
Проблема в том, что «украли сертификат» можно заменить на «злоумышленник как-то получил доступ к закрытому ключу», например скомпрометировав CA, злоумышленник выпустил себе сертификат для вашего домена, а ваш сервер тут совсем не причем. А ни вы, ни пострадавший CA в данный момент с этим ничего поделать не могут.
Так же вас могли взломать, вы предприняли все меры (изучение пути взлома, нахождение изначальной дыры, ресетап ОС, восстановление данных из бэкапа и выкатка кода без уязвимости), но сертификат условно-говоря был выпущен «только вчера и на год», и вы не можете препятствовать злоумышленнику в том, что бы использовать ваш сертификат в течении года для атаки на ваших пользователей. Да, злоумышленнику помимо сертификата еще необходим способ «вклиниться между ваши и вашими пользователями», и если «ваш сервер теперь точно не содержит уязвимостей» то сделать это не так просто, нужно иметь возможность либо контролировать ваш интернет-канал, что маловероятно, ведь вы «хоститесь в именитом ДЦ с безупречной репутацией», либо канал выхода в интернет ваших пользователей, что тоже маловероятно, ведь «пользователей миллионы и они раскиданы по всему миру и использует десятки тысяч разных аплинков».
А теперь небольшой финт: представляем что под «злоумышленник» мы имеем ввиду не скрипткидди Васю, который поломал вас через старый FTP-сервер скачав пачку эксплойтов с античата, а например какую-то «спец. службу», которой ваш датацент не может отказать в маленькой просьбе «проксировать ваш трафик через их сервер», или 99% ваших пользователей живут в очередной банановой республике, а единственный провайдер этой республики так же не может отказать в аналогичной просьбе этой самой «спец. службе».
И даже CAA на данном этапе вас никак не спасет, ибо на данный момент не обязателен, да к тому же и легко обходиться подделкой ответа DNS с DNS downgrade attack (в случае если используется DNSSEC
Блокчейн в его классическом (биткоиновском) понимании тут не нужен, я не хочу что бы «завтра» «плохие люди», купив за 100$ (1000-10,000-не важно сколько) немного мощностей на амазоне(azure, google cloud, etc), построили альтернативную ветку этого блокчейна, выкинув «мой» сертификат в утиль и подставив туда свой.
В остальном идея правильная, и уже реализованная, смотрите RFC 6962, оно же Certificate Transparency оно же на Хабре.
Осталось ни так много: набрать критическую массу и выкинуть из основных браузеров поддержку тех CA, которые не начали играть по этим правилам (читайте: перестать принимать сертификаты, которых нет в данном логе).
Это конечно в корне не решит проблему «приходиться доверять какому-то непонятному дяде», но как минимум даст «технический» инструмент намного быстрей выявлять недобросовестных «дядь» и применять к ним административные меры.
Ну а для решения проблемы «хранения данного лога на устройстве» уже придумали OCSP, только к сожалению он не работает как надо.
Ужасно нудно, почитал до конца на морально волевых качествах, надеясь что автор таки «закончит с формальным вступлением и начнет рассказывать за жизнь», но статья внезапно кончилась.
Ваш ответ:
… под своим реальным именем
Именно расстояние виновно в том что из Америки посылка за 2 суток долетает до Москвы, а потом неделю путешествует по Москве до конечного адреса?
faq
То есть, судя по FAQ, любой (в том числе и вы) можете поднять свой «лог-сервер» и следить за всеми сертификатами, которые добавлены в этот лог. А если не хотите морочится, то можете воспользоваться любым сервисом, которому лично вы доверяете… когда они появятся.
Если же клиент использует PA адреса одного провайдера, но трафик пускает через другого провайдера, то второй провайдер может спокойно блокировать этот трафик и на любой вопрос в саппорт ответит «это не ваши адреса, мы выделили вам другие, используйте их» и будет на 100% прав.
syn и ack — имеют свои порядковые номера, но начинаются не с единицы (или нуля), а генерируются рандомно.
Атакующие подделывают ip-адрес отправителя(вместо своего реального IP-адреса они в качестве «адреса отправителя» указывают адрес сервера, который ддосят в данный момент), поэтому если атакующий будет использовать tcp, то первый ответ от сервера, который syn+ack уйдет сразу «жертве ддоса», жертва ответит на него rst (reset, сброс соединения), сервер увидев вместо ack-пакета rst пакет пойдем что «что-то пошло не так» и не будет пытаться что-то отправлять в сторону «жертвы».
То есть вроде как произойдет примерно тоже самое, но не получиться такого сильного «усиления атаки», на один пакет злоумышленника «syn» промежуточный сервер сформирует один пакет «syn+ack» примерно равный по размеру изначальному syn-пакету.
В UDP же нет понятия «установки соединения», и поэтому одним маленьким пакетом (без установки соединения syn — sync+ack — ack, просто первым пакетом сразу отправляется запрос какой-то информации) можно получить относительно большой ответ. И за счет этого получается «усиление», когда злоумышленник тратит 5Гб\с на запросы (так же указывая в качестве адреса отправителя не свой реальный IP, а IP жертвы), а промежуточные сервера (сторонних людей, которые подвержены этой атаке) формируют ответов на 100Гб\с, и все ответы уходят жертве.
Вообще стоит разобраться (хотя бы в общих чертах) в механизмах работы tcp и udp и все сразу станет очевидно. Проблема не только в UPnP, раньше для того же самого широко использовались DNS и NTP протоколы, (которые тоже работают через UDP), но это стало неэффективным потому что большинство администраторов столкнулись с тем что «DNS сервер внезапно стал генерировать большой трафик в интернет», разобрались с тем, что происходит и закрыли DNS и NTP сервера фаерволами. Те, кто разумнее — заодно прикрыли и остальные сервисы работающие по UDP, поэтому видим что злоумышленники переключились на «домашних пользователей» в качестве «промежуточных серверов усиления». Со временем UPnP тоже позакрывают(зами пользователи или администраторы провайдеров) и атакующие будут искать другие способы усиление трафика (другие протоколы, или вернуться к комбинации DNS+NTP+UPnP+что-там еще есть, рассчитывая на то, что появились новые сервера с этими сервисами, которые забыли закрыть фаерволом или обновить).
Не забывайте что в текущих реалиях вы часто можете выбрать себе провайдера самостоятельно. Причем не обязательно что-бы этот провайдер «присутствовал» в вашем доме, районе или даже стране, гнать весь трафик через тот же vpn не так сложно, а единственный недостаток: слегка возросший пинг и по первости youtube неревелантные вещи в топе показывает.
Оно как бы да, но если «несравнимо большие злоупотребления» можно относительно легко отследить через тот же Certificate Transparency (или в скором времени можно будет отследить), то «отследить сливание данных о посещенных вами сайтах» можно будет только по косвенным признакам и то не 100%… еще и в зависимости от того, кому и для чего эти данные будут сливаться. А если посмотреть на историю человечества, то можно легко убедиться что если кому-то дать возможность чем-то злоупотребить, то эта возможность будет использована для злоупотребления, и вопрос только во времени (когда в руководству этими структурами придут «плохие парни», когда данную структуру получиться взломать, когда эти данные окажутся в паблике из-за технической ошибки и еще миллион возможных вариантов).
Решением может быть «дать людям возможность создавать свои сервера проверки отозванных сертификатов» (как это сейчас с DNS-серверами, когда рекурсивный DNS может поднять каждый и использовать его не боясь что он сливает данные куда-то), но в существующей системе это будет выглядеть как костыль, который с одной стороны сложно внедрить, а с другой мало кто будет использовать. Как мне видится лучшее решение: развитие в сторону OCSP Stapling.
Не всем желающим, а только тем, через кого пойдет трафик. И это можно «вынужденная мера», без которой сложно обойтись. Сравнивать это с «добровольным оповещением разных CA о посещаемых сайтах» несколько некорректно. Ведь и ip-адреса мы «отдаем всем на пути трафика», но при этом передача «на сторону» этих же ip-адресов (клиента и сервера) не приветствуется всеми параноиками мира (мягко говоря).
Проблема с DNSSEC: он мало распространен и подвержен downgrade attack'ам. А избавление от этих проблем сломает обратную совместимость очень многих вещей. Уж легче браузеры (как основные потребители шифрованного трафика на основе публичных сертификатов) допилить, чем полностью перейти на DNSSEC кмк.
Так же вас могли взломать, вы предприняли все меры (изучение пути взлома, нахождение изначальной дыры, ресетап ОС, восстановление данных из бэкапа и выкатка кода без уязвимости), но сертификат условно-говоря был выпущен «только вчера и на год», и вы не можете препятствовать злоумышленнику в том, что бы использовать ваш сертификат в течении года для атаки на ваших пользователей. Да, злоумышленнику помимо сертификата еще необходим способ «вклиниться между ваши и вашими пользователями», и если «ваш сервер теперь точно не содержит уязвимостей» то сделать это не так просто, нужно иметь возможность либо контролировать ваш интернет-канал, что маловероятно, ведь вы «хоститесь в именитом ДЦ с безупречной репутацией», либо канал выхода в интернет ваших пользователей, что тоже маловероятно, ведь «пользователей миллионы и они раскиданы по всему миру и использует десятки тысяч разных аплинков».
А теперь небольшой финт: представляем что под «злоумышленник» мы имеем ввиду не скрипткидди Васю, который поломал вас через старый FTP-сервер скачав пачку эксплойтов с античата, а например какую-то «спец. службу», которой ваш датацент не может отказать в маленькой просьбе «проксировать ваш трафик через их сервер», или 99% ваших пользователей живут в очередной банановой республике, а единственный провайдер этой республики так же не может отказать в аналогичной просьбе этой самой «спец. службе».
И даже CAA на данном этапе вас никак не спасет, ибо на данный момент не обязателен, да к тому же и легко обходиться подделкой ответа DNS с DNS downgrade attack (в случае если используется DNSSEC
В остальном идея правильная, и уже реализованная, смотрите RFC 6962, оно же Certificate Transparency оно же на Хабре.
Осталось ни так много: набрать критическую массу и выкинуть из основных браузеров поддержку тех CA, которые не начали играть по этим правилам (читайте: перестать принимать сертификаты, которых нет в данном логе).
Это конечно в корне не решит проблему «приходиться доверять какому-то непонятному дяде», но как минимум даст «технический» инструмент намного быстрей выявлять недобросовестных «дядь» и применять к ним административные меры.
Ну а для решения проблемы «хранения данного лога на устройстве» уже придумали OCSP, только к сожалению он не работает как надо.
Но это требование можно отключить через адблок
Вас*, извиняюсь за автоисправление. Не нашел в мобильной версии сайта как исправить комментарий.
Вам из отдела продаж за повинность сослали тех. статьи на хабр писать? Или как можно писать про мониторинг не о работав с системами мониторинга?