Недавно один из коллег написал пост о том как он круто выполнил задачу менеджера по срочному представлению каких-то важных данных прямо на вокзале пока ждал следующего поезда.

И у меня возник вопрос: а почему в 2019 это круто?

Мобильные телефоны, которых больше CPU и RAM чем в рабочем ноутбуке 2012г - пожалуйста. Связь 4G, быстрее Wi-Fi 802.11a/g - пожалуйста. Мобильные приложения - тоже в избытке. SSO и мобильные VPN уже тоже много лет как есть, а сейчас и Zero Trust (которому тоже уже много лет) наконец-то "вошел в тренд". 

Почему же тогда согласно статистике, более 68% работы все еще выполняется на ПК? И почему мы все так часто слышим "Мне сейчас неудобно, вот доберусь до офиса/дома [завтра] - тогда отпишусь"? Ну ладно человек за рулем или в месте, где покрытия нет. Но ведь часто это не так?  

Инфраструктура плохая? Приложения неудобные? Экраны на телефонах мелкие? Рабочая культура такая? Или просто мотивации нет?

Почему некомфортно? Точнее, почему одним комфортно - а другим нет?

В последнее время много новостей о том, что 2FA (двухфакторная аутентификация) в опасности из-за качественно выполненных фейковых страниц. Конечно, 2FA бывают разные. В некоторых "особо продвинутых" европейских банках до сих пор пор можно разжиться листиком с одноразовыми TAN-кодами.

Но уже несколько лет как индустрия не стоит на месте, и вместо одноразовых TAN/PIN-кодов прилетающих по SMS или через приложения типа RSA Token, Steam Guard, Google Authenticator есть и другие варианты.

Вот видео, нас интересует самый первый сценарий. Что происходит?

Вкратце:

1. Пользователь логинится в приложение. Приложение не выполняет аутентификацию само - оно перенаправляет пользователя в его систему контроля доступа.
2. Система контроля доступа (IAM - Identity & Access Management, SSO - Single Sign On) активирует приложение для Single Sign On на смартфоне пользователя.
3. Пользователь видит на экране смартфона, что пришел запрос (кто, откуда и т.д.), аутентифицируется и разрешает доступ
4. Система IAM получает зеленый свет и возвращает пользователя в приложение, прилагая параллельно разрешение на доступ.

Вопросы:

• Q1: Где здесь пользватель вводил что-то в свой компьютер?
• Q2: Куда дружным строем отправлятся фейковые страницы?.

Я понимаю, что теперь могут возникнуть и другие вопросы, поэтому

Подробнее

1. Пользователь логинится в приложение. Приложение не выполняет аутентификацию само - оно перенаправляет пользователя в его систему контроля доступа.

* Работает это не только для веб-сайтов, но и для десктопных и мобильных приложений. Типичный пример в бизнес-среде: приложения из MS Office 2013+ (реально 2010+, но там всё было очень кривенько).

* Стандартам и протоколам для интеграции с системами IAM/SSO (SAML, OAuth, OpenID Connect) уже много лет, за ними стоят такие гиганты как Google, Facebook и представители OpenSource сообщества. Есть куча библиотек, SDK и т.д. Так что не интегрируется только ленивый.

* Интеграция подразумевает обмен сертификатами между SSO/IAM и приложением - удачи в подделке 

2. Система контроля доступа (IAM - Identity & Access Management, SSO - Single Sign On) активирует приложение для Single Sign On на смартфоне пользователя.

* Нормальные и продвинутые системы позволяют гибко настраивать параметры 2FA

• по приложениям (почта/финансы - важно, расписание корпоративного спортзала - можно и без 2FA),
• по типу аутентификации в приложении-аутентификаторе (почта - палец/PIN, финансы - полный длинный пароль)
• контексту и т.д. (диапазон IP - внутри из офиса или из аэропорта; с какого устройтва, является ли устройство корпоративным; соответствует ли оно Compliance Policy и т.д.).

* Таким образом можно реализовать интересные сценарии. Например, тот же доступ к финансовому приложению:

• Корпоративный лаптоп в офисе - SSO через сертификат, пользователь просто заходит без вопросов, но только если лаптоп прошел проверку Health Attestation (антивирус, файрволл и т.д. отписались, что всё ОК)
• Тот же лаптоп вне офиса (дома, в пути) - 2FA
• [опционально] Тот же лаптоп вне офиса в VPN - пароль 
• Свой лаптоп - доступ запрещен, и даже знание пароля и установленный VPN-клиент не помогут, т.к. к проверкам подключается корпоративная MDM-система.
• Но посмотреть расписание корпоративного спортзала можно и со своего лаптопа/телефона - но через 2FA
• А если хочется со своего и без 2FA - регистрируй устройство в корпоративном MDM (с разделением приватного и фирменного) и тогда можно и без 2FA

