татко Крокодил

Иде OpenFest 2014.

Имаме някаква програма, която трябва да допълним, и си търсим още доброволци.

Иде OpenFest 2014.

По случая имаме пуснато CfP (т.е. зов за лектори), на което може да се подават заявки за лекции и workshop-и.

Разликите от предишни години са, че понеже във feedback-а от миналата имаше оплаквания, че лекциите били много сложни и много елементарни, сме разделили техническия поток на technical и advanced technical, така че хората да могат да си избират.
(вече имаме няколко достатъчно извратени неща за advanced потока, и събираме още)

Има планове тази година най-накрая да подкараме сериозно openart потока (което все не успявахме предишни години), има идеи дори за няколко art инсталации на самото място.

Добавили сме и civic hacking – има доста интересно развитие в областта, и трябва да и обърнем малко повече внимание.

Та, ако имате добра идея с какво искате да се изложите пред публика, submit-вайт
е :)

Мина и третия ден на Balccon 2014. В момента хората са на afterparty, а аз пиша това и заспивам, че съм съвсем скапан.
(Снимка от ракия workshop-а).

Успях да слушам малко от лекциите, но определено се забеляза, че workshop-на Мич Алтман има голям успех – беше пълно, някакви хора размахваха поялници и бяха щастливи (даже в twitter някой беше написал два реда стихотворение). Боян присъства и беше много щастлив, не знам дали от нещата за дебъгване там или от изпаренията…
(около това и debug-вахме някакъв проблем с avr-gcc-4.8.1 и const за някакви структури)

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

Лекцията, която ми направи впечатление беше за метод за генериране на пароли за brute force (някакво количество код има в github), който може да анализира съществуващи пароли и да намира в тях pattern-ите, чрез които хората са ги измислили (комбинации от речникови думи, pattern-и на клавиатурата, смяна на символи (например l33t)), и на база на това да може да се справя с по-дълги пароли/passphrase-и, като инструментариума се използва основно да дава входни данни на john the ripper, за чупене на съществуващите пароли. Като цяло нещата изглеждат доста интересни, и вероятно може да им се намери приложение (за сега е сложно да се мислят да се ползват за проверка на сила на парола, понеже базата отзад била около 20G и не всеки ще може да я deploy-не).

От другите интересни неща – Яна си беше оставила лаптопа на една пейка, и един младеж отбеляза, че изглеждал като възглавница. Едвам го спасихме (младежа), мисля, че бая го уплаши…

Утре минаваме през един манастир за ракия, и се прибираме.

Мина втория ден на Balccon 2014.
(оказа се, че “балкон” е същото на сръбски и даже дизайнера им бил кръстил директорията с техните неща “тераса”)

Успях да ида на няколко лекции.

Лекцията за “android vaccination” се оказа описание на един приятен инструмент за вкарване и изпълняване на код в работещо андроидско приложение, което много улеснява дебъгването, доста повече от простото декомпилиране. Използвали са и нещата, дето разни хора разказаха на CCC, за динамичното инструментиране, и като цяло се получава нещо много удобно за reverse-engineer-ване.

Лекцията за scada в общи линии беше “а тия хора използват криптография и security неща от вашето детство и са тривиални за чупене”.

Лекцията за heapbleed беше странна, основно научих за dynamorio (което трябва да проуча), иначе имаше идея за изследване на поведението на memory allocator-ите чрез краен автомат, така че да се прецени как се пише exploit през тях, т.е. къде и какво трябва да се намаже, за да сработи. Нямаше много директно приложими идеи, но беше добър увод.

“Linux kernel attack surface” беше интересно, бяха намерили начин чрез trace-ване на ядрото да разберат какви неща в него се ползват и на база на това да генерират kernel-ска конфигурация, от която да се build-не с правилните неща, или просто да ги изключат като функции динамично (което все още има някакви проблеми). Като цяло изглежда като опит да се заобиколи големия проблем с гигантския source на ядрото и хилядите проблеми в него, но поне е стъпка в правилната посока.

Лекцията за ipv6 measurements with RIPE atlas беше интересна и хората стояха и повече време (с риск да закъснеят за ракиения workshop). Весна разказа за доста интересни неща, които правят (и за които сме поканили и лектор на OpenFest, да ни разкаже за backend-а им), за разни измервания колко видими са помежду си различните части на ipv6 internet-а (накратко, не са добре нещата), и как една от мерките им е да дават тениски на LIR-овете, които са подкарали определено количество v6 неща. Споменаха http://visibility.it.uc3m.es/, което мисля да разгледам по-подробно.
(и да си отбележа, трябва да сложа една ripe atlas probe и в офиса)

Денят завърши с ракиен workshop. Нямаше достатъчно пиене да се убием, но стигна достатъчно да се насмучем и да обсъдим всякакви неща, например как и сърбите са същите пияници като нас (един човек обясняваше как дядо му пиел по две малки сутрин, на обед и вечер и това било съвсем в реда на нещата). Определено пиенето помага за социализацията…

Около всичкото успях да си поговоря с един от TOR хората и има шанс да допиша нещо тривиално за тях, както и да се опитам да пробутам достъпност на нашите услуги през тяхната мрежа, да видим…

Та, не съм полицай, господин пиян и лека ви нощ. Вече има план как да минем през някакъв манастир, за да вземем от някакъв странен орехов ликьор.

Update: Забравил съм да отбележа, отсрамихме се на workshop-а, като занесох една бутилка от малиновата ракия (и мисля, че хората я харесаха).

В Сърбия сме, на Balccon 2014 и зверски ми се спи.

В четвъртък по обяд тръгнахме, и с бавенето на митницата и разните toll booth-ове стигнахме за 8 часа до Нови Сад. Добрахме се до хотела си с малко въртене и гледане на 2 различни gps-а (да живее backup-а), който се оказа последните два етажа на жилищна сграда…

Мястото на събитието се оказа много интересно – текущият музей на модерно изкуство, преди това бил музей на революцията – като се ползват две зали. Едното е кино-зала, за вероятно около 100 човека, другото е едно мазе, в което на едно място са наслагали много стара техника (някакви atari-та, някакви древни сръбски компютри) и в което се провеждат и workshop-ите. Цялото нещо прилича на един голям hackerspace и усещането е такова – особено като човек види с колко duct tape са налепили кабелите и wireless AP-тата…

В петък (първия ден на събитието) успях да ида на две лекции (освен моята). Едната беше за post-quantum cryptography, която беше доста уводна, но се споменаха интересни неща (например трябва да проверя какво точно е казал Schneier по темата за ECC и кривите, които NIST препоръчва). Като цяло май няма много развитие от времената на “Post-Quantum Cryptography” на Bernstein и компания, но лекторът спомена, че в момента Wau Holland фондацията работи с някакви университети да се работи по някакви нови схеми/шифри за шифриране/подписване с публични ключове и за обмяна на ключове.

Другата лекция беше Open Source Hardware на Mitch Altman, която в общи линии беше на темата “Life is too short to do things you hate”. Звучеше много интересно и правилно, трябва да видим дали има шанс да го доведем на OpenFest…

Моята лекция мина доста добре (или поне доста по-добре, отколкото очаквах, особено при условие, че бях си забравил едни лекарства в София и трябваше да си говоря с локални аптеки, които ме гледаха като изпаднал наркоман). Събрах се добре във времето, имаше интересни въпроси и в крайна сметка я submit-нах за CCC. Не знам дали ще ме харесат (имат високи и странни критерии), но па може и да им се види интересно…

Имаше и интересни lightning talk-ове, например един човек, дето си сглобил arcad
e машина (която стои горе и направо си спомних като малък колко съм висял по такива).

(след като блогна това, смятам да ида да спя)

Бях тия дни на YAPC Europe (“Yet Another Perl Conference”), като част от техническия екип.

За мен конференцията беше осново репетиция за stream-ването за openfest – всичко мина много добре, дори с малкия екип, който бяхме (Guru, Петко, аз, както и няколко доброволци за от време на време, от които май само EXo познавам). Открих поредния проблем с ffmpeg (четенето от UDP socket се оказва, че не му е сила), но като цяло всичко сработи добре и нямаше неочаквани проблеми.
(очаквани имаше, заради проблеми с HDMI/VGA входове и конвертори)

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

Не мисля, че мога да разкажа добре за лекциите, винаги ми е трудно да ги следя, като имам някакви такива занимания, но определено имаше супер забавни неща, вкл. видях как се прави “Hello World” на perl6 чрез викане през .so файл на някаква функция от perl5, или чрез inline python…

А от техническа страна най-гадното нещо бяха lightning talk-овете, където в общи
линии бяхме като екипите на формула 1, дето сменят гуми, мисля, че се справяхме
за 10-20 секунди да сменим лектора.

(аз все още съм адски уморен, и постигнахме консенсус, че 3 дни събитие е убийствено и никога няма да удължим openfest. Не ми се мисли как ще преживеем EuroBSDCon-а, който е 4 дни…)

Идва Balccon 2014, Балканският Комюптърен Конгрес 2014 (второ издание). На мен даже ми приеха лекция (която усилено пиша), на Мариян също (който също предполагам ще пише усилено, като се сети какво предложение е пратил), та ще ходим натам.

Вероятно ще е забавно, съдейки по разказите от миналата година – в Speakers може да се види кои ще говорят (обърнете внимание на ракиения workshop).

Събитието ще се проведе на 5-6-7 септември в Нови Сад, Сърбия (490км, изглежда по-близо от Варна), та има ли още желаещи да идват? Може да помогнем с настаняването (говоря си с организаторите, иначе има описани хотели на accomodation страницата.

Може би така изглежда щастието.

От някакво време се канех да видя какво друго е писал Оруел, и в крайна сметка п
рез антикварни книжарници и подобни успях да си събера комплекта от 11 тома със
събраните му неща извън по-дългите (романите, както и “The road to Wigan pier” и “Homage to Catalonia”). Отгоре на купа е и едно издание на романите му, които о
баче съм чел (планирам да препрочета “1984” в оригинал, след като свърша с тия тухли (в момента съм към средата)).

Има няколко сериозни причини да искам да ги изчета.

Като за начало, Оруел е един от най-добре пишещите на английски автори. Неговото владеене на езика е страхотно, като успява да го комбинира с много прост и ясен изказ, което го прави перфектният пример за всеки, който иска да пише. Може би
донякъде мога да го сравня с Георги Марков в българския език.

След това, Оруел е един от най-честните хора, които съм чел. Способен е да защитава до край убежденията си и да казва каквото мисли директно и ясно (и си проличава британското в него, въпреки, че е груб, пак звучи добре), но в случаите, когато се окаже, че не е прав, е способен да се извини и да си каже в прав текст, че е сгрешил. В повечето му есета освен това, за което говори се старае да опише и собствената си гледна точка и нещата в него самия, които може да са повлияли на написаното.

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

(прескачам дребните неща, например как показва влиянието на липсата на новини и как се променя мнението на хората през войната, или стотиците ревюта на книги, които е написал и от които си харесвам неща за четене).

Като цяло, важно и интересно четиво. Жалко, че винаги ще си остане гадно усещане за недовършеност, което идва като отворя поредния том, и в началото видя в хронологията:
“21 January 1950 Orwell dies of pulmonary tuberculosis, aged 46.”

(in other news, ще се ходи на Балканския Компютърен Конгрес, където и ще говоря, но за това – в следващите дни)

Този петък (25 юли) празнуваме пак денят на системния администратор, в “Кривото” на ъгъла на “Дондуков” и “Будапеща”, след 19:00. Всякакви админи и хора, които искат да почерпят админи са добре дошли.
(добре, че някой ми напомни, щях да пропусна)

(за Варна ще пиша после)

Спи ми се ужасяващо, та ще направя поне бегъл опит да съм кратък.

Бях тия два дни на криптографска конференция в Оряховица. Добре, че Титов си спомни, че имаме да ходим, щото аз тотално бях изключил и в неделя вечер събирах спешно багаж… Пристигнахме към 12 вечерта, пихме с хората до 1-2 и станахме сутринта в 7. “I’m too old for this shit”, както е казал народа.

(Именуването на селищата в България е ужасно. Има Горна Оряховица, Долна Оряховица, Оряховица, Оряхово и Оряховец, например, и ако не помниш за кое точно са ти говорили може да се озовеш на майната си. Това е и без да споменаваме колизиите)

Гледах да не пропускам от лекциите, като някои от тях ми дойдоха много (нещата за дискретния логаритъм съдържаха твърде много математика за заспалата ми глава), но имаше и доста интересни неща. Едното беше e-voting-а и една примерна система („a href=”https://vote.heliosvoting.org”>Helios) – там забавното е, че позволява да сумираш криптирани числа, без да виждаш какви са числата всъщност (лекцията има втора част, но е в ранната сутрин утре, та ще пропусна). Друго беше иде
ята за proxy re-encryption и методите за делегиране на тая възможност, като това
и предното ме накараха да се замисля да проуча ElGamal, понеже и двете се базир
ат на него.

Третото и най-интересно за нас беше searchable encryption, който би имал приложе
ние и при нас. Лошото е, че текущите варианти leak-ват доста информация при заяв
ки, но вероятно схемите подлежат на подобрение.

Имаше и забавление – един introductory CTF с 4 задачи – разделиха ни на два отбора и ни дадоха да решим задачите и да видим кои ще се справят по-бързо. Задачите бяха елементарни (като за увод) – едно декриптиране, една програмка за reverse-engineering (да се извади един ключ), една за exploit-ване (супер лесна) и един
pcap файл, от който да се извади telnet парола.
(около тоя CTF вече съм сигурен, че не мога да чета асемблер, та за reverse-ването си търсих C декомпилатор, с който да я обърна до нещо, което мога да чета. Силно ме е срам).

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

(а самото място е много приятно, сравнително тихо (като няма спорещи математици наоколо:) ) и доста чисто и хубаво направено. Аз очаквах да изглежда древно и по
социалистически и бях доста приятно изненадан.)

Идва VarnaConf (за трети път), имаме и CfP.
Имаме и fb event.

(ако някой има проблеми с CfP-то, да ми пише директно на мен)

Записите от БургасConf.

Понеже местим офис и ми се събраха хиляда неща на главата, ще отложа писането на презентацията си като лекция.

От другите интересни работи – започнал съм да изчитам събраните съчинения на Оруел, за момента съм приключил с първия от 11те тома журналистика/есета (I have tried to tell the truth) и е доста и интересно. Отнема обаче доста време,
понеже редовно човек трябва да спре да помисли, а книгите са дебели, с не-особен
о-голям шрифт.

А на мен постоянно ми се спи.

И мина BurgasConf.

Проведе се в хотел “Аква” (в доста по-добре проветрена зала от миналия път) и тоя път bulstream (т.е. Guru) правиха streaming-а и ползвахме доста други камери, та има сериозна разлика от стандартните неща.
(Guru и Елена правиха режисурата, хвалбите по темата са за тях).

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

От лекциите тази на Мариян беше доста интресна, тази на Кунев ще трябва да я видя (щото я проспах, нещо едвам гледах), а моята не съм и написал още текста, но може да си свалите самата презентация. Учудващо е как за втория слайд даже не ме гледаха лошо – обяснявах как градът ми действа депресиращо, заради морето, слънцето, пясъка и кресливите морски лешояди (известни още като гларуси).
Моята лекция не беше нещо особено и в нея няма нещо ново – реално е нещо от типа на “ето това е някаква малка част от текущата ситуация, ако искате, ровете повече, просто да знаете, че е зле”.

И понеже вече в Бургас имам две депресиращи лекции, измислих вече трета за догодина, като темата е малко изнервяща и за мен самия – hack-ове на ниво хора (нещата от “Невидимата горила”, “Мисленето” на Канеман и т.н.). Да видим дали ще събера желание да я направя.

(записи и т.н. не зависят от мен, но ще пусна информация като излязат)

Ще има BurgasConf. Данни за събитието има на самия сайт, аз ще водя лекция за странни неща от security-то в реалния свят (ключалки и такива работи).

(до тук май направих лекции колкото за предишните две години и се очертават поне още една-две. Трябва да взема и да свърша малко работа…)

(презентацията)

[slide 2 Идеята за тази лекция]

Идеята за тази лекция ми дойде около няколко разговора с различни хора и от нашият опит с правенето на pCloud. Много често ни се случваше да погледнем конкуренцията как е направила нещо и да се ужасим в първия момент.
(а след това да се зарадваме, че се срещу нас има такива хора)

За всичките неща, за които ще говоря има лесни решения – прости като идея и сравнително лесни за реализация, като правенето им трябва да доведе до един по-добър свят.

Също така в историята има много случаи на проблеми, които са се случвали и за които всички са забравили или просто са отказали да обърнат внимание.

Нищо от това, което ще кажа не е особено ново, гениално или изобщо велико откритие. Всичкото е откриваемо с малко четене в google, wikipedia и от време на време някоя книга. Извинявам се предварително, че нямаме осигурени възглавници за хората, на които ще им се доспи от скучните неща, които ще разказвам.
(ако четете това като текст – нищо против нямам да го ползвате за приспиване)

[slide 3 Защо ние го говорим това]

Ние харесваме добре написаните неща. Също така се стараем да сме максимално отворени откъм API, код и т.н., и за това държим да правим неща, от които да не се срамуваме, или даже да се гордеем с тях.

Също така съм съвсем наясно, че тази лекция звучи като безкрайно фукане. Поне половината е такава :) За това искам да отбележа, че доста от тези грешки сме ги допускал и ние, в този или предишен проект.

