информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Первый в Рунете публичный аудит почтовой системы 03.06.02 16:34  Число просмотров: 2992
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 03.06.02 17:17  Количество правок: 1
<"чистая" ссылка>
> > > азбукой Морзе через клавишу NumLock :)
> > :))) Речь идёт о том, чтобы осложнить жизнь снифферу.
> Хм, но если речь идет о сниффере, то примерно равновесно
> что перехватывать: код ячейки из таблицы виртуальной
> клавиатуры или код введенного символа.
???
Под виртуальной клавиатурой пониматеся нарисованная на экране клавиатура со случайным
расположением клавиш, которые выбираются мышкой или "ложной" клавишей.
Это обычные, но очень эффективные действия по защите от большинства популярных снифферов.
Трассировка щелчков мышки действительно возможна, возможна и синхронная запись состояния видеопамяти
но большинство сниферов такое не обеспечивают.
Большинство применяемых- сохраняют только нажатия клавиш.
Идея не нова она обсуждалась лет пять назад и это решение было принято как оптимальное по балансу
эффективности и сложности.

> > Кроме того необходимо вскрывать ssl на связи с
> сервером > > (передача тела письма идёт ч/з
> > htpps). А он защищён уже классически, с применением
> > сертификатов.
> Гм. Сертификат я видел только при загрузке аплета. Может,
> не доглядел? ;)
Просто не разобрались:)). Браузер не всегда о них предупреждает, если авторизатор уже есть в базе
Очистите их список в браузере и всё увидите.

> вновь подключающийся в конце концов может убедиться в
> целостности и принадлежности загруженного им открытого
> ключа s-mail. Далее, он генерирует свою ключевую пару,
> формирует запрос на сертификат, шифрует его на открытом
> ключе s-mail и отправляет на s-mail.
...
> Идею отдаю бесплатно, тем более, что она давно общеизвестна

Именно так s-mail и поступает. Все сгенерированные ключи (вернее фрагменты их шифра перемылается по https:).
в виде форм ч/з
https://ksX.s-mail.com/...

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


> Вы сами правильно ниже пишете. И применение этих методов не
> осложняет техническую сторону, а решает проблему.
> Собственно, в чем суть проблемы? Достоверно получить
> открытый ключ корреспондента.Обеспечить его максимальную
> доступность разбросать по серверам
Угу. Вероятный противник делает то же самое (от Вашего имени), в таких же в больших объёмах.
Чему равна вероятность попасть на ложный ключ (>0,5)? Влад все эти схемы уже давно рассматривались в учебниках.
Там же отмечено, что для применения открытой криптографии должен быть надёжный канал, или публикация ключа должна
начаться ранее атаки на него.

Теперь крайний случай
Ваши письма он (владея каналом) перехватывает и заменяет ключ на свой.
Входящие письма он тоже перехватывает и заменяет ключ на свой.
Вообще на все последоватьльности вашего секретного ключа стоит оператор replace.
Мораль: если адресная проверка началась до публикации ключа в ассиметричном крипто ловить нечего.
Если позже- тогда все эти схемы излишни.


> Соглашусь с Вами в другом тезисе: лучше, чем ничего. Но, на
> мой взгляд, не сделаны самые простые вещи (не требующие,
> кстати, бешенных затрат), выводящие защищенность решения на
> гораздо более высокий уровень.
По-моему всё сделанно, только стандартыми средствами браузеров не наращивая объём апплетов.

> > Именно в этом плане S-Mail вне конкуренции с другими
> > российскими Web-почтами.
> А что, кто-то еще предлагает [b]защищенный[/b] сервис
> электронной почты? В противном случае, сравнение
> некорректно...
Ну, совсем недавно целая куча почт (pochtamt.ru, hotbox.ru, zmail.ru ...) радостно писала, что она предлагает защищённую почту,
при этом речь шла только о SSL до сервера. Посмотрите мою статью "Субъективная ... почт с Web-Интерфейсом".
Там приводился простой пример как читать почту rbc-шных сервисов (pochtamt.ru, fromru.com, rbcmail.com) прямо с сервера,
игнорируя все навороты на пути к нему.

> > А независимые каналы денег попросят.
> Зачем? У ребят хватило денег на сертификат Thawte для
> подписи аплета, кто мешает использовать его для подписи
> открытого ключа?
Что они и сделали в отношении сервера и спокойно пересылают его по https://.
Я говорил о сертификате на каждый ключ пользователя, что сделало бы его независимым от стойкости сервера.

> Если к этой категории относить всех, кто смог прочитать (и
> понять) русский перевод доки к PGP - тогда, да.
Много Ваших клиентов сделало (сделает) это?

> > >plug-in для Outlook ...который также загружен по
> > non-trusted каналу (ИНтернет)
> > > ;))
> > ; Как и PGP который в лучшем случае куплен на CD-шном
> > рынке.
> Это как раз худший случай ;)
Без разницы :(

> Для них есть специальный 1-дискетный дистрибутив линукса,
> который загружает trusted-серду для выполнения GPG :)
Угу. Очень удобная схема работы. Особенно для многократной пересылки документа в процессе его редактирования/согласования.
Полагаю, что для Вашего же случая совместной статьи s-mail была бы удобнее и вполне равноценна ценности поставленной задаче.

Александр.
<theory> Поиск 






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


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