HTTPS

HTTPS (абр. від англ. HyperText Transfer Protocol Secure; інші назви: HTTP over TLS, HTTP over SSL, і HTTP Secure) — схема URI, що синтаксично ідентична http: схемі, яка зазвичай використовується для доступу до ресурсів Інтернет. Використання https: URL вказує, що протокол HTTP має використовуватися, але з іншим портом за замовчуванням (443) і додатковим шаром шифрування/автентифікації між HTTP і TCP. Ця схема була винайдена у компанії Netscape Communications Corporation для забезпечення автентифікації та шифрування комунікацій і широко використовується в Інтернеті у програмному забезпеченні, в якому важлива безпека комунікацій, наприклад, у платіжних системах та корпоративних логінах.

Принцип роботи

Оскільки HTTPS це фактично HTTP, який передається через SSL або TLS, то майже всі його основні елементи шифруються: URL-запити, включаючи шлях та назву ресурсу (сторінки), параметри запиту, заголовки та кукі, які часто містять ідентифікаційні дані про користувача. Не шифруються: назва або адреса хоста (вебсайту) та порт, оскільки вони використовуються транспортним протоколом TCP/IP для встановлення з'єднання.

Шифрування гарантує помірний захист від підслуховування та від нападу «людина посередині» (man-in-the-middle), за умови це коректних налаштувань та підпису сертифікату авторизованим центром сертифікації.

TCP портом за замовчуванням для HTTPS є 443, для HTTP — 80.

Щоб підготувати вебсервер для прийняття https транзакцій адміністратор повинен створити сертифікат з відкритим ключем для вебсервера. Ці сертифікати можуть бути створені на UNIX сервері такими програмами, як наприклад OpenSSL. Цей сертифікат повинен бути підписаний уповноваженим на видачу сертифікатів (certificate authority), який засвідчує, що отримувач сертифікату — саме той, про кого йдеться у сертифікаті.

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

Довіряти HTTPS з'єднанню можна тоді і тільки тоді, коли всі наступні твердження коректні:

• Користувач довіряє тому, що у браузері правильно забезпечено підтримку HTTPS із коректними попередньо встановленими сертифікатами уповноважених на видачу сертифікатів.
• Користувач довіряє тому, що уповноважені на видачу сертифікатів засвідчують тільки відповідні (справжні) вебсайти.
• Вебсайт надає дійсний сертифікат, тобто підписаний довіреним центром сертифікації.
• Сертифікат конкретно розпізнає вебсайт (тобто коли браузер відвідує сторінку "https://example.com [Архівовано 29 жовтня 2020 у Wayback Machine.]", отриманий сертифікат правильний для "example.com", а не для інших доменних імен).
• Користувач довіряє тому, що криптографічний рівень (шифрування за допомогою SSL/TLS) достатньо надійний, щоб захиститися від дешифрування.

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

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

Деякі сайти використовують самостійно підписані сертифікати. Їх використання забезпечує захист проти підслуховування, але є ризик нападу «людина-посередині». Для запобігання нападу необхідна перевірка сертифікату іншим методом (наприклад подзвонити власнику сертифіката задля перевірки контрольної суми сертифіката).

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

Станом на початок 2017 р. HTTPS використовується на 10.13 % всіх українських доменів.

Обмеження

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

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

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

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

Проте, застосування TLS не гарантує захисту від витоків інформації про з'єднання. Наприклад, зловмисник може дізнаватись сервери, до яких звертався браузер, щонайменше з чотирьох джерел: повідомлення з сертифікатом TLS, запит до DNS, IP-адреса сервера, та розширення TLS Server Name Indication (TLS SNI). Проти деяких з цих «сторонніх каналів» існують методи захисту. Зокрема, в протоколі TLS 1.3 серверний сертифікат передається у зашифрованому вигляді за замовчуванням, а для захисту від витоків через SNI було розроблене розширення протоколу «шифрованої індикації імені сервера» — Encrypted Server Name Indication (ESNI).

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

Див. також

• Transport Layer Security (TLS)
• Secure Sockets Layer (SSL)
• Інфраструктура відкритих ключів

Посилання

• RFC 2818: HTTP Over TLS [Архівовано 31 жовтня 2018 у Wayback Machine.]
• RFC 5246: The Transport Layer Security Protocol 1.2 [Архівовано 24 грудня 2017 у Wayback Machine.]