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

И мина 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 за озвучаване/записване (като за конференции).

Никога повече няма да ползва WYSIWYG редактор, за да си пиша презентациите.

(tldr – може да видите какво ползвам в github и да си го нагласяте по ваш вкус)

Преди rogueconf бях решил, че повече не ми се занимава с libreoffice и кривото писане на лекции, та с малко търсене в google и съвети от хора открих pandoc, който се оказа доста удобен инструмент – от markdown генерира pdf презентации (и reveal.js и други такива бози), като сгъва markdown-а до latex, и от него прави pdf чрез beamer модула. Пример за това може да се види в лекцията ми от rouge2014.

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

В крайна сметка стигнах до setup-а от github repo-то горе, който изглежда по следния начин:
В един .pandoc файл си пиша презентацията, и след всеки slide – текстът, в html коментар (който pandoc-а игнорира);
Чрез Makefile (щото съм мързел) от .pandoc файла генерирам:
презентация (с разни параметри, които ще разкажа);
бележки (реално текстът на .pandoc файла, подреден чрез a2ps така, че да се събира добре на landscape A4 листи);
blog post, който казва номер на slide, заглавие и след това текста от коментара (което се прави чрез тъп php скрипт, който си написах).

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

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

–slide-level 2 – на колко “нива” са ви slide-овете. Примерната презентация е на 2, тази за pCloud api-то е на 3, като май 3 е идеално за нормално 40-минутна презентация и изглежда много добре с тая тема (Warsaw), понеже така отгоре се виждат секцията и под-секцията. Мисля, че май първо видях Харалд Велте да ползва нещо такова и бая ми хареса, но не бях мислил как го прави.

–template beamer.my – наложи се да пипна стандартния beamer template, щото по default не изкарваше кирилица (за pCloud-ската го използвах и да сложа логото в нея, което беше бая куц процес). Също така там има едно място, в което може да махнете да показва slide-ове за тези, които не са от най-долното ниво (т.е. в примерната презентация да няма “проблемът”, “решението” и “примери”).

-V colortheme:krok – има beamercolorthemekrok.sty в директорията, което е crane color theme от beamer-а, само че със сменени цветове (при мен зелено, в pcloud API-то – странно синьо).

Разбира се, може да си изберете и други теми, на този сайт има матрица с комбинациите от тема и тема за цветовете (темите за шрифтовете са малко и май default-а е ок).

Цялото нещо си има и проблеми – добавянето на лого беше супер мъчително (и стана със странен hack, в който не ми се навлиза), да се влияе на шрифтовете от markdown-а до latex-а е малко сложно, и има някакви странности (например, като сложех коментар веднага след заглавния slide, ми добавяше един празен). Също така ако не знаете latex (като мен) може да ви е доста криво да си правите някакви custom неща, но па google е добър приятел и даже в stackoverflow им texexchange, където хората редовно си задават такива въпроси и може да намерите нещо полезно.

Почваме “турнето” тази година с PlovdivConf (2014), на 17ти май, повече подробности (ще) има на страницата. Също така от тази година пускаме тестово frab, та сега всеки може да подаде заявка за лекция.

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

Утре (2ри май 2014, от 14:00) ще има How to Cryptoparty workshop/лекция в initLab, дошъл ни е на гости един младеж от Берлин да ни сподели опит. Това ни приближава още малко към по-генералната идея за такова събитие.

(ще се записва)

(от 13:00 ще правим setup-а за записа и ще обяснявам как се прави, ако на някой му е интересно)

И така, да напиша за представянето на отборите, което продължи 6-7 часа (издържани само заради няколкото чаши Lagavulin).

(списък на отборите и source код)

Отбор 1 – FMI free time (отборът се състоеше само от един човек – Атанас Керезов, който в момента ми е на върха на класацията за дразнещи хора). Беше започнал система, която да може да се ползва за уговаряне на време за посещение на администрацията (като системата на КАТ), но не беше стигнал до никъде.

Отбор 2 – Old school – бяха написали система за тези, които могат да получават стипендии, да си попълнят данните и да могат да следят къде са в класирането. Не можах да си задам въпросите, че бързо ги изгониха, но се зачудих колко лесно ще е някой да смени IBAN-ите, които се подават, и да получи на хората стипендиите.

Отбор 3 – voltron – тук ми се губи и бележките не казват много, беше някаква система за дарения и следенето на развитието на кампаниите.

Отбор 4 – hackfmi_se – отбелязал съм, че са имали ужасна презентация. WordPress plugin, който да помага на за документите на докторантите, който и се оторизира през СУСИ (което прозвуча като перфектния backdoor да се събират user-и и пароли и да се използват за системата на втория отбор да се сменят IBAN-и).

Отбор 5 – noex1t – plugin за chrome, който може да разпознае encoding-а на даден текст и да го визуализира както трябва да е. Това беше една от малкото сериозни теоретични разработки – ползва речников метод, и може да разпознава дори прекодиран през две кодировки текст (например UTF8, закаран до cp1251 и после пак до UTF8). За това ползваше външен service (за което аз го питах дали не е privacy concern, хората да си пращат части от личната кореспонденция на трети лица, и той отговори, че за до две прекодирания може да го прави от plugin-а и няма да се налага). Човекът до мен имаше въпрос, който не успя да зададе, дали ако има текст на два езика в подаденото нещо, няма да се обърка системата.

Отбор 6 – hack Bulgaria, в който беше и Радорадо – бяха разработили интересна идея, API, чрез което може да се събират задачи (да речем по програмиране) и от тях да се генерират контролни. Към тях имаше мета-данни, та да може да се направи приложение, което приема отговорите и ги проверява. Изглеждаше доста добро и удобно, интересно дали ще намери приложение.

Отбор 7 – СМГ11 (хора от СМГ, 11-ти клас :) ) бяха направили система, която даваше възможност на кандидат-студентите на едно място да видят и сравнят различни специалности в различни университети, доколкото биха им били интересни/полезни. Имаха и система за рейтинги, т.е. можеше да се отбелязва коя специалност е хубава и коя не (по няколко признака). Цялото нещо беше работещо и това беше отбора, за който гласувах с 3 точки.
Питах ги как решават следния проблем – решавам, че някоя специалност е много трудна за влизане, та пускам един ботнет да гласува против нея усилено, хората виждат, че е с нисък рейтинг и се отказват да кандидатстват, което ми дава доста по-голям шанс. Нямаха решение, но ако я пуснат, с удоволствие ще се включа с нещо. Не ми се мисли колко ще ги мразят някои ВУЗ-ове…

Отбор 8 – VPR (на които бях ментор) – бяха направили система за помощ с бърз response, т.е. хората казват “трябва ми помощ за едно контролно утре”, дават краен срок, да речем половин час, след което чакат някой да влезе в системата, да хареса въпроса им и да се свържат. Системата им предлага свързване по някакъв chat в реално време (планираха да направят и видео/аудио разговори, но не им е стигнало времето), както и търсене по тагове на търсещи.
Демонстрираха работеща система, въпреки проблемите с internet-а.

Отбор 9 – full metal team – бяха едно количество деца от ТУЕС, които даже в началото в представянето си доста добре се избъзикаха с всички фирми, които се бяха представили (“имаме много офиси, навсякъде по света…”). За съжаление така и не схванах какво им прави системата, и съм си отбелязал да ги питам, но не стигнах до там.

Отбор 10 – #чичковитечервенотиквениковчета – бяха реализирали една идея по задание от реална организация, сайт за дистрибуция на книги. В общи линии има вариант да се задава търсещите организации (детски домове например) какво търсят, или някой да каже “ей-тука имам тия книги”, или “имам два кашона, дето искам да се отърва от тях” (т.е. конкретно моят случай :) ), и системата да се погрижи да свърже който с когото трябва и да улесни организирането на пренасянето. Ще чакам да кажат къде ще е deploy-ната и ще ги ползвам с удоволствие…

Отбор 11 – Едногор – пак хора от ТУЕС, в общи линии опростен web клиент за youtube, който да може да се ползва и на по-слаби машини. Филтрира реклами, всякаквите глупости от страни и показва само заглавие и самото клипче. Няма и autocomplete (за което хората питаха).
На въпроса “ако си сменят api-то, така че тоя клиент да не работи, т.е. ако тръгнат да го спират той какво ще направи” отговорът беше “това отне ден и половина да се напише, за следващото ще е пак толкова” (и цялата зала ръкопляска).

Отбор 12 – ПодайМонстъраТам – търсачка за къде може да се спортува, в общи линии overlay на карта и географско търсене или такова по думи. Данните вътре те си ги въвеждаха/минаваха някаква модерация.

Отбор 13 – ДГ – беше система за организиране на дарения, базирана на wordpress. Идеята им беше хората през сайта да се уговарят, и даващите получаваха код, чрез който да си изпратят исканите неща. Имаха няколко метода за транспорт.
Питах ги тоя код, който се ползва как го генерират и могат ли 1) да го опростят или 2) да сложат в него някакъв error correction, понеже хората доста грешат, когато преписват.

Отбор 14 – recaro (бях им ментор) в общи линии имаха да решават traveling salesman проблема, но това, което показаха беше най-вече хардуер, който се връзва в колата и показва на шофьора какво има да разтовари, както и праща нагоре колко му е пълен резервоара, така да може от централната система да се следи какво се случва и да се праща към бензиностанция.
Имат възможност да вържат системата към CAN bus-а в колата, както и да сложат сензор в резервоара (ако е много стара), иначе частта в колата беше правена/писана с някакъв PIC18. Като цяло беше недовършен проекта и ми се стори леко странен.

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

Отбор 15 – madeinbg – търсачка за продукти, правени в България. Пак стандартна снабдителна задача, производителите попълват, хората търсят, като има и някакви chat-ове вътре, с които хората могат да задават някакви въпроси и т.н.

Отбор 16 – УТ (обратното на ТУ, понеже са от там) – модулна платформа за всякакви приложения, свързани с благотворителност, заедно с едно примерно, за размяна на дрехи. Питах ги какво им е API-то и как може да се пише нов модул, казаха, че още не е документирано.

Отбор 17 – оркестър без име – бяха направили система за отбелязване по карта на интересни събития, които се случват в момента, например улични музиканти. Даваха възможност да се правят снимки (и в бъдеще – клипчета) и да се качват заедно със събитието, като нямаха идеята за live streaming. Цялото нещо беше хибридно мобилно приложение (т.е. html и js), което беше още по-учудващо (повечето такива неща работят с огромен зор).
За да го демонстрират, си доведоха един младеж с китара на сцената да посвири и да го снимат и качат. Това си беше малко hack в/у журито, нещо от типа на замайване с bells and whistles, и май мина, щото доста хора гласуваха за тях и спечелиха втора награда.