[slide 4 Кои сме ние]

Минутка за реклама – ние сме cloud storage услуга, направена правилно. Startup сме, има ни от около година, имаме около 600k потребители и 600TB заето място и правим всякакви интересни неща, за които обаче ще ми трябва тричасов слот, че да ги изброя :)

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

[slide 5 Authentication]

Почти всички услуги трябва да пазят в някакъв вид пароли за потребителите си и да им дават да влизат в системата, за да получат достъп до някаква допълнителна функционалност. Човек би си помислил, че това е изчистено и изяснено и трябва да няма проблеми…

[slide 6 Стандартен метод за auth]

По принцип в повечето случаи влизането в системата се реализира чрез изпращане на user и парола и получаване на отговор/token, с който да работим след това.

Което е лоша идея, понеже паролата ви минава по мрежата в някакъв вид, и не може да сте сигурни дали някой не подслушва или дали някой не се прави на отсрещния сървър.

[slide 7 Правилен метод]

Правилният метод, който използва един прост криптографски примитив, се нарича challenge-response. Има и реализация в самия HTTP протокол, т.нар. digest authentication, както и в много други системи (например SIP). В web твърде рядко се среща, поради нуждата от още една заявка (или поради неинформираността на разработчиците).

Работи по следния начин:
Сървърът ви генерира nonce – някаква стойност, която е произволна, няма да се повтори пак. Смятате криптографски hash в/у нея и паролата и изпращате резултата на сървъра. Той от своя страна може да направи същото изчисление и да разбере, че вие знаете същата парола.

Така никаква информация за самата ви парола не минава през мрежата, така че дори някой да се представя за сървъра, няма начин да бъде научена.

Методът е по-бавен от другия, понеже изисква още една заявка (да си вземете nonce, с който да работите), т.е. вкарва още един round-trip. Това не е проблем, понеже това така или иначе не трябва да е особено бърз процес – т.е. колкото по-бърз е, толкова по-лесно може да се използва за brute-force атаки.

Тази схема с малко разширяване дава възможност и клиентът да потвърди, че сървъра има паролата (т.е. да се получи двустранна auth.), което ще ви оставя за домашно :) Ние все още не го реализираме, но е в плановете за светлото бъдеще.

[slide 9 Plaintext в базата данни]

Пазенето на паролите се оказва проблем, който твърде малко хора успяват да решат.

Така като гледам, сме 2014, и все пак се случва някоя сериозна услуга да пази паролите в plaintext. Това в някакви моменти е удобно – lost password функционалността може да ви прати директно паролата по пощата (сигурността на което няма да обсъждам).

От друга страна обаче, поне няколко услуги биват hack-нати всяка година и паролите им попадат в ръцете на лоши хора (или в целия internet). Това е доста неприятно за потребителите, понеже те въпреки съветите на експерти и други заблудени люде все пак използват същата парола на много места, което води до допълнителни пробиви и подобни неприятни проблеми.
(съвсем скорошен пример – преди седмица-две-три източиха на ebay паролите)

[slide 10 Първи лесен (и грешен) вариант]

Първото решение на проблема, което е лесно и грешно, е просто да се съхранява някакъв криптографски hash на паролата – md5 (много-лоша-идея) или sha1 (не-толкова-лоша идея). Това се атакува тривиално с rainbow таблици.

