Jabber

Ar3s

Старожил форума
Легенда
Регистрация
30.12.2004
Сообщения
3 357
Реакции
1 404
ssl.png
На имеющемся у нас сервере dlab.im закончился ssl сертификат. Сегодня было произведено обновление сертификата. Просьба отбросить паранойю, все пучком.
 
SSL в жаббере это конечно хорошо и замечательно, но из открытых библиотек, осталось несколько версий остались без явно выраженных уязвимостей. Так то не только кэш на северере читать можно, но и в вебе имея ноды между енд ту енд точками можно отснифать трафик и в конечном счете расшифровать переписку - сравнимо как расшифровывают ключи вифи при достаточном количестве пойманных пакетов (или даже серт подменить, т.к. у нас то нету контейнеров и валидации сертификатов и серт центров)

TLS заявлен вроде как криптостойкий , при годной длинне ключей может быть будет хорошим решением?

Кто что знает/думает по этому поводу? Наша же безопасность как пользователей, должна беспокоить нас, поэтому прошу отписаться... Среди информации в интернете много воды, нет однозначных решений, может кто то может поделиться чем то полезным...?
 
Адо, по традиции тлс называют сслом (оно так прижилось еще до стандартизации), естественно pem-сертификат в ejabberd использует достаточно секурные длины ключей по умолчанию. Ну, по крайней мере, я б такое брутить не стал:
Код:
# openssl s_client -connect dlab.im:5222 -starttls xmpp
CONNECTED(00000003)
depth=0 C = IM, ST = "damagelab ", L = dlab.im, O = dlab.im, OU = dlab.im, CN = dlab.im email=admin@dlab.im
verify error:num=18:self signed certificate
verify return:1
depth=0 C = IM, ST = "damagelab ", L = dlab.im, O = dlab.im, OU = dlab.im, CN = dlab.im email=admin@dlab.im
verify return:1
---
Certificate chain
 0 s:/C=IM/ST=damagelab /L=dlab.im/O=dlab.im/OU=dlab.im/CN=dlab.im email=admin@dlab.im
   i:/C=IM/ST=damagelab /L=dlab.im/O=dlab.im/OU=dlab.im/CN=dlab.im email=admin@dlab.im
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICyjCCAjOgAwIBAgIJAMnSbx8b1v2GMA0GCSqGSIb3DQEBBQUAMH4xCzAJBgNV
BAYTAklNMRMwEQYDVQQIDApkYW1hZ2VsYWIgMRAwDgYDVQQHDAdkbGFiLmltMRAw
DgYDVQQKDAdkbGFiLmltMRAwDgYDVQQLDAdkbGFiLmltMSQwIgYDVQQDDBtkbGFi
LmltIGVtYWlsPWFkbWluQGRsYWIuaW0wHhcNMTUwNjA4MTQ0ODI5WhcNMTYwNjA3
MTQ0ODI5WjB+MQswCQYDVQQGEwJJTTETMBEGA1UECAwKZGFtYWdlbGFiIDEQMA4G
A1UEBwwHZGxhYi5pbTEQMA4GA1UECgwHZGxhYi5pbTEQMA4GA1UECwwHZGxhYi5p
bTEkMCIGA1UEAwwbZGxhYi5pbSBlbWFpbD1hZG1pbkBkbGFiLmltMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDdBS1VlYFqBwk4B690SZIea4zSY8WumfOeZoet
y1KEyHWKjlr+XOZu/PA2UnpyRKucMkVjP7yLHKNJLVJsUzFcOXQz2UxtE/CSJ4JJ
cC1W8E7XI5nK3hTvFuRm5DlXrwF2FY4PSAWPEDmxYxkI5hWqqOF3QElbjhloN0+Q
zM3Z0QIDAQABo1AwTjAdBgNVHQ4EFgQUqDiHa95396uexeqSQT7Y/V3L8ZgwHwYD
VR0jBBgwFoAUqDiHa95396uexeqSQT7Y/V3L8ZgwDAYDVR0TBAUwAwEB/zANBgkq
hkiG9w0BAQUFAAOBgQAQuh+bNG1aLSiDhTWe/ZkRcXrJASUaaJkCbhghQdjo0Nvy
HuS7ArfD7EeBWjwzvEPpn3chr+NTT9S3/dOwWjmDPWLpgo0c1o2CxWM0R9ZuiQVY
CvOFxNUWXbW5mLb8Y5GNOQ1ji2MfM0mLMeRGRQn26lquX6P7naw/HqlPMub1AA==
-----END CERTIFICATE-----
subject=/C=IM/ST=damagelab /L=dlab.im/O=dlab.im/OU=dlab.im/CN=dlab.im email=admin@dlab.im
issuer=/C=IM/ST=damagelab /L=dlab.im/O=dlab.im/OU=dlab.im/CN=dlab.im email=admin@dlab.im
---
No client certificate CA names sent
---
SSL handshake has read 1729 bytes and written 584 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 403786AE5A70FD347146788B1A0945E808603942BA67C7B0CEAC8DC430C50B8F7203204846E3D84D8EB0FA98D8CEACC2
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1433955785
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
DONE
 
Думаю для тех кто может использовать ноды у провайдеров/хостеров -им брутить не надо, валидации ключей нету, достаточно быть посредником и автоматом принимать и передавать ключи, расшифровывая ее, зашифровывая на лету - логируя открытую переписку...
+ в самых используемых библиотеках могут быть уязимости не только с произвольным чтением данных...

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

Конечный ключ может и стойкий однако кроме ключа есть еще несколько векторов для атак, связанных с созданием ключа, библиотек его использующих, да на конец даже сам джаббер протокол и хост его размещающий, а качественно стойкий ключ еще не панацея, у больших корпов и организаций наверняка есть мощности для работы и щелканьем таких ключей если не на лету, то хотя бы за время...
 
PGP и только.
Сам otr уязвим к mitm атаке, конечно если пользователи совсем невнимательны( проверка отпечатка fingerprint ).

Упоминал уже о протоколе: https://xss.pro/index.php?topic=2...49&#entry144049

Пока jabber всех устраивает, до первой массовой атаки я думаю ;)
 
от знакомого сисадмина слышал, что россиянский СОРМ на лету расшифровывает ССЛ, каким образом он говорить не стал :) интересно, на сколько это правда?
 
так же как и делают антивирусы, перехватываются два сертефиката по середине, скажем на провайдере. а клиентам и серверам раздаются свои сгенеренные. И все. Трафик внутри раскрыт. Другое дело умеет ли это сорм и на сколько он это применяет.
 
аа ну так это я знал, думал может как то по другому бывает) а как, например, утилита для расшифровки https трафика на лету под названием sslstrip работает? по такому же принципу?)
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх