Бяспека — гэта ўжо не варыянт, а абавязковы курс для кожнага спецыяліста па інтэрнэт-тэхналогіях. HTTP, HTTPS, SSL, TLS — ці сапраўды вы разумееце, што адбываецца за кулісамі? У гэтым артыкуле мы растлумачым асноўную логіку сучасных зашыфраваных камунікацыйных пратаколаў як неспецыялістам, так і прафесійным спосабам, і дапаможам вам зразумець сакрэты «за замкамі» з дапамогай візуальнай блок-схемы.
Чаму HTTP "небяспечны"? --- Уводзіны
Памятаеце знаёмае папярэджанне браўзера?
Ваша падключэнне не прыватнае.
Калі вэб-сайт не выкарыстоўвае HTTPS, уся інфармацыя карыстальніка перадаецца па сетцы ў выглядзе адкрытага тэксту. Вашы паролі для ўваходу, нумары банкаўскіх карт і нават асабістыя размовы могуць быць перахоплены добра размешчаным хакерам. Асноўная прычына гэтага — адсутнасць шыфравання ў HTTP.
Дык як жа HTTPS і TLS, які стаіць за ім, дазваляюць бяспечна перадаваць дадзеныя праз Інтэрнэт? Давайце разгледзім гэта паэтапна.
HTTPS = HTTP + TLS/SSL --- Структура і асноўныя паняцці
1. Што такое HTTPS па сутнасці?
HTTPS (бяспечны пратакол перадачы гіпертэксту) = HTTP + узровень шыфравання (TLS/SSL)
○ HTTP: Ён адказвае за перадачу дадзеных, але змест бачны ў выглядзе адкрытага тэксту
○ TLS/SSL: Забяспечвае «шыфраванне блакіроўкі» для HTTP-сувязі, ператвараючы дадзеныя ў галаваломку, якую могуць вырашыць толькі законныя адпраўнік і атрымальнік.
Малюнак 1: Параўнанне патоку дадзеных HTTP і HTTPS.
«Блакіроўка» ў адрасным радку браўзера — гэта сцяжок бяспекі TLS/SSL.
2. Якая сувязь паміж TLS і SSL?
○ SSL (Secure Sockets Layer): Найстарэйшы крыптаграфічны пратакол, у якім былі выяўленыя сур'ёзныя ўразлівасці.
○ TLS (Transport Layer Security): пераемнік SSL, TLS 1.2 і больш прасунутага TLS 1.3, якія прапануюць значныя паляпшэнні бяспекі і прадукцыйнасці.
У нашы дні «сертыфікаты SSL» — гэта проста рэалізацыі пратакола TLS, толькі названыя пашырэнні.
Глыбока ў TLS: крыптаграфічная магія HTTPS
1. Працэс поціску рукі цалкам вырашаны
Асновай бяспечнай сувязі TLS з'яўляецца «танец поціску рукі» падчас усталёўкі. Давайце разгледзім стандартны працэс поціску рукі TLS:
Малюнак 2: Тыповы працэс узаемадзеяння па пратаколе TLS.
1️⃣ Налада TCP-злучэння
Кліент (напрыклад, браўзер) ініцыюе TCP-злучэнне з серверам (стандартны порт 443).
2️⃣ Фаза поціску рукі TLS
○ Прывітанне кліента: браўзер адпраўляе падтрымоўваную версію TLS, шыфр і выпадковы лік разам з індыкатарам імя сервера (SNI), які паведамляе серверу, да якога імя хаста ён хоча атрымаць доступ (што дазваляе сумеснае выкарыстанне IP-адраса паміж некалькімі сайтамі).
○ Прывітанне сервера і праблема з сертыфікатам: сервер выбірае адпаведную версію TLS і шыфр, а затым адпраўляе назад свой сертыфікат (з адкрытым ключом) і выпадковыя лікі.
○ Праверка сертыфіката: браўзер правярае ланцужок сертыфікатаў сервера аж да даверанага каранёвага цэнтра сертыфікацыі, каб пераканацца, што ён не быў падроблены.
○ Генерацыя папярэдняга ключа: браўзер генеруе папярэдні ключ, шыфруе яго адкрытым ключом сервера і адпраўляе на сервер. Два бакі ўзгадняюць ключ сесіі: выкарыстоўваючы выпадковыя лікі абодвух бакоў і папярэдні ключ, кліент і сервер разлічваюць адзін і той жа сіметрычны ключ сесіі шыфравання.
○ Завяршэнне рукапаціскання: Абодва бакі адпраўляюць адзін аднаму паведамленні «Завершана» і пераходзяць у фазу перадачы зашыфраваных дадзеных.
3️⃣ Бяспечная перадача дадзеных
Усе дадзеныя службы сіметрычна шыфруюцца з дапамогай узгодненага ключа сесіі эфектыўна, нават калі іх перахопліваюць пасярэдзіне, яны аказваюцца проста кучай "скажонага кода".
4️⃣ Паўторнае выкарыстанне сесіі
TLS зноў падтрымлівае сесію, што можа значна палепшыць прадукцыйнасць, дазваляючы таму ж кліенту прапусціць стомнае ўстанаўленне сувязі.
Асіметрычнае шыфраванне (напрыклад, RSA) бяспечнае, але павольнае. Сіметрычнае шыфраванне хуткае, але размеркаванне ключоў грувасткае. TLS выкарыстоўвае «двухэтапную» стратэгію — спачатку асіметрычны бяспечны абмен ключамі, а затым сіметрычную схему для эфектыўнага шыфравання дадзеных.
2. Эвалюцыя алгарытмаў і паляпшэнне бяспекі
RSA і Дыфі-Хелмана
○ RSA
Упершыню ён шырока выкарыстоўваўся падчас TLS-рукапаціскання для бяспечнага размеркавання ключоў сесіі. Кліент генеруе ключ сесіі, шыфруе яго адкрытым ключом сервера і адпраўляе яго, каб толькі сервер мог яго расшыфраваць.
○ Дыфі-Хелмана (DH/ECDH)
Пачынаючы з TLS 1.3, RSA больш не выкарыстоўваецца для абмену ключамі на карысць больш бяспечных алгарытмаў DH/ECDH, якія падтрымліваюць прамую сакрэтнасць (PFS). Нават калі закрыты ключ будзе раскрыты, гістарычныя даныя ўсё роўна не будуць раскрыты.
| Версія TLS | алгарытм абмену ключамі | Бяспека |
| TLS 1.2 | RSA/DH/ECDH | Вышэй |
| TLS 1.3 | толькі для DH/ECDH | Вышэй |
Практычныя парады, якія павінны асвоіць спецыялісты па нетворкінгу
○ Прыярытэтнае абнаўленне да TLS 1.3 для больш хуткага і бяспечнага шыфравання.
○ Уключыць надзейныя шыфры (AES-GCM, ChaCha20 і г.д.) і адключыць слабыя алгарытмы і небяспечныя пратаколы (SSLv3, TLS 1.0);
○ Наладзьце HSTS, OCSP Stapling і г.д. для паляпшэння агульнай абароны HTTPS;
○ Рэгулярна абнаўляйце і правярайце ланцужок сертыфікатаў, каб забяспечыць яго сапраўднасць і цэласнасць.
Высновы і думкі: ці сапраўды ваш бізнес бяспечны?
Патрабаванні да бяспекі, пачынаючы ад простага тэкставага HTTP і заканчваючы цалкам зашыфраваным HTTPS, змяняліся з кожным абнаўленнем пратакола. TLS, як аснова зашыфраванай сувязі ў сучасных сетках, пастаянна ўдасканальваецца, каб спраўляцца з усё больш складаным асяроддзем атак.
Ці выкарыстоўвае ваш бізнес ужо HTTPS? Ці адпавядае ваша крыптаграфічная канфігурацыя перадавым галіновым практыкам?
Час публікацыі: 22 ліпеня 2025 г.
