Основною відмінністю портативних аудіоплеєрів «покоління Інтернет» від своїх попередників є їхня тісна інтеграція з персональним комп'ютером.

У минулому портативні плеєри відтворювали музику з поширених змінних носіїв і не потребували підключення до будь-чого, крім навушників

Донедавна ПК був їм єдиним джерелом контенту. При цьому виникала необхідність механізму сполучення портативного плеєра і комп'ютера. Завдання полягала у передачі даних у цифровій формі з одного носія (у ПК) на інший (у плеєрі) у форматі, прийнятому у комп'ютерній галузі.

Контент необхідно перенести з комп'ютера, де він зазвичай зберігається на жорсткому диску форм-фактора 3.5”, на носії портативних плеєрів: флеш-пам'ять, жорсткі диски форм-фактора 1” і 1.8”

Отже, потрібно задіяти будь-який комп'ютерний інтерфейс передачі.

У будь-якому подібному інтерфейсі можна виділити два рівні. Перший – фізичний, тобто. безпосередньо дроти, роз'єми, мікросхеми тощо. Другий – програмний, це, умовно кажучи, набір інструкцій та алгоритмів, згідно з якими здійснюється обмін даними фізично. Цей програмний рівень часто називають протоколом. Сьогодні ми переважно говоритимемо саме про нього. Для користувача він є «обличчям» інтерфейсу, його можливості та недоліки визначають зручність чи складності в експлуатації пристрою загалом.

Для повноцінної експлуатації протоколу потрібна наявність двох програмних компонентів. По-перше, це драйвер, що займається безпосередньо поєднанням портативного пристрою та ПК на програмному рівні. По-друге, це програмне забезпечення, що дозволяє користувачеві керувати протоколом та використовувати його для своїх потреб. ПЗ, строго кажучи, не є безпосередньою частиною протоколу. Але без його наявності саме існування протоколу втрачає сенс. Тому в рамках цієї статті ми розглядатимемо програмне забезпечення як невід'ємну частину даних протоколів.

Будь-який програмний протокол використовує драйвери та програмне забезпечення, хоча реалізація цих компонентів у кожному конкретному випадку може сильно відрізнятися. Успішність протоколу можна умовно обчислити за такою формулою: можливості мінус незручності. Під можливостями розуміється спектр доступних функцій. Незручності зазвичай включають непрозорість при використанні, незручність в установці, складність в освоєнні, обмежену сумісність.

За мірками цифрової портативної техніки MP3-плеєри – вже досить літній клас пристроїв. Вони з'явилися в той час, коли інфраструктура ПК була не готова до ролі комп'ютера як мультимедіа-хоста. І на фізичному, і на програмному рівні в цій галузі ще не існувало поширених та стандартизованих рішень, вони лише перебували у розробці, готувалися до виходу на ринок чи існували у штучних кількостях. У подібному становищі виявилися інші родинні класи портативних пристроїв: мобільні накопичувачі, цифрові камери, стільникові телефони, КПК. Всі ці різновиди мобільної техніки з'явилися приблизно в той самий час, у другій половині 90-х років. Своєю появою вони викликали необхідність розробки єдиних стандартних протоколів сполучення ПК із портативною технікою.

Фізично все було відносно ясно. Перші портативні пристрої були змушені використовувати COM і LPT - інших широкодоступних інтерфейсів просто не було.

LPT-роз'єм досі можна знайти на більшості ПК

Так, саме фізичний інтерфейс LPT використовувався родоначальниками MP3-плеєрів, Saehan MpMan та Diamond Rio. Цей період можна назвати «кустарним», розробникам доводилося використовувати інтерфейси та протоколи, які спочатку були створені для зовсім інших завдань.

Однак мучитися в кайданах повільних і незручних інтерфейсів новому поколінню портативного аудіо довелося недовго: вже наступного 1999 виробники представили широкий спектр пристроїв, які використовують новий стандарт: USB, Universal Serial Bus.

Якийсь час спостерігалася видимість боротьби між USB та поширеним головним чином на комп'ютерах Apple Macintosh протоколом Firewire.

ВійнаFirewire-USB в портативних плеєрах: відiPod 1G – тількиFirewire – доiPod 5G – тількиUSB

Однак основна маса портативного аудіо швидко і безболісно пересіла на Universal Serial Bus, закривши, принаймні в рамках провідних рішень, питання з передачею даних фізично.