3. Пользователь видит на экране смартфона, что пришел запрос (кто, откуда и т.д.), аутентифицируется и разрешает доступ

* Обратите внимание, что при таком подходе пользователь, даже находясь на новогодней корпоративной вечеринке, сразу увидит, если кто-то пытается доступиться к его ресурсам.

Но вместо того, чтобы рвать на себе волосы достаточно просто отклонить запрос на доступ и продолжать пить отдыхать, а уже после ИБ по логам разберется.

* Также, нигде не фигурирует реальный пароль пользователя, и ничто не пишется в веб-страницу/приложение - фейковое или реальное

4. Система IAM получает зеленый свет и возвращает пользователя в приложение, прилагая параллельно разрешение на доступ.

* Разрешение (SAML Assertion) подписано ЭЦП системы IAM и действительно только для этой сессии - просто так не подделать

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

* И что тоже очень полезно (но должно поддерживаться с обеих сторон) - Just in time Provisioning - т.е. динамическое создание аккаунта в приложении.

Если в компанию пришло 10 человек, и каждому нужно создать 10 аккаунтов - какова вероятности, что админы где-то напортачат и сколько это потом исправлять? С помощью JIT Provisioning приложение получает данные из системы IAM и автоматом всё создает. Хороший пример - Salesforce.

В завершение.

Тему можно развивать долго. Вариантов много. Важно, что всё описанное выше - не космос, а вполне реальные вещи, которые может себе позволить любая организация числом от 1 до 100000 чел.

Естественно, если есть много корявых старых приложений, то всё будет сложнее, но в типичных сценариях сроки внедрения <1 мес - реальны.

Важным нюансом является то, что система IAM должна уметь работать с MDM (система управления мобильными устройствами, включая лаптопы/ПК) - иначе должный уровень безопасности не обеспечить (сохраняя вменяемый уровень простоты).

Два крупнейших решения (согласно Gartner MQ 2018):

* Microsoft Azure AD Premium P2 + Intune или MS 365 E3/E5

Отлично вписывается в формат организаций (особенно крупных), внедряющих Office 365 или двигающихся в облако Azure, есть пара подводных камней в лицензировании (типа отдельной платы на 2FA за каждую аутентификацию в отдельных пакетах), что компенсируется кучей всевозможных интеграций с другими продуктами MS и Azure  (в т.ч. мобильными приложениями), аналитикой, ИИ и т.д.

