< HomePage | Снимки
<- Петък, 23 Юли 2004 | Начална страница | Неделя, 25 Юли 2004 ->
Събота, 24 Юли 2004

Денят на семинара. За малко да закъснея за нашата лекция с ManiaX-а. Така се бях затърчал, че щях да влетя в Химическия факултет без да забележа листчето на вратата, което любезно съобщаваше, че семинара се е преместил във ФМИ в 325 зала. Брех кво става, мам.....? Мистър Мърфи пак си играе игрички с нас - този път спрял тока в залата.

Отивам в 325-та, където Ники тъкмо отговаря на някакви тъпанарски въпроси - ма кажете що да ви вярваме, ма дайте гаранции, ма нали няма по някое време да почнете да искате пари и т.н. Ква гаранция ви гони бре? Който не му харесва, да направи нещо друго и да не се занимава с нас. Единственото сигурно нещо на тая земя е смъртта и плащането на данъци.

Наков почва да представя БАРС, и понеже съм слушал вече част от презентацията не внимавам много но се забавлявам. Единственото, което запомням е, че постоянно щели да се борят за благото (голяма борба ще пада) и че е хубаво да се правят сБирки на програмисти. Хич не ми хареса идеята да се събират на едно място unix kernel разработчици и някакви си бозиндолски "програмисти" да си обменяли опит. Какъв пък опит ще си обменят? Най-много unix-джийте да научат някой нов маркетингов (блях..) термин от бозиндолджийте и да получат безплатно (warez-ско) копие на книгата "Кликане с мишката за малоумни" (How to use the mouse for dummies (tm)).

После е нашата презентация за SSH (граби на sxi или pdf), която минава добре, естествено не без дребни проблеми. Казвам и аз по някоя дума, а впоследствие се оказа, че на народа нещо не му харесали моите обаждания. Аз пък мисля че бяха на място за да може ManiaX-а да не се отклонява от плана и да не пропусне нещо (е хайде без онзи път когато се обърках за authorized_keys...). Презентацията свършва, оставям лаптопа в офиса и се засилваме за Пз, където вече са всички без нас.

Пристигаме, малка почивка, след което окупираме бара на Qualita до Марица. Мента, мартини, мента, бира, мартини, мента, мартини и т.н.

[ Коментари: 15 | Добави коментар ]
Коментари

Обажданията бяха ужасни. Защо не застана до Колев и не си разделихте говоренето по презентацията? Постоянните прекъсвания отегчиха публиката (особено мен).

Какво целиш с оплюването на презентацията за БАРС?

Разделянето на програмистите на юниксаджии и уиндоусаджии ми се струва пресилено. Има хора, които могат и са работили на повече от една платформа.

Написа Христо Дешев (www) на 27-Jul-2004 15:05


Обажданията не бяха предназначени за публиката, а за да може ManiaX-а да не изпусне нещо от плана. Презентацията трябваше си я водеше той, аз просто бях бонус, защото по принцип не трябваше да съм в събота налице в София.

Какво целя ли? Много просто - целя world domination и зомбиране на масите с цел максимален брой кликове по банерите и повече е-стотинки от рекламодателите с който да мога да спонсорирам моята тъмна дейност известна, като "оплюване".

Какво оплюване на презентацията на БАРС? Я прочети какво съм написал, ако не можеш да разбереш ще ти го нарисувам.

...стана ми смешно просто като се сетих как ще се съберат някакви си кликачи във visual basic .net edition и програмисти, който пачват linux ядрото, например. Ей това вече е забавно, чак страх да те хване :)

Написа Георги Чорбаджийски (www) на 27-Jul-2004 16:08


И в моя блог го написах, обажданията от Жоро си бяха много на място. Като обяснявам, аз поне имам навика да се отплесвам, и да пропускам разни дреболии (за това винаги гледам да пиша нещата).

В общи линии така се получи по-добър материал, с по-малко пропуски, но с дребен пробпем в представянето. За мен поне това е по-добрия вариант, за мен си е важно съдържанието, не опаковката.

Жоро, ти не си програмист, за това ти е странно такова събиране... Ама я си представи какви flamewar-и ще стават, особено като се напият... :)

Написа Васил Колев (www) на 27-Jul-2004 16:55