Съвсем накратко, rainbow таблиците са пресметнати таблици с (почти) всички възможни пароли, така че лесно да може да се намери в тях някакъв валиден string, който да отговаря на дадения hash. Също така имат метод за съхраняване на по-малко данни, та по принцип за md5 таблиците са под 2TB, за sha1 има таблици с повечето пароли пак в някакъв такъв размер.

Накратко – лоша идея.

[slide 11 Втори лесен (и правилен) вариант]

Второто решение (и първото работещо) е известно на света от поне 1970та година, от хеширането на паролите в старите unix системи, дори в повечето езици името на функцията – crypt() идва от там (тя дори не криптира).

Идеята е проста, генерираният hash да е на някакъв salt и паролата. Salt-ът се подбира да е различен за всяка парола, и се слага преди получения hash. Така лесно може да се пресметне, но не може да му се генерира rainbow таблица (т.е. ако се генерира, ще трябва да съдържа и възможните salt-ове).

[slide 12 Трети не-толкова-лесен (но правилен) вариант]

Третият вариант, който може да се използва (и който сме реализирали при нас) е да се пази “частичен” hash на паролата (т.е. по-точно пълния state на hash функцията) и някакъв salt, така че да може и да се реализира challenge-response. Това ни отне малко повече време за реализация, но така не пазим пароли в plaintext и можем да реализираме challenge-response, за да гарантираме максимална сигурност на потребителите си.

Много близко е до lenghtening атаката в/у хешове.

( Корекция след самата лекция: Реално погледнато, challenge-response може да се реализира дори с хеширани пароли по предишния начин)

[slide 13 Четвърти (велик и труден за правене) вариант]

И последният метод, който дава най-голяма сигурност, и който не съм виждал реализиран никъде, освен на една лекция. Идеята му е в общи линии като на password-authenticated key agreement протоколите, повечето от които поне доскоро бяха патентовани и като цяло не се срещат особено често.

На база на паролата се захранва един pseudo-random генератор, от който след това се генерира двойка RSA ключове (частен и публичен). На сървъра се дава само публичния ключ, а клиентът няма нужда да пази нищо, понеже от паролата може да генерира същата двойка когато си реши. Автентикацията става чрез стандартните схеми за RSA и дава възможност да се пазите от всичките атаки по-горе, и дава още едно ниво на сигурност – ако някой ви се добере до базата на сървъра, с информацията после няма да може даже да влиза при вас, т.е. даже няма да има нужда потребителите да си сменят паролите.

За съжаление не съм виждал никъде реализация на схемата. Описанието и видях в една лекция на Дан Камински преди няколко години.

[slide 14 Further reading]

И понеже темата е доста обширна, може да потърсите този стандарт – password-based key derivation function, както и да погледнете конкурсът за нови такива алгоритми за съхраняване на пароли, може да са ви полезни.

Специално PBKDF2 показва едно доста важно свойство на всички тези схеми. Важно е проверката на паролата да не е максимално бързо действие, а да отнема някакво малко, но достатъчно време, така че да да се направят brute-force атаките по-трудни.
Самият PBKDF е схема за прилагане на хеш функция много пъти (1000, 10000 или нещо такова) върху входни данни и salt, така че от това да се получи някакъв набор битове, които да се използват или като съхранена парола, или като ключ за нещо друго. Поради големия брой действия, които няма как да се направят по-лесно, лесно може да се сметнат параметри, които да ви дадат нещо като 10ms за извършване на сметката, което да доведе до невъзможност да се правят повече от 100 теста в секунда на един core.
М/у другото, пример за използвана такава схема е WPA при wi-fi мрежите – там ключът за комуникация се генерира с pbkdf2 с 1000 пъти sha1 и essid-то (името) на мрежата за salt. Ако някой е пробвал да чупи такива пароли знае, че върви доста по-бавно, отколкото просто на хешове.

[slide 15 Комуникация]

Изразът с тъпата брадва идва от едно изречение на Дийкстра, “Молив не може да се наостри с тъпа брадва, същото важи и за 10 тъпи брадви”. Подобен израз, който може би е по-подходящ (и за който се сетих на лекцията) е “Манчестърска отвертка” – която всъщност е чук, идеалният инструмент за решаване на всякакви проблеми.

[slide 16 Стандартни неща]

По принцип всичко живо използва JSON и HTTP. Те са бавни протоколи, текстови, с много overhead и не-чак-толкова удобни за parse-ване (добре поне, че има такива библиотеки в почти всеки език).

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

[slide 17 Трябва алтернатива]

Добре е да имаме алтернативи. Не всичките ни клиенти са browser-и, но всички са принудени да ползват интерфейси, писани за тях, което е доста неприятно и на моменти – много неефективно (но понеже хората са свикнали, вече не обръщат внимание). Най-добрият пример е какво ползват мобилните приложения – все http базирани api-та, а те уж са устройства, които трябва да пестят от батерия и CPU колкото се може повече.

Дори в самите browser-и вече не е това единственият подходящ и ефективен начин – в момента навлизат websockets и webrtc, точно заради това.

(имах въпрос от публиката после защо нещо не съм много оптимистично настроен по темата webrtc, човекът (Лъчко всъщност) се надявал да може да замести skype – понеже това, което реално успява да прави skype е да работи през всякакви мрежи и NAT-ове, което за останалата телефония е сложно и не се справя толкова добре. Webrtc-то още не е стигнало да бори наистина сериозно такива проблеми и вероятно ще му трябва доста време, докато започне да се справя с тях).

