≡×МЕНЮ

• Кесарів розтин
• Календар щеплень
• Аналізи крові
• Післяпологовий період
• Підготовка до пологів

Прихований канал у tls протоколах. Типи SSL-сертифікатів шифрування. Безкоштовний спосіб отримати tls сертифікат безпеки

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

SSL TLS

Протокол SSL TLS

Користувачі бюджетних організацій, та й не тільки бюджетних, діяльність яких пов'язана з фінансами, у взаємодії з фінансовими організаціями, наприклад, Мінфіном, казначейством тощо, всі свої операції проводять виключно за захищеним протоколом SSL. Здебільшого у своїй роботі вони використовують браузер Internet Explorer. У деяких випадках, Mozilla Firefox.

Помилка SSL

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

Помилка TLS

Помилка TLSу багатьох випадках може вказувати на відсутність підтримки протоколу. Але... подивимося, що можна зробити.

Підтримка протоколів SSL та TLS

Отже, під час використання Microsoft Internet Explorer, щоб відвідати веб-сайт із захищеним протоколом SSL, у рядку заголовка відображається Переконайтеся, що протоколи ssl та tls включені. Насамперед, необхідно увімкнути підтримку протоколу TLS 1.0в Internet Explorer.

Комп'ютерні новини, огляди, вирішення проблем з комп'ютером, комп'ютерними іграми, драйверами та пристроями та іншими комп'ютерними програмами." title="(!LANG:програми, драйвери, проблеми з комп'ютером, іграми" target="_blank">!}

Якщо ви відвідуєте веб-сайт, на якому працює Internet Information Services 4.0 або вище, налаштування Internet Explorer для підтримки TLS 1.0 допомагає захистити ваше з'єднання. Звичайно, за умови, що віддалений веб-сервер, який ви намагаєтеся використовувати, підтримує цей протокол.

Для цього в меню Сервісвиберіть команду Властивості оглядача.

На вкладці Додатковов розділі Безпека, переконайтеся, що вибрані наступні прапорці:

Використати SSL 2.0
Використання SSL 3.0
Використання TLS 1.0

Натисніть кнопку Застосувати , а потім ОК . Перезавантажте браузер .

Після включення TLS 1.0, спробуйте ще раз відвідати веб-сайт.

Системна політика безпеки

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

Щоб це зробити, Панелі керуванняВиберіть Адміністрація, а потім двічі клацніть піктограму Локальна політика безпеки.

У локальних параметрах безпеки розгорніть вузол Локальні політики, а потім натисніть кнопку Параметри безпеки.

Комп'ютерні новини, огляди, вирішення проблем з комп'ютером, комп'ютерними іграми, драйверами та пристроями та іншими комп'ютерними програмами." title="(!LANG:програми, драйвери, проблеми з комп'ютером, іграми" target="_blank">Компьютерная помощь, драйверы, программы, игры!}

Відповідно до політики у правій частині вікна, двічі клацніть Системна криптографія: використовувати FIPS-сумісні алгоритми для шифрування, хешування та підписування, а потім натисніть кнопку Вимкнено .

Увага! Зміна набуває чинності після того, як локальна безпекова політика повторно застосовується. Тобто увімкніть їїі перезапустіть браузер .

КриптоПро TLS SSL

Оновити КриптоПро

Далі, як одним із варіантів вирішення проблеми, є оновлення КриптоПро, а також настроювання ресурсу. В даному випадку це робота з електронними платежами. Тому, переходимо на центр посвідчення для автоматичного налаштування ресурсу. Як ресурс вибираємо Електронні торгові майданчики.

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

Налаштування SSL TLS

Налаштування мережі

Ще одним варіантом може бути відключення NetBIOS через TCP/IP- Розташований у властивостях підключення.

Реєстрація DLL

Запустити командний рядок від імені адміністратора та ввести команду regsvr32 cpcng. Для 64-розрядної ОС необхідно використовувати той regsvr32, який в syswow64.

Розділи чудової книги "High Performance Browser Networking" авторства Іллі Григорика. Переклад виконувався в рамках написання курсової роботитому дуже вільний, але тим не менш буде корисний тим, хто слабо уявляє що таке TLS, і з чим його їдять.

Загальні відомості про TLS

Протокол TLS (transport layer security) заснований на протоколі SSL (Secure Sockets Layer), спочатку розробленому Netscape для підвищення безпеки електронної комерції в Інтернеті. Протокол SSL був реалізований на application-рівні, безпосередньо над TCP (Transmission Control Protocol), що дозволяє більш високорівневих протоколів (наприклад, HTTP або протоколу електронної пошти) працювати без змін. Якщо SSL налаштовано коректно, то сторонній спостерігач може дізнатися лише параметри з'єднання (наприклад, тип використовуваного шифрування), а також частоту пересилання та приблизно кількість даних, але не може читати і змінювати їх.

Конкретне місце TLS (SSL) у стеку протоколів Інтернету показано на схемі:

Після того, як протокол SSL був стандартизований Internet Engineering Task Force (IETF), він був перейменований в TLS. Тому хоча імена SSL і TLS взаємозамінні, вони все-таки відрізняються, тому що кожне описує іншу версію протоколу.

Перша випущена версія протоколу мала назву SSL 2.0, але була досить швидко замінена на SSL 3.0 через виявлені вразливості. Як уже згадувалося, SSL був розроблений компанією Netscape, тому в січні 1999 року IETF відкрито стандартизує його під ім'ям TLS 1.0. Потім у квітні 2006 року була опублікована версія TLS 1.1, яка розширювала початкові можливості протоколу та закривала відомі вразливості. Актуальна версія протоколу зараз – TLS 1.2, випущена в серпні 2008 року.

Як вже говорилося, TLS був розроблений для роботи над TCP, проте для роботи з протоколами дейтаграм, такими як UDP (User Datagram Protocol), була розроблена спеціальна версія TLS, що отримала назву DTLS (Datagram Transport Layer Security).
 

Шифрування, автентифікація та цілісність

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

• Шифрування – приховування інформації, яка передається від одного комп'ютера до іншого;
• Аутентифікація – перевірка авторства інформації, що передається;
• Цілісність - Виявлення заміни інформації підробкою.

Для того, щоб встановити криптографічно безпечний канал даних, вузли з'єднання повинні узгодити методи шифрування і ключі. Протокол TLS однозначно визначає цю процедуру, докладніше це розглянуто у пункті TLS Handshake. Слід зазначити, що TLS використовує криптографію з відкритим ключем, яка дозволяє вузлам встановити загальний секретний ключ шифрування без попередніх знань один про одного.
Також, в рамках процедури TLS Handshake є можливість встановити справжність особи і клієнта, і сервера. Наприклад, клієнт може бути впевнений, що сервер, який надає йому інформацію про банківський рахунок, дійсно банківський сервер. І навпаки: сервер компанії може бути впевнений, що клієнт, який підключився до нього – саме співробітник компанії, а не стороння особа (цей механізм називається Chain of Trust і буде розглянутий у відповідному розділі).

Нарешті, TLS забезпечує надсилання кожного повідомлення з кодом MAC (Message Authentication Code), алгоритм створення якого є односторонньою криптографічною функцією хешування (фактично – контрольна сума), ключі якої відомі обом учасникам зв'язку. Щоразу при надсиланні повідомлення, генерується його MAC-значення, яке може згенерувати і приймач, це забезпечує цілісність інформації та захист від її заміни.

Таким чином, коротко розглянуто всі три механізми, що лежать в основі криптобезпеки протоколу TLS.
 

TSL Handshake

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

Розберемо докладніше кожен крок цієї процедури:

1. Оскільки TLS працює над TCP, спочатку між клієнтом і сервером встановлюється TCP-з'єднання.
2. Після установки TCP, клієнт посилає на сервер специфікацію у вигляді звичайного тексту (а саме версію протоколу, яку він хоче використовувати, методи шифрування, що підтримуються, etc).
3. Сервер затверджує версію використовуваного протоколу, вибирає спосіб шифрування з наданого списку, прикріплює свій сертифікат і надсилає відповідь клієнту (при бажанні сервер може запросити клієнтський сертифікат).
4. Версія протоколу та спосіб шифрування на даний момент вважаються затвердженими, клієнт перевіряє надісланий сертифікат та ініціює або RSA, або обмін ключами по Діффі-Хеллман, залежно від встановлених параметрів.
5. Сервер обробляє надіслане клієнтом повідомлення, звіряє MAC, і надсилає клієнту заключне (Finished) повідомлення клієнту в зашифрованому вигляді.
6. Клієнт розшифровує отримане повідомлення, звіряє MAC, і якщо все добре, з'єднання вважається встановленим і починається обмін даними додатків.

Зрозуміло, що встановлення з'єднання TLS є, власне кажучи, тривалим і трудомістким процесом, у стандарті TLS є кілька оптимізації. Зокрема, є процедура під назвою “abbreviated handshake”, яка дозволяє використовувати раніше узгоджені параметри відновлення з'єднання (природно, якщо клієнт і сервер встановлювали TLS-соединение в минулому). Цю процедуру розглянуто докладніше у пункті «Відновлення сесії».

Також є додаткове розширення процедури Handshake, яке має назву TLS False Start. Це розширення дозволяє клієнту та серверу розпочати обмін зашифрованими даними одразу після встановлення методу шифрування, що скорочує встановлення з'єднання на одну ітерацію повідомлень. Про це докладніше розказано у пункті "TLS False Start".
 

Обмін ключами у протоколі TLS

З різних історичних та комерційних причин найчастіше в TLS використовується обмін ключами за алгоритмом RSA: клієнт генерує симетричний ключ, шифрує його за допомогою відкритого ключа сервера та відправляє його на сервер. На сервері ключ клієнта розшифровується за допомогою закритого ключа. Після цього обмін ключами оголошується завершеним. Цей алгоритм має один недолік: ця пара відритого і закритого ключів використовується і для аутентифікації сервера. Відповідно, якщо зловмисник отримує доступ до закритого ключа сервера, то він може розшифрувати весь сеанс зв'язку. Більше того, зловмисник може просто записати весь сеанс зв'язку в зашифрованому варіанті та зайняти розшифровкою потім, коли вдасться отримати закритий ключ сервера. У той же час, обмін ключами Діффі-Хеллмана є більш захищеним, оскільки встановлений симетричний ключ ніколи не залишає клієнта або сервера і, відповідно, не може бути перехоплений зловмисником, навіть якщо той знає закритий ключ сервера. На цьому засновано службу зниження ризику компрометації минулих сеансів зв'язку: для кожного нового сеансу зв'язку створюється новий так званий «тимчасовий» симетричний ключ. Відповідно, навіть у гіршому випадку (якщо зловмиснику відомий закритий ключ сервера), зловмисник може лише отримати ключі від майбутніх сесій, але не розшифрувати записані раніше.

На даний момент, всі браузери при встановленні з'єднання TLS віддають перевагу саме поєднанню алгоритму Діффі-Хеллмана та використанню тимчасових ключів для підвищення безпеки з'єднання.

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

Відновлення сесії TLS

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

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

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

Однак тут є практичне обмеження: оскільки сервер повинен зберігати дані про всі відкриті сесії, це призводить до проблеми з популярними ресурсами, які одночасно запитуються тисячами та мільйонами клієнтів.
Для обходу цієї проблеми розроблено механізм «Session Ticket», який усуває необхідність зберігати дані кожного клієнта на сервері. Якщо клієнт при початковій установці з'єднання вказав, що він підтримує цю технологію, то сервер в ході TLS Handshake відправляє клієнту так званий Session Ticket - параметри сесії, зашифровані закритим ключем сервера. При наступному поновленні сесії, клієнт разом з ClientHello відправляє Session Ticket. Таким чином, сервер позбавлений необхідності зберігати дані про кожне з'єднання, але з'єднання як і раніше безпечне, так як Session Ticket зашифрований ключем, відомим тільки на сервері.
 

TSL False Start

Технологія поновлення сесії безперечно підвищує продуктивність протоколу та знижує обчислювальні витрати, проте вона не застосовна у початковому з'єднанні з сервером, або у випадку, коли попередня сесія вже закінчилася.
Для отримання ще більшої швидкодії була розроблена технологія TLS False Start, що є опціональним розширенням протоколу і дозволяє надсилати дані, коли TLS Handshake завершено лише частково. Детальна схема TLS False Start представлена ​​на малюнку:

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

TLS Chain of trust

Аутентифікація є невід'ємною частиною кожного TLS з'єднання. Розглянемо найпростіший процес аутентифікації між Алісою та Бобом:

1. І Аліса, і Боб генерують власні відкриті та закриті ключі.
2. Аліса та Боб обмінюються відкритими ключами.
3. Аліса генерує повідомлення, шифрує його своїм закритим ключем та відправляє Бобу.
4. Боб використовує отриманий від Аліси ключ, щоб розшифрувати повідомлення та таким чином перевіряє справжність отриманого повідомлення.

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

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

Описане в попередньому абзаці є створення «ланцюжка довіри» (або «Chain of trust», якщо англійською).
У протоколі TLS ці ланцюги довіри засновані на сертифікатах автентичності, що надаються спеціальними органами, званими центрами сертифікації (CA – certificate authorities). Центри сертифікації проводять перевірки і, якщо виданий сертифікат скомпрометований, цей сертифікат відгукується.

З виданих сертифікатів складається вже розглянутий ланцюжок довіри. Коренем її так званий “Root CA certificate” – сертифікат, підписаний великим центром, довіру якого незаперечно. У загальному вигляді ланцюжок довіри виглядає приблизно таким чином:

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

Механізм цієї перевірки простий і в його основі лежить т.зв. "Список відкликаних сертифікатів" (CRL - "Certificate Revocation List"). У кожного з центрів сертифікації є список, що представляє простий перелік серійних номерів відкликаних сертифікатів. Відповідно будь-хто, хто хоче перевірити справжність сертифіката, просто завантажує даний список і шукає в ньому номер сертифіката, що перевіряється. Якщо номер виявиться, це означає, що сертифікат відкликаний.

Тут очевидно присутня деяка технічна нераціональність: для перевірки лише одного сертифіката потрібно запитувати весь список відкликаних сертифікатів, що спричиняє уповільнення роботи. Для боротьби з цим розроблено механізм під назвою «Протокол статусів сертифікатів» (OCSP – Online Certificate Status Protocol). Він дозволяє здійснювати перевірку статусу сертифіката динамічно. Звичайно, це знижує навантаження на пропускну здатність мережі, але водночас породжує кілька проблем:

• Центри сертифікації повинні справлятися із навантаженням у режимі реального часу;
• Центри сертифікації повинні гарантувати доступність у будь-який час;
• Через запити реального часу центри сертифікації отримують інформацію про те, які сайти відвідував кожен конкретний користувач.

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

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