Как вариант, MS ADFS (Active Directory Federation Services) позволяет многое реализовать самому и без облака (в т.ч. что, чего Azure до сих пор не умеет, но приходится буквально сшивать лоскутное одеяло, интегрируя и поддерживая различные продукты от разных вендоров

* VMware WorkSpace ONE

VMware купила в 2014 абсолютного (по сей день, включая MQ 2018) лидера MDM/EMM рынка AirWatch и расширила функциональность своими решениями.

Наворотов не так много как у Microsoft, зато работает не только в облаке, больше возможностей для интеграции, больше поддерживаемых платформ (и зачастую больше функциональности - Mac, Android) экосистема (не заточена на Microsoft, как Intune/AzureAD, куча интеграций со специализированными вендорами безопасности, Threat Intelligence, Threat Management), проще лицензирование и, как результат, малые организации могут позволить себе "взрослые" фишки без доплаты.

Оба решения поддерживают управление Windows 10 Modern Management, т.к. MDM-протокол для Win10 разрабатывался (насколько мне известно) с привлечением AirWatch.

В общем, пора закругляться. Думаю дырки в повествовании еще остались. Если есть вопросы - задавайте.

На волне нескольких постов коллег о VDI и HCI, хочу поделиться парой простых примеров того, что уже работает и не требует радикальной перекомпоновки дата-центров и прочих революций. 

В трех предыдущих частях мы рассмотрели обещания, потоки и каналы 802.11ac Wave2. Сегодня закрываем тему последним, самым важным, нововведением – Multi-User MIMO.

Напомним, в Wi-Fi предыдущего поколения была проблемка: связь была полудуплексная. А, следовательно, если с точкой 4x4:4@160MHz (потенциально большая пропускная способность) общается клиент 1x1:1@20Mhz, то вся остальная часть «трубы» простаивает. А в данном случае это 1- 20/(4*160) ~= 97% !

[Здесь и далее иллюстрации из White Paper от Xirrus - по поводу MU-MIMO писали вообще все, но если бумаги от Cisco и Aruba техничны донельзя, а другие – маркетинговы донельзя, то эта – хороший пример сбалансированной подачи. Молодцы.].

Сделать связь полнодуплексной без переделки ВСЕГО-ВСЕГО не получится, но ситуацию можно улучшить: у наших коллег из «большой» сотовой связи тоже всё как-бы не совсем полнодуплексно, но одна сота обслуживает множество клиентов на огромной территории.

И тут начинаются нюансы... Напомним, и в современном Wi-Fi и в современной большой сотовой связи используется OFDM, в котором канал делится на большое количество (десятки) поднесущих. По сути, скажем, 20MHz канала делятся на 50 канальчиков в 0.4 MHz. На самом деле все сложнее, но для нашего примера сойдет. Далее оказывается, что с современными скоростями клиенту не нужны все 20Mhz – ему достаточно всего несколько «подканалов» (в зависимости от типа клиента и его задач). Есть механизм посредством которого клиент и базовая станция договариваются, какие подканалы брать и как долго их использовать. В общем, всё классно. Так работают Wi-MAX, LTE и иже с ними.

Проблема лишь в том, как это запихнуть в точку доступа? Базовая станция LTE – не крохотная коробочка, висящая под потолком, и питается не по PoE. Поэтому всей это красоты в 802.11ac мы не увидим (хотя, возможно, увидим в 802.11ax году эдак в 2019). А вместо этого увидим вот что.

Еще в 802.11ac Wave 1 сделали обязательным Beamforming (динамическое управление диаграммой направленности антенны). В Wave2 сказали: «А давайте-ка использовать Beamforming, чтобы слать сразу несколько потоков РАЗНЫМ клиентам?»

Ну а что – звучит неплохо! Теперь если на точке 4x4:4 сидят клиенты 1x1, то можно работать сразу с четырьмя. А это как бы в четыре раза быстрее! Кроме того, если есть клиенты с 2SS и 3SS – их тоже можно комбинировать: 1+1+2, 1+3, 2+2. Таким образом, задействован весь скоростной потенциал точки – ничего (из оплаченного) не простаивает – классно!

Давайте разбираться.

Первое. Обратите внимание, что везде говорится только о передаче от точки к клиенту. Обратили? А где говорится о передаче от клиента к точке? Верно – там всё по-старому, и пока клиент 1x1:1@20 передает – все остальные молчат. На самом деле, это не так и плохо, так как клиенты скачивают гораздо больше, чем закачивают. А служебные пакеты (типа ACKов) уже давно научились агрегировать для экономии времени.

Второе. Обратите внимание, как на диаграмме клиенты стоят ВОКРУГ точки. Обратили? Это тоже неспроста. Почти на всех диаграммах (кроме самой наглой маркетолохии) клиенты будут вокруг. Особенно, если диаграмма включает Beamforming:

Как вы думаете, хорошо ли будет работать формирование 3-4 НЕЗАВИСИМЫХ потоков данных, если все 3-4 клиента находятся в одном месте?

Третье и последнее. Обратите внимание, что ничего не говорится о поддержке со стороны клиента. Обратили? А она нужна! Чтобы это всё работало нужна поддержка клиентов. Без этого – ничего не будет. Впрочем, клиенты уже есть, вот, к примеру, список для Quallcomm:

Итого?

В целом, для того, чтобы MU-MIMO работал нужно следующее:

• Поддержка клиентов
• Преимущественно downstream трафик
• Клиенты со всех сторон от точки
• Клиенты не двигаются (тоже важно для Beamforming’а)

Всё это реально, и при таких условиях в реальной среде (не супер-специальной тестовой камере) общая пропускная способность в соте может достичь примерно 2.1x от обычного Single-User MIMO (именно около этой цифры колеблются отчеты и тестирования почти всех вендоров, презентуемые на реальных технических мероприятиях). Как видим – далеко не в четыре раза, но и не так бесполезно. При правильном дизайне сети через год-другой, когда MU-MIMO будет поддерживать большинство устройств от него будет польза. Если только к этому времени не выкатят 802.11ax Wave1 :)

Заключение

802.11ac Wave2 обещает много и частично выполняет обещания. Не так, чтобы он совсем бесполезен, но достичь даже 50% от новых заявленных скоростей будет практически нереально.

Из хорошего, это значит, что скорее всего не придется апгрейдить проводные сети и прокладывать новые кабели (а этим много стращали и даже придумали новый стандарт Ethernet на 2.5GBps чтобы лучше продавались коммутаторы). С другой стороны, может оказаться, что новые точки потребуют питания 802.3at PoE+, а на старом «обычном» 802.3af PoE будут работать не лучше (а то и хуже) старых.

В общем получается так же, как и с переходом с .11n на .11ac: если вам нужна скорость индивидуальных линков, и вы не строите беспроводные мосты – ничего нового вы не получите. Если вам нужна емкость (скорость по всей соте) – прирост будет. Но обязательно нужен пилот в вашем конкретном окружении и с вашими конкретными приложениями и клиентами, а то прироста может вообще не быть, или он не будет стоить потраченных денег.

Из альтернатив имеет смысл попилотить Wave1 или даже 802.11n, если цена привлекательна (Wave2 сейчас продается с большой наценкой, а Wave1 уже «не модно») и уже целиться на 802.11ax, обещающий реальные качественные, а не количественные, изменения.

Что думаете?

В предыдущих частях мы рассмотрели обещания 802.11ac Wave2 и насколько они выполняются в плане увеличения числа потоков MIMO.

В этой части рассмотрим обещания в плане каналов. А именно:

• Каналы 160Mhz: в два раза шире, чем 80Mhz Wave1
• Дополнительные каналы в 5GHz: больше каналов – лучше плотность!

Начнем с простого: дополнительные каналы в 5GHz работают только в США. Нам это не светит. Закончили.

Теперь рассмотрим каналы в 160MHz.

В 802.11a/g каналы были 20 Mhz, в 802.11n – 20/40Mhz, в 802.11ac Wave1 – 20/40/80. Wave2 добавляет еще каналы в 160MHz, обещая за счет этого еще одно удвоение скорости. Получится?

Конечно получится. Вопрос только, сколько каналов мы сможем туда уместить. В регуляторном домене ETSI доступны следующие 5GHz каналы:

• 36-48 (5170-5250 = 80MHz) Indoors
• 52-64 (5250-5330 = 80MHz) Indoors/DFS
• 100-140 (5490-5710 = 220MHz) DFS
• 149-165 (5735-5835 = 100MHz) SRD (25mW)

Как видим, технически доступно 480MHz, что достаточно для 3 каналов по 160MHz. Прямо как в 2.4GHz, но в несколько раз быстрее (потенциально). Соответственно, как только мы начинаем использовать такие каналы – возникают проблемы с организацией частотного плана и перекрытием со старыми сетям 802.11a/n/acWave1.

Кроме этого, внимательный читатель заметит, что 480Mhz доступны не непрерывно, и реально 160MHz каналов можно уместить только два. Для решения этого вопроса в 802.11ac Wave2 сделали хитрую штуку: канал 160MHz не обязан быть непрерывным, но может состоять из двух блоков по 80Mhz. Таким образом гораздо легче «вписаться» в существующую среду.

Однако и тут дела обстоят не так просто. К примеру, в диапазоне «первого» 160MHz-канала 5170-5330Mhz для первой и для второй при работе вне помещения указываются разные требования. А учитывая то, как работает DFS надеяться на стабильную работу всех 160MHz не приходится. Аналогично для последнего 100MHz блока требования ETSI указывают макс мощность в 25mW (Short Range Devices) – как далеко будет такая точка добивать? (Справедливости ради отметим что для высокоплотной среды даже такая мощность может оказаться слишком высокой)

Еще одной проблемой широких каналов является помехоустойчивость. Шанс словить помеху или искажения на 160MHz естественно выше, чем на 20MHz. Конечно, часть проблем решается коррекцией ошибок на приемнике за счет избыточного кодирования. Но чем выше data rate, тем меньше устойчивости.

Напомним, что в Wi-Fi для разных скоростей используются разные схемы модуляции с разной степенью избыточности кодирования: BPSK, QPSK, QAM. При этом для высоких скоростей используется исключительно QAM. 802.11a/g использовал QAM-16 для достижения максимальности скорости. 802.11n опередил 802.11a/g за счет введения QAM-64, а 802.11ac добавляет еще более высокую QAM-256. Вот табличка из Wikipedia.

А вот картинка (источник) о том, как ведет себя QAM-64 на 20MHz канале в относительно чистой, но реальной, а не «стерильной» среде. Изображено распределение ошибки при передаче пакета (PER: Packet Error Ratio, 1 – 100% потерянный пакет) в зависимости от соотношения сигнал-шум (SNR, Signal-Noise Ratio). Здесь используется 802.11n 2x2:2 802.11n MIMO с 20MHz каналом и со следующими параметрами MCS:

• MCS8: BPSK с 100% избыточности
• MCS12: 16-QAM с 33% избыточности
• MCS15: 64-QAM с 20% избыточности

Как видим, для BPSK при SNR20+ PER падает в 0 и пакеты пропадают очень редко. Для QAM-модуляций, в особенности для QAM-64, пакеты пропадают при любых условиях даже с 20% избыточностью кодирования. Можно ли это назвать стабильной связью? И это на 20MHz канале. Что будет на 80/160Mhz?

Стоит также напомнить, что более широкие каналы означают меньший уровень сигнала. Имея, скажем 100mW, при «размазывании» их по 160MHz полосы, естественно пиковые уровни будут меньше, чем при «размазывании» их по20MHz. Грубо говоря, каждое удвоение ширины – 3dB к уровню сигнала. Таким образом 160Mhz будет на 9dB слабее 20Mhz. Конечно, приемник тоже будет «собирать» сигнал с более широкой полосы, но шансы на искажение увеличиваются.

Так что о высоких скоростях на широких каналах лучше не думать.

