Обезличивание шифрованного трафика: Jabber и SSL

Какую уникальную информацию несёт в себе трафик, зашифрованный SSL'ем? Может быть, противник может узнать текущее время не машине пользователя, ведь при шифровании проставляется время (в GnuPG точно так)? Или время всегда идёт в UTC, а потому "уязвимость" актуальна только для протоколов обмена шифрованными сообщениями в реальном времени? Если под браузеры есть какое-никакое решение firefox+torbutton, то что можно сказать о других приложениях, работающих с SSL/TLS, например, jabber-клиентах? Если в jabber-клиенте также включено end-to-end PGP-шиврование сообщений, пишутся ли служебные поля типа версии gpg, операционной системы, времени шифрования? Смутно пропоминается обсуждение на форуме того, что при посещении скрытых сервисов Tor следует избегать https и, якобы, лучше его вообще запретить в браузере под Tor'ом — не из этих же ли соображений?

Насчёт ручного использования GnuPG: если используется опция --no-emit-version, то противник не может узнать ничего в лоб об использованном софте, но по ряду косвенных признаков формата (PGP-пакетов?) может оценить версию gpg. Поправьте, если не прав. Как опцию --no-emit-version прописать статически в конфиге gpg?

Безотносительно проблем, пораждаемых шифрованием, сами jabber-клиенты сообщают о себе слишком много: большая часть – точную версию клиента, часть из них – также и ОС. Есть ли такие клиенты, которые позволяют не афишировать свой тип и среду в которой они работают, или, ещё лучше, предоставлять фейковую информацию, выдавая себя за самый распространённый jabber-клиент в самой распространённой конфигурации и ОС?

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

На страницу: 1, 2, 3, 4 След.

Комментарии

—	*Гость* (06/07/2010 08:03) <#>

На

слайдах (стр. 23) говорится

Some Firefox privacy bugs remain
...
The TLS ClientHello message in FF2 uses uptime for the "time" variable!

Проблема уже решена в torbutton?

—	unknown (06/07/2010 08:50, исправлен 06/07/2010 08:50) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

мощный противник может устроить коллизию, т.е. сделать 2 сайта с одинаковыми onion-адресами?

Да, верно поправили насчёт 80-ти бит.

Изначально предполагалось, что теоретически может, но эта атака непрактична.
Ведь для нахождения второго прообраза под чужой сервис всё равно потребуется 2⁸⁰ попыток.

Для случайной коллизии 2⁴⁰, но ведь это только создаст неприятности когда в сети будет очень много скрытых сервисов и они случайно начнут совпадать по отпечаткам. Кроме того, хэш нужно генерить от сертификата, на создание которого требуется тоже некоторое время, замедляющее подбор.

—	*Гость* (06/07/2010 09:52) <#>

Кроме того, хэш нужно генерить от сертификата, на создание которого требуется тоже некоторое время, замедляющее подбор.

Формат ключа (от него и берётся хэш) строго задан, "крутить" можно только экспоненту (если в результате нужен работающий скрытый сервис). На этом принципе некоторые энтузиасты написали программу для генерации ключей с n-первыми (насколько хватит мощностей и терпения ждать) символами адреса под нужную маску. Впрочем перекрыть такую лазейку тоже можно, разработчики такую мысль тоже высказывали.

—	*Гость* (06/07/2010 10:09) <#>

Проблема уже решена в torbutton?

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

—	*Гость* (10/07/2010 01:24) <#>

В Gajim есть опция запретить показ локального времени на клиентской машине? Знает кто-нибудь?

—	*Гость* (11/07/2010 08:30) <#>

Или psi или gajim (кажется, первое) по умолчанию не отправляет iq:last и iq:time, зато не даёт штатными средствами запретить показ точной версии ОС.

—	*Гость* (27/07/2010 20:47) <#>

gajim все прекрасно прячет
Настройки-расширеные
,.вторая строка,,
Отсылать инф. об ОС (снять галку)

—	*Гость* (27/07/2010 22:21) <#>

Было бы там так же легко с iq:last и iq:time, цены бы не было :)

—	*Гость* (08/06/2011 07:11) <#>

На этом принципе некоторые энтузиасты написали программу для генерации ключей с n-первыми (насколько хватит мощностей и терпения ждать) символами адреса под нужную маску.

Можете дать ссылку на детали/проект?

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

Уже перекрыли, или ещё нет? На чём обсуждение закончилось?

—	*Гость* (17/06/2011 21:07) <#>

Можете дать ссылку на детали/проект?

Архив, Shallot и его предок OnionHash.

Уже перекрыли, или ещё нет? На чём обсуждение закончилось?

Для идентификационных ключей скрытых сервисов ограничивать экспоненту не стали. В настоящее время сервисы с "поддельными" адресами активно функционируют (пример выше) и по всей видимости популярны в обе стороны.
Для всех других ключей тоже не пришли к единому мнению.

—	*Гость* (17/06/2011 21:42) <#>

Shallot жил, жив, и будет жить. А жаль. Костыли совместимости с багофичами прошлого могут больно вдарить в неожиданном будущем.

—	*Гость* (17/06/2011 22:01) <#>

