Всё верно. Кстати в реализации ECDHE вроде наша российская компания CryptoPro участвовала, во всяком случае они реализовали ГОСТ'овские алгоритмы, которые тоже используют эллиптические кривые.
DHE это конечно хорошо, его использование действительно не позволяет третьей стороне расшифровать перехваченный траффик без знания даже при наличии секретного ключа сервера.
DHE это конечно хорошо, его использование действительно не позволяет третьей стороне расшифровать перехваченный траффик без знания секретного ключа сервера. Но ведь оно уже довольно давно реализовано в OpenSSL и поддерживается абсолютным большинством современных веб-серверов и браузеров.
Кстати, не знаю чего они там у себя обновили, но на gmail.com до сих пор RSA-RC4-SHA, без обмена ключами по Диффи-Хеллману. Перехваченную сессию с него можно даже Wireshark'ом расшифровать при наличии секретного ключа сервера. А вот на mail.yandex.ru включается DHE_RSA, и тут уже не всё так просто.
У нас в университете гугл внедрили глобально и это было абсолютно бессмысленно. Ну да, он есть, у всех студентов есть по аккаунту, но никто ничего в нем не делал.
При вашей миграции на гуглаппс вы потеряли наиболее значимый аспект — профит от привлечения студентов к практической работе над проектом.
Но остается небольшой нюанс — для того, чтобы скрипт или апплет могли отправлять данные по установленному жертвой соединению, необходимо обойти еще и ограничения SOP (same-origin policy, правило ограничения домена). Это важная концепция безопасности для некоторых языков программирования на стороне клиента, таких как JavaScript. Политика разрешает сценариям, находящимся на страницах одного сайта, доступ к методам и свойствам друг друга без ограничений, но предотвращает доступ к большинству методов и свойств для страниц на разных сайтах. Проще говоря, запущенный на одной странице клиент не сможет делать запросы к нужному сайту (скажем, Paypal.com). Чтобы обойти политику SOP, авторы нашли в виртуальной машине Java 0day-уязвимость и написали для нее работающий сплоит. Только не думай, что это позволяет читать существующие кукисы. Если бы это было так, тогда зачем нужен был весь этот сыр-бор с зашифрованным трафиком? Используя сплоит для обхода SOP, можно отправлять запросы и читать ответы сервера (в том числе ответы с новыми кукисами), но нельзя считывать существующие кукисы, которые сохранены в браузере.
Вообще через Java-аплеты и без всяких уязвимостей много лишнего делать можно. Если нашли одну уязвимость на установку кук, могли бы найти и другую на чтение… :-)
Вообще ЧСВ растет даже не с деньгами, а с тем что «вот моя мега игра, в неё играют сотни тысяч», и то, что игра есть самое настоящее говно с целью срубить бабла на мышкокликательных инстинктах хомячков это для большей части участников процесса есть дело десятое. Добро пожаловать в современный гейм-дев.
А мне вот жалко только художников, дизайнеров и моделлеров, за то что их шедевры иной раз попадают в такие отстойные игры, и что каждый проходящий мимо скрипткиддис может лишить их зарплаты из за отсутствия мозгов и совести у того, кто позволяет новичкам писать такие проекты за еду, без присмотра опытных разработчиков.
А я уже давно свалил на Почту для доменов от Яндекса, потому что нельзя было одновременно в обычном аккаунте сидеть и в Google Apps'овом, приходилось пароль всё время вводить… Хотя потом оказалось, что мне G+ и не нужен — кучи непонятных фолловеров, сомнительный функционал кругов. Это по началу думалось, что вот она, гениальная киллер фича с кругами. А на самом деле профита от неё ноль, пишешь или в паблик, или куда-то где уже давно сложился круг общения без G+ (irc, джаббер-конференции, списки рассылки).
> Ведь состояние машины не меняется, как была running, так и остаётся.
У неё есть ещё куча параметров, кроме running. Например uptime. На мой взгляд всё нормально. Конечно REST диктует нам множество правил, но управление довольно детерминированным объектом виртуальной машины обычно укладывается в их рамки. Конечно, в реальном мире иногда приходится эти правила нарушать, но при этом совсем не обязательно скатываться до RPC через HTTP…
DHE это конечно хорошо, его использование действительно не позволяет третьей стороне расшифровать перехваченный траффик
без знаниядаже при наличии секретного ключа сервера.Кстати, не знаю чего они там у себя обновили, но на gmail.com до сих пор RSA-RC4-SHA, без обмена ключами по Диффи-Хеллману. Перехваченную сессию с него можно даже Wireshark'ом расшифровать при наличии секретного ключа сервера. А вот на mail.yandex.ru включается DHE_RSA, и тут уже не всё так просто.
При вашей миграции на гуглаппс вы потеряли наиболее значимый аспект — профит от привлечения студентов к практической работе над проектом.
Вообще через Java-аплеты и без всяких уязвимостей много лишнего делать можно. Если нашли одну уязвимость на установку кук, могли бы найти и другую на чтение… :-)
На большинстве сайтов с https, которыми я регулярно пользуюсь:
Который хоть и является блочным, не должен быть подвержен уязвимости если я правильно понимаю её характер.
> у атакующего должна быть возможность внедрить агент в браузер жертвы
Почему бы ему тогда не стырить куку через этот агент?
Вообще ЧСВ растет даже не с деньгами, а с тем что «вот моя мега игра, в неё играют сотни тысяч», и то, что игра есть самое настоящее говно с целью срубить бабла на мышкокликательных инстинктах хомячков это для большей части участников процесса есть дело десятое. Добро пожаловать в современный гейм-дев.
А мне вот жалко только художников, дизайнеров и моделлеров, за то что их шедевры иной раз попадают в такие отстойные игры, и что каждый проходящий мимо скрипткиддис может лишить их зарплаты из за отсутствия мозгов и совести у того, кто позволяет новичкам писать такие проекты за еду, без присмотра опытных разработчиков.
У неё есть ещё куча параметров, кроме running. Например uptime. На мой взгляд всё нормально. Конечно REST диктует нам множество правил, но управление довольно детерминированным объектом виртуальной машины обычно укладывается в их рамки. Конечно, в реальном мире иногда приходится эти правила нарушать, но при этом совсем не обязательно скатываться до RPC через HTTP…
POST /vm333
reboot
?
Помоему тут всё правильно.