"ДБО BS-Client. Приватний Клієнт" v.2.5

Налаштування каналів доступу. Протоколи TLS/SSL

Версія 2.5.0.0

1. Анотація

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

Цей документ призначений для адміністраторів системи.

Документ містить інформацію про роботу в системі з протоколами TLS/SSL, призначених для вирішення традиційних завдань забезпечення захисту інформаційної взаємодії клієнт/сервер.

1. Анотація. 2

2. Принципи роботи протоколів TLS/SSL. 4

3. Secure Socket Layer (SSL). 6

3.1. Створення запиту сертифіката SSL 7

3.2. Установка сертифіката SSL 14

3.3. Налаштування SSL на веб-сайті. 17

4. Transport Layer Security (TLS). 18

4.1. Послідовність налаштування двостороннього SSL (TLS) 18

4.2. Генерація сертифіката та секретних ключів Web-сервера. 19

4.3. Встановлення сертифіката сервера (виконується на комп'ютері web-сервера) 22

4.4. Надання сертифіката Web-сайту. 31

4.5. Налаштування двостороннього SSL на веб-сайті. 35

4.6. Налаштування зв'язки BSI – RTS для двостороннього SSL 36

4.7. Генерація сертифіката та секретних ключів клієнта. 38

4.8. Встановлення сертифіката клієнта (виконується на комп'ютері клієнта) 39

2. Принципи роботи протоколів TLS/SSL

Для встановлення з'єднання Клієнта та Банку в системі «Приватний Клієнт» передбачено два канали, які мають необхідні засоби захисту інформації:

· SSL – Secure Socket Layer

· TLS – Transport Layer Security

Протоколи TLS/SSL призначені для вирішення традиційних завдань забезпечення захисту інформаційної взаємодії, які в середовищі клієнт/сервер інтерпретуються таким чином:

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

· після встановлення з'єднання між сервером та клієнтом весь інформаційний потік між ними повинен бути захищений від несанкціонованого доступу;

· При обміні інформацією сторони повинні бути впевнені у відсутності випадкових чи умисних спотворень під час її передачі.

Протоколи TLS/SSL вирішують ці завдання таким чином:

· Ідентичність партнерів може бути з'ясована з використанням асиметричної криптографії (напр., RSA, ГОСТ (при використанні CryptoPro TLS) тощо). Ця аутентифікація може бути зроблена опціонною, але вона необхідна принаймні для одного з партнерів.

· З'єднання є конфіденційним. Для шифрування даних використовується симетрична криптографія (напр., DES, RC4, ГОСТ (при використанні CryptoPro TLS) тощо). Ключі для шифрування генеруються незалежно для кожного з'єднання і базуються на секретному коді, який отримується за допомогою іншого протоколу (такого як протокол діалогу TLS).

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

Дані протоколи мають на увазі, що як транспортний протокол використовується протокол із встановленням логічних з'єднань (наприклад, TCP) і складаються з двох шарів. Перший шар включає прикладний протокол і три так званих handshake-протоколу: протокол встановлення SSL-сесії (Handshake Protocol), протокол зміни специфікації шифру (Change Cipher Spec Protocol) і протокол сигнальних повідомлень (Alert Protocol). Другий шар – це т.з. Record Protocol.

Handshake-протоколи відповідають за встановлення або поновлення захищених сесій.

Record protocol виконує такі функції:

· Розбиває дані, одержувані від прикладного рівня на блоки і збирає вхідні блоки передачі на прикладний рівень.

· Компресує вихідні дані та декомпресує вхідні.

· Прикріплює MAC або хеш до вихідних блоків даних та використовує прикріплений MAC для перевірки цілісності вхідних.

· Шифрує вихідні та розшифровує вхідні блоки даних.

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

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

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

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

При використанні ПЗ CryptoPro TLS стає можливим застосовувати криптографічні алгоритми шифрування відповідно до ГОСТу, обміну ключів за алгоритмом Діффі-Хеллмана та хешування відповідно до ГОСТ Р 34.11-94.

Стандартна реалізація протоколів SSL/TLS для ОС Windows здатна коректно працювати лише з алгоритмом RSA.

Особливості TLS

TLS виходить з специфікації протоколу SSL 3.0, опублікованого Netscape. Відмінності між цим протоколом та SSL 3.0 незначні, але вони цілком достатні, щоб зробити TLS 1.0 та SSL 3.0 несумісними (хоча TLS 1.0 має механізм, за допомогою якого програми можуть підтримувати SSL 3.0).

Поліпшення в TLS у порівнянні з SSL:

· У TLS алгоритм MAC (Message Authentication Code), що використовувався в SSL для обчислення хеша повідомлення, замінений більш стійкий алгоритм HMAC (keyed-Hashing for Message Authentication Code).

· Протокол TLS стандартизований в RFC 2246

· Додано кілька сигнальних повідомлень

· TLS дозволяє використовувати сертифікати, випущені підлеглим (некореневим) CA.

· У TLS специфіковані padding block values, що використовуються з блоковими алгоритмами шифрації.

· Алгоритми Fortezza не включені до TLS RFC, оскільки вони не є відкритими для публічного перегляду (це політика Internet Engineering Task Force (IETF)

· Непринципові відмінності у різних полях повідомлень.

Плюси та мінуси при використанні SSL

Плюси:

Не потребує встановлення додаткового програмного забезпечення на комп'ютер клієнта.

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

Мінуси:

Існує обмін ключовою інформацією між сторонами.

Плюси та мінуси при використанні TLS

Плюси:

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

Мінуси:

Використання цього варіанта можливе лише за умови використання криптографії CryptoPro CSP/TLS.

Необхідне встановлення додаткового ПЗ на робочому місці клієнта (CryptoPro).

3. Secure Socket Layer (SSL)

Secure Socket Layer (SSL) – це протокол безпеки, який був розроблений у 1996 році фірмою Netscape та забезпечує захищене з'єднання між клієнтським web-браузером та web-сервером. SSL є інтегрованою частиною більшості web-браузерів та web-серверів та використовує шифрування за алгоритмом RSA. Протокол SSL забезпечує захищену передачу даних за допомогою двох основних складових:

· Аутентифікації;

· Шифрування.

Для здійснення захищеного з'єднання протоколу SSL, необхідно щоб на web-сервері був встановлений цифровий SSL сертифікат. Цифровий SSL сертифікат є файлом, що унікально ідентифікує сервер, до якого йде підключення. Цифровий сертифікат іноді називають цифровим паспортом або цифровим ідентифікатором "digital ID".

Сертифікат SSL містить таку докладну інформацію:

· Домен, якому було видано сертифікат;

· Власник сертифікату;

· Налаштування WWW-сервера та створення нового web-сайту для роботи Інтернет-клієнта з двостороннього SSL (TLS).

· Налаштування модуля BSI.

· Налаштування модуля RTS.

· Генерація ключів та запиту на сертифікат Web-сервера.

· Генерація сертифікату клієнта.

· Встановлення сертифікатів на комп'ютери.

· Присвоєння Web-серверу встановлений сертифікат.

· Налаштування двостороннього SSL (TLS) на веб-сайті.

4.2. Генерація сертифіката та секретних ключів Web-сервера

Генерацію ключів та запит на сертифікат Web-сервера можна зробити стандартними засобами ДБО.

Для цього виберіть пункт меню Безпека -> Криптозахист -> Ручна генерація сертифіката.

ð Відкриється діалог Генерація запиту на сертифікат та секретного ключа(Мал. 4-1).

Рис. 4‑1 Генерація запиту на сертифікат та секретного ключа

https://pandia.ru/text/78/460/images/image023_1.jpg" width="411" height="466 src=">

Рис. 4‑3 Діалогове вікно «Properties» CryptoPro CSP

· Перейдіть на закладку "Service" та натисніть на кнопку « Install Personal Certificate» .

«Private certificate installation wizard»(Мал. 4-4).

Рис. 4‑4 Діалогове вікно « Private certificate installation wizard»

· Натисніть кнопку «Next».

Налаштування сертифіката (Мал. 4-5).

Рис. 4‑5 Діалогове вікно встановлення сертифіката

· Виберіть необхідний файл сертифіката та натисніть кнопку «Next».

ð Відкриється наступне вікно для встановлення сертифіката (Мал. 4‑6).

Рис. 4‑6 Діалогове вікно встановлення сертифіката

· Натисніть кнопку «Next».

ð Відкриється наступне діалогове вікно встановлення сертифіката (Мал. 4‑7).

Рис. 4‑7 Діалогове вікно встановлення сертифіката

· При виборі ключового контейнера вкажіть "Computer", потім виберіть потрібний контейнер. Натисніть кнопку «Next».

ð Відкриється наступне діалогове вікно для встановлення сертифіката (Мал. 4‑8).

Рис. 4‑8 Діалогове вікно встановлення сертифіката

· Натисніть кнопку «Browse».

ð При цьому відкриється діалогове вікно « SelectCertificateStore»(Мал. 4-9).

https://pandia.ru/text/78/460/images/image030.jpg" width="502" height="385 src=">

Рис. 4‑10 Діалогове вікно встановлення сертифіката

· Натисніть кнопку «Finish».

ð Таким чином, сертифікат сервера потрапить до персонального довідника локального комп'ютера із встановленою на рівні ОС зв'язкою з контейнером секретних ключів.

Для встановлення сертифіката можна скористатися пунктами основного меню Windows « Start - > Run» .

ð При цьому відкриється вікно « Run»(Мал. 4-11).

Microsoft" href="/text/category/microsoft/" rel="bookmark">Microsoft ManagementConsole».

· Виберіть пункт головного меню mmc "Console -> New" або натисніть на клавіші "Ctrl+N".

ð При цьому відкриється діалогове вікно « Console Root»(Мал. 4-12).

https://pandia.ru/text/78/460/images/image033_0.jpg" width="415" height="309 src=">

Рис. 4‑13 Діалогове вікно «Add/Remove Snap-in»

· Натисніть кнопку «Add».

ð При цьому відкриється діалогове вікно « AddStandaloneSnap-in»(Мал. 4-14).

https://pandia.ru/text/78/460/images/image035_0.jpg" width="523" height="195 src=">

Рис. 4‑15 Діалогове вікно «Certificates Snap-in»

· Встановіть позначку «Computer account» та натисніть на кнопку «Next».

ð На екрані з'явиться діалогове вікно « SelectComputer»(Мал. 4-16).

https://pandia.ru/text/78/460/images/image037.jpg" width="415" height="292 src=">

Рис. 4‑17 Діалогове вікно «Add/Remove Snap-in»

· Натисніть кнопку «OK».

ð При цьому відкриється вікно Console Root(Мал. 4-18), де міститься список сертифікатів LocalКомп'ютер.

https://pandia.ru/text/78/460/images/image039.jpg" width="474" height="345 src=">

ð При цьому відкриється вікно майстра налаштувань « CertificateimportWizard».

· Натисніть кнопку «Next».

ð При цьому відкриється наступне діалогове вікно « CertificateimportWizard»(Мал. 4-20).

Рис. 4‑20 Діалогове вікно «Certificate import Wizard»

· Вкажіть шлях до файлу сертифіката Центру Авторизації та натисніть кнопку «Next».

ð При цьому відкриється наступне діалогове вікно « CertificateimportWizard».

· Встановіть позначку «Автоматично визначити місце розташування сертифіката або розмістити у зазначеній директорії» та натисніть кнопку «Next».

ð При цьому відкриється наступне діалогове вікно « CertificateimportWizard».

· Для завершення процедури та закриття вікна майстра налаштувань натисніть кнопку «Finish».

· При закритті Microsoft Management Console ( MMC) Натисніть на кнопку « Yes» для збереження налаштувань.

4.4. Надання сертифіката Web-сайту

Для налаштування двостороннього SSL:

· Запустіть Internet Services Manager (Start -> Settings -> Control Panel -> Administrative Tools -> Internet Services Manager).

· У вікні, що з'явилося, зліва відкрийте дерево «Internet Information Services».

ð У дереві з'явиться гілка *<сетевое имя Вашего компьютера>.

· У списку сайтів виберіть сайт, якому необхідно налаштувати двосторонній SSL, та відкрийте параметри («Properties»).

Увага!

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

· Перейдіть на закладку "Directory Security" (Мал. 4-21).

https://pandia.ru/text/78/460/images/image003_23.jpg" width="503" height="386 src=">

· Натисніть кнопку «Next».

ð При цьому відкриється діалогове вікно « IISCertificateWizard»(Мал. 4-22).

https://pandia.ru/text/78/460/images/image043.jpg" width="503" height="248 src=">

Рис. 4‑23 Діалогове вікно "IIS Certificate Wizard"

· Виберіть зі списку встановлений сертифікат та натисніть кнопку «Next».

ð При цьому відкриється наступне діалогове вікно « IISCertificateWizard»(Мал. 4-24).

Рис. 4‑24 Діалогове вікно "IIS Certificate Wizard"

· Натисніть кнопку «Next».

ð При цьому відкриється наступне діалогове вікно « IISCertificateWizard»(Мал. 4-25).

DIV_ADBLOCK427">

Увага!

Сайт повинен бути створений та налаштований за документом «Посібник зі встановлення та налаштування системи».

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

· Перейдіть на закладку "Directory Security".

· У розділі «Secure Communication» натисніть кнопку «Edit».

· У діалоговому вікні, що відкрилося, встановіть наступні позначки:

▼ Require Secure Channel

▼ Require Client Certificates.

4.6. Налаштування зв'язки BSI – RTS для двостороннього SSL

Для налаштування використовується утиліта BSISET. EXE . Установки виконуються таким чином:

· Запустіть утиліту bsiset. exe (утиліта знаходиться в каталозі "%BSSRoot%\EXE").

ð При цьому відкриється діалогове вікно « ChooseBSI. DLLlocation» .

· Вкажіть у полі "Library" шлях до файлу bsi. DLL. Якщо налаштування модуля BSI проводилися раніше, шлях можна вибрати зі списку, розташованого нижче. Щоб вибрати шлях до bsi. dll вручну скористайтеся кнопкою .

· Натисніть кнопку «Edit».

ð При цьому відкриється діалогове вікно налаштувань « BSIConfiguration».

Для використовуваного типу захисту каналів клієнтів – двосторонній. SSL ( TLS) необхідно настроїти конфігурацію RTS .

· Необхідно розпочати нову конфігурацію для RTS. Щоб створити нове налаштування у правій частині вікна на вкладці Configs, натисніть кнопку New.

ð При цьому буде створено нову конфігурацію з ім'ям NewItem, яку можна перейменувати.

ð Для копіювання дефолтної конфігурації запустіть утиліту bsiset. exe. Натисніть кнопку Edit. Виберіть конфігурацію та натисніть кнопку «New Copy».

· Встановіть курсор на рядок NewItem і введіть ім'я налаштування в полі ConfigID.

· Потім при встановленому курсорі на назві нового налаштування натисніть кнопку «Configuration».

ð На екрані з'явиться вікно налаштувань « BSISet».

· Відкрийте розділ «Options» та перейдіть на закладку «Authentification».

· Необхідно налаштувати тип ідентифікації клієнтів. Для цього встановіть позначку в Identify by client certificate (TLS).

Для налаштування параметрів RTS знайдіть у системному треї іконку сервера, клацніть по ній правою кнопкою миші:

ð При цьому активується контекстне меню.

· Виберіть у контекстному меню команду «Налаштування…»

ð При цьому відкриється діалогове вікно «Налаштування».

· Відкрийте розділ "Options" і перейдіть на закладку "Ідентифікація клієнта" (Мал. 4-26).

https://pandia.ru/text/78/460/images/image049_0.jpg" width="510" height="368">

Рис. 4‑27 Генерація запиту на сертифікат та секретного ключа для клієнта

Введіть назву абонента, виберіть тип криптобібліотеки – Ms Crypto Api 2.0 та натисніть кнопку Далі.

ð На екрані з'явиться наступне вікно, щоб ввести параметри сертифіката.

При генерації сертифіката клієнта вкажіть у цьому вікні такі параметри:

Область застосування сертифікату 1.3.6.1.5.5.7.3.2;

Область застосування секретного ключа DigitalSignature; NonRepudiation; KeyEncipherment; DataEncipherment. Типи.

4.8. Встановлення сертифіката клієнта (виконується на комп'ютері клієнта)

Для встановлення сертифіката клієнта необхідно скористатися панеллю керування CryptoPro (Мал. 4-28).

Використовуйте пункти основного меню Windows Start -> Setting -> Control Panel -> CryptoPro CSP.

Рис. 4‑28 Початок налаштування CryptoPro CSP

· Відкриється вікно Properties: CryptoPro CSP.

· Відкрийте сторінку Serviceта натисне кнопку Install Personal Certificate.

· Відкриється вікно Private certificate installation wizard.

· Натисніть кнопку Next.

· Виберіть необхідний файл сертифіката та натисніть кнопку Next..

· Відкриється наступне вікно для встановлення сертифіката.

· Натисніть кнопку Next.

Відкриється наступне вікно для встановлення сертифіката.

Рис. 4‑29 Вибір установок сертифіката

При виборі ключового контейнера вкажіть « User», потім виберіть потрібний контейнер. Натисніть кнопку Next(Мал. 4-29).

· Відкриється наступне вікно для встановлення сертифіката.

· Натисніть кнопку Browse.

· Відкриється вікно Select Certificate Store.

· Вкажіть довідник personalдля встановлення сертифіката та натисніть кнопку Ok.

Потім у вікні для встановлення сертифіката натисніть кнопку Next.

· Відкриється наступне вікно з параметрами установки сертифіката.

· Натисніть кнопку Finish.

Таким чином, сертифікат сервера потрапить до персонального сховища поточного користувача.

ЦИФРОВА СЕРТИФІКАЦІЯ ЗАХИЩЕНОГО З'ЄДНАННЯ SSL

Для безпечної передачі даних між веб-браузером та веб-сервером використовується протокол передачі даних https, в основі якого покладено захищене з'єднання SSL.

У цій статті розповідаються загальні відомості про шифрування з відкритим ключем, цифрові сертифікати, інфраструктуру відкритого ключа (PKI - Public Key Infrastructure), про створення засвідчувального центру, конфігурування контейнерів сервлетів Apache Tomcat і JBoss для встановлення одностороннього та двостороннього захисту. як створити SSL сертифікат за допомогою утиліти keytool Також ви дізнаєтеся про способи перевірки відкликаних сертифікатів у Java (CRL списки, протокол OCSP) та конфігурування браузера для роботи з сертифікатами.

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

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

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

Повідомлення, зашифроване закритим ключем, може бути розшифроване всіма власниками відкритого ключа.

З даного алгоритму шифрування створюється захищене з'єднання SSL.

Цифровий сертифікат

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

Основні особливості наведених вище сертифікатів:

SSL сертифікат центру, що посвідчує, повинен містити поле CA зі значенням TRUE, що дозволяє видавати інші сертифікати, тобто. цей сертифікат не є кінцевим у ланцюжку.

Серверні SSL сертифікати в полі CN (common name) повинні обов'язково містити доменне ім'я або ip-адресу, за яким відбувається звернення до сервера, інакше сертифікат буде визнаний недійсним;

Клієнтські SSL сертифікати містять e-mail адресу клієнта, його ім'я та прізвище. На відміну від серверного сертифіката поле CN не є критичним до вмісту і може містити як ім'я з прізвищем, так і e-mail адресу.

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

Існують ситуації, коли користувачеві або видавцеві сертифіката необхідно призупинити або повністю зупинити його дію. Припустимо, що закритий ключ, який повинен надійно зберігатися, був втрачений, або до нього отримали доступ зловмисники. У такій ситуації користувачеві необхідно звернутися до емітенту (видавця) сертифіката, щоб останній скасував його дію. Також видавець може скасувати сертифікат у разі з'ясування того, що клієнт надав сфальсифіковану інформацію про себе. Для цього створюється спеціальний список, званий списком анульованих (відкликаних) сертифікатів (англ. Certificate revocation list, CRL). Цей список містить серійний номер сертифіката, дату припинення його дії та причину відкликання. З моменту попадання сертифіката в CRL він вважається недійсним і видавець не несе відповідальності за вміст такого сертифіката. Одним з методів перевірки CRL списку є протокол OCSP, але для цього потрібна наявність у посвідчувального центру OCSP-респондера.

Інфраструктура відкритого ключа (PKI)

Основне завдання інфраструктури відкритого ключа (Public Key Infrastructure, PKI) є визначення політики видачі цифрових сертифікатів.

Для випуску та скасування SSL сертифікатів, генерації списків відгуку (CRL) необхідно спеціальне програмне забезпечення (ПЗ). Як приклад такого програмного забезпечення можна навести Microsoft CA (входить до складу MS Windows Server 2000/2003/2008), OpenSSL (поширюється на unix-подібних ОС). Дане ПЗ розміщується на обладнанні центру, що засвідчує.

Центр, що засвідчує (англ. Certification authority, CA) – організація, яка видає цифрові SSL сертифікати на підставі даних наданих замовником. Центр, що посвідчує, несе повну відповідальність за достовірність даних представлених у SSL сертифікаті, це означає, що власник сертифіката є саме тим, за кого себе видає.

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

Захищене з'єднання SSL із двосторонньою аутентифікацією

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

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

На малюнку представлена ​​схема, де показані етапи створення захищеного з'єднання SSL.

Рис 1 - Схема створення захищеного з'єднання SSL із двосторонньою аутентифікацією

Коли клієнт намагається отримати доступ до захищеного ресурсу, сервер надсилає цифровий сертифікат. Отримавши сертифікат, клієнт здійснює його перевірку. Перевірка полягає в наступному: дати початку дії та закінчення не повинні бути простроченими, видавець сертифіката має бути довіреним, сертифікат не повинен перебувати у CRL. У разі невдалої перевірки процес встановлення з'єднання переривається. Якщо умови перевірки виконані, клієнт передає свій сертифікат серверу. Сервер проводить аналогічну перевірку. У разі невдалої перевірки сервер заборонить доступ до своїх ресурсів. При успішній перевірці встановлюється безпечне з'єднання та дані передаються у шифрованому вигляді.

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

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

Створення посвідчувального центру

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

Кореневий центр, що засвідчує – центр, якому довіряють всі. Він має SSL сертифікат, який підписаний його власним закритим ключем. Такі SSL сертифікати називають самопідписні (англ. self signed).

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

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

З вищесказаного слід, що створюється ланцюжок сертифікатів від кореневого центру до кінцевого клієнтського сертифіката.

Рис 2 – Ланцюжок сертифікатів

Для створення посвідчувального центру скористаємося дворівневою схемою, представленою на малюнку 3. У цій схемі є кореневий центр посвідчення (Root CA) і підлеглий центр посвідчення (Issuing CA). Кореневий центр посвідчення підписує власний SSL сертифікат і SSL сертифікати підлеглих посвідчуючого. Слід зазначити той факт, що чим більше рівнів використовується, тим безпечнішою є схема.

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

Рис 3 – Двохрівнева схема засвідчувального центру

Приклад організації посвідчувального центру на основі Microsoft CA можна прочитати у статті "Розгортання ланцюжка центрів сертифікації на основі Microsoft CA".

Отримання серверного SSL сертифіката в центрі, що засвідчує, і конфігурування контейнера сервлетів

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

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

Основне поле, яке має бути правильно заповнене називається Common Name (CN). У цьому полі необхідно вказати доменне ім'я або IP-адресу хоста, на якому розміщується контейнер сервлетів.

Для генерації секретного та відкритого ключів та запиту на SSL сертифікат можна скористатися утилітою keytool, що входить до складу JDK (Java development kit).

У командному рядку необхідно ввести таку команду:

$JAVA_HOME\bin> keytool -genkey -alias -keyalg -keystore

Рис 4 – Створення сховища SSL сертифікатів утилітою keytool

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

Під час створення сховища утилітою keytool буде запропоновано ввести пароль на доступ до сховища, відомості про організацію та пароль до секретного (закритого) ключа. При відповіді питання утиліти keytool «What is your first and last name?» необхідно ввести доменне ім'я або IP-адресу хоста, т.к. значення відповіді буде використано як поле CN SSL сертифіката.

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

$JAVA_HOME\bin> keytool -certreq -keyalg RSA -alias -file -keystore

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

Для видачі SSL сертифіката організації посвідчувальний центр може вимагати установчі документи, свідоцтво про реєстрацію та ін. При отриманні заявки на SSL сертифікат посвідчувальний центр виконує перевірку, порівнюючи дані у запиті на сертифікат та надіслані документи, після чого підписує запит. Підписаний запит є сертифікатом.

Рис 5 – Схема отримання сертифіката сервера

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

1) додавання сертифіката кореневого засвідчувального центру утилітою keytool: $JAVA_HOME\bin> keytool -import -trustcacerts -alias rootca -file -keystore

2) додавання сертифіката проміжного посвідчувального центру утилітою keytool: $JAVA_HOME\bin> keytool -import -trustcacerts -alias subca -file -keystore

3) заміна самопідписного сертифіката сертифікатом, підписаним у центрі, що засвідчує (вказується значення параметра alias, яке використовувалося при створенні сховища): $JAVA_HOME\bin> keytool -import -trustcacerts -alias -file -keystore

Щоб застосувати захищене з'єднання SSL, потрібно конфігурувати контейнер сервлетів. Для Apache Tomcat та JBoss необхідно у файлі server.xml додати наступний вміст:

clientAuth="false" sslProtocol="TLS"

keystoreFile=" "

keystorePass=" "

keystoreType="JKS"

keyAlias=" "

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

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

maxThreads="150" scheme="https" secure="true"

clientAuth="true" sslProtocol="TLS"

keystoreFile="

keystorePass=" "

keystoreType="JKS"

keyAlias=" "

truststoreFile="

truststorePass=" " truststoreType="JKS"

У цій конфігурації встановлюється параметр clientAuth=”true” та підключається сховище довірених сертифікатів. Створення сховища довірених SSL сертифікатів проводиться утилітою keytool так само, як і звичайне сховище. До нього необхідно додати сертифікати центрів, що засвідчують, які видають цифрові сертифікати, яким повинен довіряти контейнер сервлетів. Інакше при аутентифікації сертифікати, що надаються SSL, будуть відхилені контейнером сервлетів, т.к. до них не буде довіри.

Перевірка відкликаних сертифікатів на сервері

Існує 3 способи перевірки сертифіката на відгук: статична перевірка CRL, динамічна перевірка CRL, перевірка за протоколом OCSP. Розглянемо ці методи докладніше.

1) Статична перевірка CRL

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

