id: Гость   вход   регистрация
текущее время 23:39 28/03/2024
Автор темы: Мухтар, тема открыта 05/11/2008 13:12 Печать
Категории: криптография, софт, анонимность, случайные числа, tor, эцп, стандарты, ssl
https://www.pgpru.com/Форум/АнонимностьВИнтернет/ПрактическаяАнонимностьTORИОтпечаткиКлиентскойСистемы
создать
просмотр
ссылки

практическая анонимность TOR и отпечатки клиентской системы


Тема натолкнула меня на мысль о возможности вычисления пользователя сети TOR.


Я не очень разбираюсь в тонкостях протокола SSL, но очевидно, что этот протокол может и не предусматривать сокрытие открытых ключей клиента, а лишь их защиту от MITM. В таком случае применение одного и того же открытого ключа клиента может говорить администратору SSL сайта об активности одного и того же пользователя. Также в таком случае может быть представляется возможным для администраторов конечных узлов TOR определить отпечаток клиентской машины на основе ее открытого ключа, если этот ключ передается открытым текстом. Можно применять сеансовые открытые ключи для разных сайтов и даже одного сайта, но в таком случае появится проблема атаки на энтропию ключа и системный генератор случайных чисел.


Вслучае, если в SSL не применяется открытый ключ клиента, а лишь сеансовый ключ, скрытый открытым ключом сайта, возможен вариант определения отпечатка клиента, если удастся персонифицировать клиента по применяемому им генератору случайных чисел. Проблема также осложняется тем, что гсч может быть привязан к mac адресу сетевой карты и другим источникам энтропии.


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


Все вышеперечисленное касается и SSH, и других протоколов. Это может касаться даже особенностей реализации гсч в Java Script.


С другой стороны, нам неведомы все возможности по персонифицированию клиентской машины. Они могут быть сокрыты даже в производительности компьютера (характеристикам системы команд, длиной кеша и т.п.).


Учитывая пока что не такую уж популярность проекта TOR, для администратора конкретного сайта может не составить труда вычислить конкретного пользователя его ресурса, пользующегося TOR.


Скорее всего на данном этапе TOR годится лишь для сокрытия реального IP адреса, или для посещения сайтов не слишком замороченных админов. Но для администраторов liveinternet.ru это может быть не сложным.


Все это предназначено для обсуждения и обмысливания.


 
Комментарии
— unknown (05/11/2008 14:32, исправлен 05/11/2008 14:35)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Клиентские сертификаты, аутентифицируют клиентов банков, платёжных систем и т.д. И этот сертификат пользователь должен получить и установить в браузер вручную.

При создании SSL-сессии с обычным сайтом никаких клиентских сертификатов не используется. Браузер пользователя проверяет подпись только данных сесси, заверенных сертификатов сайта, который себя тем самым аутентифицирует.

Пользователь перед сайтом по умолчанию не аутентифицирует себя никак. После проверки подлинности сайта, между ними происходит выработка совместного сеансового ключа через протокол Диффи-Хэллмана, от пользователя при этом отсылаются только случайные параметры, но никаких ключей или постоянных данных.

Иными словами, все данные со стороны пользователя для ассиметричного крипто генерируются из случайного числа в момент соединения с сайтом.
— unknown (05/11/2008 14:41)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Вслучае, если в SSL не применяется открытый ключ клиента, а лишь сеансовый ключ, скрытый открытым ключом сайта, возможен вариант определения отпечатка клиента, если удастся персонифицировать клиента по применяемому им генератору случайных чисел. Проблема также осложняется тем, что гсч может быть привязан к mac адресу сетевой карты и другим источникам энтропии


Если кто-то использует ГПСЧ, выход которого можно просто отличить от случайных данных (а тем более догадаться по его данным к типу привязки), то SSL-сессии пользователя с таким генератором можно было бы взламывать.
Речь шла бы о нестойком генераторе, который не удовлетворял бы принципу PFS (Perfect Forward Secrecy). Никто в нормальных программах такое делать не будет.
— Мухтар (05/11/2008 15:20)   профиль/связь   <#>
комментариев: 155   документов: 20   редакций: 5
выработка совместного сеансового ключа через протокол Диффи-Хэллмана

Это точная информация? Я реализовывал в своей программе алгоритм Диффи-Хэлмана. Если я ничего не путаю, этот протокол описывает алгоритм генерации секретного ключа на основе обмена открытыми ключами! Это не то же самое, что сгенерировать случайный сеансовый ключ и передать его в зашифрованном виде с помощью одностороннего открытого ключа.

SSL uses certificates, private/public key exchange pairs and Diffie-Hellman key agreements to provide privacy (key exchange)

Key Agreement – both parties generate a shared symmetric key usually using the Diffie-Hellman algorithm in conjunction with DES (40-bit key) or 3-DES (128-bit key). Parameters used to generate the shared key are exchanged between the client and server.

