Один ли я думаю, когда читаю советы вроде
Как только облако Apple заблокируют в России по IP, у владельцев техники Apple накроется вся синхронизация между устройствами, включая и Notes, и Pages/Numbers/Keynote, и PhotoStream, и адресную книгу. Чтобы этого избежать, придётся всем мобильным устройствам раздавать с компьютера по WiFi доступ сразу через прокси-сервер. Про это тоже нужна инструкция.
об устойчивости протоколов синхронизации Apple к атакам man-in-the-middle и вообще об их защищенности? Думаю, что нет — и ожидаю появления другой инструкции — как настроить прокси-сервер и наловить много чего интересного, включая фото обнаженных оппозиционерок, пароли к лучшим оппозиционным сайтам и номера кредитных карт.
UPD Исследование устойчивости андроидных приложений к MitM:
http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf
там хттпс жы. а все MIM уже пофиксели
При условии, что пользователь не будет жать на кнопку «пох, продолжаем» при вылезшем окошечке «Ошибка SSL-сертификата». А уж как обстоит дело с этим в «программах-клиентах» — одному Богу известно.
И вообще, SSL понимает от силы несколько сот человек во всем мире — а российские оппозиционеры и кодеры под мобильные устройства вряд ли к ним относятся.
А меня всегда интересовало: при атаке обезъянка-на-проводе (Monkey, йопт, in the middle! :) нельзяли заодно подделывать и ответ центра сертификации? Или его сертификат зашит в девайсе с завода и хрен перехватишь?
Корневые сертификаты встроены в ОС (это как минимум — я не удивлюсь, если какие-то популярные программы работают со своей инфраструктурой SSL). В принципе, обновляются они не у всех и большинство пользователей просто жмет на кнопку «похер, продолжить», когда не открывается сайт по HTTPS.
А предположим, мы перехватим до кучи запросы на обновление венды, и пришлем патч с новыми сертификатами? Сертификаты же по-любому не вечны?
прежде чем что-то сетапиться, проверяется цифровая подпись, слабо подписать свои фальшивые сертификаты МС подписью?
при этом всем, оно еще лезет в интернет — проверить не отозван ли сертификат, мы наткнулись на оч смешную багу из-за этого в стиле «30 секунд тупежа на ровном месте»
ну да. Мне, пожалуй, слабо. :)
http://www.theregister.co.uk/2011/09/06/diginotar_audit_damning_fail/ — а это для серьезных парней.
ну в области синхронизации там забыдлокодили что нет такой кнопки вааще — тупо не проходит синк.
Вообще, крайне интересно посмотреть на поведение яблочного устройства, когда у него внезапно протухнут корневые сертификаты.
дык переставьте дату :)
кмк там либо игнор сего факта, либо сертификат выписан на 10 лет вперед.
Я уже видел корпоративные сети с проксёй в качестве man-in-the-middle. Сертификаты прокси казались достоверными не только корпоративным устройствам, но и гостевым аппаратам.
Вот это уже интересно :)
При проксировании HTTPS-траффика используется метод CONNECT протокола HTTP. При этом прокси не может ни прочитать содержимое запросов/ответов, ни модифицировать их; все что она знает — это факт соединения с данным IP.
Вопрос: почему прокси-сервер обязан следовать протоколу «HTTPS через прокси»?
Ответ: он не обязан, и вполне может вытворять вот какую штуку: при попытках соединиться с некоторыми интересными ему ресурсами подменять их ответ своим, используя свой сертификат для SSL-соединения. Скажем, при попытке обратиться к https://server.com проксик ответит клиенту сам, используя либо «поддельный» (такие штуки уже были зафиксированы), либо самоподписанный (пользователи настолько привыкли жать на кнопочку «пох, соединяемся», что не придадут этому значения) сертификат для server.com. Содержимое странички, разумеется, будет настоящим, полученным от самого https://server.com.
Извиняюсь, но даже в Википедии про это написано довольно подробно: http://ru.wikipedia.org/wiki/Человек_посередине
То есть, риски примерно эквивалентны подключению к публичному непроверенному WiFi, и при использовании надо применять примерно такую же осторожность.
Если мы считаем, что SSL/TLS выполняет свои обещания (безопасная передача информации по небезопасному каналу), то прокси можно использовать. Если не считаем — то нельзя использовать не только прокси.
А многие ли из тех, для кого пишут подобные инструкции, задумываются о рисках в случае «публичного непроверенного WiFi»? А тут — вообще совсем другой коленкор, тут будет VPN, за который деньги заплатили. Через такое соединение ни в коем случае нельзя пускать «весь доступ», как предлагает большой специалист по интернетам
долбоНосик. Какой-нибудь turbofilm — это одно, gmail — совсем другое.