Блогът на Петко
False Hopes

Roaming and Steering

• Петко Борджуков

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

Въведение

Речник

  • STA – станция – клиент на дадена безжична мрежа.
  • BSS – basic service set, базово множество услуги – точка за достъп и всичките ѝ клиенти.
  • ESS – extended service set, разширено множество услуги – няколко BSS-а, свързани чрез система за дистрибуция.
  • DS – distribution system, система за дистрибуция – системата, чрез която множество BSS-и са свързани в един ESS. Ще подразбирам Ethernet сегмент.
  • Roaming – роуминг – преминаване от един към друг BSS в един и същи ESS.
  • Client steering – насочване на клиенти – активно действие от страна на точка за достъп, което кара клиент да се асоциира с определен BSS.
  • Band steering – насочване към честотна лента – като client steering, само че насочва клиента към BSS в по-предпочитана честотна лента.

Стандартизация

IEEE 802.11 стандартите изрично отбягват специфицирането на „настойчиви“ действия и логика от страна на точките за достъп, що се отнася за насочване на клиентите. С други думи, когато се говори за избор на BSS, с който да се асоциират, топката е ИЗЦЯЛО в ръцете на STA имплементациите. Отказ от асоциация, на базата на друго, освен липса на правомощия за асоциация, е в разрез със стандартите.

Поправки на IEEE 802.11 с отношение към роуминг и насочване на клиенти – IEEE 802.11f (нестандартизиран), IEEE 802.11r, IEEE 802.11k, IEEE 802.11v, IEEE 802.11ad.

Съществуващи имплементации на насочване на клиенти

Решения със затворен код

Почти всеки сериозен производител на Wi-Fi хардуер, има собствена нестандартизирана имплементация на client и band steering. Няма да навлизам в детайли за Cisco, Aruba, UBNT, защото имплементациите им са затворени и нямам наблюдения над тях, освен за съществуването им.

hostapd

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

Нестандартизирани подходи за насочване към честотна лента в официалните версии на hostapd

hostapd поддържа два подхода за насочване към честотна лента – отказ от отговор на probe request, ако даден клиент е бил забелязан на интерфейс в 5 ГХц честотна лента, или отказ от асоциация при същото условие[1]. И двата са доста „непохватни“, защото не взимат предвид това дали клиентът не би имал проблем при свързването към BSS-а на другия банд.

Важно е да се отбележи, че гореспоменатите два подхода могат да бъдат използвани само в случай, че една и съща инстанция на hostapd управлява всички физически интерфейси. Това е в разрез с текущата имплементация в OpenWrt и LEDE, при която за всеки физически интерфейс се стартира отделна инстанция на hostapd. Въпросът за изоставяне на сегашната имплементация беше отхвърлен от разработчиците на LEDE, защото би изискал сериозни промени в LEDE и ще направи системата по-малко отказоустойчива – при проблем с hostapd на един интерфейс, ще спре и другия.

Също така, не е имплементиран начин споменатите в [1] таблици от съседи да бъдат споделяни между отдалечени инстанции на hostapd. Това прави описаните в [1] подходи неприложими или поне непредвидими, при използване на повече от едно устройство в един ESS.

Нестандартизиран подход за насочване към честотна лента във форка на hostapd на Google

В доста информативна лекция по темата[2], служител на Google представи собствената им интелигентна имплементация[3] на band steering.

Плюсовете на тази имплементация пред вече съществуващата в hostapd са:

  • Взима предвид потенциални проблеми при свързване към BSS-а на 5 ГХц.
  • Предвидена е да бъде използвана в сценарий, при който отделна инстанция на hostapd управлява всяки отделен физически интерфейс.

За съжаление обаче е неизползваема в контекста на ESS с повече от една точка за достъп на отделни устройства.

Бих бил много щастлив, ако някой се заеме и имплементира дистрибутиран списък с клиенти, с който да работи тази имплементация. Нужна ни е за Open Fest.

Насочване към честотна лента чрез специфицираните в IEEE 802.11ad инструменти

IEEE 802.11ad въвежда промени, чиято цел е да улеснят избора на правилния банд от клиенти. В повече детайли – въвежда се MB (като multi-band) информационен елемент в beacon фреймовете на BSS-ите и метод за бързо прехвърляне на клиентска сесия между отделни BSS-и. В hostapd и wpa_supplicant от относително скоро съществува имплементация и за двете, но е скрита за конфигурационен флаг[4].