Для підключення CRL у контейнерах сервлетів Apache Tomcat та Jboss слід у ssl-конекторі додати атрибут:

crlFile=”

Недоліком цього способу є необхідність постійного контролю адміністратора за оновленням файлу CRL.

2) Динамічна перевірка CRL

Цей спосіб дозволяє перевіряти CRL автоматично. Для цього необхідно, щоб у сертифікаті, що надається клієнтом SSL, у розділі розширень був прописаний атрибут CRLDistributionPoint, в якому вказується URL-адреса, за якою розташований список відкликаних сертифікатів (CRL).

Щоб перевірити клієнтський SSL сертифікат у CRL необхідно налаштувати два параметри для віртуальної машини Java. Ці параметри можна вказати у скрипті запуску контейнера сервлетів. Для Apache Tomcat і Jboss під Windows це виглядає так:

set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.net.ssl.checkRevocation=true

Dcom.sun.security.enableCRLDP=true -Djava.security.debug=certpath

Параметр java.security.debug=certpath дозволяє спостерігати в консолі запущеного контейнера перевірку автентичності сертифіката.

До недоліків даного способу можна віднести затримку доступу до захищеного ресурсу, пов'язану із завантаженням великого обсягу файлу CRL.

3) Перевірка за допомогою протоколу OCSP

Протокол OCSP (Online certificate status protocol) розроблено як альтернативу CRL. Ця перевірка підтримується технологією JSSE (Java Secure Socket Extension) з версії JDK 5. OCSP працює у поєднанні з CRL. Звертання до CRL відбувається у разі виникнення помилки при взаємодії з OCSP. У випадку, якщо OCSP визначив статус SSL сертифіката, перевірка CRL не здійснюється. Сертифікат може мати один із трьох статусів: анульований, нормальний, невідомий.

Для перевірки OCSP сертифікат повинен містити в розділі розширень атрибут AuthorityInfoAccess зі значенням URL-адреси OCSP-респондера.

OCSP-респондер – програмне забезпечення, розташоване на мережному ресурсі центру, що засвідчує, яке обробляє запити на визначення статусу сертифіката і видає результати перевірки.

Щоб віртуальна машина Java здійснювала перевірку по OCSP необхідно встановити властивість ocsp.enable=true. Ця властивість налаштовується у файлі JAVA_HOME\jre\lib\security\java.security. У цьому файлі можна прописати адресу OCSP-респондера як ocsp.responderURL. Ця властивість буде використовуватися у разі відсутності URL-респондента в SSL сертифікаті.

Отримання клієнтського SSL сертифіката в центрі, що засвідчує, і конфігурування web-браузера

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