[slide 18 Примерен binary протокол]

По тази причина ние сме направили допълнителната възможност да може да се комуникира с интерфейсите ни през просто binary api.
Като казвам просто – то наистина е такова, описанието му се събира на няколко страници, реализацията (която имаме публикувана в github) е 700 реда на C или 536 реда на java, заедно с коментарите. Има много по-малко overhead, и се обработва много лесно на всякаква платформа. Също така в себе си има няколко хитрини, например ако в даден пакет определен string се среща повече от веднъж, съдържанието му се пази само на едно място и останалите са reference.

Разбира се, има и други варианти – в един предишен проект сме използвали protobuf (който се оказа доста удобен), има msgpack и какви ли не още отворени проекти с публични реализации за повечето платформи.
(ползвали сме protobuf за един друг проект и даже аз, дето по принцип не пиша код се оправих съвсем лесно да си parse-вам данните)

[slide 19 QUIC и пътят напред]

И да слезем по-надолу – един от проблемите в съществуващите протоколи е, че осъществяването на връзка е бавно. Нужни са 3 пакета (и 1 RTT), за да се осъществи връзка м/у две точки по TCP, а когато добавим SSL/TLS, добавяме и още 2-3 RTT-та в зависимост от някои настройки на протокола.

Едно от съществуващите решения е разработка на google, казва се QUIC – Quick UDP Internet Connections, протокол, който замества комбинацията от TCP+TLS. Има в себе си всички полезни неща от TCP, като правилните алгоритми за напасване на скоростта и congestion avoidance, но криптирането в него е по подразбиране, и осъществяването на връзка става в рамките на едно rtt, заедно с избирането на ключове и т.н..
Има също така интересни feature-и, като например multiplexing – да се обработват няколко заявки в една връзка (като в SCTP). Друго нещо е forward error correction, да може да коригира грешки в пакетите или изгубени такива по вече пратени данни.

Ние сме в процес на разглеждане на протокола, ако ни хареса достатъчно, мислим да го използваме. В момента има поддръжка в chrome и opera, ако придобие достатъчно разпространение, ще реши проблема и с firewall-ите. Разработката на google е пусната под BSD лиценз, и е сравнително малко код на C++, та би трябвало скоро да се появи и на други места.

Като цяло, струва си да прочетете описанието, протоколът е пример как трябва да изглежда следващото поколение internet протоколи.

[slide 20 Употреба на SSL/TLS]

Ако не сте живели под камък в последната година и половина, вероятно сте наясно защо е важно да се ползва криптиране на връзките и по принцип SSL/TLS.
(ако сте, питайте търсачките за Edward Snowden)

Вече повечето услуги имат поддръжка за TLS – отне години и доста лобиране/мрънкане от страна на общността, но е често срещано. Не винаги е реализирано правилно обаче…

[slide 21 Правилна употреба на SSL/TLS]

Първото е, че в твърде много случаи не се обръща внимание на шифрите, които се използват, съответно сигурността на връзката с някои места е почти същата като за без криптография. Пример за това е как преди около година Android смениха списъка си с поддържани шифри/алгоритми и приоритетите им, понеже “в java стандарта било така” (предишния им списък беше взет от openssl). Java 6 е стандарт на около 10 години и в новия е оправено…

Друго важно нещо е т.нар. forward secrecy – това е възможността след осъществяването на връзката двете страни да разменят през DH или друг алгоритъм ключове, които са само за тази сесия и се забравят след нея. Така се подсигуряваме, че дори да изтекат главните ключове на сървъра, то записаната от преди това комуникация няма да може да се декриптира и ще остане тайна.

За заинтересуваните хора, които имат сървъри – на този сайт може да проверите поддръжката си на подходящите алгоритми и шифри, резултатът може да ви е интересен.

И разбира се, SSL/TLS не е панацея, и те имат собствени проблеми (като например heartbleed наскоро).

[slide 22 SSL/TLS Session caching]

За услуги, които имат повече от един физически сървър, който поема криптираните сесии (но на същия domain), има друг полезен момент – да се реализира глобален SSL session cache, който да пази определени параметри, за да не се renegotiate-ват всеки път. Това спестява едно RTT от всяка заявка и определено се усеща.

За целта може да ви се наложи да използвате някакъв backend storage (memcache или redis), в който всичките ви сървъри да пазят тези сесии, но да се подкара не е особено сложно и може да има видим ефект за потребителите ви.

[slide 23 Privacy]

Много услуги правят грешката да разкриват информация за потребителите си, която реално не трябва да излиза извън тях. Например често през някоя функционалност, като lost password или invite може да разберете дали даден потребител е регистриран в услугата.
Това е неприятно, понеже улеснява всякакви атаки в/у вашите потребители, особено ако не сте ориентирани към разпространяване на информацията на потребителите ви и продаването и/им (като почти всички социални мрежи)
(корекция от публиката на лекцията – всички социални мрежи)

Примерът за разкриването дали даден файл (което btw е проблем, който идва основно от дедупликацията в повечето такива услуги) е как един определен service можеше да му кажеш “аз ще ти кача файл с тоя MD5” и той казваше “а, аз го имам, заповядай”. Това за известно време сериозно се използваше за share-ване на файлове без реално да се вижда какво става…

[slide 24 Не всички клиенти са равни]

