Как стать автором
Обновить

Комментарии 34

Конечно, я смотрю, уже что-то висит подобное на главной, но я делал перевод сегодня ночью, когда еще не было опубликовано ничего. Не сочтите за плагиат, и не пропадать же добру.
Ну кривенький перевод и?
Перевод неплох. Но вычитка и корректировка, конечно, не помешают.
Неплох, для гуглтранслейта)
«Как только наши руки получили новенький iPhone 4S»
Оно сжато с помощью аудиокодека Speex, который имеет смысл, поскольку этот кодек специально предназначенный для VoIP.
Это конкуренция. В данном случае вы опоздали, в другой раз может больше повезет.
Думаю, можно сделать скидку этому автору за то, что ему прошлось сначала написать пост в песочницу, затем дождаться модерации и получения инвайта (+ регистрации на сайте) и уже потом отправки сюда на сайт :)
спасибо, было приятно читать.
Я не понял в чем Apple нужно поменять их политику безопасности? Если портить корневые сертификаты то какая политика устоит?
Банить по ID — самое очевидное решение.
я имел в виду вот это:

Поэтому все, что нам было нужно, так это установить пользовательский SSL центр сертификации, добавить его в наш iPhone 4S, и подписать с его помощью сугубо наш поддельный сертификат, как «guzzoni.apple.com». И это сработало: Siri оправлял команды на наш собственный HTTPS сервер! Похоже, кто-то в Apple все-же упустил эту деталь.
Ну SSL как-бы придуман для того, чтобы данные перехватывать не получалось и сервер Siri подделать не вышло. Но вторую проверку, как известно, можно отключить на клиенте (ну или установить свой сертификат в хранилище). Он не предназначен же для защиты от взлома собственно протокола. Тем более, что после того как они узнали технические детали, можно вообще пользоваться оригинальным сервером/сертификатами и выглядеть всё будет, как честный iPhone 4S.
Очевидное-невероятное. Как быть с «упёртыми» ID?
Имелось в виду проверять сертификат в приложении, а не полагаться на openssl (или какую они там библиотеку юзают) для проверки валидности.

Вот, например, ssh никому, кроме себя не верит. И его не убедить, что узел доверенный, если его ключа нет в списке известных хостов.
Но точно также ничего не меняет добавить ключ. Не хардкодить же отпечатки в бинарнике.
Как раз хардкодить в бинарнике в данном случае — очевидная процедура. На этапе компиляции просто брать текущий актуальный сертификат (и запасной, который not valid before) и вкоживать.
если я отредактирую known_hosts, то ssh будет обманут абсолютно точно так же, или я неправ?
Именно. Но откуда именно читается этот файл, решает бинарник. И он же решает читать ли его, или использовать хардкоженные ключи.

Заметим, что в этом случае подмена будет существенно затруднена, а при минимальных усилиях по защите целостности этого кода, доведена до крайне высокого уровня защиты. Разумеется, бинарник тоже ломаем, но с куда большей кровью.
ну тогда уж легче просто запретить менять корневые сертификаты но ведь так никто не делает (я даже склонен догадаться почему)
Запретить менять сертификаты «вообще» — поломать всю PKI (читай, нормальный SSL в браузере). Запретить конкретному приложению пользоваться системными сертификатами и юзать только свои (имеется в виду, иметь свои доверенные корневые сертификаты) менее инвазивно.
… PS Хотя идея с выпуском своего фальшивого сертификата и добавления себя как доверительного — да, интересно. Очень.
> Но откуда именно читается этот файл, решает бинарник.

Не совсем так. Побуду немного занудой:

Конфиг /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


Т.е. конфиг может быть для каждого пользователя свой или системный/общий для всех. Т.е. некоторая гибкость все-таки присутствует.
Какой файл конфига читать — решает бинарник. Я не говорю про тот конкретный ssh, который у вас из пакета в системе стоит, я говорю о том, что приложение имеет полную свободу решать, каким ключам оно верит, а каким нет. С корневыми сертификатами аналогично.
Пост в принципе дополняет написанный ранее, т.к. в нем больше информации непосредственно по коммуникации клиент-сервер. После предыдущего у меня еще были сомнения. Спасибо.
НЛО прилетело и опубликовало эту надпись здесь
Интересная статья, интересно было читать и спасибо за перевод.
Надежда на появление Siri на Android угасла с прочтением абзаца про UDID :(
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
>Например, когда вы используете преобразование текста в речь, сервер Apple даже присылает оценку доверия и временную метку для каждого слова.

Оценка доверия — что это такое?
Скорее всего какая-то матанская оценка правильности преобразования, не могу точно ничего сказать.
а зачем пользователю её отсылать? хм странно
Выглядит как пост какого-то школохакера (ну разработчики онлайн игр, приложений для телефонов и вконтактиков по уровню от школьников недалеко и ушли), это надо же додуматься, «взломать» https на клиенте, имея полный доступ к устройству. Все черные шляпы скрежещут зубами от бессилия рядом с французскими игроделами.

> Content-Length почти 2 Гб. Что, очевидно, не соответствует стандарту HTTP.

Очевидно, что тело запроса генерируется на ходу, и на ходу же отправляется, может для уменьшения времени отклика, может, чтобы память зря не расходовать, его длина заранее неизвестна, потому посылается заведомо большая длина, чтобы какой-нибудь проприетарный кривопрокси/кривовиндофаерволл/кривоантивирус не оборвал соединение раньше времени.

> И эти сервера отвечают ему невероятным количеством информации. Например, когда вы используете преобразование текста в речь, сервер Apple даже присылает оценку доверия и временную метку для каждого слова.

И что в этом плохого?

> И давайте понаблюдаем, сколько времени понадобится Apple, чтобы поменять их политику безопасности.

При чем тут безопасность? Максимум что можно получить — потратить немного процессорного времени на сервере Эппл. А да, можно еще написать кривой клиент для андроида, вбив в который свой Эппл id можно будет получить и на том аналог siri. Но зачем?
трафик Siri отправлялся по TCP на порт 443, на сервере 17.174.4.4

А там сидит 10000 человек на зарплате, распознают на слух и отправляют обратно))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории