Перейти к содержимому


Фото
- - - - -

Блокировка HTTPS-траффика субдоменов через DrWeb ES 10

https teamviewer

  • Please log in to reply
22 ответов в этой теме

#1 repsac1987

repsac1987

    Newbie

  • Posters
  • 3 Сообщений:

Отправлено 17 Сентябрь 2018 - 21:56

Здравствуйте. 

Возникла проблема с блокировкой некоторых HTTPS-сайтов через модуль "Родительский Контроль".

Добавляю в черный список маску, например, mask://teamviewer - сайт https://www.teamviewer.com- блокируется, но https://*.teamviewer.com - нет.

Подскажите, пожалуйста, как настроить правильно блокировку субдоменов через модуль "род. контроля".



#2 VVS

VVS

    The Master

  • Moderators
  • 17 324 Сообщений:

Отправлено 17 Сентябрь 2018 - 22:04

Добавляю в черный список маску, например, mask://teamviewer - сайт https://www.teamviewer.com- блокируется, но https://*.teamviewer.com - нет.

Эта фраза для меня непонятна...

--
меня вот что возмутило.  что даже не начинают толком диалог сразу дампы...... © alehas777

 


#3 repsac1987

repsac1987

    Newbie

  • Posters
  • 3 Сообщений:

Отправлено 17 Сентябрь 2018 - 22:23

 

Добавляю в черный список маску, например, mask://teamviewer - сайт https://www.teamviewer.com- блокируется, но https://*.teamviewer.com - нет.

Эта фраза для меня непонятна...

 

В мануале по блокировке в род. контроле есть описание как блокировать по ключевой фразе в урле - задается через mask://

На примере mask://teamviewer - происходит блокировка урлов, которые начинаются на teamviewer - https://teamviewer.com или https://www.teamviewer.com

Хочется настроить и блокировку субдоменов, типа таких - qwe123.teamviewer.com

Запись вида mask://*.teamviewer или mask://*teamviewer не срабатывают.


Сообщение было изменено repsac1987: 17 Сентябрь 2018 - 22:23


#4 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 17 907 Сообщений:

Отправлено 18 Сентябрь 2018 - 08:41

Без включенной проверки https можно заблокировать только хосты, которые прописаны в сертификате. Соответственно полный url или сабдомен не заблокировать. В ES нельзя включить проверку https, по а это локальная фича для однопользовательских продуктов.
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#5 repsac1987

repsac1987

    Newbie

  • Posters
  • 3 Сообщений:

Отправлено 18 Сентябрь 2018 - 10:01

Без включенной проверки https можно заблокировать только хосты, которые прописаны в сертификате. Соответственно полный url или сабдомен не заблокировать. В ES нельзя включить проверку https, по а это локальная фича для однопользовательских продуктов.

 

Ожидается ли проверка HTTPS для ES?



#6 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 17 907 Сообщений:

Отправлено 18 Сентябрь 2018 - 10:49

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

Сообщение было изменено Konstantin Yudin: 18 Сентябрь 2018 - 10:49

With best regards, Konstantin Yudin
Doctor Web, Ltd.

#7 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 17 907 Сообщений:

Отправлено 20 Сентябрь 2018 - 00:32

заметил тут, что chrome не дает подменять сертификат у сайтов если они EV. включаем проверку ssl, заходим на github.com например и видим что сертификат настоящий. заходим IE/Edge и видим наш. Так что фичу обхода ака MitM уже режут для важных ресурсов, что есть хорошо.
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#8 Dmitry_rus

Dmitry_rus

    Massive Poster

  • Helpers
  • 2 888 Сообщений:

Отправлено 20 Сентябрь 2018 - 12:53

фичу обхода ака MitM уже режут

Без сомнений, такая тенденция будет только усиливаться. Имеет смысл хорошенько подумать - нужна ли в свете происходящего проверка ssl/https? А т.к. обычных http становится всё меньше, то скоро и проверять окажется нечего... ;)



#9 VVS

VVS

    The Master

  • Moderators
  • 17 324 Сообщений:

Отправлено 20 Сентябрь 2018 - 14:18

 

фичу обхода ака MitM уже режут

Без сомнений, такая тенденция будет только усиливаться. Имеет смысл хорошенько подумать - нужна ли в свете происходящего проверка ssl/https? А т.к. обычных http становится всё меньше, то скоро и проверять окажется нечего... ;)

IMHO нужна.

Но только не проверка по SSL всего подряд, а проверка по SSL только того, что укажет пользователь.


--
меня вот что возмутило.  что даже не начинают толком диалог сразу дампы...... © alehas777

 


#10 AndreyKa

AndreyKa

    Advanced Member

  • Posters
  • 653 Сообщений:

Отправлено 20 Сентябрь 2018 - 15:41

Без включенной проверки https можно заблокировать только хосты, которые прописаны в сертификате. Соответственно полный url или сабдомен не заблокировать.

 