Отбор 18 – Осем – мобилно приложение за дарителски sms-и (които и спечелиха първа награда) – в общи линии агрегатор на всички съществуващи кампании в телефона, като те събират на едно място базата и тя се пресипва на телефона и човек може да си гласува за каквото си хареса (дори да няма internet, така и така гласуването е със sms-и). Оказа се, че на всяка проверка си точат целите данни наново, та ми се искаше да намеря време да им дам идеи как може да си организират синхронизиране само на промените и да пестят доста трафик на потребителите (текущата им база е около 4MB).

Отбор 19 – панда (на които бях ментор) – бяха направили благотворителна система за продаване на content. Създателя на съдържанието го качва, описва го, системата генерира thumb-ове и т.н., след което казва и за кои каузи да отиват парите от продажбите. Имаха реализирани и плащания през един payment процесор.
Имаше въпроси дали пазят кредитни карти (щото се въвеждат на техния сайт) – не, дали правят обработката на content-а в отделен процес/с друг user id – могат, въпрос на deployment, и дали става ясно какви са таксите и къде отиват – може да се expose-не.
Най-учудващото беше, че наистина са успели да го сглобят за два дни, може би трябваше да спечелят повече от трето място :) (вероятно им помогна, че няколко човека от екипа си работят професионално и пишат сериозно)

Отбор 20 – план бе – бяха направили нещо като kickstarter за благотворителност, като интересната част към него беше, че може да се дари обещание за нещо. Идеята на обещанието е, аз казвам – ако някой дари X лева, аз ще му направя курс по програмиране, Александър Тодоров ще му сготви конски кюфтета или нещо такова. Идеята е доста ценна, надявам се да се появи някъде.

Отбор 21 – el romantico, на които бях ментор и които в петък имаха 4 идеи, в събота работеха по пета – бяха направили система за намиране на курсове (т.е. пак снабдителния проблем). Дава се възможност някой да предложи курс, да даде минимален брой хора, които да дойдат, и останалите да се записват. Системата им работеше :) Питахме ги дали имат филтриране по географска локация – казаха, че са го махнали, и нямат също така идея дали курсът в крайна сметка се случва или не.

Отбор 22 – RQ – бяха написали система за резервации в ресторанти и подобни заведения (и не беше ясно дали това има много връзка с благотворителната тематика на hackaton-а). Собствениците на заведения можеха да качват архитектурни скици на заведението си и да обработват заявки за резервации, като поставят хората на определени места. Скиците се работеха като bitmap-и, и резервациите се маркираха просто с правоъгълници, т.е. нямаше анализ и разпознаване на картинки, но бяха докарали пълна работеща система. Нямаха и автоматично разполагане на резервации. Имаха допълнителни бележки към всяка резервация, като metadata как да се разположат хората.

Отбор 23 – парчетата – бяха направили система за следене на заетостта на залите в университета, в общи линии улеснител на учебния отдел, който и работеше. Интересно дали вече няма нещо такова.

Отбор 24 – 42 (на които бях ментор) бяха направили визуализатор на произволни данни в/у карта чрез csv файлове. Ползваха за основа OpenStreetMap. Питахме дали може да комбинират няколко вида данни или да изобразяват функция от два вида (например брой училища на глава от населението за даден регион), нямаха го.
(те имаха доста по-мащабна идея, но явно не бяха успели да я доработят)

Отбор 25 – супер герои – бяха направили “мобилен app за доброта”, в общи линии като контролния дисплей на някой супер герой. Хората подават заявка за помощ през някакъв вариант на приложението, след което всеки докато си върви по улицата може да види къде наблизо има някакви проблеми и да се включи, ако иска. Примерът, който бяха дали е как можем да видим, че някой има проблеми с компютъра и е от нашия вход, и да идем да помогнем.
Планираха да сложат ACK за всеки, който е реших да иде да решава даден проблем, за да не се получава slashdot-ване на някой проблем.
Нямаха добро решение за случая ако някой използваше системата като honeypot, т.е. или да примамва хора, или да гледа къде има пострадали хора и да ходи да лешоядства – казаха, че оставят решението за пускане на заявка за помощ на самите крайни потребители.
Не беше съвсем ясно и какъв точно е target-а на приложението.
(работеше)

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

Отбор 27 – repl5 (бях им ментор) – бяха направили система за генериране на тестове (от тия, дето печатаме, за да изпитваме студентите). Един от менторите им беше помогнал с написването на разпознаването на изображения, за да може да се проверяват по-лесно тестовете.
Имаше бая въпроси към тях: как валидират генерираните тестове, т.е. как знаят, че не са повторили въпрос, или отговор (щото това винаги е бил първия бъг на всичките генератори, които съм виждал) – ще си напишат тестове към алгоритъма; възможност за повече от един верен отговор – имат; схемата им с табличката за попълване на факултетния номер (5 реда с числата от 0 до 9, и човек на всеки ред отбелязва поредната си цифра от факултетния номер) беше лесна за объркване – имат и друга; какво става, когато човек си коригира отговор на листа – разпознаването би трябвало да се справи (това не го вярвам).
Ще е хубаво най-накрая да има унифицирана система за това, но не е ясно дали ще е тази (иначе работи като приложение директно в browser-а на потребителя, само на javascript и генерира pdf-и, т.е. е доста portable, за разлика от много други, дето сме правили).