Не так просто склалося все для програмних протоколів. В той короткий періодКоли виробники вимушено використовували COM і LPT, програмні протоколи були виключно їх власної розробки. Ніякими іншими вони, власне, і було, т.к. і COM-, і LPT-інтерфейси створювалися свого часу, звичайно, зовсім не для передачі мультимедійних файлів на портативні цифрові програвачі. Розробляти драйвери та програмні оболонки для останніх крім самих розробників було нікому, а про стандартизацію мови взагалі не йшлося.

Але й поява USB не вирішила проблеми. Індустрія насамперед перейнялася створенням стандартних протоколів для мобільних накопичувачів, цифрових камер. Ситуація з MP3-плеєрами була взагалі не зрозуміла: заборонять їх чи ні, а якщо все ж таки не заборонять, то які особливості повинні мати протоколи, щоб форум SDMI дав добро. У подібних умовах розробка програмних протоколів, як і раніше, лежала на плечах розробника пристрою. Так тривало щонайменше чотири роки, поки, нарешті, в плеєрах почали з'являтися стандартні протоколи передачі. Ці роки були часом панування першого різновиду програмних протоколів – пропрієтарних чи закритих.

Характерною їх рисою були індивідуальні драйвери та програмне забезпечення для кожного виробника, а найчастіше для кожного нового покоління плеєрів у рамках продукції одного й того самого виробника.

Пропрієтарний протокол на прикладіRCA-ThomsonЛіра. Використовується власний драйвер (PDP2222.SYS), який необхідно встановлювати окремо на кожен ПК, до якого планується підключати програвач

Це створює багато незручностей для користувача. Ні про яку прозорість не йдеться – користувач сам змушений вручну встановлювати драйвери та ПЗ для свого плеєра. При цьому можуть виникати різні складності, наприклад, якщо покупець помилково підключить плеєр до ПК раніше за встановлення драйверів.

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

Про сумісність теж краще забути: драйвери та ПЗ працювали лише з цією моделлю плеєра (у кращому випадку – з кількома моделями від даного виробника), а плеєр міг працювати тільки з ПК, на якому встановлені ці драйвери та ПЗ. Можливості програмних оболонок спочатку були дуже мізерні і обмежувалися виключно копіюванням аудіофайлів на згадку про плеєр. Пізніше з'явилася різноманітність у способах копіювання контенту на плеєр: індивідуально за треками або синхронізацією вмісту пам'яті плеєра з вмістом скомпонованої з аудіофайлів, що знаходиться на ПК бібліотеки. Окремі програмні оболонки підтримували лише з цих способів. З часом ПО набувало додаткових можливостей, наприклад, копіювання будь-яких файлів, а не тільки підтримуваних плеєром, що давало можливість використання його як накопичувача (функція отримала прізвисько Data Taxi). Проте те що, що з цієї операції була обов'язкова установка на ПК драйверів і, серйозно знижував корисність цієї функції. Про високі естетичні якості, бездоганну роботу і хорошу ергономіку оболонок мова, як правило, і зовсім не йшла. Користувачі тоді були в масі своїми людьми суворими і нерозбещеними: копіюються файли на плеєр - і добре.

Через пропрієтарні системи пройшли більшість виробників: iriver, Rio Audio, Creative, Cowon, Mpio і т.д. Кожен із цих виробників свого часу мав і свої драйвери, і своє програмне забезпечення, у когось більше, у когось менш вдале. У будь-якому випадку, змінивши плеєр на пристрій іншого виробника, користувач змушений був пристосовуватися до нової оболонки з її логікою та особливостями. Багато виробників продовжують і сьогодні комплектувати свої пристрої цими програмами як альтернативою стандартам MSC/UMS або MTP-рішенням.

Пропрієтарніоболонки-менеджери: Iriver Music Manager, Cowon JetAudio, Mpio Manager, Creative Play Center

Зоопарк всіляких оболонок було влаштовувати споживачів (з існуванням купи різношерстих драйверів вони ще могли змиритися). Не влаштовував він і виробників, особливо невеликих ресурсів, які не мали на розробку якісного програмного забезпечення. Тому в 1999 - початку 2000-х років певну популярність набуло використання оболонок сторонніх виробників.

Серед них можна назвати програму MusicMatch Jukebox.

ІнтерфейсMusicMatch Jukebox

