HostiServer
2026-06-01 20:23
Історія HTTPS: від Chrome 68 у 2018 до 99% веб-трафіку у 2026
Як HTTPS став стандартом інтернету: від Chrome 68 до 2026
Коли ви заходите на будь-який сайт у 2026 році та у адресному рядку Chrome ви побачите іконку замка або взагалі нічого, бо HTTPS уже вважається даністю, а не досягненням. Та наоборот, якщо сайт працює по голому HTTP, браузер крутить великий червоний попереджувальний екран на весь монітор: «Атакуючий може намагатися викрасти вашу інформацію». Конверсія таких сторінок — нуль.
Минуло вісім років з того моменту, як Chrome 68 у липні 2018 року вперше масово показав мітку «Not Secure» поруч з адресами HTTP-сайтів. Хоть це не була найгучніша подія в історії веба, але саме вона змусила мільйони власників сайтів за кілька місяців перейти на HTTPS — це те, що раніше затягували роками.
Наша стаття — про те, як ми сюди прийшли, що змінилось за вісім років, і де веб опиниться у найближчому майбутньому. Технічна частина (як налаштувати TLS на Nginx, який сертифікат вибрати, як зробити міграцію без втрати SEO) винесена в окремі статті — на них будуть посилання в відповідних місцях.
Як ми жили до HTTPS: коротка передісторія
HTTPS не виник у 2018 році разом з Chrome 68. Протокол SSL з'явився ще в 1995-му в Netscape — буквально на світанку комерційного веба. Але до 2010-х його використовували переважно банки, платіжні шлюзи і сторінки логіну в великих сервісах. Решта інтернету жила на звичайному HTTP.
Проблем це не викликало, поки виконувалися дві умови: трафік йшов через довірених інтернет-провайдерів, і користувач не сидів у публічних мережах. Обидва припущення розбилися об реальність на початку 2010-х:
- Публічний Wi-Fi став доступний всюди. Кав'ярні, готелі, аеропорти, метро. У відкритій бездротовій мережі будь-який сусід зі сніфером міг читати весь HTTP-трафік навколо себе — паролі, кукі, особисті повідомлення.
- Інтернет-провайдери почали інжектити рекламу. Спочатку точково, потім масово. Якщо сайт працював по HTTP, провайдер легально (а часто і нелегально) міг вставити свій банер прямо у тіло сторінки під час передачі.
- Сніфінг трафіку перейшов на промисловий рівень. Після 2013 року, коли вийшли документи Сноудена, стало зрозуміло, що масовий перехват трафіку — це не теорія, а реальна практика на рівні держав.
Розшифровка кожного HTTPS-запиту коштувала ресурсів і часу, але до 2014 року це вже не було серйозним бар'єром. Веб був готовий до переходу — не вистачало лише поштовху.
2014: Google робить HTTPS фактором ранжування
У серпні 2014 року Google офіційно оголосив, що наявність HTTPS враховується в алгоритмах пошукової видачі. На той момент вага цього сигналу була мінімальна — компанія прямо сказала: «впливає лише на 1% запитів і слабше, ніж якість контенту». Але напрямок був заданий: безпечні сайти будуть отримувати перевагу, а небезпечні — поступово втрачати позиції.
Багато хто проігнорував цей сигнал. На той час перехід на HTTPS виглядав непростим завданням: треба було купити сертифікат (від $50 до $500 на рік у комерційних центрів сертифікації), правильно налаштувати сервер, виправити mixed content, переписати всі внутрішні посилання, налаштувати 301-редиректи з HTTP. Для більшості малого і середнього бізнесу це були гроші і години роботи без очевидної віддачі.
Тоді Google підключив важелі, які зрештою перевернули ситуацію.
2015: запуск Let's Encrypt
У квітні 2015-го стартує проєкт Let's Encrypt — некомерційний центр сертифікації, який видає SSL-сертифікати безкоштовно. Підтримуваний Mozilla, EFF, Cisco, Akamai та іншими гравцями галузі. Це усуває фінансовий бар'єр повністю: тепер сертифікат коштує нуль доларів і автоматично оновлюється кожні 90 днів.
До кінця 2016 року Let's Encrypt видав 24 мільйони сертифікатів. До 2020-го — мільярд. Він став стандартом де-факто для більшості сайтів у світі.
2017: попередження на формах введення паролів
У січні 2017 року Chrome 56 починає показувати мітку «Not Secure» для HTTP-сторінок, які містять поля введення паролів або номерів карт. Це ще не повне маркування всього HTTP, але вже видимий сигнал: Google готує перехід.
Власники сайтів отримують півтора року попередження. Хто почув — мігрував. Хто не почув — отримав сюрприз у липні 2018-го.
Липень 2018: Chrome 68 і кінець епохи HTTP
24 липня 2018 року виходить Chrome 68. У changelog — рядок, який змінив веб: тепер усі сайти без HTTPS отримують мітку «Not Secure» в адресному рядку, незалежно від того, чи є на сторінці форми, чи ні.
На той момент Chrome контролював понад 60% глобального ринку браузерів. Це означало: 6 з 10 відвідувачів вашого сайту бачили попередження одразу при заході. Конверсії інтернет-магазинів на HTTP падали у 2-3 рази вже у перший день після оновлення браузера.
Що сталося далі
За кілька місяців після виходу Chrome 68 частка HTTPS-трафіку в інтернеті зросла з ~70% до ~85%. До кінця 2019-го — до 95%. Це був найшвидший масовий перехід на новий стандарт безпеки в історії веба.
| Рік | Частка HTTPS у завантаженнях сторінок (Chrome) | Подія |
|---|---|---|
| 2014 | ~35% | HTTPS оголошено сигналом ранжування Google |
| 2016 | ~50% | Let's Encrypt досягає 24 млн виданих сертифікатів |
| 2017 | ~65% | Chrome 56: попередження на формах паролів |
| 2018 | ~85% | Chrome 68: мітка «Not Secure» для всіх HTTP-сайтів |
| 2020 | ~95% | TLS 1.3 стає стандартом за замовчуванням, Chrome починає блокувати mixed content |
| 2026 | ~99% | HTTP/3 у продакшені, ECH, post-quantum TLS у бета-тестуванні |
Цифри Chrome публікує у відкритому звіті Transparency Report — їх можна перевірити будь-коли. Динаміка очевидна: за вісім років HTTPS пройшов шлях від «бажано» до «без нього сайт не існує».
Що насправді робить HTTPS
Шифрування часто розуміють вузько — «дані не прочитати». Насправді HTTPS вирішує три окремі задачі, відомі в криптографії як тріада CIA (Confidentiality, Integrity, Authenticity).
Конфіденційність
Трафік між браузером і сервером шифрується сучасними алгоритмами (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305). Якщо хтось перехопить пакети — побачить безглуздий потік байтів. Розшифрувати його методом перебору ключів не реально за час життя сонячної системи.
Цілісність
Кожен переданий блок підписується криптографічним MAC (Message Authentication Code). Якщо хтось спробує змінити пакет у дорозі — навіть один біт — отримувач побачить, що підпис не сходиться, і розірве сесію. Це означає: інтернет-провайдер уже не може вставити рекламний банер у вашу сторінку, а зловмисник на публічному Wi-Fi не може підкласти JavaScript-малварь у відповідь.
Автентичність
Сертифікат, виданий довіреним центром (CA), доводить, що домен належить саме тій організації, яка його обслуговує. Це не дає створити фішингову копію вашого сайту на тому самому домені — браузер просто не довірить підробному сертифікату. Атаки типу «людина посередині» (MITM), у яких зловмисник видає себе за справжній сервер, без скомпрометованого CA неможливі.
Чого HTTPS НЕ робить
Це важливо розуміти, бо «у мене є SSL — я в безпеці» — поширена помилка. HTTPS захищає тільки канал передачі. Усе інше — окремі задачі:
| Загроза | Чи захищає HTTPS | Що насправді потрібно |
|---|---|---|
| Перехоплення трафіку у Wi-Fi | Так | HTTPS |
| Підміна контенту в дорозі | Так | HTTPS |
| SQL-ін'єкції, XSS | Ні | Безпечний код, WAF, валідація вводу |
| Вразливості в плагінах CMS | Ні | Регулярні оновлення |
| Brute-force атаки на адмінку | Ні | Сильні паролі, 2FA, fail2ban |
| DDoS-атаки | Ні | Захист на рівні мережі (L3/L4) і додатків (L7) |
| Слабкі паролі SSH на сервері | Ні | Ключова автентифікація, відключення root-логіну |
| Застарілі протоколи TLS (POODLE, BEAST) | Частково | Вимкнути застарілі протоколи SSLv3, TLS 1.0 та TLS 1.1 на рівні сервера |
⚠️ Окремо про конфігурацію TLS: навіть з валідним сертифікатом сервер може мати погано налаштовану криптографію — увімкнені застарілі шифри, дозволений TLS 1.0/1.1, відсутній OCSP stapling. Перевірте свій сайт на SSL Labs — якщо отримуєте оцінку нижче A, час оновлювати конфіг. Деталі — у нашому матеріалі про SSL/TLS Security Guide.
Що змінилось у HTTPS за вісім років після Chrome 68
Стаття 2018 року описувала ситуацію станом на той момент. За вісім років технологія шифрування у вебі змінилась суттєво — і у багатьох випадках на краще без необхідних втручань з боку власника сайту, на рівні самих браузерів і серверів.
TLS 1.3 став стандартом за замовчуванням
TLS 1.3 вийшов у серпні 2018-го як RFC 8446 — практично одночасно з Chrome 68. Перший handshake скоротився з 2 RTT до 1 RTT, з'явилась підтримка 0-RTT для повторних з'єднань (резюме сесій), застарілі шифри (RC4, 3DES, SHA-1) вирізали з протоколу повністю.
До 2026 року TLS 1.3 — це стандарт у Nginx, Apache, IIS, Caddy «з коробки». TLS 1.2 ще підтримується для сумісності, але TLS 1.0 і 1.1 офіційно деприковані IETF (RFC 8996) і блокуються браузерами.
Mixed content повністю блокується
Раніше, якщо HTTPS-сторінка завантажувала зображення або скрипт по HTTP, браузер показував зламаний замочок, але контент пропускав. У 2020 році Chrome почав блокувати mixed content за замовчуванням: спочатку скрипти і стилі, потім зображення, потім усе. Зараз у 2026 змішаний контент просто не вантажиться — без винятків.
HTTP/3 пішов у продакшен
HTTP/3 на базі QUIC (UDP замість TCP) у 2026 році підтримується Cloudflare, Google, Facebook, більшістю великих CDN та сучасними версіями Nginx. Він технічно вимагає HTTPS — без шифрування QUIC просто не існує. Тобто перехід на HTTPS відкрив дорогу до наступного покоління транспортних протоколів. Деталі — у нашому матеріалі про HTTP/3 та його вплив на продуктивність.
Сертифікати стали короткими
У 2020-му максимальний термін дії публічних сертифікатів обмежили 398 днями (раніше було 3 роки). У 2024 році CA/Browser Forum проголосував за подальше скорочення — до 47 днів до 2029-го. Логіка проста: короткий термін = швидше відкликання скомпрометованих сертифікатів. На практиці це означає: без автоматизації (Certbot, acme.sh) сертифікати обслуговувати ручками вже не реально.
HSTS і preload-листи стали нормою
Заголовок HSTS (HTTP Strict Transport Security), про який у статті 2018 року згадували як «бонус», у 2026-му — стандартна частина базової конфігурації. Великі сайти (Google, Facebook, банки) включені у preload-лист, який вбудований прямо у браузери. Це означає: браузер навіть першого разу не спробує піти по HTTP.
На горизонті — постквантова криптографія
У 2024 році Chrome почав експерименти з постквантовими алгоритмами обміну ключами (X25519Kyber768). Логіка: коли (якщо) з'являться достатньо потужні квантові комп'ютери, вони зможуть зламати поточну криптографію з відкритим ключем. Тому інженери великих компаній уже зараз готують стандарти, які будуть стійкими. У 2026-му це ще експеримент, але через 3-5 років стане новим стандартом — як TLS 1.3 у свій час.
Якщо ваш сайт досі на HTTP
У 2026 році це рідкісний випадок, але такі сайти ще зустрічаються — переважно старі корпоративні сторінки, які не оновлювались роками, або внутрішні системи, до яких ніхто не доходив. Якщо це про вас, переходити треба було вчора.
Короткий план без деталей:
- Отримати сертифікат. Для більшості сайтів — безкоштовний Let's Encrypt через Certbot. Для e-commerce з фінансовою гарантією — комерційний OV/EV від DigiCert або Sectigo.
- Налаштувати сервер. Nginx або Apache з підтримкою TLS 1.2/1.3, актуальними шифрами, OCSP stapling. Перевірка — SSL Labs, оцінка A або вище.
- Виправити mixed content. Усі внутрішні посилання, шляхи до зображень, CSS, JS — перевести на HTTPS. Перевірка — DevTools у Chrome, вкладка Console покаже всі заблоковані ресурси.
- Налаштувати 301-редирект з HTTP на HTTPS. Для пошукових систем і користувачів, які приходять по старих посиланнях. Без редиректу втрачаються SEO-позиції.
- Оновити Google Search Console. Додати HTTPS-версію як окрему property, оновити sitemap.xml, перевірити індексацію.
- Увімкнути HSTS. Заголовок, який примушує браузер ходити лише по HTTPS. Після перевірки що все працює — заявка у preload-лист.
ℹ️ Детальний покроковий гайд з прикладами конфігів Nginx і Apache, обробкою mixed content, тестуванням і налаштуванням Google Search Console — у нашій окремій статті про міграцію на HTTPS і HTTP/2.
Що буде з HTTPS у найближчі роки
Якщо тренд останніх восьми років продовжиться, найближчі п'ять років принесуть кілька важливих змін.
Сертифікати на 47 днів
CA/Browser Forum затвердив план поетапного скорочення максимального терміну дії сертифікатів: 200 днів (2026) → 100 днів (2027) → 47 днів (2029). Це остаточно знищить ринок ручного управління сертифікатами — без автоматизації жоден сайт не виживе. Хороша новина: Certbot і acme.sh уже працюють так роками, нічого особливого вчити не доведеться.
Постквантова криптографія
У 2025-2027 роках браузери і сервери поетапно отримають підтримку гібридних алгоритмів обміну ключами (класичний + постквантовий). До 2030-го це стане стандартом. Власник сайту нічого спеціального робити не буде — оновлення Nginx або Apache принесе нові алгоритми автоматично.
ECH (Encrypted Client Hello)
Розширення TLS, яке шифрує навіть ім'я домену під час handshake. Зараз ім'я хосту видно у відкритому вигляді — навіть якщо інший трафік зашифрований, провайдер бачить, які сайти ви відвідуєте. ECH це закриває. Cloudflare уже підтримує, Chrome вмикає поетапно. До 2027-го очікується широка підтримка.
Перехід на DoH/DoT за замовчуванням
Шифрування DNS-запитів (DNS over HTTPS, DNS over TLS) уже включене в Chrome і Firefox, але поки що умовно. Через кілька років це стане стандартною поведінкою — і остання велика «дірка» у тому, що бачить провайдер про вашу активність, закриється. Деталі — у нашому матеріалі «Що таке DNS і як він працює».
💡 Підсумок для власника сайту: у 2026 році HTTPS — це не один з кроків забезпечення безпеки, це нульова точка. Якщо сайт без HTTPS — це навіть не зона ризику, це зона неіснування для пошуковиків і користувачів. Усе решта будується вже поверх.
🚀 Налаштування HTTPS «під ключ» від команди Hostiserver
Якщо самостійно займатися сертифікатами, TLS-конфігами і mixed content не хочеться — команда інженерів Hostiserver робить це щодня.
💻 Cloud (VPS) Хостинг
- Від $19.95/міс — KVM-ізоляція, повний root-доступ
- Безкоштовний SSL Let's Encrypt з автоматичним оновленням
- Налаштований TLS 1.3 і сучасні шифри з коробки
- HTTP/2 та HTTP/3 підтримуються «з коробки» на Nginx
- Допомога з міграцією з HTTP — техпідтримка робить безкоштовно для нових клієнтів
- 24/7 інженерна підтримка — <10 хв відповідь, без call-центру
🖥️ Виділені Сервери
- Від $90/міс — повна ізоляція без сусідів на залізі
- Налаштування TLS на A+ у SSL Labs — стандартна частина приймання сервера
- Платні OV/EV сертифікати — допомога з замовленням і встановленням
- SLA 99.9% uptime з гарантією у договорі
- Безкоштовна міграція з іншого провайдера, включно з SSL і конфігами
💬 Не впевнені, який варіант вам необхідний?
💬 Напишіть нам і ми зі всім допоможемо!
Часті питання
- Чи буде HTTP колись повністю заблокований у браузерах?
Скоріше за все, ні — у тому сенсі, що повна заборона HTTP створить проблеми для внутрішніх систем, локальної розробки (localhost), деяких IoT-пристроїв. Але користувацький досвід зробили настільки негативним (червоний попереджувальний екран на весь монітор, неможливість відправити форму без явного підтвердження), що реально HTTP уже непридатний для публічних сайтів. Це не заборона, але це функціональний кінець.
- Чи правда, що Let's Encrypt — це менш надійний сертифікат, ніж платний?
Технічно — ні. Let's Encrypt видає сертифікати того самого типу (DV — Domain Validation), що й платні DV-сертифікати від Comodo чи RapidSSL. Криптографія однакова, рівень шифрування однаковий, рівень довіри браузерів однаковий. Різниця — у валідації організації: платні OV/EV сертифікати перевіряють, що домен належить конкретній юридичній особі, що додає рівень довіри для e-commerce і фінансових сайтів. Для блогу, корпоративного сайту, лендингу — Let's Encrypt більш ніж достатньо.
- Якщо у мене на сайті немає форм і платежів, навіщо HTTPS?
Кілька причин окрім захисту форм. По-перше, без HTTPS неможливо включити HTTP/2 і HTTP/3 — сайт буде помітно повільнішим. По-друге, HTTPS захищає вас від інжекту сторонньої реклами і малварі провайдером у дорозі. По-третє, без HTTPS Google знижує сайт у видачі. По-четверте, користувачі бачать «Not Secure» у браузері і не довіряють. У 2026 році відсутність HTTPS — це просто непрофесійно.
- Чи можна довіряти будь-якому сертифікату, який підписаний CA?
В цілому так, але з обмеженнями. Список довірених CA, який вбудовується у браузери та операційні системи, контролюється і регулярно ревізується. Якщо помічено, що CA видає шахрайські сертифікати (як було з DigiNotar у 2011-му або Symantec у 2017-му) — браузери відкликають довіру до всього центру. Існує також публічний журнал Certificate Transparency, де реєструються всі видані сертифікати, і власник домену може моніторити, чи не виданий хтось підробний сертифікат на його ім'я.
- Чи варто переходити на HTTP/3, чи достатньо HTTP/2?
Залежить від аудиторії. Якщо ваші користувачі сидять переважно на мобільних з нестабільним з'єднанням (4G, метро, поїздки) — HTTP/3 дасть помітну різницю, особливо в показниках TTFB і LCP. Якщо це B2B-сайт зі стабільним десктопним трафіком — різниця менш помітна. У будь-якому випадку, налаштовувати треба обидва: HTTP/3 для тих, хто підтримує, HTTP/2 як fallback для решти. Сам перехід на HTTP/3 не вимагає змін у коді сайту — це робота на рівні веб-сервера.
- Як перевірити якість TLS-налаштувань мого сайту?
Найпростіше — тест на SSL Labs. Безкоштовно, займає 1-2 хвилини, показує оцінку від A+ до F, перелік підтримуваних шифрів, потенційні проблеми (слабкі ключі, вразливі шифри, відсутність OCSP stapling). Метою має бути A або A+. Якщо оцінка нижче — це сигнал, що пора оновлювати конфіг сервера. Якщо самостійно розбиратися не хочеться, техпідтримка хостинг-провайдера зазвичай це робить безкоштовно.