Тогда не понятно почему блокируется https://www.teamviewer.com, если в сертификате нет www.teamviewer.com?

То есть www не считается поддоменом?

Прикрепленные файлы:



#11 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 17 907 Сообщений:

Отправлено 26 Сентябрь 2018 - 13:30

конец все ближе https://www.bleepingcomputer.com/news/security/cloudflare-improves-privacy-by-encrypting-the-sni-during-tls-negotiation/
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#12 IlyaS

IlyaS

    Massive Poster

  • Posters
  • 2 842 Сообщений:

Отправлено 26 Сентябрь 2018 - 20:13

конец все ближе https://www.bleepingcomputer.com/news/security/cloudflare-improves-privacy-by-encrypting-the-sni-during-tls-negotiation/

нетфильтр ждет участь dwhv?

#13 Crus

Crus

    Newbie

  • Posters
  • 4 Сообщений:

Отправлено 07 Июнь 2019 - 01:20

заметил тут, что chrome не дает подменять сертификат у сайтов если они EV. включаем проверку ssl, заходим на github.com например и видим что сертификат настоящий.

Подмена для github.com не работала в Chrome из-за HPKP. Начиная с Chrome 72 перехват в DrWeb вновь работает - от HPKP отказались. Впрочем, Chrome и ранее (во времена HPKP) давал возможность осуществлять MitM.

конец все ближе https://www.bleepingcomputer.com/news/security/cloudflare-improves-privacy-by-encrypting-the-sni-during-tls-negotiation/

Или "новое начало" MitM :) Ведь сейчас работа Gate/"Офисный контроль" в ES продуктах по части HTTPS как раз на SNI базируются?



#14 Afalin

Afalin

    Guru

  • Dr.Web Staff
  • 3 583 Сообщений:

Отправлено 07 Июнь 2019 - 09:35

Ведь сейчас работа Gate/"Офисный контроль" в ES продуктах по части HTTPS как раз на SNI базируются?

Её ж тут вообще нет, помнится.


Семь раз отрежь – один раз проверь

#15 Crus

Crus

    Newbie

  • Posters
  • 4 Сообщений:

Отправлено 07 Июнь 2019 - 17:02

Её ж тут вообще нет, помнится.

Подразумевал блокировку доступа к "нерекомендуемым" сайтам для Gate и определенным тематическим группам (оружие, игры) для Офисный контроль. Т.е. речь про блокировку по доменам, а не фильтрацию трафика.



#16 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 17 907 Сообщений:

Отправлено 07 Июнь 2019 - 17:47

Ведь сейчас работа Gate/"Офисный контроль" в ES продуктах по части HTTPS как раз на SNI базируются?

да. но на нем далеко не уедешь.
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#17 Crus

Crus

    Newbie

  • Posters
  • 4 Сообщений:

Отправлено 07 Июнь 2019 - 19:36

да. но на нем далеко не уедешь.

Именно. Сейчас для решения задачи блокировки у нас используется Офисный контроль. С распространением шифрования SNI, как понимаю, он перестанет выполнять свою функцию. Поэтому интересует, будет ли введен MitM в ES? Вот здесь (доступ закрыт) этот вопрос раскрывается или там речь не о ES-продуктах? Можно в ЛС.



#18 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 17 907 Сообщений:

Отправлено 07 Июнь 2019 - 19:43

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

в контексте проверки SSL/TLS куда важней обсуждать вопрос - все идет к тому что митм скоро будет невозможен, и что делать в таком раcкладе?
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#19 Konstantin Yudin

Konstantin Yudin

    Смотрящий

  • Dr.Web Staff
  • 17 907 Сообщений:

Отправлено 07 Июнь 2019 - 19:44

я как безопасник счастлив что митм будет невозможен. но как разработчик ав продукта, я несчастен. дилема. :)
With best regards, Konstantin Yudin
Doctor Web, Ltd.

#20 Crus

Crus

    Newbie

  • Posters
  • 4 Сообщений:

Отправлено 07 Июнь 2019 - 20:17

сначала меняем область видимости для перехвата SSL, потом включаем в ES.

Ясно. А под сменой "области видимости для перехвата" подразумевается, к примеру, перехват только в браузерах? Или что-то другое?

 

в контексте проверки SSL/TLS куда важней обсуждать вопрос - все идет к тому что митм скоро будет невозможен

Даже в браузерах? Можно какие-то ссылки по теме? Просто не вижу предпосылок кончины "законного" MitM в браузерах. Вот, к примеру, цитата из MDN про отключения проверки привязки для не публичных корневых сертификатов:

 

Firefox and Chrome disable pin validation for pinned hosts whose validated certificate chain terminates at a user-defined trust anchor (rather than a built-in trust anchor). This means that for users who imported custom root certificates all pinning violations are ignored.





Also tagged with one or more of these keywords: https, teamviewer

Читают тему: 0

0 пользователей, 0 гостей, 0 скрытых