информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Сетевые кракеры и правда о деле ЛевинаСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Именно так. Но этот сертификат будет валидным с точки... 29.03.11 17:06  Число просмотров: 2565
Автор: fingus Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Фигня какая-то. А не кажется ли вам, что данная защита
> противоречит здравому смыслу?
> Когда лезешь на сайт, обычно выскакивает сертификат, но это
> сертификат именно целевого сервера. В противном смысле
> теряется смысл защиты - лезу я на сайт своего банка
> проверить счет или сделать платеж, а мне выскочет
> сертификат какого-то другого прокси сервера, так?
Именно так. Но этот сертификат будет валидным с точки зрения броузера и ни каких предупреждений не появится. Понять, что сертификат был выдан кем-то другим можно только специально посмотрев его свойства. Поэтому, большая часть пользователей ни чего не заметит. Я бы даже сказал, что ни кто не заметит, часто ли вы проверяете кем выдан валидный сертификат к сайту? Если только случайно или из любопытства посмотрит.
Но тут уже этическая сторона вопроса. Обычно в организациях с которыми я сталкивался адреса интернет банков заносятся в исключения и при написании политики терминирования HTTPS трафика их трафик не расшифровывается. Плюс, во многих случаях, есть специальное всплывающее окно с описанием политики безопасности или хотя бы предупреждение
<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-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach