67 ответов в этой теме

[Raven301]

Добрый день! Наблюдаю следующего рода проблему в Dr.Web Security Space: при включенном сканировании HTTPS обрывается доступ на ресурс https://www.fandom.com/и его тематические подразделы - выкидывает ошибку сертификата во всех браузерах, при этом алерта от самого антивируса вроде блокировки модулем SpIDer Gate - не появляется. Внесение ресурса в исключения SpIDer Gate не помогает. Если отключить сканирование HTTPS в настройках - доступ на ресурс появляется. Стало быть, проблема в совместимости промежуточного сертификата Dr.Web с обозначенным веб-ресурсом.

Аналогично с Rockstar Games Launcher - если запустить игру GTA V - на стартовом экране игры ошибка входа аккаунта в сеть, ссылается на отсутствие доступа к сети. Если вносить исключения в брандмауэр для программы или вообще выключить его - не помогает. Как и в предыдущем случае - помогает только отключение сканирования SSL.

Сразу скажу, пробовал и в браузеры, и в Rockstar Games Launcher импортировать сертификат вручную - проблему это не решило.

[VVS]

Молодцы указанные Вами ресурсы, борются с атакой типа MITM.

Побольше бы таких.

[Raven301]

Молодцы указанные Вами ресурсы, борются с атакой типа MITM.

Побольше бы таких.

Решения, так полагаю, нет?

Отключить проверку SSL насовсем - не вариант, т.к. по сути это сводит на нет веб-фильтрацию.

[VVS]

Я думаю, что решение заключается в внесении в исключения SpIDer Gate приложения, которое ходит на этот ресурс.

[ant76]

Молодцы указанные Вами ресурсы, борются с атакой типа MITM.

Побольше бы таких.

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

Сообщение было изменено ant76: 16 Июнь 2024 - 21:02

[Raven301]

Я думаю, что решение заключается в внесении в исключения SpIDer Gate приложения, которое ходит на этот ресурс.

Как уже писал выше - делал так: GTAV.exe, файлы Rockstar Games Launcher и Epic Games Launcher исключал - не помогает. А по поводу доступа на fandom - это получается, браузеры заносить в исключения веб защиты?

[VVS]

 

Молодцы указанные Вами ресурсы, борются с атакой типа MITM.

Побольше бы таких.

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

Ещё раз повторяю для людей, имеющих эквивалентную Вашей квалификацию - использование своего сертификата посередине между источником и получателем информации является нарушением секурности.

И честь и хвала тем ресурсам, которые борются с этим.
 

[VVS]

 

Я думаю, что решение заключается в внесении в исключения SpIDer Gate приложения, которое ходит на этот ресурс.

Как уже писал выше - делал так: GTAV.exe, файлы Rockstar Games Launcher и Epic Games Launcher исключал - не помогает. А по поводу доступа на fandom - это получается, браузеры заносить в исключения веб защиты?

Выше Вы писали: "Внесение ресурса в исключения SpIDer Gate не помогает".
Про внесение в исключения приложений Вы ничего не писали, так что уточните, пожалуйста, что и как Вы делали на примере браузера.

[basid]

Молодцы указанные Вами ресурсы, борются с атакой типа MITM.

Побольше бы таких.

Тупо форсят (неподдерживаемый) TLSv1.3:

* Connected to www.fandom.com (199.232.208.194) port 443
* ALPN: curl offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / [blank] / UNDEF

[Raven301]

Выше Вы писали: "Внесение ресурса в исключения SpIDer Gate не помогает".
Про внесение в исключения приложений Вы ничего не писали, так что уточните, пожалуйста, что и как Вы делали на примере браузера.

Да, описал только внесения всех разрешающих правил в брандмауэр, тут не договорил про внесение в исключения SpIDer Gate, сорян. И это для приложений Rockstar делал - бестолку, только отключение сканирования SSL помогает. А на примере браузера - вносил домен fandom.com в исключения SpIDer Gate - не помогло. Браузер не вносил в исключения - а зачем? Это же лишит веб-фильтрации при заходе по ссылкам через него.

Отмечу, что на других двух ПК стоят антивирусы двух других вендоров так же с функцией сканирования SSL с внедрением промежуточного сертификата в трафик (и нет, не Kaspersky) - доступ на fandom подобным образом не обрубается, например. 

[VVS]

 

Выше Вы писали: "Внесение ресурса в исключения SpIDer Gate не помогает".
Про внесение в исключения приложений Вы ничего не писали, так что уточните, пожалуйста, что и как Вы делали на примере браузера.

Да, описал только внесения всех разрешающих правил в брандмауэр, тут не договорил про внесение в исключения SpIDer Gate, сорян.

Брандмауэр к делу отношения не имеет.
 

И это для приложений Rockstar делал - бестолку, только отключение сканирования SSL помогает. А на примере браузера - вносил домен fandom.com в исключения SpIDer Gate - не помогло.

Это тоже к делу отношения не имеет.
 

Браузер не вносил в исключения - а зачем? Это же лишит веб-фильтрации при заходе по ссылкам через него.

Нет, не лишит, если правильно настроить.
Вы в эти настройки заходили, смотрели, что там настраивается?

[Raven301]

Нет, не лишит, если правильно настроить.
Вы в эти настройки заходили, смотрели, что там настраивается?

Если только так. Прописал - заработало. Одна беда - такое же нужно для всех браузеров. https://ibb.co/165KFb7

[ant76]

 

 

Молодцы указанные Вами ресурсы, борются с атакой типа MITM.

Побольше бы таких.

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

Ещё раз повторяю для людей, имеющих эквивалентную Вашей квалификацию - использование своего сертификата посередине между источником и получателем информации является нарушением секурности.

И честь и хвала тем ресурсам, которые борются с этим.
 

 

Еще раз напишу почему на Касперского с его MITM данный ресурс не ругается??? У меня в Касперском MITM включен тоже (проверка зашифрованного трафика, на том ресурсе в браузере отображает что используется сертификат Касперского, что и должно быть при MITM).

[ant76]

 

Выше Вы писали: "Внесение ресурса в исключения SpIDer Gate не помогает".
Про внесение в исключения приложений Вы ничего не писали, так что уточните, пожалуйста, что и как Вы делали на примере браузера.

Да, описал только внесения всех разрешающих правил в брандмауэр, тут не договорил про внесение в исключения SpIDer Gate, сорян. И это для приложений Rockstar делал - бестолку, только отключение сканирования SSL помогает. А на примере браузера - вносил домен fandom.com в исключения SpIDer Gate - не помогло. Браузер не вносил в исключения - а зачем? Это же лишит веб-фильтрации при заходе по ссылкам через него.

Отмечу, что на других двух ПК стоят антивирусы двух других вендоров так же с функцией сканирования SSL с внедрением промежуточного сертификата в трафик (и нет, не Kaspersky) - доступ на fandom подобным образом не обрубается, например. 

 

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

[ant76]

 

Молодцы указанные Вами ресурсы, борются с атакой типа MITM.

Побольше бы таких.

Тупо форсят (неподдерживаемый) TLSv1.3:

* Connected to www.fandom.com (199.232.208.194) port 443
* ALPN: curl offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / [blank] / UNDEF

Вот видимо в этом и проблема, видимо Dr. Web не поддерживает TLS 1.3, другие вендоры поддерживают. Тоже самое и с протоколом HTTP/2, HTTP/3. Но опять .... "зачем вам это надо, это всё ваши хотелки".

[ant76]

 

 

Молодцы указанные Вами ресурсы, борются с атакой типа MITM.

Побольше бы таких.

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

Ещё раз повторяю для людей, имеющих эквивалентную Вашей квалификацию - использование своего сертификата посередине между источником и получателем информации является нарушением секурности.

И честь и хвала тем ресурсам, которые борются с этим.
 

 

Человек проверил с другими вендорами, там при нарушении "секурности" сайт никак не реагирует, с Касперским при нарушении "секурности" сайт тоже молчит на нарушение "секурности". "для людей, имеющих эквивалентную Вашей квалификацию"  получается что веб сервер на котором размещается веб ресурс умеет определять вендора и при определении Dr. Web начинает ругаться на нарушение "секурности", так что ли??????

Сообщение было изменено ant76: 17 Июнь 2024 - 07:02

[Alexander007]

VVS, Доброе утро . Я, вот не нашел в Настройках , две варианта : По умолчанию “Полное отключение проверки SSL” и ”Проверить SSL” - она в функции отсутствуют, насколько знаю она доступна в ES , но не все .
Наш работники сидят на Security Space, в итоги тоже жалуются на это . Несколько человеков хотят нормально поиграться ..

Сообщение было изменено Alexander007: 17 Июнь 2024 - 08:03

[basid]

Ещё раз повторяю для людей, имеющих эквивалентную Вашей квалификацию - использование своего сертификата посередине между источником и получателем информации является нарушением секурности.

И честь и хвала тем ресурсам, которые борются с этим.

В данном конкретном вопросе - категорически несогласен.

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

 

С другой стороны, лично я, вообще не намерен доверять владельцам серверов и (вполне обоснованно) желаю проверять весь трафик или "на конечном узле" ("у себя") или "на доверенном промежуточном узле" ("в организации"). Моё недоверие к владельцам серверов основано на том простом факте, что "паранойя шифрования" служит сугубо бизнес-целям: защита рекламного трафика и собираемых персональных данных от ("бесплатного") доступа третьих лиц (интернет-провайдеров - в первую очередь). А ещё сервер может стать источником заражения в результате халатности его владельцев или из-за целенаправленной атаки.

 

Чтобы понимать, какие деньги крутятся в этом бизнесе - достаточно вспомнить о капитализации гугла и периодических (регулярных) инцидентах взлома отдельных серверов или целых сегментов инфраструктуры.

 

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

 

P.S.

Мне, конечно, хотелось бы менее ресурсоёмкого механизма, чем "перешифровка" и, в принципе, такой механизм имеется, но не является ни распространённым ни общепринятым.

[ant76]

 

Ещё раз повторяю для людей, имеющих эквивалентную Вашей квалификацию - использование своего сертификата посередине между источником и получателем информации является нарушением секурности.

И честь и хвала тем ресурсам, которые борются с этим.

В данном конкретном вопросе - категорически несогласен.

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

 

С другой стороны, лично я, вообще не намерен доверять владельцам серверов и (вполне обоснованно) желаю проверять весь трафик или "на конечном узле" ("у себя") или "на доверенном промежуточном узле" ("в организации"). Моё недоверие к владельцам серверов основано на том простом факте, что "паранойя шифрования" служит сугубо бизнес-целям: защита рекламного трафика и собираемых персональных данных от ("бесплатного") доступа третьих лиц (интернет-провайдеров - в первую очередь). А ещё сервер может стать источником заражения в результате халатности его владельцев или из-за целенаправленной атаки.

 

Чтобы понимать, какие деньги крутятся в этом бизнесе - достаточно вспомнить о капитализации гугла и периодических (регулярных) инцидентах взлома отдельных серверов или целых сегментов инфраструктуры.

 

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

 

P.S.

Мне, конечно, хотелось бы менее ресурсоёмкого механизма, чем "перешифровка" и, в принципе, такой механизм имеется, но не является ни распространённым ни общепринятым.

 

Всё так, в причем в статьях на том же Яндекс Дзен компания Dr. Web пишет что это важная составляющая антивирусного решения, когда зашифрованный трафик проверяется.

Но мне вот при таком раскладе тоже хотелось бы, чтобы при этом антивирус когда проверяет зашифрованный трафик делал это надлежащим образом и при этом поддерживал современные протоколы утвержденные для веба. Но сейчас имеем обратное... Когда включаешь ты проверку зашифрованного трафика, то косяк как тут описано или откат идет на старый веб протокол http 1.1 (у которого скорость ниже и многие другие фишки устарели), когда веб ресурс поддерживает http/2 или http/3. И похоже тоже самое и с TLS, судя по приведенному логу TLS 1.3 современный не поддерживается ПО Dr. Web.

[Roman Rashevskiy]

Мне, конечно, хотелось бы менее ресурсоёмкого механизма, чем "перешифровка" и, в принципе, такой механизм имеется, но не является ни распространённым ни общепринятым.

Имеете в виду извлечение ключей из памяти на лету?