Отримати клієнтський SSL сертифікат можна без самостійної генерації запиту, зробивши це за допомогою центру, що засвідчує. Для цього на сайті УЦ необхідно заповнити форму із зазначенням імені, прізвища, e-mail адреси та ін. На підставі цих даних буде згенеровано запит. У цій ситуації генерація секретного ключа покладається на центр, що засвідчує. Після перевірки даних та підпису запиту, клієнту надсилається файл, що містить секретний ключ і сертифікат, а також файли кореневого та проміжних центрів, що посвідчують.

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

Рис 6 – Схема отримання SSL сертифіката клієнта

Як приклад зробимо встановлення клієнтського SSL сертифіката в web-браузер Microsoft Internet Explorer. Для цього необхідно в меню вибрати Сервіс > Властивості браузера. На закладці «Зміст» виберіть «Сертифікати…».

Рис 7 – Управління SSL сертифікатами у MS Internet Explorer

Запускаємо майстер імпорту сертифікатів, натиснувши кнопку «Імпорт…». У цьому майстрі вказуємо шлях до сертифікату кореневого центру, що засвідчує. Далі вибираємо сховище "Довірені кореневі центри сертифікації" для додавання до нього сертифіката.

Аналогічно додаються сертифікати проміжних центрів сертифікації у сховищі «Проміжні центри сертифікації» та клієнтський сертифікат у сховищі «Особисті».