— unknown (05/11/2008 16:04, исправлен 05/11/2008 16:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Ну да, так стороны и генерируют только случайные числа a и b – это не ключи.

Передают их после возведения в их степень генератора (первообразного корня) по модулю p. И обмениваются числами в виде степеней по модулю. Опять же, это и не рассматривается как асимметричные ключи.

И получают совместный ключ K=gab mod p, потому что одна сторона знает чему равно присланное ga mod p и своё b, а другая знает чему равно присланное gb mod p и своё a.

Вот они и перемножают каждый со своей стороны по модулю и получают одно и тоже.

Хэшированием (лучше использованием специальной Key Derivation Function – KDF из общего значения K получают симметричный ключ.

Все остальные параметры или фиксированы стандартом и реализацией или могут быть заверены сайтом, он же подписывает свой запрос ga mod p. И что тут не так?
— Мухтар (05/11/2008 17:05)   профиль/связь   <#>
комментариев: 155   документов: 20   редакций: 5
В ваших утверждениях верно то, что открытые ключи протокола Диффи-Хэллман сами по себе, а асимметричные ключи RSA сами по себе. В остальном может быть много нюансов. Например, нюанс: для ускорения на Web сервере числа для Диффи-Хэллман могут генерироваться реже, чем для каждой сессии. Для клиента это ничего не меняет. Точно также случайные числа на клиенте тоже могут генерироваться не для каждой сессии. Потому что разве это что-то меняет, кроме анонимности? :)

По конкретике: тут нужно смотреть как реализацию библиотек OpenSSL, так и использование ее функций на браузере. Кстати, OpenSSL библиотеки используются в реализациях SSH и прочих туннелях, а это означает что механизм ротации ключей вынесен в отдельные функции.
— unknown (05/11/2008 17:46)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Если бы параметры можно было оставлять, то возможны были бы replay-атаки (повторная отправка данных), что может привести по крайней мере к отказу в обслуживании.

А вообще для этого пишут стандарты, которым стараются следовать большинство нормальных реализаций:
http://www.ietf.org/rfc/rfc2246.txt
— Мухтар (05/11/2008 17:59, исправлен 05/11/2008 18:49)   профиль/связь   <#>
комментариев: 155   документов: 20   редакций: 5
F.1.1. Authentication and key exchange

TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and
total anonymity. Whenever the server is authenticated, the channel is
secure against man-in-the-middle attacks, but completely anonymous
sessions are inherently vulnerable to such attacks. Anonymous
servers cannot authenticate clients. If the server is authenticated,
its certificate message must provide a valid certificate chain
leading to an acceptable certificate authority. Similarly,
authenticated clients must supply an acceptable certificate to the
server. Each party is responsible for verifying that the other's
certificate is valid and has not expired or been revoked.

The general goal of the key exchange process is to create a
pre_master_secret known to the communicating parties and not to
attackers. The pre_master_secret will be used to generate the
master_secret (see Section 8.1). The master_secret is required to
generate the certificate verify and finished messages, encryption
keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending
a correct finished message, parties thus prove that they know the
correct pre_master_secret.

F.1.1.1. Anonymous key exchange

Completely anonymous sessions can be established using RSA or
Diffie-Hellman for key exchange. With anonymous RSA, the client
encrypts a pre_master_secret with the server's uncertified public key

If the server is authenticated, it may request a certificate from the
client, if that is appropriate to the cipher suite selected. Now the
server will send the server hello done message, indicating that the
hello-message phase of the handshake is complete. The server will
then wait for a client response. If the server has sent a certificate
request message, the client must send the certificate message. The
client key exchange message is now sent, and the content of that
message will depend on the public key algorithm selected between the
client hello and the server hello. If the client has sent a
certificate with signing ability, a digitally-signed certificate
verify message is sent to explicitly verify the certificate.

F.1.4. Resuming sessions

When a connection is established by resuming a session, new
ClientHello.random and ServerHello.random values are hashed with the
session's master_secret. Provided that the master_secret has not been
compromised and that the secure hash operations used to produce the
encryption keys and MAC secrets are secure, the connection should be
secure and effectively independent from previous connections.
Attackers cannot use known encryption keys or MAC secrets to
compromise the master_secret without breaking the secure hash
operations (which use both SHA and MD5).

Sessions cannot be resumed unless both the client and server agree.
If either party suspects that the session may have been compromised,
or that certificates may have expired or been revoked, it should
force a full handshake. An upper limit of 24 hours is suggested for
session ID lifetimes, since an attacker who obtains a master_secret
may be able to impersonate the compromised party until the
corresponding session ID is retired. Applications that may be run in
relatively insecure environments should not write session IDs to
stable storage.


И вот еще http://sysoev.ru/nginx/docs/ht.....ml#ssl_session_cache
— unknown (06/11/2008 08:54)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Интересно, но вроде если сессия начинается заново, то и handshake идёт по новой. В крайнем случае можно браузер перезапустить.

Если неохота копаться в исходниках, можно разобрать SSL-соединение через сниффер (например tcpdump или tethereal/wireshark – там пакеты с handshake или продолжением сессии разбираются по заголовкам).
— Мухтар (18/11/2008 10:23)   профиль/связь   <#>
комментариев: 155   документов: 20   редакций: 5
unknown, наверное вы правы. Слишком глаза затмевает желание защищать свой огород :))
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3