Но закончить хочется на позитивной ноте. Хоть широкие каналы и далеко от того, что нам обещает маркетинг, польза от них есть, да и вреда почти никакого. В 802.11n широкие каналы работали очень редко – как только рядом появлялась точка неспособная понимать широкие каналы (802.11a/b/g) – приходилось сворачиваться на 20MHz и выжидать. Так что, к примеру, в густонаселенных местах они почти не работали. В 802.11ac это учли. Теперь есть такая штука как Dynamic Bandwidth Allocation, которая, по сути позволяет менять ширину канала попакетно. Таким образом даже 160MHz каналы могут быть использованы (хоть и редко). А если все рядом стоящие точки поддерживают эту штуку – они просто «распилят» общий широкий канал на несколько узких и будут передавать одновременно. При этом, если другие молчат, точка сможет передавать и на все 80-160Mhz. В общем, очень круто и своевременно!

Правда, и тут есть своя ложка дегтя: эту штуку должны поддерживать клиенты и соседи, что логично. Проблема в том, что она не вошла в обязательную часть 802.11ac Wave1. Есть Wave1 чипсеты, которые ее поддерживают, но не все. Так что пока большинство не переберется на Wave2 потенциал этой штуки полностью раскрыт не будет (но время от времени она все равно будет работать).

Итого.

В общем [BUSTED], но какая-то польза есть.

Важно понимать, что макс. скорость на макс. ширине канала – это утопия, и пока все (включая клиентов) не переедут на Wave2 – практически все профессионалы рекомендуют оставаться по-умолчанию на 20MHz.

Тем не менее, скомбинировав тот же низкоскоростной BPSK с широким каналом можно получить более высокую среднюю скорость и стабильность чем от двух узких каналов с QAM. Однако каждый случай будет уникален.

Что думаете?

В последней части рассмотрим MU-MIMO

802.11ac Wave2 Wi-Fi – не спешим (ч4) – MU-MIMO

В прошлой части мы рассмотрели, что нам обещает 802.11ac Wave2. В этой рассмотрим, насколько данные обещания выполнимы.

4-8SS. Обещанные новые пространственные потоки MU-MIMO – это хорошо, но выполнимо ли? Тут есть много «но», но основных три:

• Клиенты. Во-первых, для достижения высоких скоростей их должны поддерживать и клиенты (тут нужно сделать оговорку на MU-MIMO, но мы к нему вернемся). Если ноутбуки с 3SS мы еще видели, то телефоны и планшеты – самый массовый тип клиента – еле добрались до 2SS (да и то, в основном тоже для маркетинга). Выше лезть не позволяют ограничения по питанию, что приводит нас к следующему пункту.
• Питание. Со времен выхода первых точек 802.11n одним из важных конкурентных факторов для производителей WLAN-оборудования была возможность работы от 802.3af (PoE). 802.3at (PoE+), конечно, лучше, но может повлечь замену не только свичей, но и UPSов, электрооборудования, систем охлаждения и т.д. Понятно, что каждый новый SS – это, фактически, дополнительное мини-радио. А радио – основной потребитель энергии. Плюс, возросшие скорости требуют более мощных процессора и памяти, особенно с учетом новомодных штук типа Application-Layer Firewall’ов. Какой мощности должен быть процессор, способный проверять на прикладном уровне 7.62Gb трафика в секунду? И питаться от 802.3af?
• Среда. И последнее. Для высокой скорости нужен качественное (и устойчивое) соотношение сигнал-шум (для того, чтобы работали самые быстрые MCS) и благоприятный multipath (чтобы потоки таки разнеслись в пространстве и сошлись на клиенте). А это, как-бы, взаимоисключающие требования: для хорошего и стабильного сигнала нужна прямая видимость. А при прямой видимости – какой multipath? Мы уже это проходили с выходом точек 802.11n 3SS, когда диаграммы самих же вендоров показывали, что новые скорости достигаются только в 10-15м от точки. Если третий поток добавить было так сложно – как, думаете, обстоят дела с четвертым? С пятым? С восьмым?

В общем, надеяться на высокие скорости от новых потоков, особенно от 8SS могут только создатели беспроводных мостов: две точки смотрящие друг в друга кучей супер-узконаправленных антенн (тарелки и т.д.), никаких ограничений по питанию (всё равно требуются спец-БП для мощных радио) – можно запустить 4 потока на 8 антеннах и получить отличную избыточность (=помехозащищенность, дальность и т.д.) сигнала.

Остальным придется выбирать. В принципе, дополнительные антенны – это хорошо (если они работают от 802.3af – многие вендоры просто отключают радиоцепи при работе со стандартным PoE, но забывают об этом сказать в пресс-релизе). Это избыточность сигнала. Это лучшая помехозащищенность. Это в целом немного более быстрые скорости если у клиента достаточно приемных антенн. И даже если антенн недостаточно – всё равно чуть более быстрые скорости (более качественный beamforming). Это, в конце концов, лучший потенциал для MU-MIMO (о нем позже).