"постоянно щели да се борят за благото (голяма борба ще пада)"

Това ми прозвуча снизходително. Затова заговорих за оплюване. Извинявам се, ако съм сбъркал.

За мен проблема не е дребен, но пък кой съм аз? Ще се обаждам, като почна да мога да правя презентации, като Васил Колев. Това не е бъзик, а похвала.

Написа Христо Дешев (www) на 27-Jul-2004 19:12


Презентацията я направи Жоро, аз само давах акъл :)

Написа Васил Колев (www) на 28-Jul-2004 01:14


Извиненията се приемат :) Просто не си свикнал с начина ми на изразяване. Коментара за борбата беше по повод на това, че Наков докато водеше презентацията на всеки слайд казваше по два пъти, че щели да се борят за ....... (попълнете точките). Когато правиш презентация понякога не се усещаш и ако някой израз ти хареса как звучи започваш несъзнателно да го използваш пак и пак. След това като се чуеш какви си ги приказвал ти става смешно :-)

Написа Георги Чорбаджийски (www) на 28-Jul-2004 10:00


И двамата се справиха чудесно!
Поздравявам ги.
Все пак са и част от core тима на ISECA и това е обичайно за тях. ;-)

Написа Ники (www) на 28-Jul-2004 10:01


Ами поне по това, което чух на генералната репетиция в Химическия факултет, лекцията на Васил беше доста добра и информативна. Пък и Жоро едва ли се е намесвал ей така за да разсее изложението. Просто нормално е като иде реч за такива неща някой да следи за пълнотата и да допълва като усети, че нещо е пропуснато (а винаги има такива неща).

Много ми се щеше да обясня проблемите на SSH относно разкриваемостта на сесийния ключ при големи трансфери на информация с един сесиен ключ и т.н.. но може да се напише статия и ако и Васил напише неговото изложение да се стиковат в едно общо "литературно произведение":)

Написа Веселин Колев на 28-Jul-2004 22:15


А Весо ти сигурен ли си за сесийния ключ при ssh v2?
Че не се прави rekey ?

Написа Ники (www) на 29-Jul-2004 01:26


-> regress/rekey.sh

Ако имаш предвид това, което се намира в сорс дървото на дистрибутива openssh, трябва да те разочаровам. Това са първи стъпки към истински re-keying. Още не е направен така, че да е управляем параметрично (и е доста бъгав). Примерно не можеш да кажеш да се прави re-keying по дадено разпределение (както е при IPsec имплементите).

Cisco също имат някакви проблясъци по темата в последните си OS-и. Но единствено валидния re-keying е този направен по разпределение (времево или по трафик).

Ако имаш интерес, пиши ми на мейла да се видим и да ти порисувам схемички. Пия столично тъмно:)

Написа Beco на 29-Jul-2004 18:27


В ssh2 има ръчен re-key. Все пак атаката за да сработи изисква огромно количество данни, така че едва ли е особено опасна. Понякога нещата, който на теория изглеждат много страшни на практика не са проблем в 99.9% от случаите.

Написа Георги Чорбаджийски (www) на 29-Jul-2004 19:33


Значи, Георги, има два вида атака, която може да се приложи. При едната правиш само статистически анализ. Там са ти нужни наистина огромни трансфери. При другата атака не са нужни чак такива трансфери. Достатъчно е да знаеш какво има в трафика. Тази атака е доста добре приложима, ако през SSH тунел прекарваш PPP и така свързваш примерно две мрежи. Достатъчно е в едната мрежа да имаш хост, който да генерира трафик в тунела и ти да знаеш какво има в този трафик. Например хост от тази мрежа се свързва за http://bozi.unixsol.org и гледа някой филм от енцикликата за Джеймс Бонд.

Факт е, че атаката може да я има и ако някой иска може да я направи. Не е много сложно и май се иска само ентусиазъм и малко късмет.

По принцип, още при първите дизайни на IPsec решенията, създателите им са си задали въпроса "как и защо да правим предоговаряна не ключа". Защо е било ясно, но виж, задачата "как да" е била по трудна. Оформили са се две крайни решения - да се състави разпределение по време или разпределение по трафик.

- разпределение по време: заплюваш някакво време и казваш "това е нула" и на всеки 3600 секунди сменяме сесийния ключ. Това е линейно разпределение. Може да се измисли по-гъвкаво решение по часови пояси - през работно време смяна на ключа през 60 секунди, вечер на 600 секунди и т.н.