Изобщо, на моменти имам чувството, че много от интерфейсите са правени от някой, който приятелката му го е зарязала заради някой developer и той сега държи да си го върне. Представям си човек, който стои в тъмна стаичка, пише спецификация и си мисли “и аз на теб да ти го …”…

Няма един правилен интерфейс, един правилен начин, един пръстен, който ги владее и т.н.. Колкото и да ни се повтаря от някакви хора, които нямат въображение, няма да стане вярно :) Има нужда от интерфейси, който да са удобни за различни хора, по различен начин, от различни среди и различни начини на мислене.

[slide 25 Предаване на параметри]

Например, предаването на параметри. При нас параметър може да бъде предаден където ви е удобно – като GET, като POST, в URL-то на POST-а, или в cookie. Даваме ви възможност за прострелване в крака, но от друга страна ви даваме начин да ни ползвате от възможно най-простите клиенти на тоя свят, които нямат POST.

[slide 26 обработка на request-и в движение]

Нещо, което е повече в категорията “имам тъпа брадва и искам с нея да остря моливи” – ужасно много услуги обработват заявката, след като я получат цялата. Ако качвате файл, който трябва после да отиде по други машини, имате една очевидна латентност, дължаща се на последвалата обработка.

Това се дължи най-вече на ползването на HTTP и криви сървъри, и като цяло може да не е така – повечето content може да се обработва в реално време, докато се качва – да се копира на други места, да му се смятат checksum-и и какво ли не още. Не е нужно да караме потребителите да чакат, само защото нас ни е домързяло да направим няколко прости подобрения.

[slide 27 blatant self-promotion]

И оставащата част от презентацията е хубави неща, които са специфични за cloud storage услуги, или “защо ние сме по-добри от останалите”. Не само ние правим тези неща, но май само ние правим всичките.

[slide 28 Thumbnail combining]

Нещо, което пак идва от тъпата брадва на HTTP/AJAX и компания – ако имате да покажете галерия от thumbnail-и, няма смисъл да ги дърпате един по един. Много по-ефективно е да може да ги комбинирате в един голям файл и да ги показвате, докато пристигат.

Конкретните методи за това са доста грозни (thumb-овете, изредени по един на ред в base64 и се декодират после), но си личи промяната в скоростта.

[slide 29 On-the-fly zip]

Нещо, което идва основно от мързела на разработчиците – не е нужно да генерирате zip файл и така да го дадете на потребителя, може директно да му го stream-нете, понеже zip-ът е такъв удобен формат (явно идва от времената, в които е трябвало да може да се пише на лента). Не е единственият такъв, но е пример за как някои неща могат да се случват моментално, вместо да се изчакват.

[slide 30 Rsync-подобен протокол]

Rsync съществува като идея от времената, в които аз бях младши системен администратор, но по някаква причина не се среща достатъчно често като идея в повечето услуги.

Идеята е много проста – ако от едната страна имате част от даден файл или негова по-ранна версия, е много по-лесно да копирате само разликите, а не целият файл. Поддържаме го и в двете посоки – и за качване, и за сваляне на файлове, като самата идея не е сложна за реализация, дори и в web приложения. Не ползваме директно rsync протокола, понеже не пасва добре в нашия интерфейс, но сме сравнително близо, и също така за една част от хешовете използваме друга функция, понеже се оказва по-удобна.

(още нямаме качена документацията за метода, понеже не остана време, обещавам да я качим в най-скоро време. Ще качим и код, който го реализира.)

[slide 31 Видео с напасващ се bit rate]

Една хубава възможност, която доста video услуги биха могли да предлагат – да се напасва bitrate на видеото към връзката ви (т.е. да не праща с повече, отколкото вие може да приемете), което прави възможно да гледате видеа и на доста неприятна връзка.

[slide 32 Файлови операции]

И накрая нещо, което е повече интересно, отколкото важно – интерфейсът за дребни промени по файловете, редакция на място е доста удобен и помага да се пренесат различни приложения и действията им директно към storage услугата.

[slide 33 Други готини неща за в бъдеще]

Тук исках да кажа и други неща, но не ми стигна времето да ги извадя.

Това е един план за светлото бъдеще (в рамките на годината) – да направим end-to-end криптиране на файловете на потребителите, т.е. да им дадем функционалност, чрез която те още при себе си да криптират всичко и да не можем да го четем, както и да са сравнително сигурни, че не не им подменяме или омазваме файловете. Би трябвало всички да го правят – реално погледнато няма причина нещата, които са лични за потребителя да могат да бъдат известни на оператора на услугата, и има доста разработки по въпроса.
Например, има дори няколко paper-а по темата за криптирана база данни – тя стои криптирана на един сървър (който няма ключовете), вие пращате криптирана заявка, сървъра прави някакви сметки и ви дава отговор от вашите данни, който също е криптиран и който само вие може да разберете. Все още нещата са в начални стадии, но са една добра идея за бъдещето.

[slide 34 Отворени сме към други идеи]

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

Приемаме всякакви корекции и идеи – по принцип имаме натрупана работа като за 3-4 години напред, но това още не е успяло да ни уплаши :)

Smallman си издадоха третия албум и направиха концерт в Terminal 1.

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