До появи iTunes для Windows PC саме вона використовувалася для роботи з Apple iPod. Працювала вона з плеєрами інших виробників, таких, як RCA-Thomson.

Програми типу MusicMatch Jukebox були першими паростками стандартизації. Вони дозволяли використовувати плеєри різних виробників без встановлення додаткового програмного забезпечення для кожного з них. Рішення не було бездоганним, це був лише крок від різномастових протоколів та оболонок до стандартизованих рішень. У даному випадку був стандартизований тільки інтерфейс управління протоколом, установка окремих драйверів для кожного пристрою, як і раніше, виявлялася необхідною. Самі оболонки не входили до складу операційної системи, їх необхідно було встановлювати окремо, з Інтернету або з супутнього CD. Їх функціональність, стабільність роботи та зручність часто також викликали питання. Підтримувалися далеко не всі плеєри, що змушувало виробників комплектувати пристрої плагінами для популярних програм-менеджерів.

Доступно для завантаження на сайтіRCA-Lyra: в першу чергу плагін дляMusicMatchJukebox і лише потім власна оболонкаLyraDJ

Зазвичай згодом програма «товстіла», обростала непотрібними користувачеві функціями, рекламою, вимагала дедалі більше ресурсів.

Ще одна популярна у минулому оболонка –RealJukebox

Одночасно зростав тиск конкурентів: у 2001 році Windows Media Player увійшов у стандартне постачання Windows XP, у 2003 році з'явився iTunes для Windows. Невеликі азіатські компанії в 2002-2003 році також знайшли хорошу заміну цього програмного забезпечення – відкритий протокол MSC/UMS. В результаті оболонки типу MusicMatch Jukebox зійшли зі сцени, щоб поступитися місцем протоколам нового покоління. Але їхня спадщина не пропала даремно: модель «одна оболонка для різних плеєрів» багато в чому успадкована системою Microsoft PlaysForSure.

Одна риса пропрієтарних систем, проте, дозволила їм прожити на окремих ринках довше за розумне. Їхня закритість створювала перешкоди при використанні плеєра для вільного перенесення даних з ПК на ПК, тобто, за версією RIAA, при використанні його як знаряддя цифрового піратства. На проблемних ринках, на зразок американського, компанії, які не бажають привертати до себе зайвої уваги, продовжували дотримуватися пропрієтарного підходу навіть після поширення універсальних рішень.

На сайтіiriver непропрієтарні прошивки досі відзначаються особливо, якUMS абоMTP

Тут можна згадати, наприклад, iriver чи Creative. Плеєри iriver взагалі випускалися у двох варіантах: для ринку США – працюючі через пропрієтарний протокол, для інших – через відкритий MSC/UMS. Таке життя після смерті для закритих протоколів продовжилося аж до виходу в 2004 протоколу MTP, який, будучи відносно універсальним, влаштував і звукозаписні компанії.

Період 2002-2004 років. був перехідним від "темних століть" закритих систем до відносної відкритості сучасних протоколів. Сьогодні чисті пропрієтарні протоколи повністю вийшли із вжитку.

Ймовірно, ви чули таку фразу: вам потрібно використовувати VPN для захисту вашої конфіденційності. Тепер ви думаєте: "Добре, але як працює VPN?"

В інтернеті багато статей, які пропонують використовувати якийсь один протокол, але мало хто знаходив час, щоб пояснити деякі з основних технологій VPN. У цій статті я розповім, які існують протоколи VPN, їх відмінності та що ви повинні шукати.

Що таке VPN?

Перш ніж ми розглянемо конкретні протоколи VPN, швидко згадаємо, що таке VPN.

По суті, VPN дозволяє отримати доступ до загальнодоступного інтернету за допомогою приватного підключення. Коли ви натискаєте посилання на Інтернет, ваш запит переходить на правильний сервер, зазвичай повертає правильний контент. Ваші дані по суті протікають безперешкодно з A на B, а веб-сайт або служба можуть бачити вашу IP-адресу серед інших ідентифікуючих даних.

Коли ви використовуєте VPN, всі ваші запити спершу надсилаються через приватний сервер, що належить провайдеру VPN. Ваш запит надсилається від A до C через B. Ви можете отримати доступ до всіх раніше доступних даних (і в деяких випадках - до більшого числа). Але на веб-сайті або службі є лише дані провайдера VPN: їх IP-адреса і т.д.

Існує багато застосувань для VPN, у тому числі захистити ваші дані та особистість, уникнути репресивної цензури та шифрувати ваші повідомлення.

Що таке протоколи VPN?

Протокол VPN точно визначає, як ваші дані маршрутизуються між вашим комп'ютером та VPN-сервером. Протоколи мають різні специфікації, пропонуючи користувачам переваги за різних обставин. Наприклад, деякі віддають пріоритети швидкості, в той час як інші зосереджені на конфіденційності та безпеці.

Давайте розглянемо найпоширеніші протоколи VPN.

1. OpenVPN

OpenVPN – це протокол VPN з відкритим вихідним кодом. Це означає, що користувачі можуть перевіряти вихідний код на наявність уразливостей або використовувати його в інших проектах. OpenVPN став одним із найважливіших протоколів VPN. OpenVPN має відкритий вихідний код і є одним із найбезпечніших протоколів. OpenVPN дозволяє користувачам захищати свої дані з використанням, по суті, непорушного шифрування ключів AES-256 (серед інших), з 2048-бітною автентифікацією RSA та 160-бітним алгоритмом SHA1.

Крім забезпечення надійного шифрування, OpenVPN також доступний практично для кожної платформи: Windows, MacOS, Linux, Android, iOS, маршрутизаторів та багато іншого. Навіть Windows Phoneта Blackberry можуть його використовувати!

Протокол OpenVPN у минулому піддавався критиці через низьких швидкостей. Однак нещодавні впровадження призвели до деякого прискорення, і увага до безпеки та конфіденційності заслуговує на увагу.

2. L2TP/IPSec

Протокол тунелю рівня 2 – дуже популярний протокол VPN. L2TP є наступником знеціненого PPTP (детальніше див. Нижче розділ PPTP), розроблений Microsoft і L2F, розроблений Cisco. Однак L2TP фактично не забезпечує жодного шифрування чи конфіденційності.

Відповідно, служби, що використовують L2TP, часто пов'язані з протоколом IPsec безпеки. Після впровадження L2TP/IPSec стає одним із найбільш безпечних підключень VPN. Він використовує шифрування AES-256 біт і не має відомих уразливостей (хоча IPSec нібито був скомпрометований NSA).

Тим не менш, в той час як L2TP / IPSec не має відомих уразливостей, він має деякі невеликі недоліки. Наприклад, за промовчанням протокол використовує UDP на порту 500. Це спрощує визначення та блокування трафіку.

3. SSTP

Протокол Secure Socket Tunneling Protocol є ще одним популярним протоколом VPN. SSTP має одну помітну перевагу: він повністю інтегрований з кожною операційною системою Microsoft з інсталяції Windows Vista з пакетом оновлень 1 (SP1). Це означає, що ви можете використовувати SSTP з Winlogon або для підвищення безпеки - смарт-чіп. Крім того, багато постачальників VPN мають спеціальні вбудовані інструкції SSTP для Windows. Їх можна знайти на веб-сайті постачальника VPN.

SSTP використовує 2048-бітові SSL/TLS-сертифікати для автентифікації та 256-бітові SSL-ключі для шифрування. Загалом SSTP досить безпечний.

SSTP є, власне, пропрієтарним протоколом Microsoft. Це означає, що ніхто не може повністю перевірити базовий код. Тим не менш, більшість з них, як і раніше, вважають SSTP безпечним.

Нарешті, SSTP має вбудовану підтримку Windows, Linux і BSD. Android, macOS та iOS підтримують сторонні клієнти.

4. IKEv2

Internet Key Exchange (Інтернет обмін ключами) версії 2 – ще один протокол VPN, розроблений Microsoft та Cisco. IKEv2 є протоколом тунелювання, що забезпечує сеанс обміну безпечними ключами. Тому (як і його попередник), IKEv2 часто сполучається з IPSec для шифрування та автентифікації.

Хоча IKEv2 не такий популярний, як інші протоколи VPN, він має безліч рішень для мобільних VPN. Це пов'язано з тим, що він вміє повторно підключатися в моменти тимчасової втрати інтернет-з'єднання, а також під час комутатора (наприклад, від Wi-Fi до мобільних даних).

IKEv2 - це пропрієтарний протокол із власною підтримкою пристроїв Windows, iOS та Blackberry. Для Linux доступні версії з відкритим вихідним кодом, а підтримка Android доступна через інші програми.

На жаль, в той час як протокол ikev2 відмінно підходить для мобільного зв'язку, є вагомі докази того, що американське АНБ активно експлуатуючи його недоліки, щоб підірвати трафік IPSec.

5. PPTP

Протокол тунелювання "точка-точка" є одним із найстаріших протоколів VPN. Він, як і раніше, використовується в деяких місцях, але більшість служб давно оновлені до більш швидких та безпечних протоколів.

PPTP було введено ще 1995 року. Він був фактично інтегрований з Windows 95, розроблений для роботи з комутованими з'єднаннями. Тоді це було надзвичайно корисно.

Але технологія VPN прогресувала і PPTP більше не захищений. Уряди та злочинці давно порушили шифрування PPTP, зробивши будь-які дані, надіслані з використанням протоколу незахищеними.

Однак він ще не зовсім мертвий... Розумієте, деякі люди вважають, що PPTP дає кращі швидкості з'єднання саме через відсутність функцій безпеки (у порівнянні з сучасними протоколами). Таким чином, він, як і раніше, використовується, оскільки користувачі просто хочуть дивитися Netflix з іншого розташування.

Підіб'ємо підсумок протоколів VPN

Ми розглянули п'ять основних протоколів VPN. Давайте швидко підсумуємо їх плюси та мінуси.

OpenVPN:має відкритий вихідний код, пропонує найсильніше шифрування, що підходить для всіх видів діяльності, має трохи повільніший час з'єднання.

L2TP/IPSec:широко використовується протокол, хороші швидкості, але він легко блокується через залежність від одного порту.

SSTP:гарна безпека, важко блокувати та виявляти.

IKEv2:швидкий, зручний для мобільних пристроївз кількома реалізаціями з відкритим вихідним кодом (потенційно підривається АНБ).

PPTP:швидкий, широко підтримуваний, але повний дір у сфері безпеки використовується тільки для потокової передачі та основного перегляду веб-сторінок.

Щоб забезпечити повну безпеку та спокій, виберіть постачальника VPN, який пропонує вам вибір протоколу. Крім того, ви можете використовувати платні рішення VPN, такі як ExpressVPN, а не безкоштовний сервіс. Коли ви платите за VPN, ви купуєте послугу. Коли ви використовуєте безкоштовний VPN, ви не маєте, що вони можуть зробити з вашими даними.

Який протокол VPN ви зазвичай використовуєте? Чи пропонує ваш VPN-провайдер вибір? Розкажіть це у коментарях!

17 липня, 2017 , BIS Journal №3(26)/2017

Порівняння технологій та протоколів захищеного доступу

VPN є невід'ємною частиною всіх систем інформаційної безпеки, у тому числі тих, що забезпечують захист систем фінансових організацій. Ця технологія є найпростішим, зрозумілішим та доступнішим способом безпечно об'єднати територіально розподілені майданчики та надійно захистити інформацію при передачі по мережах загального користування.

Існує безліч сценаріїв застосування VPN: організація взаємодії між віддаленими офісами, підключення віддалених співробітників або клієнтів, підключення банкоматів, доступ до ЦОДів, в яких зосереджені ресурси інформаційних систем банку. Крім завдання забезпечення взаємодії, у ряді випадків, VPN дозволяє сформувати чіткий периметр захисту та забезпечити доступність сегментів інформаційної системи.

Однак, перш ніж почати вибір конкретного постачальника рішення, потрібно і важливо розуміти, які технології VPN існують і яка різниця між ними.

ПРОПРИЄТАРНІ ПРОТОКОЛИ

Усі протоколи передачі даних поділяються на дві категорії.

Перша категорія, про яку йтиметься - пропрієтарні (закриті) протоколи та технології, що є інтелектуальною власністю окремих компаній. Переваги такого підходу в тому, що технологія може бути швидко допрацьована під вимоги виробника обладнання або бажання конкретного замовника. Проте, є й низка мінусів.

По-перше, для замовника велика ймовірність стати об'єктом досліджень і технічних доробок за свої гроші. Щоб знизити ризик появи архітектурних помилок, необхідно максимально повно відпрацювати нову технологіюіз залученням якомога ширшого кола експертів. На жаль, база замовників російських вендорів, які використовують пропрієтарні протоколи, не завжди дозволяє це зробити. До речі, закордонні лідери ІТ ринку не йдуть шляхом створення пропрієтарних протоколів. Вони розвивають функціональні можливості загальноприйнятих протоколів, відкривають доступом до своєї технології та роблять її публічною, доступною для інших виробників.

По-друге, істотним недоліком є ​​те, що нестандартний дизайн продукту та недокументована поведінка пристроїв можу поставити замовника у залежність від постачальника продуктів. Якщо якість сервісу або послуг перестане влаштовувати замовника, перехід із пропрієтарного протоколу на інший може бути вкрай витратним або взагалі неможливим без повної перебудови системи безпеки. У кращому випадку замовник зможе розраховувати на використання апаратних платформ, на які можна буде поставити нове програмне забезпечення. Фахівці компанії "С-Терра СіЕсПі" вже мали досвід встановлення свого VPN-шлюзу на платформи компанії Stonesoft (яка хоч і використовувала стандартні протоколи, але, як відомо, припинила активну діяльність на ринку мережевої безпеки в Росії).

По-третє, будь-який нестандартний дизайн створює проблеми під час пошуку несправності або неправильної роботи пристроїв. Необхідно мати у штаті людей, які знають особливості поведінки як стандартного устаткування, і специфіку роботи технологій конкретного виробника.

І, по-четверте, треба враховувати той факт, що пропрієтарний протокол має мінімальні шанси для сумісності з іншими виробниками.

ПУБЛІЧНІ ПРОТОКОЛИ

Друга категорія - це публічні (або стандартні) протоколи, які можуть застосовуватись в устаткуванні, виробленому різними вендорами. Опис цих технологій наводиться у спеціальних документах (Request for Comments, RFC) організації інженерної ради Інтернету (Internet Engineering Task Force, IETF). Їх створюють та доповнюють найкращі експерти галузі. Для VPN з публічних протоколів найчастіше використовуються IPsec та SSL у різних варіаціях.

SSL (TLS)

Це сімейство протоколів призначене для забезпечення віддаленого клієнтського доступу та орієнтоване на конкретні користувацькі програми. Існує кілька варіантів використання SSL (TLS):

Безклієнтський режим.У цьому режимі використовується одностороння автентифікація сервера на стороні клієнта. При цьому користувачу не потрібно встановлювати спеціалізоване ПЗ для захисту трафіку, а достатньо мати на АРМ-і тільки криптопровайдер. Робота в такому режимі можлива тільки з Web-додатками, причому в російських реаліях є прив'язка до найпопулярнішого браузеру Internet Explorer. Такий режим роботи підходить, наприклад, для обмеженого переліку сценаріїв захищеного доступу до веб-порталу.

Клієнтський режим.Якщо потрібно забезпечити доступ до будь-якої іншої програми, використовується спеціальний SSL (TLS)-клієнт. У цьому режимі можна використовувати двосторонню аутентифікацію.
Однією з головних переваг протоколу є відсутність або мінімальна необхідність персонального налаштування клієнта. Однак, якщо на робочу станцію буде встановлено нове ПЗ або з'явиться новий сервіс, до якого потрібний доступ, користувач повинен буде додати ці параметри до параметрів клієнта.

Також потрібно враховувати особливість, що стандартний SSL працює на рівні програми та не може захистити трафік від мережевого обладнання або від сегментів мережі. Вирішити це завдання може протокол DTLS, але він також має клієнт-серверну модель і слабко поширений серед російських виробників.

IPsec працює на нижчому рівні моделі OSI, і для його роботи не потрібна підтримка програм. Він чудово підходить для створення захищених з'єднань як між філіями у територіально розподіленій мережі, так і для організації захищеного віддаленого доступу.

За рахунок роботи протоколу на мережному рівні, для роботи VPN не потрібно вносити зміни до ПЗ на робочих місцях. Всі додатки користувача працюють "прозоро" і не знають про існування VPN. Протокол завжди здійснює двосторонню автентифікацію.

При реалізації віддаленого доступу потрібне персоналізоване налаштування клієнта кожної конкретної робочої станції. При цьому клієнт захищає всі мережеві взаємодії між АРМ і віддаленою мережею. Отже, необхідність наявності на робочих місцях користувачів засобів захисту від несанкціонованого доступу до АРМ є більш актуальною, ніж у випадку SSL.

IPsec є найвідомішим протоколом для побудови VPN та продовжує розвиватися. З'явилася друга версія протоколу розповсюдження ключів IKE, стек протоколів є частиною стандарту IPv6.

Крім вищепереліченого, стандартні протоколи IPsec і SSL (TLS) мають певні переваги саме в російських реаліях. Йдеться про діяльність технічного комітету зі стандартизації "Криптографічний захист інформації" (ТК 26) у галузі вироблення рекомендацій щодо використання одноманітних вузлів заміни та параметрів еліптичних кривих у російських ГОСТах з криптографії, а також їх використання у протоколах передачі даних. Ця діяльність вже принесла свої плоди – низка російських виробників, у тому числі компанія «С-Терра СіЕсПі», забезпечили сумісність своїх сертифікованих рішень під час використання протоколу IPsec. Безумовно, якби застосовувалися пропрієтарні протоколи, таких результатів неможливо було досягти. Хоча такі процеси не відбуваються швидко, у замовників з'являється перспектива виконання заповітної мрії – появи технічної сумісності різних сертифікованих VPN-рішень між собою.

Використання стандартних протоколів у різних сферах (Syslog, SNMP, Netflow тощо) дозволяє об'єднувати продукти в єдину систему. Наприклад, така практика є загальноприйнятою під час вирішення завдань моніторингу та побудови SIEM-систем.

РОБИМО ВИСНОВКИ

При виборі стандартного протоколу замовник має визначитися із бажаним сценарієм використання. Якщо йому достатньо захисту лише окремих сервісів і важлива простота налаштування - SSL (TLS), при потребі повного зв'язку між об'єктами - його вибір IPSec.

Разом з тим, необхідно пам'ятати, що окрім протоколу передачі даних, у кожному рішенні є велика кількість різних технологійта особливостей. Тому варто оцінювати та порівнювати продукти загалом, залежно від поставленого завдання.

Сьогодні я розповім про чудовий протокол мовлення RTMFP. У ньому реалізовано багато цікавих підходів і існує дуже багато забобонів щодо його можливостей. Хочу підігріти інтерес до цієї теми та розвіяти існуючі ілюзії. Я не знайшов нічого кращого для мовлення в реальному часі і вирішив написати цей пост.

Передісторія

Давним-давно у далекій галактиці...
У 2004 році жила-була Amicima, Inc.в якій було розроблено GPL реалізація протоколу MFP - MFPNet. Потім вони випустили amiciPhone- одного із конкурентів Skype, але через проблеми позиціонування справи пішли не дуже добре. У 2007 році їх придбали Adobe так як їм потрібен був хороший протокол мовлення реального часу.

А що не так з RTMP?

RTMPне є протоколом мовлення реального часу:

• не вирішується проблема мінімізації затримок;
• мовлення припиняється при зміні адреси пристрою;
• TCP значно збільшує затримки та роздмухує повідомлення непотрібними перевірками доставки;
• немає контролю розміру вікна.

Враховуючи швидкість розвитку мобільних мереж, покупка Amicima була досить логічним та перспективним рішенням.

Забобони з приводу RTMFP

1. Це пропрієтарний протокол

   Adobe вирішила його опублікувати у вигляді RFC7016щоб підігріти увагу громадськості, але якось обійшлося. Як це не дивно, це не схоже на криву специфікацію RTMP і більше нагадує MFP.

   Сам по собі модульний протокол: обмін сертифікатами, шифрування, синхронізація потоків виконані у вигляді окремого профілю. Те, що відбувається у Flash'і, залишається у Flash'e. Для розробників сторонніх рішень, типу Cumulus, Flash залишався чорним ящиком; якось тихо та непомітно у квітні 2014-го вийшов Adobe"s RTMFP Profile for Flash Communication.

2. Це UDP - отже, немає гарантії доставки

   Достатньо багато протоколів реального часу використовують UDP, для гарантії доставки додають мережну контрольну суму та вибіркові перевірки доставки. Перевіряють лише те, що обов'язково має прийти, а не все поспіль. Для аудіо/відео контроль доставки пакетів не має більшого значення. Розмір вікна (MTU) зазвичай максимальний і статичний, що підвищує можливість виникнення ситуації програвання порожнечі з наступним прийомом неактуальних даних при втраті пакета.