Отбор 28 – бащата на Кнут Хамсун (проверих в wikipedia, Педер Педерсен) – бяха направили проста система с QR кодове за информация за статуите из ФМИ, на кого са, какво е направил и т.н..
Оказа се, че те пишат в QR-а директно URL (а самия QR е на лист, залепен за статуята), което значи, че ако подменя листа с някакво друго url, хората ще отварят него. Решението им за в бъдеще е, че ако QR кодът е издълбан на статуята, то няма да работи номера с фалшификацията (а самия код е супер издръжлив на опити за промяна).

Отбор 29 – Оги самотния войн – беше нещо за предизвикателства/challenges, но нямам много бележки по него и не беше особено ясен (и не беше стигнал много далече, основно имаше някаква идея).

Отбор 30 – placeholder – бяха направили lock screen, който показва реклами, от които приходите по принцип да отиват за благотворителност. Единствената ми бележка е “ужасна идея”.

(приемам корекции и допълнения, сигурен съм, че имам доста грешки и пропуски)

(неособеноадекватенpost, пишете корекции ако видите нещо)

В последните три дни бях на HackFMI 3. То приключи преди около 12 часа, а сега съм леко адекватен и ще се опитам да напиша нещо по въпроса.

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

(аз бях успял да измисля атаки в/у два от проектите, за които ме питаха още преди разпределянето. Беше забавно.)

Всичките бяха интересни. Записал съм си някаква част от тях:
Единият отбор (VRP) правеше система за комуникация в реално време, да се откриват хората по конкретен проблем и да могат да си пишат и да прекарват аудио/видео в реално време. С тях си говорих за webrtc и как могат да решат проблема с NAT-а и изобщо да прекарат медията, съответно след като открихме, че няма TURN поддръжка в повечето browser-и, двете ми идеи бяха да се срещат през TOR, или да ползват някакъв flash chat (през red5 и нещо такова), понеже е докарано да работи.

Вторият (42) правеше карта на местата, удобни за инвалиди, т.е. overlay в/у google maps или OSM, който да използваш за да провериш къде можеш да отидеш да свършиш определена работа и да е достъпно. Там говорихме откъде могат да събират данни (OSM, OKFN проектите и т.н.), както и че атаката, която аз бих измислил в/у системата е да направя някакви много привлекателни места за такива хора (на картата), да застана там с едно паве и да ги обирам един по един.
(някъде по това време бях обвинен в безчовечност)
(в отбора имаше двама колеги от моя офис)

Третия отбор (El Romantico, който беше в стая 404 и бяха изтървали да се кръстят отбор “Not Found”) имаше 4 идеи (на следващия ден работеше по пета). Две от тях съвпадаха с други, които бях чул, третата беше вариант на patreon/gittip за България (което от няколко месеца и аз мисля), и четвъртото – система за обсъждане, подобна на reddit/slashdot с модерация. На четвъртата идея се появи и Кънев, който разказа една доста добра идея за такава система с гласуване – която дава възможност за конкретни въпроси да си дадеш гласа на някой друг участник в системата, и той да го използва вместо теб (което звучеше супер интересно и жалко, че не го направиха).

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

В събота имаше пак няколко слота за обикаляне по отбори – пак посетих първите (VRP, с webrtc-то), едни хора, които решаваха traveling salesman проблем, като цяло някакви хора, които решаваха проблема за запознаването (“Имаме хора, дето предлагат нещо и хора, които търсят нещо, да им улесним живота”). Едно изключение от тоя тип неща беше изцяло client-side генератор на тестове (такива, дето печатаме на хартия и с които изпиваме студентите) на javascript, който генерираше pdf-и.
(като цяло май много от нещата ми се губят, въпросите и отговорите ми се смесват в главата и не си водех бележки)
Бях взел Велин с мен, и той също остана учуден от това колко интересна е цялата работа, даже в един момент каза “А ако можеше да използваме цялата тая енергия за мирни цели…”.

В неделя нямаше менторстване, та използвах повечето време, което бях във ФМИ да подкарвам frab за различните конференции (в петък/събота Митьо ми беше помогнал да му setup-на deployment-а с puma), та в общи линии вече има frab.it-tour.bg, който тия дни ще пуснем официално.
(wifi-то беше ужасяващо през цялото време, повечето работа, която свърших беше на кабел, това трябва да му се измисли решение)

Последва закриващата част.

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

Започна изслушването на отборите (29 на брой), в около 19:00. Продължи до около 1:30… В един момент дадох на Яна ключовете от нас, да иде да донесе една бутилка Lagavulin, която бая помогна.
(списък с отборите/проектите и с source code-а им)

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

Като цяло изслушването беше интересно и бая тежко (имам един файл с около 170 реда съкратени бележки, от който ще направя като имам време един огромен blog post). Мисля, че аз зададох най-много въпроси (и вероятно съм виновен за поне половин-един час от закъснението, учуден съм, че не ме линчуваха), като доста ги дъвкахме за всякакви начини, по които може да им се счупи системата или защо са взели някакво странно (за нас) решение.
(интересни въпроси задаваха и Пенков, Семерджиев и един човек, който седеше до мен и който май така и не му научих името. Също така, лицето Атанас Керезов е най-дразнещия човек, на който съм попадал в последните месеци и който основно се заяждаше с отборите, вместо да задава смислени въпроси.)

