информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыВсе любят медАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
 Рекордное число уязвимостей в 2021 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Админа не волнуют жалкие проблемы пользователей :) К тому... 23.03.11 09:08  Число просмотров: 2368
Автор: Winer <Виктор С.> Статус: Member
<"чистая" ссылка>
> Фигня какая-то. А не кажется ли вам, что данная защита
> противоречит здравому смыслу?
> Когда лезешь на сайт, обычно выскакивает сертификат, но это
> сертификат именно целевого сервера. В противном смысле
> теряется смысл защиты - лезу я на сайт своего банка
> проверить счет или сделать платеж, а мне выскочет
> сертификат какого-то другого прокси сервера, так?
> Разумеется на этом все будет закончено. Либо сертификат
> сервера я смогу сохранить в хранилище сертификатов, тогда
> связь опять же не установится.
> Если же клиент зашифрует сессионный ключ на сертификате
> целевого сервера, то никто из промежуточных проксиков не
> сможет ничего расшифровать - секретный ключ только на
> целевом сервере.

Админа не волнуют жалкие проблемы пользователей :) К тому же, зачем тебе на работе заходить на сайт банка?
<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
<"чистая" ссылка>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach