Що таке SSL

Протокол SSL (secure socket layer) був розроблений фірмою Netscape, як протокол що забезпечує захист даних між сервісними протоколами (такими як HTTP, NNTP, FTP і т.д.) і транспортними протоколами (TCP / IP). Не секрет, що можна без особливих технічних хитрувань переглядати дані, якими обмінюються між собою клієнти та сервери. Був навіть придуманий спеціальний термін для цього - "sniffer". А у зв'язку зі збільшенням обсягу використання Інтернету в комерційних цілях, неминуче поставало питання про захист переданих даних. І користувачі не дуже були б раді, якщо номер їхньої кредитної картки, був би перехоплений, яким не будь заповзятливим хакером "по дорозі" до віртуального магазину. І, загалом, поява такого протоколу як SSL було цілком закономірним явищем. З одного боку залишаються всі можливості сервісних протоколів (для програм-серверів), плюс до цього всі дані передаються в зашифрованому вигляді. І разкодувати їх досить важко. Опустимо тут можливості злому SSL (вона, безумовно, є, але це окрема тема для великої статті). Слід зазначити, що SSL не тільки забезпечує захист даних в Інтернеті, але так само виробляє "пізнання" сервера і клієнта ("server / client authentication"). У даний момент протокол SSL прийнятий W3 консорціумом (W3 Consortium) на розгляд, як основний захисний протокол для клієнтів і серверів (WWW browsers and servers) у мережі Інтернет.

Уявіть собі, що є дві людини, які спілкуються за допомогою Інтернету і відповідно не бачать один одного.  І позбавлені можливості, дізнатися, про те хто ж його абонент. Їх імена - Аліна і Ден. Припустимо Аліні треба, дізнатися дійсно вона розмовляє з Деном чи ні. У цьому випадку діалог може виглядати наступним чином:

* Аліна відправляє Дену випадкове повідомлення.
* Ден шифрує його з допомогою свого приватного ключа і відправляє його Алісі.
* Аліна дешифрує це повідомлення (з допомогою публічного ключа Денаа). І порівнявши це повідомлення з посланим, може переконатися в тому, що його дійсно послав Ден.

Але насправді з боку Дена не дуже вдала ідея шифрувати повідомлення від Аліни з допомогою свого приватного ключа. І повертати його. Це аналогічно підпису документа, про який Ден мало що знає. З такої позиції Ден має сам придумати повідомлення. І послати його Аліні у двох екземплярах. У першому повідомлення передається відкритим текстом, а друге повідомлення зашифровано за допомогою приватного ключа Дена. Таке повідомлення називається message digest. А спосіб шифрування повідомлення за допомогою свого приватного ключа - цифровим підписом (digital signature).

Тепер закономірно постає питання про те, яким чином поширювати свої публічні ключі. Для цього (і не тільки) була придумана спеціальна форма - сертифікат (certificate). Сертифікат складається з наступних частин:

* Ім'я людини / організації випускає сертифікат.
* Для кого був випущений даний сертифікат (суб'єкт сертифіката).
* Публічний ключ суб'єкта.
* Деякі часові параметри (термін дії сертифіката і т.п.).

Сертифікат "підписується" приватним ключем особи (або огрганізаціі), який випускає сертифікати. Організації, які виробляють подібні операції називаються - "Certificate authority (CA)". Якщо в стандартному Web-клієнті (web-browser), який підтримує SSL, зайти в розділ security. То там можна побачити список відомих організацій, які "підписують" сертифікати. З технічного боку, створити свою власну CA досить просто. Але проти цього можуть діяти швидше юридичні препятсвія.

Тепер розглянемо, яким чином відбувається обмін даними в Інтернеті. Скористаємося все тими ж дійовими особами.

* Аліна: привіт.
* Ден: привіт, я - Ден (видає свій сертифікат).
* Аліна: а ти точно Ден?
* Ден: Аліна я - Ден. (Повідомлення передається два рази, один раз на відкриту, другий раз, зашифрований за допомогою приватного ключа Дена).
* Аліна: все нормально, ти - дійсно Ден. (І надсилає Дену секретне повідомлення, зашифроване за допомогою публічного ключа Дена).
* Ден: А ось і моє повідомлення (посилає повідомлення, яке було зашифровано за допомогою секретного ключа, наприклад того ж шифрованого повідомлення Аліни).

Оскільки Ден знає повідомлення Аліни, тому що він володіє приватним ключем і Аліна знає, що було в тому повідомленні. Тепер вони можуть використовувати симетричний шифрувальний алгоритм (де в якості секретного ключа виступає повідомлення Аліни) і безбоязно обмінюватися шифрованими повідомленнями. А для контролю над пересиланням повідомлень (від випадкового / навмисної зміни) використовується спеціальний алгоритм - Message Authentication Code (MAC). Досить поширеним є алгоритм MD5. Зазвичай, і сам MAC-code так само шифрується. У зв'язку з цим достовірність повідомлень підвищується в кілька разів. І внести зміни в процес обміну практично неможливо.

Тепер кілька слів про реалізацію SSL. Найбільш поширеним пакетом програм для підтримки SSL - є SSLeay. Остання версія (SSLeay v. 0.8.0) підтримує SSLv3. Ця версія доступна у вихідних текстах. І без особливих проблем встановлюється під UNIX (я не пробував ставити SSLeay під операційні системи фірми Microsoft). Цей пакет призначений для створення і управління різного роду сертифікатами. Так само до його складу входить і бібліотека для підтримки SSL різними програмами. Ця бібліотека необхідна, наприклад, для модуля SSL в поширеному HTTP сервері - Apache. Якщо Ви встановлюєте версію, поза США, то особливих проблем з алгоритмом RSA бути не повинно. Але тільки накладається обмеження на довжину ключа в 40 біт (можливо, на даний момент це обмеження зняте, але на пакеті SSLeay це жодним чином не позначилося. Действеут це обмеження і на інший пакет від фірми Netscape - SSLRef). А от якщо комп'ютер з SSLeay знаходиться на території США, то за використання алгоритму RSA необхідно сплатити будь то гроші. Але про це потрібно розмовляти з самою фірмою RSA Data Security Inc. Я точно не знаю, але з чуток необхідно реєструвати сертифікати у ФСБ. Якщо хто володіє такою інформацією, завжди буду радий дізнатися.

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