Перегляд вихідного коду сторінки HTTPS

{{IPstack}}{{Протоколи безпеки Інтернет}}{{HTTP}}
'''HTTPS''' (інші назви: '''HTTP over [[Transport Layer Security|TLS]]''',<ref name="HTTP Over TLS">{{cite web | url=https://tools.ietf.org/html/rfc2818 | title=HTTP Over TLS | publisher=The Internet Engineering Task Force | date=May 2000 | accessdate=30 січня 2017 | author=Network Working Group | archive-date=31 жовтня 2018 | archive-url=https://web.archive.org/web/20181031095731/https://tools.ietf.org/html/rfc2818 }}</ref><ref name="HTTPS-ranking-signal">{{cite web | url=https://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html | title=HTTPS as a ranking signal | publisher=Google Inc. | work=Google Webmaster Central Blog | date=August 6, 2014 | accessdate=30 січня 2017 | quote=You can make your site secure with HTTPS (Hypertext Transfer Protocol Secure) [...] | archive-date=8 березня 2016 | archive-url=https://web.archive.org/web/20160308074838/https://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html }}</ref> '''HTTP over SSL''',<ref name="Enabling HTTP Over SSL">{{cite web | url=https://docs.adobe.com/docs/en/cq/5-6-1/deploying/config-ssl.html | title=Enabling HTTP Over SSL | publisher=Adobe Systems Incorporated | accessdate=30 січня 2017 | archive-date=8 березня 2015 | archive-url=https://web.archive.org/web/20150308084326/http://docs.adobe.com/docs/en/cq/5-6-1/deploying/config-ssl.html }}</ref> і '''HTTP Secure'''<ref name="Secure your site with HTTPS">{{cite web | url=https://support.google.com/webmasters/answer/6073543?hl=en | title=Secure your site with HTTPS | publisher=Google, Inc. | work=Google Support | accessdate=30 січня 2017 | archive-date=15 грудня 2017 | archive-url=https://web.archive.org/web/20171215041903/https://support.google.com/webmasters/answer/6073543?hl=en }}</ref><ref name="What is HTTPS?">{{cite web | url=https://www.instantssl.com/ssl-certificate-products/https.html | title=What is HTTPS? | publisher=[[Comodo Group|Comodo CA Limited]] | accessdate=30 січня 2017 | quote=Hyper Text Transfer Protocol Secure (HTTPS) is the secure version of HTTP [...] | archive-date=12 лютого 2015 | archive-url=https://web.archive.org/web/20150212105201/https://www.instantssl.com/ssl-certificate-products/https.html }}</ref>)&nbsp;— схема [[URI]], що синтаксично ідентична http: схемі, яка зазвичай використовується для доступу до ресурсів [[Інтернет]]. Використання https: URL вказує, що протокол [[HTTP]] має використовуватися, але з іншим портом за замовчуванням (443) і додатковим шаром [[шифрування]]/[[автентифікація|автентифікації]] між HTTP і [[TCP]]. Ця схема була винайдена у компанії [[Netscape Communications Corporation]] для забезпечення автентифікації та шифрування комунікацій і широко використовується в [[Інтернет]]і у програмному забезпеченні, в якому важлива безпека комунікацій, наприклад, у платіжних системах та корпоративних логінах.

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

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

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

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

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

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

* Користувач довіряє тому, що у браузері правильно забезпечено підтримку HTTPS із коректними попередньо встановленими сертифікатами уповноважених на видачу сертифікатів.
* Користувач довіряє тому, що уповноважені на видачу сертифікатів засвідчують тільки відповідні (справжні) вебсайти.
* Вебсайт надає дійсний сертифікат, тобто підписаний довіреним центром сертифікації.
* Сертифікат конкретно розпізнає вебсайт (тобто коли браузер відвідує сторінку "https://example.com {{Webarchive|url=https://web.archive.org/web/20201029155204/https://example.com/ |date=29 жовтня 2020 }}", отриманий сертифікат правильний для "example.com", а не для інших [[Доменне ім'я|доменних імен]]).
* Користувач довіряє тому, що криптографічний рівень (шифрування за допомогою SSL/TLS) достатньо надійний, щоб захиститися від дешифрування.

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

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

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

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

Станом на початок 2017 р. HTTPS використовується на 10.13&nbsp;% всіх українських доменів<ref>{{Cite web|url=https://www.ukralio.com/statistika-ukrainskogo-internetu|title=Статистика українського інтернету ukralio.com|website=www.ukralio.com|language=uk|accessdate=2017-02-16|archiveurl=https://web.archive.org/web/20170217063340/https://www.ukralio.com/statistika-ukrainskogo-internetu|archivedate=2017-02-17|deadurl=yes}}</ref>.

== Обмеження ==

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

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

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

Передача даних через захищені канали допомагає усунути деякі ризики: при використанні [[Transport Layer Security|TLS]], [[HTTP Strict Transport Security|HSTS]], фіксованих публічних ключів, веббраузер може бути впевнений, що він отримує дані з саме того сервера, до якого він звернувся. Проте, ці механізми [[Автентифікація|автентифікують]] лише сервер, але не отримані дані. Зловмисник (або адміністратор вебсайту) з доступом до сервера може довільно змінювати дані. Механізм [[Subresource Integrity|SRI]] дозволяє авторам вебсторінок гарантувати, що користувачі завантажуватимуть зі сторонніх вебсайтів тільки ті ресурси, які визначив автор сторінки<ref>{{cite web | url = http://www.w3.org/TR/2016/REC-SRI-20160623/ | title = Subresource Integrity | work = W3C Recommendation | date = 23 June 2016 | accessdate = 6 грудня 2017 | archive-date = 15 липня 2017 | archive-url = https://web.archive.org/web/20170715115110/https://www.w3.org/TR/2016/REC-SRI-20160623/ }}</ref>.

Проте, застосування TLS не гарантує захисту від витоків інформації про з'єднання. Наприклад, зловмисник може дізнаватись сервери, до яких звертався браузер, щонайменше з чотирьох джерел: повідомлення з сертифікатом TLS, запит до DNS, IP-адреса сервера, та розширення TLS Server Name Indication (TLS SNI). Проти деяких з цих «сторонніх каналів» існують методи захисту. Зокрема, в протоколі TLS 1.3 серверний сертифікат передається у зашифрованому вигляді за замовчуванням, а для захисту від витоків через SNI було розроблене розширення протоколу «шифрованої індикації імені сервера»&nbsp;— Encrypted Server Name Indication (ESNI)<ref>{{cite web | url = https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/ | title = Encrypted SNI Comes to Firefox Nightly | author = Eric Rescorla | publisher = Mozilla Security Blog | date = 2018-1018 | accessdate = 22 жовтня 2018 | archive-date = 24 березня 2020 | archive-url = https://web.archive.org/web/20200324233735/https://blog.mozilla.org/security/2018/10/18/encrypted-sni-comes-to-firefox-nightly/ }}</ref>.

Слід також зазначити, що використання сайтом HTTPS не гарантує захисту від шахрайства. Так, наприклад, за даними 2017 року дедалі більше [[фішинг]]ових вебсайтів стали використовувати HTTPS з дійсними сертифікатами для введення користувачів в оману<ref>{{cite web | url = https://www.heise.de/security/meldung/Ganz-und-gar-nicht-sicher-Immer-mehr-Phishing-Webseiten-setzen-auf-HTTPS-3911127.html | title = Ganz und gar nicht sicher: Immer mehr Phishing-Webseiten setzen auf HTTPS | date = 07.12.2017 | author = Dennis Schirrmacher | publisher = Heise online | accessdate = 8 грудня 2017 | archive-date = 8 грудня 2017 | archive-url = https://web.archive.org/web/20171208021958/https://www.heise.de/security/meldung/Ganz-und-gar-nicht-sicher-Immer-mehr-Phishing-Webseiten-setzen-auf-HTTPS-3911127.html }}</ref>.

== Примітки ==
{{reflist|2}}

== Див. також ==

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

== Посилання ==
* [https://tools.ietf.org/html/rfc2818 RFC 2818: HTTP Over TLS] {{Webarchive|url=https://web.archive.org/web/20181031095731/https://tools.ietf.org/html/rfc2818 |date=31 жовтня 2018 }}
* [https://tools.ietf.org/html/rfc5246 RFC 5246: The Transport Layer Security Protocol 1.2] {{Webarchive|url=https://web.archive.org/web/20171224222709/https://tools.ietf.org/html/rfc5246 |date=24 грудня 2017 }}

{{-}}{{Computer-security-stub}}{{Internet-stub}}
{{URI scheme}}
{{TLS/SSL}}
{{Вебоглядачі|fsp}}
{{портали|Програмування|Інформаційні технології}}

[[Категорія:Акроніми]]
[[Категорія:HTTP]]
[[Категорія:Інтернет-протоколи]]
[[Категорія:Криптографічні протоколи]]