Като интересна статистика – броих, имаше около 20% жени в участниците, но нямаше нито една менторка (следващия път трябва да набутаме Яна да им помогне с маркетинговата част, и да видим кои програмистки биха се престрашили).
Също така имаше няколко ученически отбора – 10ти, 11-ти клас (които бяха даже с придружител, и едните трябваше да им пишат извинителна бележка, щото бяха първа смяна и нямаше шанс да спят достатъчно, че да могат нормално да идат на училище). Имаше и хора от други университети (например отбор на ТУ, който нарочно се беше кръстил УТ).
Спокойно мога да кажа, че в традицията на олимпиадите по информатика развращавахме младото поколение с това да висят ден и нощ, да пият нещо, което да ги държи будни, да пишат, дебъгват и да дремват по половин час по столове/бюра/дивани.

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

Останах малко след края да помогна с изчистването, после се видях с някакви хора пред факултета и в 3:15 се бях прибрал вкъщи, свърших малко работа и умрях. Тая сутрин съм изпил едно кафе и не усещам да има особен ефект…

btw. За всички отбори, на които бях ментор (и за останалите) – ако продължавате тези проекти или по принцип може да ви е полезен някакъв акъл от мен, пишете, идвайте на ИББ и т.н..

Update: Напомниха ми да спомена, ученическите отбори бяха от СМГ, НПМГ и ТУЕС, като май ТУЕС бяха най-представени.

Update 2: А като си тръгвахме в 3 сутринта, имаше някакъв младеж, останал да спи някъде във факултета, понеже имал контролно в 8…

This is my talk from RIPE-SEE3, on the deployment of IPv6 in Sofia University. The presentation can be downloade in pdf or odp format.

I’ve put the slide number or the notes/comments I have in [], the rest is as close to what I said as I remember, with some corrections.

[1]

Hello. I’m going to talk about the IPv6 deployment in Sofia University. It’s an important example how this can be done on a medium-to-large scale, with no hardware upgrades or hidden costs.

This presentation was prepared by Vesselin Kolev, who did most of the architecture of the network there and was involved in its operations until recently.

(I want to clarify, we’re not the same person, and we’re not brothers, I get that question a lot)

[2]

Please note that I’m only doing this presentation, I was not involved in the deployment or any network operations of the university’s network.

[3]

These are the people that did and operated this deployment. Most of them aren’t there any more – Vesselin Kolev is at Technion in Israel, Nikolay Nikolov and Vladislav Rusanov are at Tradeo, Hristo Dragolov is at Manson, Radoslav Buchakchiev is at Aalbord University, Ivan Yordanov is at Interoute, Georgi Naidenov is a freelancer. Stefan Dimitrov, Vladislav Georgiev and Mariana Petkova are still at the university, and some of them (and some of the new people there) are at this conference, so if you have questions related to the current operations there, they’ll probably be able to answer better than me.

[4]

So, let me start with the addressing.

[5]

This is the current unicast network that’s in use in the university. It was assigned around February 2011 and was used from the 11th of February 2011 onwards. It’s a /47, later on I’ll explain why.

Also please note that the maintenance of the records in the RIPE database for the network is done only with PGP-signed emails, to protect this from hijacking. As noted by one previous speaker, there are a lot of cases in RIPE NCC, where bad people try to steal prefixes (as their value is rising), and that’s possible mostly because there aren’t good security measures in place in a lot of LIRs.

[6]

Before that, the university used a /35 from SpectrumNet (since then bought by Mobiltel), until they got their own allocation.

It should be noted that in IPv6, the renumbering is a lot easier than in IPv4 and this was done very fast.

[7]

Now, on the allocation policy,

[8]

this is how unicast addresses are assigned. It’s based on RFC4291, and for the basic entities in the university (faculties) there’s a /60, for each backbone network, server farm or virtual machine bridge there’s a /64, and all the additional allocations are the same as the initial size (on request).
Also, allocations of separate /64 are available for special/specific projects.

[9]

The university also utilizes RFC4139 addresses, for local restricted resources. The allocations are done on /32 basis.

[10]

Now, onto the intra- and inter-AS routing,

[11]

The software used is Quagga on CentOS.
There is a specific reason for using CentOS – the distribution is a recompilation of RHEL, and follows it closely, which means that it’s as stable as it gets – if there’s a security or other important update, just the pieces are backported to the current version of the software, which effectively means that you can have automatic updates running on your servers and routers and be confident that they won’t break horribly.
That’s in stark contrast with almost every router vendor I can think of.

[12]

The current transit providers for the university network are Unicom-B (the academic network in Bulgaria), and SpectrumNet (now owned by Mobiltel).
The university has private peering with Digital systems, Evolink (it changed it’s name from Lirex), ITD, Netissat and Neterra. It also provides an AS112 stub node.

(For the people that don’t know, AS112 is somewhat volunteer project run anycast nodes for the DNS servers for some zones that generate crap traffic, e.g. “example.com”, or the reverse zones for the RFC1918 addresses)

[13]