по всей видимости популярны в обе стороны.

"В обе стороны" — это о чём? Не понятно ещё вот что. Допустим, мы намеренно генерим слабые ключи. Наша единственная цель — получить заданный отпечаток ключа. Насколько это ускорит процесс их генерации? По крайней мере нам не нужно находить большие простые числа, получать случайные данные из random и т.д. Вопрос можно поставить в контексте не только "получить 2 onion-адреса с разными ключами" (кстати, как тогда они будут работать, на кого Tor будет редиректить согласно протоколу?), но и в контексте "первые n байт для PGP-ключа совпадают". Ведь неплохое пространство для атаки на ключи... и выдачи себя за кого-то.

—	валерка (19/06/2012 01:26) <#>

люди посоветуйте плиз анонимный джаббер на с самбиан 3

—	*Гость* (19/06/2012 01:34) <#>

Поставь свой сервак и вруби на бомбусе SSL до него через Tor.

—	*Гость* (05/11/2013 12:22) <#>

В конфиге jabber-клиента пишут

# SSL/TLS options:
# TLS is now regarded as the default encryption for connecting to jabber.
# You can require TLS by setting tls to 1.  If your jabber server
# still doesn't support TLS, you can use the old-style SSL by setting
# ssl to 1.  It's not possible to use old-style SSL and TLS together.
#set ssl = 0
set tls = 1
# Moreover, it's possible to check whether the fingerprint of the
# ssl certificate matches ssl_fingerprint.
# You can get the fingerprint of your server either with gnutls or openssl:
# 1. gnutls-cli -p 5223 $your_server
# 2. openssl s_client -connect $your_server:5223 | \
#    openssl x509 -fingerprint -md5 -noout
#set ssl_fingerprint = 97:5C:00:3F:1D:77:45:25:E2:C5:70:EC:83:C8:87:EE
# Set ssl_ignore_checks to 1 to disable all certificate checks except the
# fingerprint check.
#set ssl_ignore_checks = 0

Возникают вопросы:

Что лучше? SSL или TLS?
Почему опции проверки сертификата относятся только к SSL? Разве для TLS эти сверки не нужны?
Откуда взять валидный отпечаток, например, для jabber.ru?

Проверил, что дают предложенные команды:

$ gnutls-cli -p 5223 jabber.ru
Resolving 'jabber.ru'...
Connecting to '84.201.146.161:5223'...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 1023 bits
 - Peer's public key: 1023 bits
- Certificate type: X.509
 - Got a certificate list of 1 certificates.
 - Certificate[0] info:
  - subject `OU=Go to https://www.thawte.com/repository/index.html,
OU=Thawte SSL123 certificate,OU=Domain Validated,CN=jabber.ru', 
issuer `C=US,O=Thawte\, Inc.,OU=Domain Validated SSL,
CN=Thawte DV SSL CA', RSA key 2048 bits, signed using RSA-SHA1, 
activated `2013-02-28 00:00:00 UTC', expires `2015-03-30 23:59:59 UTC', 
SHA-1 fingerprint `b770e0f99c1e5e8ed19e91f07f244c54e0ffb6ac'
- The hostname in the certificate matches 'jabber.ru'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.2
- Key Exchange: DHE-RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed
 
- Simple Client Mode:
 
*** Fatal error: A TLS packet with unexpected length was received.
*** Server has terminated the connection abnormally.

И другая:

$ openssl s_client -connect jabber.ru:5223 | openssl x509 -fingerprint -md5 -noout
depth=0 OU = Go to https://www.thawte.com/repository/index.html, 
OU = Thawte SSL123 certificate, OU =
Domain Validated, CN = jabber.ru
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Go to https://www.thawte.com/repository/index.html, 
OU = Thawte SSL123 certificate, OU =
Domain Validated, CN = jabber.ru
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Go to https://www.thawte.com/repository/index.html, 
OU = Thawte SSL123 certificate, OU =
Domain Validated, CN = jabber.ru
verify error:num=21:unable to verify the first certificate
verify return:1
MD5 Fingerprint=72:81:04:DD:15:D7:6F:FC:6E:B3:20:3A:1A:4D:CA:D6
read:errno=0

Про порт 5223 пишут, что он legacy. Кто-нибудь знает, как дружит jabber.ru с SSL/TLS на конвенциональном порту 5222? Кому не трудно, проверьте, такие же ли у вас отпечатки для сертификатов или нет. Смущают сообщения об ошибках

- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted

verify error:num=20:unable to get local issuer certificate
verify error:num=27:certificate not trusted
verify error:num=21:unable to verify the first certificate

Пока установил себе

set ssl = 1
set ssl_ignore_checks = 0

но прописать отпечаток явным образом было бы не лишним.

P.S. Здесь есть ссылка на статью «The State of TLS on XMPP» (в трёх частях). Там довольно интересная статистика и по клиентам и по серверам. Основной посыл в том, что на практике, оказывается, не всё так хорошо, как в теории (что и следовало ожидать). Ещё есть ссылка с небольшим списком XMPP-серверов, где указано, кем подписаны их сертификаты.

На страницу: 1, 2, 3, 4 След.

Ваша оценка документа [показать результаты]