Положителното на тази имплементация е, че е стандартизирана от IEEE, но носи и редица отрицателни характеристики:

  • Изисква поддръжка от клиентска страна.
  • Нужно е една инстанция на hostapd да управлява всички физически интерфейси (като при 2.2.1).
  • Нова е, неистествана е и преди всичко – не е активирана по подразбиране.

Насочване на клиентите чрез средствата на IEEE 802.11r, k и v.

От Cisco са описали по същество що е то Assisted Roaming чрез използването на горните стандарти[5]. Препоръчвам да прочетете статията за детайли. Обобщено обаче, идеята зад методите за улесняване на решенията за роуминг зад тези поправки, е следната:

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

В hostapd и wpa_supplicant изглежда съществуват поне частични имплементации[6]. Предстои да ги проуча и тествам преди Open Fest.

Огромният недостатък е, че е нужно клиентите да имплементират дадената логика за избор на BSS.

Насочване на клиентите чрез ограничаване на мощността на излъчване на мрежовите карти на точките за достъп и избор на кодировки за висока производителност

Най-изпитаният и най-широко съвместим метод за „поощряване“ на клиентите да преминат към друг BSS остава внимателното избиране на подходяща мощност на излъчване от страна на точките за достъп. Това, комбинирано с ограничаването на basic rate-овете до 54Mbps исторически винаги е работило доста добре на Open Fest[9].

Особености при роуминг

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

Обновяване на кеша на L2 устройствата в Ethernet сегмента

Две точки за достъп могат да бъдат свързани чрез два различни порта на суич или дори чрез отделни суичове. Докато мигриралият от един към друг BSS клиент не изпрати фрейм, която да обнови кешовете на L2 устройствата в мрежата, трафикът, адресиран до него, ще продължи да бъде изпращан до предходната му точка за достъп.

В hostapd съществува частична имплементация на невлязлата в сила поправка IEEE 802.11f, която се грижи при свързване на нова станция да изпрати от нейно име LLC фрейм до целия Ethernet сегмент[7].

С наскоро приет пач, IAPP имплементацията в hostapd вече работи и при двубандови точки за достъп[10][11].

Ускоряване на свързването с новия BSS

IEEE 802.11r дефинира два подхода за ускоряване на свързването с BSS-а, към който даден клиент преминава. Това е нужно, защото началното ръкостискане при WPA и ОСОБЕНО при WPA Enterprise е доста времеемко.

Двата подхода са preauthentication по въздуха и preauthentication по системата за дистрибуция. hostapd поддържа поне ft-over-ds[8] за WPA И за WPA Enterprise.

Бъдещи имплементации

На базата на проучването ми на имплементацията на 802.11r, k и v, може да се oкаже, че от нова имплементация на client steering няма нужда, но това ще стане ясно по всяка вероятност чак след OF, ако изобщо.

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

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

• Петко Борджуков

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

Силно препоръчвам прочитането на Crossing Borders: Security and Privacy Issues of the European e-Passport и останалите цитирани статии за подробно запознаване с изредените проблеми.

Недостатъци от технологична гледна точка

  • Неоторизиран достъп до биометричните данни в личните карти на гражданите[@Heimo-abuse][@Kosta-epassport]
  • Неоторизирано проследяване на физическото местоположение на гражданите[@Heimo-abuse][@Hoepman-epassport][@Kosta-epassport]
  • Клониране на откраднати лични карти[@Heimo-abuse]
  • Компроментиране на частния ключ, съответстващ на публичния ключ, използван за шифриране на биометричните данни[@Heimo-abuse]
  • Липса на механизъм за управление на достъпа до личните данни от гражданите[@Hoepman-epassport] (например ограничаване на достъпа само до снимка, само до пръстови отпечатъци или само до изображение на ирис).
  • Естеството на биометричните данни не позволява отказ от тях в случай на компроментирането им[@Kosta-epassport]