This is the basic schema of the external connectivity. The university has two border router, each of which is connected to both upstream providers (and to the private peers, but that would’ve cluttered the drawing too much). They’re interconnected through one of the MAN networks, and are in the Lozenetz campus (where the University Computing Center is, the main operator of the network) and the Rectorate.

[14]

These are the prefixes that the university originates. Here we can see why the university has a /47 – so it could be de-aggregated, for traffic engineering of the inbound traffic. That’s one problem that nothing has solved yet, and that would plague us for a lot more years…
Here each border router announces a /48, and both announce the /47, so they can effectively split the inbound traffic.

There’s also the IPv6 prefix for AS112, announced from both borders.

[15]

This is what every router should do for the prefix announces it receives. Basically, everything from a private ASN is dropped, and all prefixes that are not in 2000::/3 (the unicast part of the IPv6 space), are shorter than /3 or longer than /49 are also dropped.

[16]

Here you can see the schema of the backbone network – the two border routers, and the access routers of the faculties. They’re all under the administrative control of the network operations team.

[17]

For this schema to work efficiently, the two border routers do the job of route reflectors, and the access routers are route reflector clients – e.g. each access router has two BGP sessions, one with each border router, and that way it learns all the routes coming from the rest of the access routers.
This setup would’ve been unmanageable otherwise, as doing a full mesh of so many routers would’ve resulted in full mess.
[Ok, I didn’t think of that pun at the presentation]

[back to 16]

The initial idea was to actually have the border routers be route reflectors only, and have all the access routers in the VLANs of the external BGP peers, for the traffic to flow directly and not have the two borders as bottlenecks. This wasn’t implemented because of administrative/layer8-9 issues.

[19]

This is how the core network connects with the faculty networks – the access router is connected in a network with the routers of the faculty, and via OSPF (or RIP in some cases) it redistributes a default route to them.

(Yes, RIP is used and as someone told me a few hours ago, if it’s stupid and it works, maybe it’s not that stupid)

[20]

Now here’s something I would’ve done differently :)

Both OSPF and RIP are secured using IPSec, here’s how the config looks like.

[21]

This is not something that you usually see, mostly because it’s harder to configure and the weirdness in the interoperability of different IPSec implementations. For an university network, where risk factors like students exist, this provides a layer of protection of the routing daemons (which, to be frank, aren’t the most secure software you can find) from random packets that can be sent in those segments.
It’s reasonable to accept that the kernel’s IPSec code is more secure than the security code of the routing daemons.

This the only thing that this setup provides more than the other options – a pre-shared key is used, as there aren’t any implementations that have IKEv1 and can be used for this task.

Also, this is harder to operate and configure for untrained personnel, but the team decided to go ahead with the extra security.

[22]

And of course, there has to be some filtering.

[23]

Here’s a schema of one external link – in this case, to Neterra.

[24]

Here we can see the configuration of the packet filtering. This is basically an implementation of BCP38.

First, let me ask, how many of you know what BCP38 is?
[about 25-30% of the audience raise their hands]
And how many of you do it in their own networks?
[Three times less people raise their hands]
OK, for the rest – please google BCP38, and deploy it :)
[Actually, this RFC has a whole site dedicated to it]

Basically, what BCP38 says is that you must not allow inbound traffic from source addresses that are not routed through that interface. In the Cisco world it’s known as RPF (Reverse path filtering), AFAIK in Juniper it’s the same.

In Linux, this is done best using the routing subsystem. Here what we can see is that on the external interface we block everything that’s coming from addresses in our network, and on the internal – anything that’s not from the prefixes we originate.

[25]

Here we can see the setup on an access router (as we can see, BCP38 is deployed on both the border and access routers). Here we can differentiate and allow only the network of the end-users.

[26]

On the border routers, there’s also some filtering with IPtables, to disallow anyone outside of the backbone network to connect to the BGP daemon, and also to disallow anyone to query the NTP server.
(what’s not seen here is that connection tracking is disabled for the rest of the traffic, not to overload it)

[27]

On the access routers, we also have the filtering for the BGP daemon and the NTP server, but also

[28]

we filter out any traffic that’s not related to a connection that was established from the outside. This is the usually cited “benefit” of NAT and the reason for some ill-informed people to ask for NAT in IPv6.

With this, the big-bad-internet can’t connect directly to the workstations, which, let’s be frank, is a very good idea, knowing how bad the workstation OS security is.

[29]

The relevant services provided by the university have IPv6 enabled.

[30]

Most of the web server have had support since 2007.

The DNS servers too, and there’s also a very interesting anycast implementation for the recursive resolvers that I’ll talk in detail about later.

The email services also have supported IPv6 since 2007, and they got their first spam message over IPv6 in on the 12th of December, 2007 (which should be some kind of record, I got mine two years ago, from a server in some space-related institute in Russia).

[31]

ftp.uni-sofia.bg has been IPv6 enabled since 2010, it’s a service for mirroring different projects (for example Debian).

The university also operates some OpenVPN concentrators, that are accessible over IPv6 and can provide IPv6 services.

[32]

The coverage of the deployment is very good – in the first year they had more than 50% of the workstations in the Lozenetz campus with IPv6 connectivity, and today more than 85% of the workstation in the whole university have IPv6 connectivity.
(the rest don’t have it because of two reasons – either they are too old to support it, or they are not turning it on because they had problems with it at the beginning and are refusing to use it)