Рис 8 – Ланцюжок сертифікації

Щоб переглянути вміст сертифіката, вибирається потрібний сертифікат SSL і натискається кнопка «Перегляд».

Якщо отримання клієнтського сертифіката відбувається у відомого центру, що засвідчує, то, як правило, його SSL сертифікати вже містяться в сховищах web-браузера і немає необхідності їх додавати. Слід лише додати клієнтський сертифікат.

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

Перевірка відкликаних сертифікатів на клієнта

Якщо як клієнт використовує web-браузер MS Internet Explorer, його можна налаштувати, щоб здійснювалася перевірка надісланих сертифікатів в CRL. Для цього необхідно у властивостях браузера перейти на закладку «Додатково» і відзначити два атрибути «Перевіряти анулювання сертифікатів видавців» та «Перевіряти анулювання сертифікатів серверів».

Налаштування платіжних систем

Налаштування платіжних систем багато в чому залежить від того, як надає зв'язок зі своїми терміналами сам оператор платіжної системи. Як правило, якщо використовуються термінали міських платежів, то використовується захищене SSL-з'єднання і вам потрібно включити та налаштувати для зв'язку з терміналами SSL WEB-сервер як показано нижче. Якщо для проведення платежів використовуються веб-сайти в інтернеті, то, як часто в таких випадках потрібно налаштовувати саме http сервер на Carbon Billing. Попередньо обов'язково уточніть у вашого оператора платіжних систем за яким саме протоколом зв'язку він надає підключення до своїх терміналів оплати перед налаштуванням Carbon Billing.
SSL WEB-сервер для платежів має кілька параметрів, значення яких наведено нижче.