Неясноти от етична гледна точка

  • Конфиденциалност: Може ли гражданин да откаже или ограничи употребата на биометричните си данни от институции, на които няма доверие?[@Sprokkereef-ethicalpractice]
  • Ясна цел: Съществува ли защита срещу неоторизирана употреба на биометричните данни, отвъд начално дефинираната им цел? Могат ли допълнитени функции да бъдат добавяни с течение на времето? Може ли липсата на ограничения „ясна цел“ да доведе до злоупотреба с биометрични данни и от страна на публичния и от страна на частния сектор?[@Sprokkereef-ethicalpractice]

    Например, опитът при въвеждането на биометрични паспорти във Финландия през 2006-а говори, че при втората част на въпросната реформа (през 2009-а година), е взето решение да се изгради национален регистър на пръстови отпечатъци. Дори в рамките на съответния законодателен процес, целите на регистъра са разширени неколкократно, включително чрез предоставянето на достъп до него на полицията.[@Heimo-abuse]

  • Пропорционалност: Биометричните данни адекватни, релевантни и пропорционални ли са, спрямо целта, за която са събрани?[@Sprokkereef-ethicalpractice]

Липса на проучване за оценка на ефекта от въвеждането на биометрични данни в личните карти

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

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

Недостатъци от финансова гледна точка

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

Последствия

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

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

  • Автоматично взривяване на бомба в близост до определен гражданин, гражданин на определена държава или група граждани на определена държава.

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

  • Злоупотреба с биометрични данни от лица с достъп до изграден регистър на биометричните данни на всички български граждани.

  • Изтичане на регистър с биометричните данни на всички български граждани.

Заключение

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

Библиография

nginx и HTTP/2

• Петко Борджуков

От версия 1.9.5 nginx има експериментална поддръжка за HTTP/2. Време е за проба.

HTTP/2

Без да навлизам в детайли (защото HTTP/2 in a nutshell си е отделен дълъг блог пост), на високо ниво, HTTP/2 се различава от HTTP/1.x по:

  • това, че е двоичен, вместо текстов
  • предоставя мултиплексиране, вместо доставяне на данните под ред и с блокиране
  • може да използва една(!) TCP връзка за паралелизъм (заради мултиплексирането)
  • използва компресия на хедърите
  • позволява на сървърите да изпращат (push) проактивно отговори в кешовете на клиентите (тази функционалност все още не е имплементирана в nginx)

Повече информация може да бъде открита тук: https://http2.github.io/faq/#general-questions

Поддръжката от страна на браузърите е изненадващо добра, както може да бъде видяно тук: http://caniuse.com/#feat=http2.

Дългото очакване

HTTP/2 беше окончателно стандартизиран през май тази година, но имплементацията в nginx отне доста време.

Изненадващо, през август се появи алфа версия на patch, който да въведе HTTP/2 функционалнст. Този patch напълно премахва SPDY и го замества с новата версия на HTTP. Това дойде изневиделица за някои, но същата политика налага и Chromium, месеци по-рано. Честно казано бързото пенсиониране на протоколи доста ми харесва.

Mainline версия на nginx с HTTP/2 поддръжка се появява през октомври, като в блог пост авторите описват особеностите около имплементацията.

Конфигурация на nginx

Конфигурацията на HTTP/2 на пръв поглед по нищо не се различава от тази на SPDY – просто се добавя http2 в listen директивата в даден server блок.

server {
    listen 443 ssl http2 default_server;

    ssl_certificate    server.crt;
    ssl_certificate_key server.key;
    ...
}

НО

Има една основна разлика – HTTP/2 дефинира черен списък от комплекти от шифри, които не могат да бъдат използвани. Този списък е доста обширен, за да го обобщя – може да се използват само AEAD шифри с ефимерна обмяна на ключове. В противен случай Firefox и Chromium отказват да отворят сайта. Chromium с грешка INADEQUATE_SECURITY, а Firefox – без грешка – дори в конзолата.

Може би би било добра идея nginx да изписва грешка или предупреждение, че се използват непозволени шифри, но това е друг въпрос.

Низът от шифри, който използвам за https://petko.me е следният:

ssl_ciphers "ECDH+aRSA+AESGCM:EDH+aRSA+AESGCM";

Затворена бета на Let's Encrypt

• Петко Борджуков

Вчера от Let’s Encrypt ми изпратиха E-Mail, че домейните, за които съм поискал да бъдат подписани сертификати, са одобрени.

Let’s Encrypt

Let’s Encrypt е автоматизиран, отворен доставчик на (безплатни) удостоверителни услуги (на английски – Certificate Authority).

За повече информация, препоръчвам следните лекции:

Записване за бета програмата

Преди повече от месец, в Twitter акаунта на Let’s Encrypt беше обявено записване за бета програма, което ставаше, посредством попълване на Google формуляр. Въпреки че намерих за ироничен факта, че разчитат на Google, реших да изпратя заявка.