3. RTMFP нам не потрібний - у нас є WebRTC

   WebRTCце не протокол, це браузерна технологія – спроба інтегрувати SIP з RTP стеком у браузер. Якщо схрестити купу RTP, SRTP, SCTP, RTCP, ZRTP, RTSP - вийде RTMFP. Але в ряді випадків подібні зв'язки мають надмірність і проблеми з адресацією яких немає в RTMFP.

   RTMFP має і прокидання через NAT, і контроль розміру вікна, і метадані для потоків з контролем надмірності з боку програми, і forwarding/redirect сесій, і свій DHT.

   Скільки потрібно інкапсулювати RTP-подібні протоколи, щоб це все реалізувати?.. Думаю, десь 4-5 штук.

   Поточна реалізація протоколів мовлення нагадує ситуацію:
   

   «Існує 6 протоколів, але вони мають фатальний недолік, і ми розробимо ще один...»
   Минає рік.
   «Існує 7 протоколів, і вони мають фатальний недолік...»

   
   RTMFP - це спроба замінити існуючі рішення. Це спроба їх генералізувати, позбавиться надмірності і зробити доступними для користувачів.

RTMFP та модель OSI

Отже, розглянемо, які рівні моделі OSI покриває RTMFP протокол.

• Фізичний та канальний

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

• Мережевий та транспортний

  Це IP та UDP multicast.
  Тут і Path MTU discovery і Congestion Control вже в коробці для кожного конкретного потоку. Є режим передачі даних з вибірковою частотою перевіркою доставки – перевіряємо раз на N пакетів. Всі пакети мають тимчасові мітки для вимірювання затримки при доставці. Вбудована кільцева хеш-адресація кінцевих точок типу DHT.

• Рівень вистави

  Для Flash це, звичайно, AMF3 та інкапсульований RTMP, але передавати можна будь-які інші дані.

Безпека у RTMFP

• Класичний обмін ключами по Діффі-Хелман зі статичними та ефемерними ключами.
• Cookies та сертифікати в сесіях, з можливістю цифрового підпису пакетів. Щоправда, за умовчанням непідписані пакети вважаються валідними.
• Для шифрування використовується AES128, але можна використовувати будь-який інший блоковий алгоритм.
• HMAC-SHA256 або мережеві контрольні суми.

Користувальницьку автентифікацію та авторизацію можна реалізувати з боку програми. Питання фільтрації зловреда залишається відкритим.

Де функція-вбивця?

Я думаю, чи всі пам'ятають провал трансляції останньої презентації нового поп-телефону IPhone 6 Plus?

Так ось уявіть собі, що один клієнт отримує вхідний потік і транслює його ще двом і більше (якщо можливо), і так поки дозволяє максимально можлива затримка. При цьому в дереві клієнтів відбуваються перестановки та сортування в реальному часі з метою мінімізації затримок та оптимізації вікна пакета. У результаті можна досягти багаторазового зменшення вихідного трафіку сервера мовлення.

І всі його побачать.

Варіанти використання

1. Мовлення контенту у реальному часі

   Власне це призначення самого протоколу, і з цим завданням він справляється дуже добре.
   Його можна використовувати не тільки для передачі аудіо/відео, але і як основний транспорт у іграх Flash.

2. CDN

   Це Р2Р і для завантаження файлу потрібно лише знати його ім'я, хеш та розмір.
   Можна реалізувати шлюз http2rtmfp - можливості відкриваються досить цікаві.

3. Відео-конференції та чати

   У пост-сноуденівську епоху RTMFP - доступний та захищений Р2Р транспорт. Основною перевагою є можливість продовжити мовлення при зміні мережевої адреси пристрою. WebRTC може відвалитися при зміні стільника в 3G/4G. RTP стек погано підходить для мовлення у подібному середовищі.

4. Передача даних реального часу всередині приватних мереж

   Основною перевагою для даного варіанту використання є можливість гнучкої політики маршрутизації, мінімізації затримок, опціональної перевірки доставки пакетів та вбудованих засобів пріоритезації трафіку. Все це можна налаштувати індивідуально для кожної конкретної програми.

Як справи з існуючими рішеннями на базі RTMFP?

Якщо коротко - справи дуже погано. На сьогоднішній день із відкритих реалізацій є хіба що Cumulus. Розвивається він дуже мляво. Заснований не на RFC, а на перших реверсах RTMFP Cirrus 1, тому сумісність з поточним Flash Profile Cirrus 2 досить сумнівна. У ньому реалізована більшість корисностей, зокрема організація надмірності в Р2Р і мовлення між пристроями. Є FMS, але він працює як FMS.

Буду радий конструктивним зауваженням.

У коментарях прошу зазначити аналоги RTMFP, якщо вам вони відомі.