Всё это в целом позволит немного поднять емкость сети, но надеяться на 33%+ прироста я бы не стал.

Вердикт: [BUSTED]. А вы как считаете?

В следующей части напишу о каналах. Много букв получается.

802.11ac Wave2 Wi-Fi – не спешим. Ч3 – каналы

Устройства 802.11ac Wave2 уже доступны на каждом углу обещая тот самый «гигабитный» Wi-Fi. А для тех, кто помнит, что «гигабитный» Wi-Fi нам уже обещали 802.11ac Wave1 – обещают «мультигигабитный» Wi-Fi. Давайте разбираться, что мы получим на самом деле.

Для начала, что же нового приносит Wave2?

• 4SS+: новые чипсеты Wave2 поддерживают четыре и выше пространственных потока MIMO (Spatial Streams), что как-бы на 33%+ быстрее Wave1 с 3SS.
• Каналы 160Mhz: в два раза шире, чем 80Mhz Wave1
• Дополнительные каналы в 5GHz: больше каналов – лучше плотность и емкость сети!
• MU-MIMO: самая главная и активно продвигаемая фишка. Традиционная Wi-Fi сота – это хаб. Можно иметь точку с суперширокими каналами, супербольшим количеством потоков и т.д., но если клиент поддерживает только один поток на 20Mhz и на самой медленной модуляции – весь остальной потенциал точки будет потрачен впустую. В зависимости от комбинации точки и клиента неэффективность может составлять 70%+ доходя в крайних случаях до 90% потерянного потенциала (=выброшенных на ветер денег). MU-MIMO (Multi-User MIMO) обещает если не решить, то хотя бы улучшить проблему, обеспечив параллельную передачу данных нескольким клиентам. Таким образом, наш хаб как бы превращается в свитч и мы уже не теряем весь тот (оплаченный) потенциал.

Во всяком случае, в пресс-релизах и маркетинговых материалах все именно так. Еще любят добавить цифр:

• взять пропускную способность 802.11ac Wave1 - 1.3Gbps
• удвоить за счет новой ширины каналов (80 -> 160): 1.3*2 = 2.6Gbps
• добавить новые потоки (Wave1 3SS -> Wave2 8SS): 2.6/3*8 = 6.93 Gbps
• поделить на пропускную способность 802.11n (600Mbps): 6.9/0.6 = в 11.5 раз быстрее!
• 802.11ac работает только в 5GHz, но мы добавим на всякий случай 2.4 радио (которое работает в 802.11n до 600Mbps) и получим 6.93+0.6 = 7.53 ~=7.6 Gbps (на точку).
• напомнить о необходимости поменять все свитчи на 2.5G или 10G, чтобы не платить за прокладку новых кабелей.

А что на самом деле? Какие их этих цифр «честные»? Какие полезные? Какие реальные? Напишите в комментариях свои соображения, а я на выходных опубликую вторую часть с подробным анализом.

802.11ac Wave2 Wi-Fi – не спешим. Ч2 - потоки

Недавно в одном из прочитанных блогов увидел интересное утверждение (в моем вольном переводе):

Думаете, когда вы работаете с онлайн-банкингом из офиса, у вас сквозное безопасное соединение? Подумайте еще разок.

Достаточно, чтобы заинтересовать и немного покопать. Оказалось, что в "насквозь безопасное" HTTPS соединение можно врезать как минимум двух посредников (Man In The Middle). Правда, оба должны быть Trusted (TMITM), так что не надо сильно паниковать. Пока что.

Вариант 1: корпоративный/операторский файрвол или прокси

В корпоративных сетях пользователи обычно выходят в Интернет через прокси, который может быть задан явно или неявно (transparent или просто продвинутый firewall). Это необходимо для поддержания хотя-бы минимального корпоративного контроля над трафиком (фильтрация нежелательных сайтов/скриптов/рекламы, антивирусные проверки, кеширование и т.д.) и, в принципе, логично.

Абсолютно понятно, как это работает для нешифрованного HTTP, а вот с HTTPS - понятно не все. Ведь HTTPS как раз и предназначен для защиты от "врезания" в сессию и перехвата трафика: данные шифруются, а аутентичность сервера проверяется сертификатами. Так что, возникают как минимум два вопроса:

1. Почему я должен доверять сертификату прокси?
2. Даже если я доверяю сертификату прокси, он же выпущен на имя прокси, а не на имя моего банка - как он может сработать?

Выходит, что может.

Первый вопрос вообще не возникает, если в компании развернута собственная инфраструкра сертификатов и есть свой CA. В таком случае, сертификат этого CA будет установлен как доверенный на каждой рабочей машине, и всё, что будет подписано этим же сертификатом (наш прокси) также будет доверенным. Именно из-за этого подобное "доверенное" (Trusted) внедрение и становится возможным в этом сценарии.