Формулярът беше изключително прост – поле, в което да изредиш за кои домейни искаш сертификати и поле за E-Mail адрес.

Начало на бета програмата

На 19-и октомври от Let’s Encrypt обявиха, че са получили cross-signatures за двата си intermediate сертификата, което означава, че подписаните от тях сертификати вече са доверени в браузърите.

Малко повече от седмица след това получих E-Mail, че домейните, за които съм поискал да бъдат подписани сертификати, са одобрени. Ето съдържанието на E-Mail-а:

From: Let’s Encrypt Beta <betaprogram@letsencrypt.org>

Date: Tue, Oct 27, 2015 at 5:14 PM

Subject: Let’s Encrypt Closed Beta Invite

To: [email here]

Greetings from Let’s Encrypt, [email here].

Thank you for your interest in our beta program! We’re excited to let you know that your domains (below) have been whitelisted, and you can now utilize an ACME client to obtain a certificate for them.

Quick Start

To use Let’s Encrypt’s official client to obtain your real certificates, you will need to provide the production API URL on the command line:

https://acme-v01.api.letsencrypt.org/directory

When running the Python client (installation directions [1]), be sure to specify the --server argument with the production URL:

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --agree-dev-preview --server \
      https://acme-v01.api.letsencrypt.org/directory auth

If you are using a different ACME client, be sure to configure it to use the production URL in order to get valid certificates. Many clients will default to the staging URL.

Known Issues

There are some known issues with the official Python client posted here: https://github.com/letsencrypt/letsencrypt/wiki/Known-issues

Renewals and Lifetimes

Certificates from Let’s Encrypt are valid for 90 days. We recommend renewing them every 60 days to provide a nice margin of error. As a beta participant, you should be prepared to manually renew your certificates at that time. As we get closer to General Availability, we hope to have automatic renewal tested and working on more platforms, but for now, please play it safe and keep track.

Rate Limiting

During this beta test we have very tight rate-limiting in place. We plan to loosen these limits as the beta proceeds.

There are two rate limits in play: Registrations/IP address, and Certificates/Domain.

Registrations/IP address limits the number of registrations you can make in a given day; currently 10. This means you should avoid deleting the /etc/letsencrypt/accounts folder, or you may not be able to re-register.

Certificates/Domain you could run into through repeated re-issuance. This limit measures certificates issued for a given combination of Top Level Domain + Domain. This means if you issue certificates for the following domains, at the end you would have what we consider 4 certificates for the domain example.com.

www.example.com
example.com www.example.com
webmail.example.com ldap.example.com
example.com www.example.com

The limit on Certificates/Domain has a window of 60 days, to give 30 days for renewals. We know it’s restrictive at present; thank you for your patience in helping us ensure Let’s Encrypt is ready for the whole world.

Certificate Transparency

Part of our transparency mission includes publicly disclosing the certificates we issue via Certificate Transparency. Your email address is not publicly disclosed.

Helpful Information

Let’s Encrypt maintainence events are posted on https://letsencrypt.status.io/ and Twitter (@letsencrypt_ops). If you need help, both the Let’s Encrypt community at https://community.letsencrypt.org/ and #letsencrypt on irc.freenode.org are excellent sources of assistance.

If there are updates for Beta program participants, they will be posted at the community site at https://community.letsencrypt.org/t/beta-program-announcements/1631.

Your whitelisted domains are: …

След като набързо хвърлих едно око на изходния код на https://github.com/letsencrypt/letsencrypt, го клонирах на FreeBSD машината си и го изпробвах. Не ми допада, че letsencrypt-auto трябва да се изпълни с root привилегии, но изглежда работи доста чисто. Промените върху файловата система, които забелязах, са създаване на директории /etc/letsencrypt, в която се помещават ключовете и сертификатите и ~/.local/share/letsencrypt, в която е „виртуалната python среда“ на инструмента.

По подразбиране letsencrypt-auto прави няколко неща:

  • Създава средата, в която да се изпълни да се изпълни letsencrypt клиентът
  • Генерира чифт потребителски ключове, с които да се достъпва системата на Let’s Encrypt
  • Пита за кои домейни искаш сертификат (с curses-базиран UI)
  • Генерира 2048-битов ключ и CSR
  • Валидира домейните
  • Изпраща CSR-а за подпис
  • Записва получения сертификат в /etc/letsencrypt, заедно с пълната му верига сертификати