Увімкнути SSL WEB-сервер для платежів- Якщо оператор платіжної системи здійснює роботу з терміналами оплати за SSL, то необхідно включити саме SSL WEB-сервер.
IP-адреса для підключення за HTTPS- адреса для підключення терміналів або сайтів платіжних систем для платежу клієнту в БД Carbon Billing.
Порт для підключення по HTTPS- за замовчуванням використовується порт 1443. Якщо потрібно змінити цей порт, то по можливості вказуйте порти вище 1024.
Дозволені адреси клієнтів для SSL WEB-сервера
Домен для сертифіката серверного SSL- вкажіть ваш публічний домен або окремо зареєстрований для сервера платежів на Carbon Billing домен. Опція не обов'язкова і дозволяє звернутися до SSL-WEB-серверу по домену імені замість IP-адреси.
Вимагати та перевіряти клієнтський сертифікат- Обов'язково відзначити якщо настроюєте веб-інтерфейс касира. Якщо ви налаштовуєте роботу з платіжною системою, то уточніть необхідність перевірки клієнтського сертифіката у оператора платіжної системи.
Створити клієнтський сертифікат- Буде створено клієнтський сертифікат, який потрібно надати оператору платіжної системи. Сертифікат із суфіксом.pfx буде доступний на сервері в каталозі /var/lib/usrcert і матиме ім'я файлу, що дорівнює CN-імені, вказаному вами при створенні сертифіката. Завантажити файл сертифіката із сервера можна програмою winscp.