Но что делать с неправильным именем в сертификате? Существует (и довольно давно) класс программ типа MITMproxy или HoneyProxy, которые этот вопрос успешно решают. Их основная функция - читить в Apple GameCenter генерировать сертификаты на лету! Прокси устанавливается в качестве промежуточного CA (подписанного Enterprise Root CA) и динамически генерирует сертификаты (для себя же) на любое имя. Таким образом, клиент думает, что он общается с банком, хотя, на самом деле, его HTTPS сессия заканчивается на прокси. Подробности тут.

Так что, исходное утверждение оказалось верным, и верить рабочим HTTPS-соединениям можно лишь настолько, насколько можно верить своему ИТ-отделу. Или же использовать браузер вроде Firefox, у которого имеется свое, независимое от ОС, хранилище сертификатов и поддержка Certificate Pinning (не так давно ставшая популярной в браузерах). Ну, или, конечно же, не использовать рабочие машины в рабочей сети в нерабочих целях, но кто будет следовать этому глупому правилу? VPN тоже может помочь, если он не на основе SSL.

То же самое может произойти если использовать смартфон "от оператора" с операторской прошивкой - вероятность нахождения на нем по умолчанию доверенного сертификата для всей инфраструктуры оператора близка к 100%.

Вариант 2: Облачный бесключевой прокси CloudFlare

Хорошо, администратор моей работчей сети может мониторить мои соединения с рабочей машины. Ну да ладно. Во всяком случае, целевой сервер, к которому я подключаюсь должен быть аутентичным - иначе прокси запаникует и не построит до него HTTPS-сессию (если только админы не накосячили с настройкой). В свете недавнего анонса Keyless SSL от CloudFlare, похоже, это уже тоже не факт.

Технические подробности можно почитать тут. Для нас важно то, что в данном сценарии уже целевой сервер (тот же онлайн-банкинг), оказывается, уже банку не принадлежит! Хорошая новость в том, что он принадлежит кому-то, кому банк доверяет.

Товарищи из CloudFlare разработали способ представляться HTTPS-сервером заказчика без необходимости подделывать сертификаты или даже подписываться ключами заказчика. По факту, как раз проверка аутентичности проводится с сервером банка, но как только она пройдена - сеанс устанавливается с доверенным сервером CloudFlare. Цель благородна - разгрузка HTTPS-трафика клиентов и защита от DDoS-атак. Сколько времени понадобится на изобретение метода имперсонации целевого сервера без необходимости получать его сертификаты и ключи (или как быстро "органы" разных стран затребуют себе бекдор-доступ) - кто его знает. Надеюсь, достаточно долго.

Итого

В, казалось бы, "безопасном от и до" HTTPS соединении могут успешно поселиться как минимум два посредника. Оба должны быть доверенными, но доверяет им ваш админ, ваш босс, ваш банк, ваш магазин - только не вы. Если вы думаете, что в Интернете еще есть 100% приватность - подумайте еще разок.

А вы знаете какие-то еще методы атак на HTTPS?

P.S. Оригинал тут.

На фоне объявления QCA (Quallcom Atheros — один из лидеров в Wi-Fi чипсетах) о покупке Wilocity (один из разработчиков WiGig чипсетов) поднялась волна энтузиазма по поводу 802.11ad. В частности, возникла мысль построить на 802.11ad систему видеонаблюдения — ведь с 7Gbps пропускной способности можно снимать видео в высоком разрешении с большого числа камер! Давайте разбираться:

Согласно Wiki, минимальный уровень сигнала для работы 802.11ad на минимальной скорости (385Mbps PHY на секундочку!) равен 68 dBm.

Согласно вот этой статье (хорошая статья по 802.11ad, кстати), максимальная мощность передатчика 802.11ad составляет 10 dBm. Это, кстати, в 10 раз меньше, чем в Wi-Fi.

Потери при распространении сигнала FSPL на всего лишь 10 м для 60GHz (в которых работает 802.11ad) составляют 88 dB (посчитано на одном из множества калькуляторов FSPL). Плюс, есть еще дополнительные потери из-за резонанса с молекулами кислорода, но давайте это опустим.

Построив простую формулу бюджета мощности канала, получим, что для работы 802.11ad на минимальной скорости на расстоянии 10 м нам нужно усиление в канале порядка 10 dB. Подробности и матан тут.

Откуда же этим 10dB взяться? Либо из усиления антенн, либо от beamforming'а, который так радужно расписывают маркетологи от 802.11ac и 802.11ad. Однако, антенны мобильных устройств обычно отличаются отрицательным усилением, так что тут нам ловить нечего. Beamforming (как показали результаты 802.11ac) может выдать 3-5dB сверху. Т.е. на передающую антенну точки доступа остается 5-7 dB.