Както споменах, не ми хареса нуждата да изпълня скрипта с административни права. Освен това, не ми хареса от колко неща зависи под FreeBSD:

bootstrap/freebsd.sh:

#!/bin/sh -xe

pkg install -Ay \
  git \
  python \
  py27-virtualenv \
  augeas \
  libffi \

Изпълнението на този скрипт ми инсталира perl-5.20 и ми преинсталира(!) perl-5.18, без очевидна нужда за това.

Валидацията на домейните ми също беше доста неприятна – като начало, скриптовете не откриват наличието на nginx и те изправят пред избор (в грозно форматиран текст, който прилича на stack trace на python) – да създадеш файл в /.well-known/ на уеб сървъра, който отговаря за дадения домейн, или да спреш уеб сървъра и да изпълниш Bash-python black voodoo magic заклинание, което пуска уеб сървър, който сервира нужните данни. Ето как изглежда съобщението, което се показва след приятния curses-базиран диалог за избор на домейни:

Bash-Python Black Voodoo Magic:

Make sure your web server displays the following content at
http://petko.me/.well-known/acme-challenge/al8Z37ePxkms5jo0WtqguLq2aT7sQEd_S1IubcFzpwU before continuing:

{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "vhDQ-ssP5mgMd27zpovkmSD7oV3sjhTKdO2AU5N9GMkUMNsQ612dIa1sxXGErrW9WGlOa8EkPeK2T4JA5IBUNnuxJBJfT-EmT3suH2uW8klbFlJqHDIAHbnVZjVcrqKFS4Iuub5oaG0wPT4hPe4IKR3vob7DL7Yv0sgHwFFD0N8VWDCb6kG5HUqyvvMr6x0sPOyPQEzzJO-YWUwZM-FQ-sXLfxkBsI9hz9EqfaxvGV3wUVY_OOKMbKcyCM0e_sa7Vrd0jg_FEgHLW2dFVe1wdLLW4YEiimNHwINVloZxQ4QrSAaGI-aXJx1FojPGpkLwviSTmMGGC2MD7BSVqIzjiQ"}}, "payload": "eyJ0bHMiOiBmYWxzZSwgInRva2VuIjogImFsOFozN2VQeGttczVqbzBXdHFndUxxMmFUN3NRRWRfUzFJdWJjRnpwd1UiLCAidHlwZSI6ICJzaW1wbGVIdHRwIn0", "signature": "LCNiHNdZheeLCEcNG3JStH6J3pTZHqWL3Zne5AkzuFJ5NM8UQrhpAE-ie8E5VeXEGvXZFlJOpKU72rDmlaBQIyrWF1NLHh1A9vbTdPf_xa1lwVvASAFnvgcUU0c7o--5BegP4GEeWHkeOpqi5s45f-ktNUxtPuY9KrK_ByEQdcwfTcaUGwgOy86Oy-zVfyU45K6e-7fGahXLmrmcG9ADf4EQFVAx6Kax42kTkGl9oS-IiitQcCkc7pZA8nDWG_D6f5u01bBvBOn4PewBauajBr5fOX1StIi4ealnDKq0mcY4JlD8Efp6wAopqQAIoecHxCbiRUWULBevvW6wCzpUKA"}

Content-Type header MUST be set to application/jose+json.

If you don't have HTTP server configured, you can run the following
command on the target server (as root):

mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
echo -n '{"header": {"alg": "RS256", "jwk": {"e": "AQAB", "kty": "RSA", "n": "vhDQ-ssP5mgMd27zpovkmSD7oV3sjhTKdO2AU5N9GMkUMNsQ612dIa1sxXGErrW9WGlOa8EkPeK2T4JA5IBUNnuxJBJfT-EmT3suH2uW8klbFlJqHDIAHbnVZjVcrqKFS4Iuub5oaG0wPT4hPe4IKR3vob7DL7Yv0sgHwFFD0N8VWDCb6kG5HUqyvvMr6x0sPOyPQEzzJO-YWUwZM-FQ-sXLfxkBsI9hz9EqfaxvGV3wUVY_OOKMbKcyCM0e_sa7Vrd0jg_FEgHLW2dFVe1wdLLW4YEiimNHwINVloZxQ4QrSAaGI-aXJx1FojPGpkLwviSTmMGGC2MD7BSVqIzjiQ"}}, "payload": "eyJ0bHMiOiBmYWxzZSwgInRva2VuIjogImFsOFozN2VQeGttczVqbzBXdHFndUxxMmFUN3NRRWRfUzFJdWJjRnpwd1UiLCAidHlwZSI6ICJzaW1wbGVIdHRwIn0", "signature": "LCNiHNdZheeLCEcNG3JStH6J3pTZHqWL3Zne5AkzuFJ5NM8UQrhpAE-ie8E5VeXEGvXZFlJOpKU72rDmlaBQIyrWF1NLHh1A9vbTdPf_xa1lwVvASAFnvgcUU0c7o--5BegP4GEeWHkeOpqi5s45f-ktNUxtPuY9KrK_ByEQdcwfTcaUGwgOy86Oy-zVfyU45K6e-7fGahXLmrmcG9ADf4EQFVAx6Kax42kTkGl9oS-IiitQcCkc7pZA8nDWG_D6f5u01bBvBOn4PewBauajBr5fOX1StIi4ealnDKq0mcY4JlD8Efp6wAopqQAIoecHxCbiRUWULBevvW6wCzpUKA"}' > .well-known/acme-challenge/al8Z37ePxkms5jo0WtqguLq2aT7sQEd_S1IubcFzpwU
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
SimpleHTTPServer.SimpleHTTPRequestHandler.extensions_map = {'': 'application/jose+json'}; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()"
Press ENTER to continue

Първият вариант ми се стори по-приятен, въпреки великата глупост, че трябва на ръка да се зададе в конфигурацията на web сървъра какъв content type трябва да има дадения файл. За нещастие, по някаква причина не сработи при мен и се наложи да прибягна до втория вариант.

Втория вариант проработи за един домейн, но не и ако бях задал два – petko.me www.petko.me.

За всяко ново изпълнение на letsencrypt-auto се генерира нов (2048-битов!) частен ключ. Няма очевиден начин за увеличаване на големината на ключа или да указване на вече съществуващ такъв. След ровене открих, че има --csr параметър, който обаче при мен не проработи.

В крайна сметка според мен letsencrypt-auto не трябва да бъде използван.

Алтернативен инструмент

В крайна сметка изискванията ми са следните:

  • Искам сертификат, подписан от Let’s Encrypt
  • Искам да преизползвам частния ключ на сегашния си сертификат, за да не отрежа достъпа на клиентите (имам конфигуриран HPKP)
  • Искам да ми бъде върнат подписания сертификат като текст, с който да работя, както сметна за добре
  • Не искам да изпълнявам каквото и да е като root
  • Не искам да инсталирам излишни пакети

Предосатвеният от Let’s Encrypt инструмент не успя да отговори на изискванията ми. За щастие попаднах на https://github.com/diafygi/letsencrypt-nosudo. Със скрипта от това репо и с долния модифициран шелскрипт (разчита key.pem и openssl.cnf да са в работната директория), успях да се сдобия с подписан сертификат за petko.me и www.petko.me.

letsencrypt/examples/generate-csr-existing-key.sh:

#!/bin/sh
# This script generates a simple SAN CSR to be used with Let's Encrypt
# CA. Mostly intended for "auth --csr" testing, but, since it's easily
# auditable, feel free to adjust it and use it on your production web
# server.

if [ "$#" -lt 1 ]
then
  echo "Usage: $0 domain [domain...]" >&2
  exit 1
fi

domains="DNS:$1"
shift
for x in "$@"
do
  domains="$domains,DNS:$x"
done

SAN="$domains" openssl req -config "${OPENSSL_CNF:-openssl.cnf}" \
  -new -nodes -subj '/' -reqexts san \
  -key key.pem \
  -out "${CSR_PATH:-csr.der}" \
  -outform DER

echo "You can now run: letsencrypt auth --csr ${CSR_PATH:-csr.der}"

Заключение

Мъка. Но има светлина в тунела.

Безжичната мрежа на OpenFest 2014

• Петко Борджуков

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

Хардуерът

Тази година Крокодила си беше поставил за цел да имаме поне 10 устройства, които да пръснем из сградата. В крайна сметка имахме 11:

