У меня давно есть инвайт (хоть я почти ничего и не писал), и я не знал, что read-only подразумевает даже отутствие возможности комментировать. Ну тогда я бы им багу на гитхабе открыл в официальном репозитории, чтобы какой-то след остался :) Впрочем, это всё не важно, я снова занудствую.
Справедливости ради, стоит отметить, что я бы на месте aabc сразу дал бы комментарий сюда для пруфов, а потом уже бы ждал премодерации. А твит Taylor Hornby вообще бесполезный (сам по себе, а так-то вас на правильный путь могло и яблоко, упавшее с дерева, натолкнуть — это же не повод его награждать) и про другое. Так что лучше на двоих, чем на троих, по поводу aabc — согласен.
Это странно, потому что фикс появился не глубоко ночью, когда был коммит «update to 1.3.4» а только недавно. А где эта проблема была описана в твиттере? И почему этим ребятам из твиттера не достанется приз?
А, ну да, ещё сейчас в андроид-версии клиента длина p проверяется только с точностью до байт (исходя из того, что 256 * 8 = 2048, есть сравнение с 256). Таким образом, сервер может ещё и выслать p чуть короче (скажем, 2041 бит), а потом в качестве g_a (или g_b) присылать не только 0 и само p, но и некоторое количество нетривиальных кратных p (где-то 2^7 — 1 вариант). И то если длина g_a_or_b тоже проверяется, в чём я не уверен :) Но это уже совсем мелочь в рамках того же бага про нулевой результат для секретного ключа.
Есть ещё одна «закладка» для MITM (по крайней мере, в андроидовском клиенте она, вроде, есть, и в документации к протоколу о проверках, необходимых для её избежания, не говорится):
Сервер может даже в исправленной версии Диффи-Хелмана (без nonce) подсунуть клиентам в качестве g_a (или g_b) число, являющееся нулём по модулю p (поскольку документация говорит о 2048-битной последовательности — это может быть либо 0, либо само p). Тогда оба клиента увидят одинаковый identicon («визуализацию ключа», она будет являться представлением SHA1 от нуля).
Однако, судя по дальнейшим манипуляциям с ключом, домножения на ноль с клиентскими сообщениями не случится и они будут гоняться через «голый» AES (а значит, пользователи будут думать, что всё нормально и смогут передавать секретные данные в таком режиме). Причём, так их сможет подслушать не только сервер, но и внешний наблюдатель, который прознает про то, что сервер так себя повёл!
P. S.: Поправьте меня, если я что-то пропустил. Да, случай вырожденный, но, всё-таки, формально он от авторского отличается не сильно (как минимум, нужны фиксы в клиенте). Или я, всё-таки, где-то ошибся?
Принципиальный момент заключается в том, что у электромотора не может быть «рабочего объёма». А лошади у него есть. Их бы, скорее всего, государство смогло учесть, если бы от них растаможка была. К примеру, у некоторых в ПТС попадает сумма мощностей и уже ежегодный транспортный налог (а не растаможка) считается с учётом этой суммы.
Каких ещё бензиновых лошадей? Что за бред? А дизель? На самом деле, после 3 лет растаможка считается от рабочего объёма двигателя. Что не применимо к электромобилям, это да.
Пруф: habrahabr.ru/post/206900/#comment_7130934
Сервер может даже в исправленной версии Диффи-Хелмана (без nonce) подсунуть клиентам в качестве g_a (или g_b) число, являющееся нулём по модулю p (поскольку документация говорит о 2048-битной последовательности — это может быть либо 0, либо само p). Тогда оба клиента увидят одинаковый identicon («визуализацию ключа», она будет являться представлением SHA1 от нуля).
Однако, судя по дальнейшим манипуляциям с ключом, домножения на ноль с клиентскими сообщениями не случится и они будут гоняться через «голый» AES (а значит, пользователи будут думать, что всё нормально и смогут передавать секретные данные в таком режиме). Причём, так их сможет подслушать не только сервер, но и внешний наблюдатель, который прознает про то, что сервер так себя повёл!
P. S.: Поправьте меня, если я что-то пропустил. Да, случай вырожденный, но, всё-таки, формально он от авторского отличается не сильно (как минимум, нужны фиксы в клиенте). Или я, всё-таки, где-то ошибся?