Найти антенну на 5dB не проблема, даже всенаправленную (а полезность направленных антенн, сами понимаете, ограничена). Но только у такой антенны угол раскрытия в вертикальной плоскости будет около 15 градусов, что весьма немного, и весьма неудобно.

Так что, уже на расстоянии 10 м работа 802.11ad проблематична.

Можно ли его использовать для стриминга видео? Да!

• Стримить видео с ноутбука на внешний монитор или проектор на расстоянии 2-3 м.
• Стримить видео с планшета на телевизор без кабелей или переходников.
• Стримить видеофайлы на внешнее хранилище для бекапа.

Стримить видео с камеры наблюдения? Ну, если от камеры до точки <10м и точно нельзя бросить провод... :) Вторым вариантом будет направленная антенна на камере с большим коэффициентом усиления — жизнь (и кислород) покажет, насколько это реально.

С другой стороны, такая малая дальность — сущее благо для домашнего пользователя: сосед за стеной наконец-то перестанет "забивать мой Wi-Fi своим Wi-Fi". Аналогично, у корпоративных админов WLAN появится шанс увидеть как вся BYODшная мелочь убирается из и без того загруженного диапазона 2,4 ГГц (и заодно, не так быстро замусоривает 5 ГГц), что тоже неплохо.

В общем, как говорят буржуи: "Right tools for the right job" (картинка кликабельна).

 Что вы думаете по поводу 802.11ad?

Среди множества анонсов MWC2014 хочу выделить два. Один, погромче, от Broadcom, он сам по себе еще наделает много шуму. Второй, потише, от Huawei - там всё "без шуму и пыли", но очень интересно.

Broadcom анонсировала WLAN-чипсет для мобильных устройств с поддержкой 802.11ac 2x2:2 MIMO (867Mbps), вызвав немалый ажиотаж в прессе. Давайте разбираться.

Итак, 867Mbps, говорите?

• У кого-то дома есть гигабитный интернет?
• Кто-то видел насколько быстрый хотспот?
• У кого дома есть NAS для фильмов с реально быстрым RAID'ом? Даже одиночный SSD не всегда может отдавать данные так быстро.
• Если SSD в ПК не может читать так быстро, то у кого еще есть уверенность, что телефон сможет это писать так быстро на встроенную флеш-память (не говоря уже о карточке)? Имеющиеся у меня данные показыват скорости порядка 35-65Mbps для среднестатистического телефона.
• Две антенны = как минимум в два раза больше потребляемая мощность. Как это скажется на сроке работы от аккумулятора?

Какой же тогда от него толк, говорите?

Ну, для начала, если что-то передавать в два раза быстрее - это займет в два раза меньше времени. Так как ключевым ресурсом Wi-Fi сети является именно эфирное время - то возрастет общая емкость ячейки (количество клиентов или средняя скорость на клиента при том же количестве). Заодно, т.к. антенны меньше времени заняты передачей, можно сэкономить немного энергии. Но это всё только при небольшого объема передачах (браузинг), которые отправятся напрямую в ОЗУ телефона (если производитель такую фичу реализовал). Да и то, нужно же еще, всё-таки, данные с такой скоростью отдавать - а это значит буферизация на точке, и приличная, а то никакой разницы с "обычным" 802.11ac@433Mbps видно не будет.

 А вот что реально может помочь, так это технологии MRC и STBC, в сочетании с режимом 2x2:1 или, вообще, 1x2:1.

• При двух приемных антеннах MRC позволяет путем математики рекомбинировать исходный поток данных из копий принятого сигнала, улучшая чувствительность приемника ("среднетемпературно-по-больнице" на 3дБ).
• При двух передающих антеннах STBC позволяет путем математики передать один поток данных так, чтобы MRC получил сигнал в наилучшей форме, добавляя "математического" усиления к передаче (еще примерно столько же).
• В итоге, получаем значительное улучшение параметра Rate-over-Range за счет лучшего соотношения сигнал/шум. Что, согласитесь, немаловажно для небольшого по размерам устройства, большая часть антенн которого закрыта ладонью пользователя.

Итого, равно как и с самим 802.11ac, основное улучшение здесь не скорость (которую нам будут продавать маркетологи), а дальность и чистота сигнала. Опять же, чисто из батарейных соображений, мне интересно сравнить этот 2x2:2 и 1x2x1 (на прием-то меньше энергии уходит) и посмотреть, стоит ли овчинка выделки. Время покажет - вроде-бы такой чипсет стоит в Galaxy S5.

А вот что реально было пропущено большинством обозревателей MWC под шумом анонсов смартфонов, так это эта штука:

Это - полноценный роутер в формате SFP. С поддержкой IPv6 и даже SDN. Уровень всех этих поддержек, конечно же, надо бы проверить - но сама идея! Представляете, что можно потенциально с такой штукой сделать, особенно, добавив к ней WWAN-модем?