Комментарии 56
Не доводи до предела,
До предела не доводи!
Это я про аккумулятор.
До предела не доводи!
Это я про аккумулятор.
Бездумно жмякающим кнопки пользователям статья не поможет, а те кто дочитают до конца и так особо не страдают от излишней доверчивости. Был случай, когда пользователю выводишь большооое такое окно с предупреждением, а потом слышишь типа «Окошко? Красненькое такое с крупными буквами? да я его всегда закрваю, оно только мешается...».
НЛО прилетело и опубликовало эту надпись здесь
А ещё контролируя траффик можно подсунуть невнимательному пользователю свой корневой сертификат.
И уже им подписывать сертификаты для прокси.
Кстати о том, что при установке webmoney вы так-же ставите корневой сертификат, котороым они могут подписать сертификат для любого домена.
Правда мило?
И уже им подписывать сертификаты для прокси.
Кстати о том, что при установке webmoney вы так-же ставите корневой сертификат, котороым они могут подписать сертификат для любого домена.
Правда мило?
Да, мило.
Я не ставил его, хоть они и хотели.
И сейчас они уже вроде образумились, я пользуюсь light.webmoney.ru/, и браузер уже не ругается.
Я не ставил его, хоть они и хотели.
И сейчас они уже вроде образумились, я пользуюсь light.webmoney.ru/, и браузер уже не ругается.
Кстати о том, что при установке webmoney вы так-же ставите корневой сертификат, котороым они могут подписать сертификат для любого домена.
Правда мило?
Для этого его и устанавливают, не?
Для любого, не только для своих.
То есть они могут к примеру выдать сертификат на paypal.com.
А зачем они его предлагают установить — я не знаю. Наверно вебмастера WM тогда ещё не знали основ работы цифровой сертификации. Или же они надеялись такими действиями получить место среди корневых CA — не вышло.
То есть они могут к примеру выдать сертификат на paypal.com.
А зачем они его предлагают установить — я не знаю. Наверно вебмастера WM тогда ещё не знали основ работы цифровой сертификации. Или же они надеялись такими действиями получить место среди корневых CA — не вышло.
Я понимаю, что могут для любого. Но к WebMoney лично у меня доверия больше, чем к VeriSign, последним я свои деньги не доверяю.
Зачем предлагают установить свой тоже понятно — доменов у них много всяких разных, получать на каждый сертификат у Network Solutions накладно, просить юзеров чтоб жали «всё равно продолжить» не солидно… Но сейчас или деньги лишние появились, или клиенты достали. А вообще помню даже интересовался можно ли получить у них ssl сертификат на свои домены или получить SSL Certificate Authority для своего персонального сертификата, но ответили как-то невнятно, а интерес был чисто спортивный, так что забил.
Зачем предлагают установить свой тоже понятно — доменов у них много всяких разных, получать на каждый сертификат у Network Solutions накладно, просить юзеров чтоб жали «всё равно продолжить» не солидно… Но сейчас или деньги лишние появились, или клиенты достали. А вообще помню даже интересовался можно ли получить у них ssl сертификат на свои домены или получить SSL Certificate Authority для своего персонального сертификата, но ответили как-то невнятно, а интерес был чисто спортивный, так что забил.
Первый вопрос не заметил сразу.
Ниже ответил: habrahabr.ru/blogs/infosecurity/111714/#comment_3566323
Ниже ответил: habrahabr.ru/blogs/infosecurity/111714/#comment_3566323
Не важно, корневой он или промежуточный, который даже устанавливать не надо — им можно подписать любой сайт. Промежуточным сертификатом можно префиксировать конечный, с любым указанным Common Name.
А почем, находясь по середине, и имея возможность пропускать траффик сквозь себя нельзя вместе с подделкой целевого сайта, подделать заодно и центры сертификации? (и, соответственно, на запросы про правильность своего фиктивного сертификата отправлять утвердительные ответы)?
НЛО прилетело и опубликовало эту надпись здесь
Люди вы о чем, какую передачу?
Не будет никакой алгоритм, использующий сертификаты, доверять полученному по http сертификату.
Ниже ответил: habrahabr.ru/blogs/infosecurity/111714/#comment_3566323
Не будет никакой алгоритм, использующий сертификаты, доверять полученному по http сертификату.
Ниже ответил: habrahabr.ru/blogs/infosecurity/111714/#comment_3566323
НЛО прилетело и опубликовало эту надпись здесь
Да, мы получаем всё, что конечный пользователь, и всё, что получает сервер.
Но, мы не получаем общий ключ. Он не передаётся в явном виде при установлении соединения, он вычисляется и клиентом и сервером. Например алгоритм Диффи-Хеллмана (это ещё не SSL, но для для начала). Но при наблюдении со стороны его вычислить невозможно, а без него невозможно расшифровать передаваемые данные.
Именно это в сочетании с обязательной аутентификацией сервера (которая защищает от MITM) и является сутью SSL.
Но, мы не получаем общий ключ. Он не передаётся в явном виде при установлении соединения, он вычисляется и клиентом и сервером. Например алгоритм Диффи-Хеллмана (это ещё не SSL, но для для начала). Но при наблюдении со стороны его вычислить невозможно, а без него невозможно расшифровать передаваемые данные.
Именно это в сочетании с обязательной аутентификацией сервера (которая защищает от MITM) и является сутью SSL.
Список доверенных центров сертификации зашит, утрируя, в браузере, их закрытого ключа вы не знаете, а значит не сможете себя за них выдать.
потому что открытые ключи центров сертификации прописаны прямо в недрах браузера и для проверки достоверности сертификата сайта сеть не используется
Сертификаты центров сертификации установлены в вашей системе (или браузере), заранее.
Подделать-то можно.
Но чтобы был толк надо чтобы пользователь скачал сертификат (подсунуть ему можно любой), и установил его в браузере или на компьютере. То есть нужно активное действие пользователя для этого.
Но устанавливать сертификат может понадобиться 0.1% пользователей. И они достаточно осторожны чтобы проверить его отпечаток по другому каналу.
Более правдоподобно подменить какой-нибудь скачивамый по http инсталлятор на свой, с подарком. А запущенный бинарник уже что хочешь сделает.
Но чтобы был толк надо чтобы пользователь скачал сертификат (подсунуть ему можно любой), и установил его в браузере или на компьютере. То есть нужно активное действие пользователя для этого.
Но устанавливать сертификат может понадобиться 0.1% пользователей. И они достаточно осторожны чтобы проверить его отпечаток по другому каналу.
Более правдоподобно подменить какой-нибудь скачивамый по http инсталлятор на свой, с подарком. А запущенный бинарник уже что хочешь сделает.
НЛО прилетело и опубликовало эту надпись здесь
А как часто они будут скачивать корневые сертификаты? xD
А если серьёзно — инсталлятор думаю активный пользователь скачивает пусть раз в неделю.
Заранее подготовить «подарок». Оставить скрипт, который ждет когда пользователь запросит какой-нибудь .exe файл. Когда пользователь запросил файл, скрипт качает его, пакует вместе с «подарком» в один бинарник, и выдаёт пользователю.
Тут правда надо, чтоб инсталлятор был не слишком большой, т.к. потоково передавать уже не выйдет, нужно сначала целиком скачать.
А если серьёзно — инсталлятор думаю активный пользователь скачивает пусть раз в неделю.
Заранее подготовить «подарок». Оставить скрипт, который ждет когда пользователь запросит какой-нибудь .exe файл. Когда пользователь запросил файл, скрипт качает его, пакует вместе с «подарком» в один бинарник, и выдаёт пользователю.
Тут правда надо, чтоб инсталлятор был не слишком большой, т.к. потоково передавать уже не выйдет, нужно сначала целиком скачать.
Блин мне эта идея нравится, может быть станет темой для третьей части.
Если конечно сосед снова даст мне повод и если будет время.
Если конечно сосед снова даст мне повод и если будет время.
imho проще при посещении атакуемым какого либо сайта выдавать пугающую табличку:
«Этот сайт требует проверки подлинности SSL, для этого необходимо установить сертификат»,
и ссылочка на него. Это как вариант.
Или так: Сайтов человек будет посещать больше, чем что-то качать, наверняка есть такие которые или пользуются самоподписными сертификатами (разные статистики доступа в интернет) или часто выдающие алерты на тему ssl. Вот при заходе на них и требовать установку.
Невнимательный/«неразбирающийся в интернетах» человек скорее всего установит его чтобы посетить нужный ему сайтик.
«Этот сайт требует проверки подлинности SSL, для этого необходимо установить сертификат»,
и ссылочка на него. Это как вариант.
Или так: Сайтов человек будет посещать больше, чем что-то качать, наверняка есть такие которые или пользуются самоподписными сертификатами (разные статистики доступа в интернет) или часто выдающие алерты на тему ssl. Вот при заходе на них и требовать установку.
Невнимательный/«неразбирающийся в интернетах» человек скорее всего установит его чтобы посетить нужный ему сайтик.
НЛО прилетело и опубликовало эту надпись здесь
WindowsUpdate? Они по http вроде работают, обновления списков корневых УЦ помню бывали часто, может туда внедриться и свой подсонуть?
А некоторые браузеры пользуются, кажется, не системным хранилищем, а своим списком УЦ. Можно ещё так попробовать, фейковое обновление такого браузера сделать
Сильно подозреваю, что WU для каждого скачанного файла проверяет ЭЦП.
Сильно надеюсь, что все программы, которые автоматически (без участия пользователя) по http что-то качают и запускают (в том числе и обновляторы) проверяют ЭЦП для всего запускаемого. Иначе станет страшно жить.
Сильно надеюсь, что все программы, которые автоматически (без участия пользователя) по http что-то качают и запускают (в том числе и обновляторы) проверяют ЭЦП для всего запускаемого. Иначе станет страшно жить.
Ну, там вроде везде всё подписано и хрен там что заменишь — https там не нужен. Т.е. если подписан список обновлений и он хранит контрольные суммы для обновлений, то никак туда не влезешь.
т.е. у корневых центров сертификации самоподписанные сертификаты, установленные по умолчанию во всех браузерах, я правильно понимаю?
да
Да, классический вариант сети доверия. Есть несколько [не связанных друг с другом] Центров Сертификации. Есть принципиальное решение считать их доверенными (в ОС/Браузере). Есть сертификаты сайтов, подписанные этими ЦС. И поскольку мы доверяем этим ЦС, то доверяем и этим сайтам, при прохождении проверки подлинности сертификата, есстествено. Т.е. проще говоря — «друг моего друга — мой друг».
Простые истины, на доступном для всех языке. Спасибо, понравилось.
Думаю в вашем случае было бы так же идеальным решением использовать sslstrip, заточенный под это.
Жду следующих эпизодов «Войн в Песочнице» ;)
Думаю в вашем случае было бы так же идеальным решением использовать sslstrip, заточенный под это.
Жду следующих эпизодов «Войн в Песочнице» ;)
Забавно, как раз публикация автора sslstrip и вдохновила меня на эти действия, но на то, что там была упомянута сама утилита.
Сейчас посмотрел — действительно там уже реализовано то, что я тут делал. И кстати тоже на питоне и с использованием twisted-web. Что-ж, построил велосипед.
Более того, погуглив по слову sslstrip, нашёл статью, зная о существовании которой раньше, не стал бы сам писать. По крайней мере вторую часть, хотя первая мне казалась ещё более тривиальной темой.
Да и вообще по всему интернету про неё писали, даже для кулхацкеров инструкцию составили, а я будто сейчас проснулся =(
Сейчас посмотрел — действительно там уже реализовано то, что я тут делал. И кстати тоже на питоне и с использованием twisted-web. Что-ж, построил велосипед.
Более того, погуглив по слову sslstrip, нашёл статью, зная о существовании которой раньше, не стал бы сам писать. По крайней мере вторую часть, хотя первая мне казалась ещё более тривиальной темой.
Да и вообще по всему интернету про неё писали, даже для кулхацкеров инструкцию составили, а я будто сейчас проснулся =(
Замечетельная статья, наталкивающая на много мыслей.
Жаль только, что вы сразу отмели вариант MITM, потому что автор статьи, на которую вы ссылаетесь, как раз описывает реальную возможность это сделать, используя свой конечный сертификат для подписания сертификата на атакуемый сайт, используя свой конечный в качестве промежуточного. Автор утверждает, что многие браузеры не проверяют, что является ужасной дырой.
Ну, и ещё в оригинальной статье понравился забавный трюк с установлением в качестве favicon.ico значка «замка».
Жаль только, что вы сразу отмели вариант MITM, потому что автор статьи, на которую вы ссылаетесь, как раз описывает реальную возможность это сделать, используя свой конечный сертификат для подписания сертификата на атакуемый сайт, используя свой конечный в качестве промежуточного. Автор утверждает, что многие браузеры не проверяют, что является ужасной дырой.
Ну, и ещё в оригинальной статье понравился забавный трюк с установлением в качестве favicon.ico значка «замка».
Ну MITM, связанный с тем, что браузеры не проверяют (не проверяли?) BasicConstraints я не рассматривал по следующим причинам:
1) Для этого нужно иметь и использовать какой-нибудь завалящий, но валидный сертификат. А цепочки сертификатов — это не только средство проверки подлинности сайта, но и средство в случае чего найти виноватого. То есть, используя свой сертификат для подписи чего попало, мы, во-первых, рискуем, что по этой цепочке что-то восстановят, во-вторых если сертификат отзовут — то придётся предпринимать дополнительные действия.
2) Некоторые браузеры не проверяют, а некоторые — проверяют. А мы выяснили, что negative feedback намного хуже, чем отсутствие positive feedback. Поэтому метод strip более надёжен, так как он никогда не вызовет negative feedback.
А насчёт фавиконки — я всё же не перевод делал, хоть и много взял оттуда.
Мне показалось, что лучше добиваться не «ощущения безопасности», а «ощущения обыденности».
Не знаю как в Firefox, но в Chrome favicon отображается в заголовке вкладки, в значок SSL в адресной строке. То есть замочек был бы не там, где должен быть и являлся бы дополнительным отличием от привычного вида при использовании настоящего SSL.
1) Для этого нужно иметь и использовать какой-нибудь завалящий, но валидный сертификат. А цепочки сертификатов — это не только средство проверки подлинности сайта, но и средство в случае чего найти виноватого. То есть, используя свой сертификат для подписи чего попало, мы, во-первых, рискуем, что по этой цепочке что-то восстановят, во-вторых если сертификат отзовут — то придётся предпринимать дополнительные действия.
2) Некоторые браузеры не проверяют, а некоторые — проверяют. А мы выяснили, что negative feedback намного хуже, чем отсутствие positive feedback. Поэтому метод strip более надёжен, так как он никогда не вызовет negative feedback.
А насчёт фавиконки — я всё же не перевод делал, хоть и много взял оттуда.
Мне показалось, что лучше добиваться не «ощущения безопасности», а «ощущения обыденности».
Не знаю как в Firefox, но в Chrome favicon отображается в заголовке вкладки, в значок SSL в адресной строке. То есть замочек был бы не там, где должен быть и являлся бы дополнительным отличием от привычного вида при использовании настоящего SSL.
А может вы слышали про функциональность инспектирования https траффика в MS Forefront TMG? Интересно было бы почитать, как это?
у меня в gmail'e стоит принудительное использование ssl (собственно из-за него в ходе недавних событий в Беларуси я не смог читать почту)
а для сайтов аля веб-мани и т.п. я сам лично наблюдаю наличие ssl.
а для сайтов аля веб-мани и т.п. я сам лично наблюдаю наличие ssl.
Принудительное использование ssl? В настройках GMail?
Спешу обрадовать, что это хорошо, но не защищает от описанной схемы, так как в ней взаимодействие с сервером идёт именно по SSL.
Для защиты нужно контролировать или форсировать SSL на стороне клиента. Например изменив закладку в браузере с gmail.com/ на gmail.com/.
Спешу обрадовать, что это хорошо, но не защищает от описанной схемы, так как в ней взаимодействие с сервером идёт именно по SSL.
Для защиты нужно контролировать или форсировать SSL на стороне клиента. Например изменив закладку в браузере с gmail.com/ на gmail.com/.
переадресация на https идет на уровне сервера gmail'a, а не у меня в браузере. даже когда я ввожу просто http:// gmail меня переадресовывает на https://
Я понимаю. И именно на это рассчитана описанная в статье атака. Пользователь рассчитывает, что сервер его перенаправит на https.
Но! Сам акт перенаправления происходит по http, который никак не защищён.
Поэтому man-in-the-middle может эту переадресацию вырезать из потока данных, идущих от сервера к вам, и вы так и останетесь на http.
Защититься от этого можно было бы не надеясь на перенаправление (которого может и не быть, т.к. MITM) а заходя напрямую по https. Если вы зашли по прямой ссылке https://, то man-in-the-middle (почти) ничего не сможет сделать.
Но! Сам акт перенаправления происходит по http, который никак не защищён.
Поэтому man-in-the-middle может эту переадресацию вырезать из потока данных, идущих от сервера к вам, и вы так и останетесь на http.
Защититься от этого можно было бы не надеясь на перенаправление (которого может и не быть, т.к. MITM) а заходя напрямую по https. Если вы зашли по прямой ссылке https://, то man-in-the-middle (почти) ничего не сможет сделать.
я говорю о том, что неважно откуда пришел запрос на gmail (http или https), если в gmail'e стоит только https то он его переадресует в любом случае, что бы вы не делали.
похожую технику я использую для сайта авторизации в локальной сети: сайт описан в vhoste который слушает 443 порт (ssl), а vhost для 80 порта (http) просто делает жесткий редирект на https:\\sitename ( Redirect permanent / sitename ). Т.е. что ты не делай, в любом случае тебя отправят на https. (примерно так-же работает и принудительный ssl на gmail'e)
похожую технику я использую для сайта авторизации в локальной сети: сайт описан в vhoste который слушает 443 порт (ssl), а vhost для 80 порта (http) просто делает жесткий редирект на https:\\sitename ( Redirect permanent / sitename ). Т.е. что ты не делай, в любом случае тебя отправят на https. (примерно так-же работает и принудительный ssl на gmail'e)
Взгляните на картинку:
Сервер тут видит, что к нему кто-то подключается через https (он не может знать, что где-то там есть клиент и атакующий, и они соединены по http), поэтому он никаких перенаправлений делать не будет, и спокойно покажет всю секретную инфу.
Этот почти пруфпик показывает, как клиент прекрасно открыл по http форму авторизации Google (не интерфейс GMail, но ситуация аналогичная). Сервер в этот момент считает, что соединение происходит через https. Без MITM клиент не смог бы открыть такой адрес по http, так как сервер, действительно, перенаправил бы его на https.
Принудительный SSL со стороны сервера способен бороться только против пассивного прослушивания (что тоже хорошо, но недостаточно).
Чтобы защититься от MITM за качеством и наличием шифрования обязан следить клиент.
Если я непонятно объясняю, то почитайте первоисточник.
Сервер тут видит, что к нему кто-то подключается через https (он не может знать, что где-то там есть клиент и атакующий, и они соединены по http), поэтому он никаких перенаправлений делать не будет, и спокойно покажет всю секретную инфу.
Этот почти пруфпик показывает, как клиент прекрасно открыл по http форму авторизации Google (не интерфейс GMail, но ситуация аналогичная). Сервер в этот момент считает, что соединение происходит через https. Без MITM клиент не смог бы открыть такой адрес по http, так как сервер, действительно, перенаправил бы его на https.
Принудительный SSL со стороны сервера способен бороться только против пассивного прослушивания (что тоже хорошо, но недостаточно).
Чтобы защититься от MITM за качеством и наличием шифрования обязан следить клиент.
Если я непонятно объясняю, то почитайте первоисточник.
Перехватывать https путём выкусывания из http всех ссылок на https — это всё равно, что описывать в очередной раз арп спуффинг и взлом wi-fi с wep.
Да, действительно боянисто получилось.
Статью писал как историю из жизни, которой хотелось поделиться с обществом.
Подробнее остановился на тех местах, которые для меня показались интересными и нетривиальными, в частности идея sslstrip, не думал, что все её уже знают.
Как видно по дискуссии выше, действительно не все.
Статью писал как историю из жизни, которой хотелось поделиться с обществом.
Подробнее остановился на тех местах, которые для меня показались интересными и нетривиальными, в частности идея sslstrip, не думал, что все её уже знают.
Как видно по дискуссии выше, действительно не все.
Если цель — получить пароль от гмейла и сделать это незаметно для пользователя, то можно вообще на змаорачиваться с заменой https на http, а просто выдавать фейковую http страницу с формой ввода, а после ввода пароля — логинить пользователя на настоящем сервере и уже никак не препятствовать трафику между жертвой и сервером. В этом случае заподозрит неладное только тот, кто заметит http вместо https на странице входа в гмейл. А когда залогинится, то всё будет как обычно.
Только хотел написать про sslstrip и его автора Moxie Marlinspike — тут уже упомянули. Один моментик — когда занимаетесь такими вещами, надо быть очень аккуратным и уж точно не стоит устраивать цирк с паролями одногруппниц. Тот же Moxie вроде никого и не ломал (по крайней мере публично особо не хвастался), у него недавно на границе отобрали ноутбук и телефоны. Неприятно-с.
Это Moxie-то никого не ломал?
отсюда
Но по сути я с вами согласен, аккуратным нужно быть.
login.yahoo.com 114 Gmail 50 ticketmaster.com 42 rapidshare.com 14 Hotmail 13 paypal.com 9 linkedin.com 9 facebook.com 3
отсюда
Но по сути я с вами согласен, аккуратным нужно быть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Войны в песочнице — Часть 2. Обход HTTPS