Around 20% of the traffic that the university does is IPv6.
[question from the public – what is in that traffic? We should be showing people that there’s actually IPv6 content out there, like facebook and youtube]

From my understanding (the university doesn’t have a policy to snoop on the users’ traffic) this is either to google(youtube), or to the CERN grid (which is IPv6 only). Yes, there actually exists a lot of content over IPv6, netflix/hulu have already deployed it, and it’s just a few of the big sites (twitter is an example) that are still holding back.

The university provides both ways for the configuration of end-nodes – Router Advertisement (RA) and DHCPv6. For most cases they’re both needed, as RA can’t provide DNS servers, and DHCPv6 can’t provide a gateway (which is something that’s really annoying to most people doing deployments).

[33]

Here’s how the default route is propagated in the network.

[34]

This was actually a surprise for me – there are actually two default routes in IPv6. One is ::/0, which includes the whole address space, and there is 2000::/3, which includes only the unicast space. There is a use for sending just 2000::/3, to be able to fence devices/virtual machines from the internet, but to leave them access to local resources (so they can update after a security breach, for example).

[35]

Here is how you redistribute ::/0, by first creating a null route and adding it in the configuration.

[36]

And here’s how it’s propagated in the network, using OSPF.

[37]

We can do the same for 2000::/3,

[38]

and push it to the virtual machines, who also have connectivity to the local resources through a different path.

[39]

Now, this is something very interesting that was done to have a highly-available recursive DNS resolver for the whole network.

[40 and 41 are the same, sorry for the mistake]

[41]

This is how a node works. Basically, there’s a small program (“manager”) that checks every millisecond if the BIND daemon responds, and if it’s just starting, it adds the anycast resolver addresses to the loopback interface and redistributes a route through OSPF.

(note the addresses used – FEC0::.. – turns out that this is the default resolver for MS windows, so this was the easiest choice. Seems that even in the land of IPv6 we still get dictated by MS what to do)

[42]

If the name server daemon dies, the manager withdraws the addresses.

Also, if the whole nodes dies, the OSPF announce will be withdrawn with it.

[43][44][43][44][43][44]

Here you can see what changes when a node is active. If one node is down, the routers will see the route to the other one, and send traffic accordingly.

[45]

And if they’re both operational, the routers in both campuses get the routes to the node in the other campus with lower local preference, so if they route traffic just to their own, and this way the traffic is load-balanced.

[46]

Thank you, and before the questions, I just want to show you again

[3]

the people that made this deployment. They deserve the credit for it :)

[In the questions section, Stefan Dimitrov from SU stood up and explained that now they have three border routers, the third one is at the 4th kilometer campus]

И мина RIPE-SEE-3.

Проведе се в х-л Кемпински, за два дни, беше с малко лекции/workshop-и и доста разговори/networking (видях се с хора, с които не се бях виждал от 10+ години).

Пропуснах първите неща от първия ден, че бях зает да си нося лаптопа на ремонт (и все пак да се наспя), та хванах сесиите след обяда. Първо слушах човека от DT по темата за новата мрежа, която правят (TeraStream) – интересна идея, забавното беше как чак 2011 осъзнали, че мрежата им е остаряла и не става, но па сега я правят както трябва – чист ipv6 (ipv4 е service с тунели отгоре), 100gbps и anycast на интересните услуги. Също така им е хрумнало в адреса да слагат няколко бита, които да играят ролята на QoS битовете, и да раздават няколко префикса на потребител, например един за видео/телевизия, един за voice, един за internet, и мислят как да стандартизират процеса за избиране на source адрес.
RIPE разказаха за различните неща, които правят – конференции и т.н., Erik Vinecke от cisco разказа нещо за мерене на ipv6 deployment-и, което заедно със следващите две неща не слушах, понеже си препрочитах моята лекция.
(чух някакви части от лекцията на Nathalie Trenaman за нейния deployment на ipv6 у тях, и си беше интересно и доста мъчително, Мариян я пита във въпросите що се е мъчила да се занимава с vendor-и, вместо да ползва opensource неща)

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

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

Втория ден започна с лекция за Ansible (което се оказа някакъв вариант на chef/puppet/cfengine), нищо интересно, след което имаше доста интересна лекция за “Crowdsourcing Infrastructure Geolocation”, т.е. проект, който по различни начини определя къде се намират ip-тата на разни router-и, за да може човек да си визуализира traceroute (note to self, да си оправя всичките DNS LOC записи). Искрено се надявам проекта да успее :)

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

Следващият слот беше по “Governance” темата и привлече най-страшните въпроси. Първо говори един човек от CERT България (който не беше лектора по програма) и беше в общи линии изяден с парцалите, понеже нищо не знаеше.
После говори Венета Донова за net neutrality-то в Европа и в България, основно за законовите моменти около него – беше разширение и update на лекцията и от openfest (ако не се лъжа), и се получи доста добре.
Последва я Аглика Клайн от Europol EC3 – отдел, който се занимава с техническата част на разследванията, анализа и координиране на операции. В общи линии въпросите към нея бяха “защо да ви вярваме”, “вие сте тия, дето ни тровят най-много живота”, спряхме се на това как детското порно се използва основно срещу доставчиците (имаме си достатъчно такива случаи в България) и т.н., и т.н.. Успя да издържи на въпросите, но се измъкна от някои въпроси. Имаше и момента, че от една страна нямат право да приемат feedback и каквото и да е от хората или фирмите (само от държавите-членки), но от друга страна са пускали по молба на microsoft advisory, да кажат на хората, че XP-то спира да се поддържа.
(после имаше и допълнителни разговори и обяснение как една от причините никак да не ги обичаме е, че ги използват много усилено срещу нас, и че те са от хората, които трябва да се борят за улесняване на security research-а, не срещу него (както са направили в Германия със забраната да се пишат exploit-и), трябва да и пратя на FX лекцията за хардуера, който law enforcement хората ползват и колко е счупен)