Преживяването беше супер. Свириха си новия албум и доста от хубавите стари неща
(например Ocean), не говориха много, просто свириха и радваха хората (аз мисля, че бях ухилен през повечето време). Дори невероятната гъчканица (билетите бяха свършили бързо, даже 80те допълнителни за разпродаване на входа) не можа да ми помрачи удоволствието.

И мисля както съм вече прилично неадекватен да си легна.

Точно преди една година ми направиха дупка в главата.

Не знам дали станах по-добър човек (по-скоро не), но освен някакви дребни болки
не е имало никакъв друг проблем след това. Да не те боли е хубаво нещо.

(Ася, благодаря)

Тия дни си смених (пак) заглавието на блога, и от нямане на работа (или по-точно като почивка от разни неща, като например писане на лекции) и поради повредите, които се получиха в главата ми от четене на философски и подобни книги (“Моите правилни възгледи за всичко” на Лешек Колаковски (бля), книжката с афоризмите на Талеб (клишета от задник) и “The other side of sadness” на George Bonanno (страхотна книга)) реших да попиша малко глупости.
(приемете предното гигантско изречение като предупреждение)

(“In this moment I am happy” не знам откъде идва, брат ми си го беше написал на вратата едно време)

tldr: Светът/животът са прекрасни.

Та, светът е прекрасен. Слушам много хора да се оплакват от него, от живота и вселената като цяло, но това винаги е една изкривена картина, в която са извадени само нещата, които не им харесват.

Има няколко важни неща, които се пропускат:

Повечето проблеми са временни. Времето ги оправя, ние ги забравяме, или просто осъзнаваме колко незначителни са. Рядко има смисъл да им даваме да ни пречат да се радваме на живота.

Винаги има нещо интересно около нас. Да ти е скучно е признак или на някаква депресия, на тъпота или просто на нежелание да се направи нещо по въпроса. Човек с достатъчно желание и малко вътрешен мир може да си живее добре даже сам в главата си (както аз правя от време на време).
(като допълнение – винаги има нещо хубаво наоколо)

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

В общи линии как се чувстваме е въпрос на личен избор. Дори да ни липсва способността съзнателно да го решим и реализираме, в наши дни се продава достатъчно добра дрога, че да го поправи.

Спасението на давещите се/нещастните/страдащите си остава в техните ръце.

(бяха ми споменали, че звуча будистки – мисля, че будистите са по-скоро на принципа “животът е гаден, ама какво от това/ние ще се справим и ще ни е спокойно въпреки това”, което аз намирам за примиренческо и като цяло за грешно)

(презентация)

[slide 3 Често срещана практика]

(този трик вероятно има някакво стандартно име, което аз не знам, цялата лекция ми хрумна една вечер докато не можех да спя и така и не се зарових)

Много често ни се налага да генерираме token/код, който да изпратим на някой потребител (по страничен канал), за да се удостовери. Едно често срещано решение е да се генерира нещо съвсем random, което обаче води до пазене на твърде много state и много често не е практически възможно.

[slide 5 просто решение – подпис с криптографски hash/hash mac]

Проблемът има просто решение, чрез криптографски (hash) подписан token, от който може да се извади цялата информация, без да е нужно да се гледа някакъв state. Генерира се тривиално, като до информацията се долепя един HMAC подпис с някакъв secret, който ви е познат на вас.
(hmac е метод за прилагане на hash функция, например sha1. Не е добра идея да се използва директно SHA1 или нещо от същото семейство, понеже подлежи на lengthening атака, но може да се ползва SHA3)

Така тази информация се проверява тривиално, и не изисква да пазите каквото и да е и да могат да ви препълнят някакви таблици, да генерират писания в базата и т.н.

[slide 6 Инвалидация на token]

Схемата има един проблем – няма прост начин да се инвалидира. За това има няколко различни workaround-а:
Имаме timestamp, при който знаем кога изтича token-а и като цяло го правим да е валиден за кратко.
Слагаме в него нещо, което потребителя може да промени и така да го инвалидира (например паролата му, чрез смяната и може да ги направи невалидни).
Можем и да пазим кога последно сме генерирали token и да не признаваме по-стари (или по-нови) такива.
В общи линии последните две неща ни карат да питаме външен източник, когато проверяваме token-а, но пак ми дават възможност да държим много по-малко state.

[slide 8 VERP ]

За всички, които трябва да пращат поща и да знаят дали адресът не е bounce-нал – проста схема, в която пишем в Return-path: адресът, на който сме пратили писмото и по отговорите на този адрес знаем кой точно не се е получил. Към това лесно се добавя един прост подпис, така че да не се получават случайни писма при някакво глупаво изчерпване.

[slide 9 TCP Syncookies]

Вече default на всички tcp/ip стекове. Идеята е съвсем проста – ISN (initial sequence number) на сесията, който връщаме в SYN+ACK пакета представлява hash на secret и още няколко неща, така че когато получим третия пакет от handshake, можем да сме сигурни, че този клиент е искал да се свърже с нас.
(За повече подробности потърсете за SYN flood и защита от него).

[slide 10 client-side session]

Също така можем да спестим място от потребителски сесии – можем да пазим само последен timestamp и нищо друго, а самата сесия да е в cookie при потребителя и да не ни интересува. Така можем да сме сигурни, че ние сме му я подали и че не съдържа нещо, което не сме искали.

В четвъртък (15 май), от 19:30 в initLab ще правя пак workshop за озвучаване/записване (като за конференции).