Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | |
То, что позволено политикой безопасности организации. 23.03.11 10:50 Число просмотров: 2497
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
<networking>
|
но как это им удается, если сертификат на стороне клиента, Холмс? 22.03.11 15:05
Автор: lazy_anty Статус: Member
|
Сканирование HTTPS-трафика -
GFI WebMonitor 2011 может расшифровывать защищенный SSL-трафик, проверять его содержимое на наличие вредоносного кода, а затем зашифровывать обратно и передавать пользователю, без чего невозможно обеспечение полной безопасности загружаемого контента из сети.
http://www.gfi.ru/webmonitor
|
|
Очень просто -... 22.03.11 15:10
Автор: Winer <Виктор С.> Статус: Member
|
> Сканирование HTTPS-трафика - > GFI WebMonitor 2011 может расшифровывать защищенный > SSL-трафик, проверять его содержимое на наличие > вредоносного кода, а затем зашифровывать обратно и > передавать пользователю, без чего невозможно обеспечение > полной безопасности загружаемого контента из сети.
Очень просто - http://www.visolve.com/squid/squid30/network.php#https_port
ISA делает точно так же.
|
| |
и каспер так умеет. 23.03.11 04:40
Автор: Den <Denis> Статус: The Elderman
|
|
| |
Иными словами, клиент всегда видит сертификат прокси-сервера. 22.03.11 16:15
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
| | |
Это только одна из трех частей задачи. Вторая - прокси... 28.03.11 17:23
Автор: lazy_anty Статус: Member
|
Это только одна из трех частей задачи. Вторая - прокси должен уметь "прозрачно" или с разрешения/ведома клиента пользоваться сертификатом целевого сервера. Третья - прокси должен независимо хранить/извлекать откуда-то (из AD?) сертификаты разных пользователей и "от их имени" устанавливать защищенные соединения также независимо.
|
| | | |
Обычно схема терминирования https трафика выглядит... 29.03.11 16:52
Автор: fingus Статус: Незарегистрированный пользователь Отредактировано 29.03.11 16:57 Количество правок: 1
|
> Это только одна из трех частей задачи. Вторая - прокси > должен уметь "прозрачно" или с разрешения/ведома клиента > пользоваться сертификатом целевого сервера. Третья - прокси > должен независимо хранить/извлекать откуда-то (из AD?) > сертификаты разных пользователей и "от их имени" > устанавливать защищенные соединения также независимо. Обычно схема терминирования https трафика выглядит следующим образом:
- на прокси устанавливается сертификат из CA которому доверяют клиенты. Чаще всего это сертификат выданный внутренним СА. Хотя может быть и внешний, если это не одна организация а провайдер услуг.
- клиент инициирует SSL сессию посылая HELLO серверу
- прокси перехватывает запрос и посылает его на сервер от имени клиента
- сервер отвечает посылая свой публичный сертификат, соответственно он отвечает прокси серверу
- прокси генерирует сертификат с именем сервера и посылает его клиенту. Т.к. этот сертификат подписан сертификатом которому клиенты доверяют, то и новому сертификату они так же доверяют
В итоге обычный пользователь не видит ни каких предупреждений от броузера, т.к. сертификат отвечает всем признакам действительного:
сертификат выдан доверенным СА
сертификат содержит имя сервера к которому происходит обращение
сертификат годен по сроку годности
Получается, что это не один туннель, а два. Один от клиента к прокси, а второй - от прокси до сервера. Соответственно на самом прокси сервере трафик будет незашифрованный и его можно проверять на вирусы или на наличие определённой информации
|
| | |
Фигня какая-то. А не кажется ли вам, что данная защита... 22.03.11 21:45
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman Отредактировано 22.03.11 21:45 Количество правок: 1
|
Фигня какая-то. А не кажется ли вам, что данная защита противоречит здравому смыслу?
Когда лезешь на сайт, обычно выскакивает сертификат, но это сертификат именно целевого сервера. В противном смысле теряется смысл защиты - лезу я на сайт своего банка проверить счет или сделать платеж, а мне выскочет сертификат какого-то другого прокси сервера, так? Разумеется на этом все будет закончено. Либо сертификат сервера я смогу сохранить в хранилище сертификатов, тогда связь опять же не установится.
Если же клиент зашифрует сессионный ключ на сертификате целевого сервера, то никто из промежуточных проксиков не сможет ничего расшифровать - секретный ключ только на целевом сервере.
|
| | | |
Именно так. Но этот сертификат будет валидным с точки... 29.03.11 17:06
Автор: fingus Статус: Незарегистрированный пользователь
|
> Фигня какая-то. А не кажется ли вам, что данная защита > противоречит здравому смыслу? > Когда лезешь на сайт, обычно выскакивает сертификат, но это > сертификат именно целевого сервера. В противном смысле > теряется смысл защиты - лезу я на сайт своего банка > проверить счет или сделать платеж, а мне выскочет > сертификат какого-то другого прокси сервера, так? Именно так. Но этот сертификат будет валидным с точки зрения броузера и ни каких предупреждений не появится. Понять, что сертификат был выдан кем-то другим можно только специально посмотрев его свойства. Поэтому, большая часть пользователей ни чего не заметит. Я бы даже сказал, что ни кто не заметит, часто ли вы проверяете кем выдан валидный сертификат к сайту? Если только случайно или из любопытства посмотрит.
Но тут уже этическая сторона вопроса. Обычно в организациях с которыми я сталкивался адреса интернет банков заносятся в исключения и при написании политики терминирования HTTPS трафика их трафик не расшифровывается. Плюс, во многих случаях, есть специальное всплывающее окно с описанием политики безопасности или хотя бы предупреждение
|
| | | |
Админа не волнуют жалкие проблемы пользователей :) К тому... 23.03.11 09:08
Автор: Winer <Виктор С.> Статус: Member
|
> Фигня какая-то. А не кажется ли вам, что данная защита > противоречит здравому смыслу? > Когда лезешь на сайт, обычно выскакивает сертификат, но это > сертификат именно целевого сервера. В противном смысле > теряется смысл защиты - лезу я на сайт своего банка > проверить счет или сделать платеж, а мне выскочет > сертификат какого-то другого прокси сервера, так? > Разумеется на этом все будет закончено. Либо сертификат > сервера я смогу сохранить в хранилище сертификатов, тогда > связь опять же не установится. > Если же клиент зашифрует сессионный ключ на сертификате > целевого сервера, то никто из промежуточных проксиков не > сможет ничего расшифровать - секретный ключ только на > целевом сервере.
Админа не волнуют жалкие проблемы пользователей :) К тому же, зачем тебе на работе заходить на сайт банка?
|
| | | |
С чего же фигня? Админ точечно принимает сертификаты, отстальные в топку. В результате защищённость не страдает. 22.03.11 21:48
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
| | | | |
Что значит "точечно"? 22.03.11 22:23
Автор: Fighter <Vladimir> Статус: Elderman
|
|
| | | | | |
То, что позволено политикой безопасности организации. 23.03.11 10:50
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
| | | | | | |
Раньше это так и называлось: "определяется политикой безопасности организации". 23.03.11 14:36
Автор: Fighter <Vladimir> Статус: Elderman Отредактировано 23.03.11 14:45 Количество правок: 1
|
А "точечно " обозначало "выборочно", "избирательно", т.е. "на усмотрение ..." или, по-честному, - "как хрен вштырит".
|
| | | | | | | |
Да хоть ковровой бомбёжкой. Суть та же ) Выборочно - хочу-не хочу. Точечно - знаю, что хочу. 23.03.11 14:42
Автор: kstati <Евгений Борисов> Статус: Elderman Отредактировано 23.03.11 14:44 Количество правок: 1
|
|
| | | | | | | | |
Ну-ну. 23.03.11 14:48
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
|