У разі настроювання HTTP WEB-сервера для платежів.

Увімкнути HTTP-сервер для платежів- Якщо оператор платіжної системи здійснює роботу з терміналами оплати за відкритим http-з'єднанням, то увімкніть саме HTTP-сервер.
IP-адреса для підключення по HTTP- Адреса веб-сервера для підключення терміналів або серверів платежів.
Порт для підключення через HTTP- за замовчуванням використовується порт 1444. Якщо потрібно змінити цей порт, то по можливості вказуйте порти вище 1024.
Дозволені адреси клієнтів для HTTP-сервера- якщо не вказано, доступ буде відкритий всім.

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

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

Критичність параметра subjectAltName ssl-сертифікатів

При генерації ssl-сертифікатів для сервера, наприклад для https-сервера платежів, використовується розширення subjectAltName. Історично по дефолту це розширення у сертифікаті позначається як критичне, що може призвести до проблем при інтеграції білінгу з деякими платіжними системами.

Під час створення клієнтських сертифікатів subjectAltName не задається.

Критичність параметра скасовується опцією в локальній консолі "Конфігурування сервера - Додаткові установки - Налаштування для розробників - Не робити SSL параметр AltName критичним".

Після включення цієї опції всі новостворені серверні сертифікати генеруватимуться з некритичним розширенням subjectAltName. Старий сертифікат для https-сервера платежів доведеться перегенерувати вручну таким чином:

