Автор Тема: DrWEB 11 и проверка шифрованного трафика  (Прочитано 2930 раз)

Оффлайн R00tico

  • Участник
  • *
  • Сообщений: 23
В новой версии DrWEB появилась возможность проверять шифрованный трафик (https сайты).
Проверка шифрованного трафика на KDesktop 7.0.5 64бит и Simply Linux 7.0.5 64бит не работает.
Сделал запрос в DrWEB - http://forum.drweb.com/index.php?showtopic=325254

Проблема скорее всего в том, что путь где у вас в системе лежат доверенные корневые сертификаты отличается от того, что прописано в GateD.CaDir.
Нужно поправить параметр GateD.CaDir. У вас это наверное какой-нибудь /etc/pki/tls/certs.

Подскажите, где в Альте лежат доверенные корневые сертификаты?

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 378
Что-то тут где-то не то написано. Каким образом корневые сертификаты могут помочь его декодировать ? Предполагается, что кто угодно по дороге может взять, и посмотреть вовнутрь https ? Нет, так можно. Это называется MITM, но как-то оно того...

Оффлайн yaleks

  • Мастер
  • ***
  • Сообщений: 6 244
Что-то тут где-то не то написано. Каким образом корневые сертификаты могут помочь его декодировать ? Предполагается, что кто угодно по дороге может взять, и посмотреть вовнутрь https ? Нет, так можно. Это называется MITM, но как-то оно того...
видимо так и происходит, а утилиты drweb умеют добавлять свой сертификат в доверенные. Но не всегда работает.
В альте /usr/share/ca-certificates

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

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 566
А у него нет иного способа проверить трафик как встать между сайтом и браузером :-)
Давным-давно Касперский виндузовый имел точно такую же опцию проверки https.

ИМХО лучшая защита от интернет угроз это palemoon/firefox с noscript и adblock запущенные в контейнере. Например в docker. И степень изоляции уже более менее достаточная и ресурсов не так много кушает как виртуалка.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 378
А у него нет иного способа проверить трафик как встать между сайтом и браузером :-)
Давным-давно Касперский виндузовый имел точно такую же опцию проверки https.
А ну как они свой сертификат сольют случайно (или не очень) ? Интересно, как им такой сертификат выдали вообще... Сейчас вот, со всякими запрет-инфо, можно ждать проблем на госуровне в этом плане, но как эти-то успели ?..

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 566
А они его себе сами выдали :-)
Имя получателя
C (Страна): RU
L (Местность): Moscow
O (Организация): DrWeb
OU (Подразделение): SpIDer Gate
CN (Общее имя): SpIDer Gate Trusted Root Certificate
Имя выдающего
C (Страна): RU
L (Местность): Moscow
O (Организация): DrWeb
OU (Подразделение): SpIDer Gate
CN (Общее имя): SpIDer Gate Trusted Root Certificate

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 378
А они его себе сами выдали :-)
А они аккридитованным центром стали ? Ну, приехали тогда. :-)

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 566
Не, не стали. Поэтому просят пользователя самого прописать их сертификат в нужное место :-)
Ну как тот самый олбанский вирус :-)
Цитировать
Для правильной работы механизма проверки трафика, передаваемого через защищенные сетевые соединения, необходимо выполнить экспорт в файл сертификата Dr.Web, который в дальнейшем необходимо вручную добавить в перечни доверенных сертификатов приложений, использующих защищенные соединения. В первую очередь это веб-браузеры и почтовые клиенты.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 378
Цитировать
Для правильной работы механизма проверки трафика, передаваемого через защищенные сетевые соединения, необходимо выполнить экспорт в файл сертификата Dr.Web, который в дальнейшем необходимо вручную добавить в перечни доверенных сертификатов приложений, использующих защищенные соединения. В первую очередь это веб-браузеры и почтовые клиенты.

А, речь про локальную проверку, а не про прозрачный прокси какой-то ? Тогда нормально. Это уже свой MITM. :-)

Оффлайн yaleks

  • Мастер
  • ***
  • Сообщений: 6 244
А, речь про локальную проверку, а не про прозрачный прокси какой-то ? Тогда нормально. Это уже свой MITM. :-)
Ну а что мешает это на машинку с прокси-сервером поставить?

Оффлайн ASte

  • Мастер
  • ***
  • Сообщений: 1 566
да речь про локальную проверку на рабочей станции.
если поставите на proxy, то на клиенте браузер ругнется. если ему конечно не подсовывать этот сертификат в доверенные.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 378
А, речь про локальную проверку, а не про прозрачный прокси какой-то ? Тогда нормально. Это уже свой MITM. :-)
Ну а что мешает это на машинку с прокси-сервером поставить?
Потому, как браузер - это конечный клиент. По факту, в общем-то, уже и не MITM. А на такой прокси браузер-то и ругнуться должен, как раз. Если только не совсем везде этот сертификат разложить.

Оффлайн R00tico

  • Участник
  • *
  • Сообщений: 23
Решение найдено:
su -
drweb-ctl cfset GateD.CaDir /usr/share/ca-certificates/ca-bundle.crt

После этого проверка защищенных соединений в FireFox заработала
В следующих обновлениях обещали пофиксить - http://forum.drweb.com/index.php?showtopic=325254