практическая анонимность TOR и отпечатки клиентской системы
Тема[link1] натолкнула меня на мысль о возможности вычисления пользователя сети TOR.
Я не очень разбираюсь в тонкостях протокола SSL, но очевидно, что этот протокол может и не предусматривать сокрытие открытых ключей клиента, а лишь их защиту от MITM. В таком случае применение одного и того же открытого ключа клиента может говорить администратору SSL сайта об активности одного и того же пользователя. Также в таком случае может быть представляется возможным для администраторов конечных узлов TOR определить отпечаток клиентской машины на основе ее открытого ключа, если этот ключ передается открытым текстом. Можно применять сеансовые открытые ключи для разных сайтов и даже одного сайта, но в таком случае появится проблема атаки на энтропию ключа и системный генератор случайных чисел.
Вслучае, если в SSL не применяется открытый ключ клиента, а лишь сеансовый ключ, скрытый открытым ключом сайта, возможен вариант определения отпечатка клиента, если удастся персонифицировать клиента по применяемому им генератору случайных чисел. Проблема также осложняется тем, что гсч может быть привязан к mac адресу сетевой карты и другим источникам энтропии.
При установке сертификата в браузер, сеансовый ключ может генерироваться лишь единожды, если это не обсуждается в протоколе.
Все вышеперечисленное касается и SSH, и других протоколов. Это может касаться даже особенностей реализации гсч в Java Script.
С другой стороны, нам неведомы все возможности по персонифицированию клиентской машины. Они могут быть сокрыты даже в производительности компьютера (характеристикам системы команд, длиной кеша и т.п.).
Учитывая пока что не такую уж популярность проекта TOR, для администратора конкретного сайта может не составить труда вычислить конкретного пользователя его ресурса, пользующегося TOR.
Скорее всего на данном этапе TOR годится лишь для сокрытия реального IP адреса, или для посещения сайтов не слишком замороченных админов. Но для администраторов liveinternet.ru это может быть не сложным.
Все это предназначено для обсуждения и обмысливания.
Клиентские сертификаты, аутентифицируют клиентов банков, платёжных систем и т.д. И этот сертификат пользователь должен получить и установить в браузер вручную.
При создании SSL-сессии с обычным сайтом никаких клиентских сертификатов не используется. Браузер пользователя проверяет подпись только данных сесси, заверенных сертификатов сайта, который себя тем самым аутентифицирует.
Пользователь перед сайтом по умолчанию не аутентифицирует себя никак. После проверки подлинности сайта, между ними происходит выработка совместного сеансового ключа через протокол Диффи-Хэллмана, от пользователя при этом отсылаются только случайные параметры, но никаких ключей или постоянных данных.
Иными словами, все данные со стороны пользователя для ассиметричного крипто генерируются из случайного числа в момент соединения с сайтом.
Если кто-то использует ГПСЧ, выход которого можно просто отличить от случайных данных (а тем более догадаться по его данным к типу привязки), то SSL-сессии пользователя с таким генератором можно было бы взламывать.
Речь шла бы о нестойком генераторе, который не удовлетворял бы принципу PFS (Perfect Forward Secrecy). Никто в нормальных программах такое делать не будет.
Это точная информация? Я реализовывал в своей программе алгоритм Диффи-Хэлмана[link2]. Если я ничего не путаю, этот протокол описывает алгоритм генерации секретного ключа на основе обмена открытыми ключами! Это не то же самое, что сгенерировать случайный сеансовый ключ и передать его в зашифрованном виде с помощью одностороннего открытого ключа.
Ну да, так стороны и генерируют только случайные числа a и b – это не ключи.
Передают их после возведения в их степень генератора (первообразного корня) по модулю p. И обмениваются числами в виде степеней по модулю. Опять же, это и не рассматривается как асимметричные ключи.
И получают совместный ключ K=gab mod p, потому что одна сторона знает чему равно присланное ga mod p и своё b, а другая знает чему равно присланное gb mod p и своё a.
Вот они и перемножают каждый со своей стороны по модулю и получают одно и тоже.
Хэшированием (лучше использованием специальной Key Derivation Function – KDF из общего значения K получают симметричный ключ.
Все остальные параметры или фиксированы стандартом и реализацией или могут быть заверены сайтом, он же подписывает свой запрос ga mod p. И что тут не так?
В ваших утверждениях верно то, что открытые ключи протокола Диффи-Хэллман сами по себе, а асимметричные ключи RSA сами по себе. В остальном может быть много нюансов. Например, нюанс: для ускорения на Web сервере числа для Диффи-Хэллман могут генерироваться реже, чем для каждой сессии. Для клиента это ничего не меняет. Точно также случайные числа на клиенте тоже могут генерироваться не для каждой сессии. Потому что разве это что-то меняет, кроме анонимности? :)
По конкретике: тут нужно смотреть как реализацию библиотек OpenSSL, так и использование ее функций на браузере. Кстати, OpenSSL библиотеки используются в реализациях SSH и прочих туннелях, а это означает что механизм ротации ключей вынесен в отдельные функции.
Если бы параметры можно было оставлять, то возможны были бы replay-атаки (повторная отправка данных), что может привести по крайней мере к отказу в обслуживании.
А вообще для этого пишут стандарты, которым стараются следовать большинство нормальных реализаций:
http://www.ietf.org/rfc/rfc2246.txt
И вот еще http://sysoev.ru/nginx/docs/ht.....ml#ssl_session_cache[link3]
Интересно, но вроде если сессия начинается заново, то и handshake идёт по новой. В крайнем случае можно браузер перезапустить.
Если неохота копаться в исходниках, можно разобрать SSL-соединение через сниффер (например tcpdump или tethereal/wireshark – там пакеты с handshake или продолжением сессии разбираются по заголовкам).
unknown, наверное вы правы. Слишком глаза затмевает желание защищать свой огород :))