- разпределение по трафик: решаваш на всеки 10 гигабайта пренесена информация да правиш предоговорка на сесийния ключ. Тук обикновено по инерция хората казват "е, да ама след като трафика е решаващ за разкриването на сесийния ключ, защо ни е да имаме предоговрка планирана по време, а не само по трафик". Истината е, че ако се направи анализ от гледна точка на начина на атака, става ясно, че има различни видове трафик. Много ясно е, че ако ако пуснеш един обикнвен флуд по тунела в повечето случаи ще генерираш хомогенен трафик и той е опасен. За теб радостно ще бъде трафика да е нехомогенен (разни услуги).

И тогава по-досетливите хора са решили да направят хибридна схема време/трафик разпраделение. Т.е. схемата като замисъл е простичка: ако за еди какво си време мине еди колко си трафик, се прави предоговорка. За момента няма схема за предоговорка на сесиен ключ, която да се базира на класификация на информацията в тунела, но се очаква скоро да има и такива решения.

Е такава схема лиспва на SSH. И няма изгледи и да я има. Да не говорим, че няма никакъв мениджмънт на ключовете. Забележи, че ти имаш удостоверяване на база "ключ", а не на база "сертификат". Ключа не може да има състояние на валидност, проверяемо по някакъв начин, ако не е в рамките на сертификат. Направи си един файлов сървър и пусни потребителите през sftp чрез удостоверяване с публичен ключ. Следват следните неприятни задачки за решаване:

1) Намиране на сигурен канал за предаване на ключа от клиента до сървъра. Похватът "аз нося дискетка на оператора" е неприложим и кошмарен и не гарантира пак идентичността на ключа, защото трябва да принудиш преносителя да ти даде "отпечатъка" на листче и да се подпише с кръвта си, че това е точно отпечатък на това дето го има на дискетата. Ако някой е в Австралия, а сървъра е в София, задачката става доста гадна. Трябва да ползваш външна за SSH протокола структура за обмен на ключ.

2) Следене на състояние на ключа. Нямаш еднозначна услуга, която да следи дали един ключ е валиден - не знаеш кога е създаден (нямаш срок на валидност), не знаеш дали не е разкрит частния ключ, компелементарен към публичния - я потребителя дето го ползва ти каже, я не, а може и той да не знае за събитието. Няма комюнити или удостоверител, който да следи по услугите в някакъв набор от системи дали няма някакви съмнителни оторизации и т.н. и от там да съди за това дали с ключа се правят бели и прочие.

3) Няма удостоверителни вериги - не можеш примерно да кажеш "ей сега ще дам достъп до дадена услуга на цял отдел". Трябва да имаш всички ключове на отдела. И ако броят потребители имащи достъп до дадена услуга се мени, ще си имаш куп разправии с менажирането на достъпа.

И т.н. :) стана късно и ми се яде. Стига толкова.

Написа Beco на 29-Jul-2004 21:26


За тази втората атака с известният ти трафик бях забравил, благодаря. Аз си мислех единствено за статистическата атака.

Написа Георги Чорбаджийски (www) на 29-Jul-2004 22:30


Управлението на ключовете в SSH наистина не може да се мери по никакъв начин с истинска идентификация чрез сертификати но и никога не е било съобразявано за такива тежки изисквания. Весо, имаш ли идея защо във SSH протокола не искат да вкарат rekey-ing? Има ли някакви технически проблеми с това или просто проблема е неразбран и го игнорират?

Написа Георги Чорбаджийски (www) на 29-Jul-2004 22:35


Ами до колкото ми се върти нещо в главата от списъците, дето чета, има и политически момент и предпазливост.

Май трябва да проуча въпроса детайлно и да ви докладвам.

Написа Beco на 29-Jul-2004 23:14


Добавяне на коментар
Не пишете nicknames, освен ако не се обръщам така към вас.
Е-мейл адресът няма да се показва на сайта.
Към него ще има връзка.

Коментарът трябва да е написан на български с кирилица или на английски. Останалите се трият.

Запомни адреса и името ми, за да не го пиша следващия път
начало
Valid XHTML 1.0! Valid CSS!