Имаше три lightning talk-а, от които единия беше за BGNOG-а (който споменах по-горе), успяхме да стигнем от идея до реализация за около 12 часа.

В последният слот интересните лекции бяха две. Едната беше за RIPE Atlas проекта, и за anchor машините (за които мисля да взема една в нашия datacenter, Мариян се замисли за три), самият проект има лесен начин да се интегрира в monitoring системите ми и мисля тия дни да му отделя малко време. Другата лекция беше сравнителен анализ на internet-а в България, Турция и Румъния, гледан от BGP гледна точка, от Renesys – накратко, в Турция нещата не са добре, при нас и в Румъния са доста по-чисти, като в Румъния са около три пъти по-големи. Удобни сме от гледна точка на латентност за финансови и т.н. институции да си слагат тук нещата, дано успеем да се възползваме.

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

Update: Трябваше да привлачим и Яна на събитието, понеже изкарах накрая поне половин час да давам идеи как да привлекат повече хора – имаше около 220 дошли, и те го считаха за голям успех, но аз си мисля, че даже чистите мрежови администратори в България са поне 150-200 и щеше да им е интересно да дойдат. Едното нещо, което може да помогне е NOG-а, другото – просто да си говорят директно с някакво количество хора/LIR-ове, не през някакви тежки mass mail-вания до адреси от базата им, щото тях никой не ги чете сериозно.

Update 2: Сайт с наземни кабели, за който не знаех (като допълнение на за подводните).

“Чичо Тони, тримата глупаци и ДС” (и трейлър).

Почти никой не прави у нас филми, дето да си заслужават времето дори да ги изтеглиш, какво остава да ги гледаш. Явно па тези, които си струват, се намира кой да ги преследва и да се опитва да ги спре/забрани.

Весела Казакова е направила филм за човекът зад голяма част от анимациите, които се водят на Доньо Донев, и който не е признат основно защото ДС не са го харесвали. Пробвайте се да отделите малко време, да не трябва да се примиряваме с “Хубав е филма, като за български”.

Весела Казакова е говорила пред Капитал по темата.

Втория ден, след като се намързелувах и се появиха хора в Краковския hackerspace, отидох да ги видя.

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

А аз в неделя сутрин докато тихичко си работех ми опука дисплея на лаптопа, та по случая тия дни ще съм малко offline през деня (ще съм на RIPE SEE-3 и ще съм малко ограничен в това кога ще мога да съм си пред машината).

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

И днес беше деня на посещението в Аушвиц.

(четох си по пътя “Dominion” на C.J.Sansom, частта в която изселват евреите в Англия, беше странно)

Обиколката продължи няколко часа – първо в Аушвиц 1, после в Аушвиц 2 – Биркенау. Първият лагер е доста по-малък, вторият прилича на набор бараки за животни посред полето. Доста са запазени, особено телените огради и доста от сградите, и си е интересно да видиш на живо как са изглеждали нещата (и например как изглеждат два тона човешка коса). Не мисля, че преживяването е за хора с по-слаби нерви, нищо, че екскурзоводите са доста внимателни и се стараят да обясняват спокойно и нетормозещо.

Жалко, че няма така запазени лагери от ГУЛАГ-а, да може да се направи едно хубаво сравнение.

И дойде време да си използвам странния подарък за рождения ден – екскурзия до Аушвиц/Биркенау (Освиенцим).

Полетът ми беше в нормално време и с online checkin-а даже идиотското задръстване по Цариградско шосе не беше проблем. Летях през Виена и стигнах съвсем спокойно в Краков (само в последния полет имаше някакъв пиян руснак с трима цивилни полицаи около него).

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

Съвсем лесно си намерих мястото за спане (един много готин таван в една кооперация без асансьор), след което с помощта на един таблет с gps и osmand на него си намерих един супермаркет, в който да си напазарувам храна (който освен, че супер много приличаше на малките български от рода на Пикадили експрес, беше и бая евтин).
(цените в/у две са в лева, в/у четири – в евро, доста лесно се смята)

Та, аз мисля да се излежавам, чета и може да попиша по една лекция, ако на някой му трябвам – няма ме :)

(обществено-полезната работа я свърших, писах mail на админа на www.uni-sofia.bg, че са vulnerable за heartbleed проблема)

Не че не сте видели от други места, но:
DSA-2896
heartbleed.com
официалния сайт на openssl.

apt-get update && apt-get -y dist-upgrade и ритнете каквото трябва.

(алтернативното заглавие беше fuckfuckfuckfuckfuckfuckfuckfuckfuckfuck)

Update: Сайт, който тества за проблема.
Update 2 command-line test tool.