ap00 - alix2d2 с dnma92 и cm9 MiniPCI Wi-Fi карти (София – дясно)
ap01 - alix2d2 с dnma92 и cm9 MiniPCI Wi-Fi карти (G1)
ap02 - alix3d2 с dnma92 MiniPCI Wi-Fi карта (София – ляво)
ap03 - alix3d2 с dnma92 MiniPCI Wi-Fi карта (G3)
ap04 - Cisco WAP561 (Пловдив)
ap05 - Cisco WAP561 (Бургас)
ap06 - alix3d2 с TP-Link MiniPCI Wi-Fi карта с чипсет AR9280 (G1)
ap07 - alix3d2 с cm9 MiniPCI Wi-Fi карта (резерва)
ap08 - alix3d2 с cm9 MiniPCI Wi-Fi карта (резерва)
ap09 - TP-Link WDR4300 (лоби)
ap10 - TP-Link WDR4300 (Варна)

С изключение на двете устройства Cisco, всички използвани Wi-Fi карти бяха с чипсет Atheros. dnma92 е двубандова и поддържа 2x2 MIMO, cm9 е двубандова, но поддържа само 802.11b/g, двете устройства TP-Link поддържат 3x3 MIMO на 5-гигахерцовата си карта и 2x2 на 2,4-гигахерцовата.

Софтуерът

На всички устройства (с очевидното изключение на двете Cisco) беше инсталирана OpenWRT Barrier Breaker, рекомпилирана с CONFIG_PACKAGE_ATH_DFS=y и CONFIG_ATH_USER_REGD=y, което да позволи използването на канали от 52 до 64 в 5-гигахерцовия ISM банд.

Допълнително на всички устройства беше пуснат SNMP сървър.

Конфигурацията

Имахме три основни разновидности на конфигурацията на точките за достъп – 802.11n в 5 ГХц и 2,4 ГХц спектър, 802.11b/g в 2,4 ГХц спектър и двете Cisco.

Обща част

Всички точки за достъп извършваха IEEE 802.1q VLAN tagging на рамките и бяха свързани с останалата част от мрежата през един „trunk“ порт и имаха следната конфигурация на мрежата:

management: eth0.600
wireless (bridge mode): eth0.601, wlan0 и wlan1, ако има такъв

Бриджът, в който са добавени безжичните интерфейси, няма никакъв адрес от трето ниво, включително link-local IPv6.

Интервалът за излъчване на beacon рамки беше 250 милисекунди, за да се намали натоварването на каналите (повече за това – в частта за мрежата за бавни устройства). Докато експериментирах с тази настройка, забелязах, че понякога Wi-Fi клиентите не откриваха дадена точка за достъп при сканиране. Този проблем се наблюдаваше, при beacon интервал по-голям от 300ms.

На безжичните карти беше зададена България за regulatory domain и беше активирано излъчването на информационен елемент за държава (по стандарт IEEE 802.11d) в beacon рамките, с надеждата клиенти, които по подразбиране на поддържат канали 12 и 13, да бъдат „заразени“ с правилния regdomain от някоя точка за достъп на видим от тях канал.

Точките за достъп бяха конфигурирани да обменят информация по IAPP относно клиентите, свързващи се към тях, за да се намали времето за миграция на клиент помежду им. Това наложи да оправя поддръжката на IEEE 802.11f в конфигурационните скриптове на OpenWRT, защото в Barrier Breaker по подразбиране IAPP работи само в шифрирани мрежи, и дори в този случай се чупи, заради използване на изведени от употреба команди за установяване на име на физически интерфейс (eth0.600 например) по име на логически интерфейс (wan, lan, и т.н.).

Силата на сигнала на всяка точка за достъп беше далеч под максималната – почти всички радиа бяха конфигурирани да излъчват с между 8 и 10dBm с цел да се „поощряват“ клиентите да преминават между тях. 5-гигахерцовите радиа бяха усилени малко повече отколкото 2,4-гигахерцовите, за да ги предпочитат двубандовите клиенти (не беше особено ефективно, повече – за догодина). Отнесох доволно количество подхвърляния докато се разхождах с лаптопа си в петък, гледайки силата на сигнала и дали машината ми преминава между точки за достъп по очаквания начин. Това беше едно от най-досадните неща за конфигуриране.

Точките за достъп за бавни устройства (със SSID OpenFest Legacy Devices)

Още от преди да започнем да мислим мрежата, от няколко места ни предупреждаваха да „отрежем бавните устройства, защото забавят всички други“. Крокодила настояваше за отделна Wi-Fi мрежа за бавни устройства, за да няма хора без Интернет на Феста.

