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