Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Конечно, я смотрю, уже что-то висит подобное на главной, но я делал перевод сегодня ночью, когда еще не было опубликовано ничего. Не сочтите за плагиат, и не пропадать же добру.
Я не понял в чем Apple нужно поменять их политику безопасности? Если портить корневые сертификаты то какая политика устоит?
Банить по ID — самое очевидное решение.
я имел в виду вот это:
Поэтому все, что нам было нужно, так это установить пользовательский SSL центр сертификации, добавить его в наш iPhone 4S, и подписать с его помощью сугубо наш поддельный сертификат, как «guzzoni.apple.com». И это сработало: Siri оправлял команды на наш собственный HTTPS сервер! Похоже, кто-то в Apple все-же упустил эту деталь.
Ну SSL как-бы придуман для того, чтобы данные перехватывать не получалось и сервер Siri подделать не вышло. Но вторую проверку, как известно, можно отключить на клиенте (ну или установить свой сертификат в хранилище). Он не предназначен же для защиты от взлома собственно протокола. Тем более, что после того как они узнали технические детали, можно вообще пользоваться оригинальным сервером/сертификатами и выглядеть всё будет, как честный iPhone 4S.
Очевидное-невероятное. Как быть с «упёртыми» ID?
Имелось в виду проверять сертификат в приложении, а не полагаться на openssl (или какую они там библиотеку юзают) для проверки валидности.
Вот, например, ssh никому, кроме себя не верит. И его не убедить, что узел доверенный, если его ключа нет в списке известных хостов.
Вот, например, ssh никому, кроме себя не верит. И его не убедить, что узел доверенный, если его ключа нет в списке известных хостов.
Но точно также ничего не меняет добавить ключ. Не хардкодить же отпечатки в бинарнике.
Как раз хардкодить в бинарнике в данном случае — очевидная процедура. На этапе компиляции просто брать текущий актуальный сертификат (и запасной, который not valid before) и вкоживать.
если я отредактирую known_hosts, то ssh будет обманут абсолютно точно так же, или я неправ?
Именно. Но откуда именно читается этот файл, решает бинарник. И он же решает читать ли его, или использовать хардкоженные ключи.
Заметим, что в этом случае подмена будет существенно затруднена, а при минимальных усилиях по защите целостности этого кода, доведена до крайне высокого уровня защиты. Разумеется, бинарник тоже ломаем, но с куда большей кровью.
Заметим, что в этом случае подмена будет существенно затруднена, а при минимальных усилиях по защите целостности этого кода, доведена до крайне высокого уровня защиты. Разумеется, бинарник тоже ломаем, но с куда большей кровью.
ну тогда уж легче просто запретить менять корневые сертификаты но ведь так никто не делает (я даже склонен догадаться почему)
Запретить менять сертификаты «вообще» — поломать всю PKI (читай, нормальный SSL в браузере). Запретить конкретному приложению пользоваться системными сертификатами и юзать только свои (имеется в виду, иметь свои доверенные корневые сертификаты) менее инвазивно.
… PS Хотя идея с выпуском своего фальшивого сертификата и добавления себя как доверительного — да, интересно. Очень.
> Но откуда именно читается этот файл, решает бинарник.
Не совсем так. Побуду немного занудой:
Конфиг /etc/ssh/sshd_config позволяет это настраивать:
Т.е. конфиг может быть для каждого пользователя свой или системный/общий для всех. Т.е. некоторая гибкость все-таки присутствует.
Не совсем так. Побуду немного занудой:
Конфиг /etc/ssh/sshd_config позволяет это настраивать:
# For this to work you will also need host keys in /etc/ssh_known_hosts
< ... >
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
Т.е. конфиг может быть для каждого пользователя свой или системный/общий для всех. Т.е. некоторая гибкость все-таки присутствует.
Пост в принципе дополняет написанный ранее, т.к. в нем больше информации непосредственно по коммуникации клиент-сервер. После предыдущего у меня еще были сомнения. Спасибо.
Интересная статья, интересно было читать и спасибо за перевод.
Надежда на появление Siri на Android угасла с прочтением абзаца про UDID :(
>Например, когда вы используете преобразование текста в речь, сервер Apple даже присылает оценку доверия и временную метку для каждого слова.
Оценка доверия — что это такое?
Оценка доверия — что это такое?
Выглядит как пост какого-то школохакера (ну разработчики онлайн игр, приложений для телефонов и вконтактиков по уровню от школьников недалеко и ушли), это надо же додуматься, «взломать» https на клиенте, имея полный доступ к устройству. Все черные шляпы скрежещут зубами от бессилия рядом с французскими игроделами.
> Content-Length почти 2 Гб. Что, очевидно, не соответствует стандарту HTTP.
Очевидно, что тело запроса генерируется на ходу, и на ходу же отправляется, может для уменьшения времени отклика, может, чтобы память зря не расходовать, его длина заранее неизвестна, потому посылается заведомо большая длина, чтобы какой-нибудь проприетарный кривопрокси/кривовиндофаерволл/кривоантивирус не оборвал соединение раньше времени.
> И эти сервера отвечают ему невероятным количеством информации. Например, когда вы используете преобразование текста в речь, сервер Apple даже присылает оценку доверия и временную метку для каждого слова.
И что в этом плохого?
> И давайте понаблюдаем, сколько времени понадобится Apple, чтобы поменять их политику безопасности.
При чем тут безопасность? Максимум что можно получить — потратить немного процессорного времени на сервере Эппл. А да, можно еще написать кривой клиент для андроида, вбив в который свой Эппл id можно будет получить и на том аналог siri. Но зачем?
> Content-Length почти 2 Гб. Что, очевидно, не соответствует стандарту HTTP.
Очевидно, что тело запроса генерируется на ходу, и на ходу же отправляется, может для уменьшения времени отклика, может, чтобы память зря не расходовать, его длина заранее неизвестна, потому посылается заведомо большая длина, чтобы какой-нибудь проприетарный кривопрокси/кривовиндофаерволл/кривоантивирус не оборвал соединение раньше времени.
> И эти сервера отвечают ему невероятным количеством информации. Например, когда вы используете преобразование текста в речь, сервер Apple даже присылает оценку доверия и временную метку для каждого слова.
И что в этом плохого?
> И давайте понаблюдаем, сколько времени понадобится Apple, чтобы поменять их политику безопасности.
При чем тут безопасность? Максимум что можно получить — потратить немного процессорного времени на сервере Эппл. А да, можно еще написать кривой клиент для андроида, вбив в который свой Эппл id можно будет получить и на том аналог siri. Но зачем?
трафик Siri отправлялся по TCP на порт 443, на сервере 17.174.4.4
А там сидит 10000 человек на зарплате, распознают на слух и отправляют обратно))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расшифровывая Siri