Реших да изровя малко повече информация по въпроса, преди да се втурна да се доверявам на необосновани подхвърляния. Открих следните две статии: „Wi-Fi Probing Behavior and Configured Data Rates“ и „Limit SSIDs & Data Rates to Maintain Network Performance“, които ми разясниха същността на проблема.

Решението беше да заделя един канал, който да е изцяло за стари устройства и да ги оставя да си работят там, за да им е бавно само на тях. Двете виртуални точки за достъп, които бяха заделени за тях (вж. графика 1), бяха конфигурирани да излъчват на първи канал и да поддържат всички Basic Rates – от 1 до 54.

Точките за достъп за бързи устройства (със SSID OpenFest 2014)

Всички виртуални точки за достъп, които бяхме зачислили за бързи устройства, бяха оставени изрично само с 54Mbps basic rate.

Двете точки за достъп Cisco (със SSID OpenFest)

Изрично бяха с различно SSID, за да бъдат извън „роуминг домейна“ на машините ни с OpenWRT. Конфигурацията им се състоеше в това да им сложа парола, да задам в кой VLAN да бъдат виртуалните им точки за достъп и да им намаля радиата до минимум (или 25%, според уеб интерфейса им).

Разпределение на каналите

Имахме ограничено физическо пространство, в което трябваше да работят заедно 6 точки за достъп в 2,4-гигахерцови спектър и 5 – в 5-гигахерцовия. Разпределението в 5-гигахерцовия спектър беше лесно, защото там имаме достатъчно на брой канали, които са на разстояние повече от 20MHz един от друг, а и затихването на сигнала в този спектър е по-голямо.

Конфигурацията на 2,4-гигахерцовите мрежи обаче не беше толкова лесна за избор – в крайна сметка реших да разделя спектъра на 1-ви, 4-ти, 7-ми, и 13-ти канали, за да оставя 13-ти канал незашумен.

Физическо разпределение

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

Разпределение на устройствата

Проблеми

Проблемите (за щастие) бяха малко и с ограничен ефект.

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

Дебъгването на този проблем изведе наяве и друг – тъй като всичките точки за достъп бяха в един Ethernet сегмент, ARP заявките (както и теоретично всеки друг Ethernet broadcast) се излъчваха в радиоефира от всяка точка за достъп. Това стана особено забележимо в края на първия ден, когато доста от хората си бяха тръгнали. ARP таблицата на рутера се беше поизпразнила, за разлика от NAT таблицата му. Наблюдавахме излъчване на около 20 ARP заявки в секунда, идващи от самия рутер. Това е проблем, който ще трябва да решим за следващата година.

Бележки

Няколко души изразиха силно съмнение в това, че двата TP-Link WDR-4300 ще се справят. Устройствата се работиха абсолютно безпроблемно, без значение, че са на по-малко от половината от цената на Alix устройство с нужната периферия.

Неща, които липсваха

Липсваха ни скриптове, които да извеждат броя закачени клиенти на всяко радио, RSSI за всеки клиент, MAC адреси и т.н. SNMP сървъра, предложен в пакетната система на OpenWRT доста лесно се надгражда, но нямахме време да си ги допишем.

Липсваше ни система за централизирано наблюдение и управление на точките за достъп. Имахме само 7 устройства, които да се конфигурират на ръка, но това не пречеше да е досадно да се настройва конфигурация отделно на всяко желязо. Да не говорим, че търсенето към кое AP е закачен определен клиент беше също доста бавно и неефективно.

Мрежите ни бяха отворени. Мисля, че толкова много хардуер би се справил с конфигурация, подобна на тази на CCC – WPA Enterprise, който приема всяка комбинация на потребителско име и парола.

Липсваше ни метод за подтикване на двубандовите клиенти да се закачат на 5-гигахерцова мрежа. Тук нямаме тривиално решение – или трябва да имплементираме нещо ново в hostapd, или да измислим нещо хитро с blacklist-ване на всички MAC адреси по подразбиране за всяка 2,4 ГХц мрежа. Идеи са добре дошли.

Не успяхме да си изпрограмираме спектрален анализатор, който да приема данни от HackRF-а на Крокодила и да ни рисува Density Map в (близко до) реално време. Оглеждам Kismet Spectrum-Tools, на които трябва да им се допише поддръжка за HackRF.

Благодарности

Благодарим на Elwix, BIX, Нет Ис Сат, Точо и Мариян за заетия хардуер.