1. Перемонтуємо в rw розділ, на якому лежить конфіг (для цього має бути включений режим віддаленого помічника):

Mount -o rw, remount /mnt/bk_disc/

2. Відкриваємо редактором файл /etc/ics/ics.conf та коментуємо рядок з MHTTPD_F_CERT .

3. Перезапускаємо https-сервер платежів:

/etc/init.d/mhttpd_F restart

Зміна сертифіката у https-сервера платежів не зачіпає згенеровані раніше клієнтські сертифікати для касирів або платіжних систем.

Налаштування прийому платежів за http без шифрування

При необхідності проводити прийом платежів від платіжних систем за незахищеним протоколом http необхідно зробити наступні налаштування:

1) Включити http сервер прийому платежів.

2) Вказати IP адресу, на якій повинен працювати прийом запитів. Ця адреса повинна належати до одного з інтерфейсів Carbon Billing:

Потім вказати порт, на якому прийматиме запити запити сервер.

3) Зробити список IP адрес, з яких прийматимуться запити. Це дуже важливий крок, оскільки http не передбачає авторизацію платіжної системи через сертифікат:

За промовчанням з HTTP можуть працювати протоколи платіжної системи Робокасса та Унікасу. Якщо потрібно, наприклад, приймати запити на http за протоколом ОСМП необхідно зробити таке:

1) Завантажити сервер у режимі уд. помічника і підключитися через ssh під користувачем root.

2) Виконати такі команди:

Mount -o rw, remount /mnt/ro_disc chattr -i -R /var /www/fiscal/htdocs/http/ cp /var /www/fiscal/htdocs/osmp.php /var /www/fiscal/htdocs/http/ osmp.php chown mhttpd_F:mhttpd_F /var /www/fiscal/htdocs/http/osmp.php

Потрібно відредагувати рядок у скрипті:

Mcedit /var /www/fiscal/htdocs/http/osmp.php рядок: include "../include/class_page.php"; замінюємо на: include "../../include/class_page.php";

Зберігаємо файл та виходимо з редактора.

Після м'якого перезавантаження модуль прийому платежів за протоколом ОСМП буде доступний за адресою http://1.1.1.1:1444/osmp.php з IP-адреси 2.2.2.2.

Доступ за негативного балансу

Може бути реалізований двома способами:

• Через редактор правил та мереж тарифу;
• Через [файл додаткових настроювань ics_tune.sh]

Встановлення веб-доступу

Додаткові налаштування сервера веб-доступу

Налаштування захищеного з'єднання (на основі Secure Socket Layers, SSL)

За необхідності можна настроїти захист з'єднаньз сервером веб-доступу до DIRECTUM : інформація, що передається каналами зв'язку, шифруватиметься. Для того щоб можна було працювати із захищеними з'єднаннями, зробіть таке:

1. Змініть конфігураційний файл сервера веб-доступу:

· Крок 1. Запустіть утиліту конфігурування сервера веб-доступу C :\ Program Files \ DIRECTUM Company \ WebAccessConfig \DirWebConfigurator.exe.

· Крок 2. Вікно «Вибір веб-сайту Сервера веб-доступу DIRECTUM »:

а) у списку, що випадає, виберіть веб-сайт сервера веб-доступу до DIRECTUM . За промовчанням він має назву «Сервер веб-доступу до DIRECTUM»;

б) Натисніть на кнопку OK ;

· Крок 3. Вікно «Параметри Сервера веб-доступу DIRECTUM », закладка «Загальні»:

а) у списку «Захищене з'єднання» виберіть «Для віддалених». Якщо потрібно встановити захищене з'єднання і для користувачів локальної мережі, виберіть «Для віддалених і локальних»;

б) Натисніть на кнопку OK .

2. Налаштуйте IIS на роботу з SSL -з'єднаннями, встановивши сертифікат автентифікації сервера. Для цього генерується сертифікат із призначенням «Забезпечує отримання ідентифікації від віддаленого комп'ютера» з можливістю експорту до служби сертифікації підприємства, внаслідок чого необхідно отримати *. pfx -Файл закритого ключа.

3. Якщо ви використовуєте веб-службу сертифікації Windows , то зробіть таке:

а) під час створення сертифіката вкажіть опцію можливого експорту сертифіката. Після того, як сертифікат встановлений у локальній системі, його можна переглянути за допомогою Internet Explorer – пункт меню «Властивості браузера», закладка «Зміст», кнопка Сертифікати . Для експорту використовуйте кнопку Експорт , вкажіть Так, експортувати закритий ключ, та вкажіть пароль.

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

4. Щоб підтримувалися і відкриті (незахищені) з'єднання, потрібно встановити опцію Дозволити підтримку відкритих з'єднань HTTPна закладці «Веб-сайт» властивостей веб-сайту.

5. Для того щоб можна було встановити сертифікат центру, що посвідчує, за посиланням зі сторінки входу, необхідно користувачеві, від якого запускається група додатків « DIRECTUM », дозволити «Читання» та «Запит сертифікатів» у оснащенні «Центр сертифікації» у властивостях потрібного центру сертифікації на закладці «Безпека».

Див. також:

IPad