Безбедноста повеќе не е опција, туку задолжителен курс за секој практичар на интернет технологија. 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
○ Client Hello: Прелистувачот ја испраќа поддржаната TLS верзија, шифра и случаен број заедно со Server Name Indication (SNI), што му кажува на серверот до кое име на хост сака да пристапи (овозможувајќи споделување на IP адреса низ повеќе страници).
○ Здраво на серверот и проблем со сертификатот: Серверот ја избира соодветната верзија и шифра на TLS и го враќа својот сертификат (со јавен клуч) и случајни броеви.
○ Потврда на сертификат: Прелистувачот го потврдува синџирот на сертификати на серверот сè до доверливиот root CA за да се осигури дека не е фалсификуван.
○ Генерирање на предмастер клуч: Прелистувачот генерира предмастер клуч, го шифрира со јавниот клуч на серверот и го испраќа до серверот. Двете страни преговараат за сесискиот клуч: Користејќи ги случајните броеви на двете страни и предмастер клучот, клиентот и серверот го пресметуваат истиот симетричен сесиски клуч за шифрирање.
○ Завршување на ракувањето: Двете страни си испраќаат пораки „Завршено“ една на друга и влегуваат во фазата на шифриран пренос на податоци.
3️⃣ Безбеден пренос на податоци
Сите податоци за услугата се симетрично криптирани со договорениот клуч за сесија ефикасно, дури и ако се пресретнати во средината, тоа е само еден куп „измешан код“.
4️⃣ Повторна употреба на сесијата
TLS повторно ја поддржува Session, што може значително да ги подобри перформансите со тоа што му овозможува на истиот клиент да го прескокне досадното ракување.
Асиметричното криптирање (како што е RSA) е безбедно, но бавно. Симетричното криптирање е брзо, но дистрибуцијата на клучеви е гломазна. TLS користи стратегија во „два чекора“ - прво асиметрична безбедна размена на клучеви, а потоа симетрична шема за ефикасно криптирање на податоците.
2. Еволуција на алгоритмот и подобрување на безбедноста
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 спојување итн. за да ја подобрите целокупната HTTPS заштита;
○ Редовно ажурирајте го и прегледувајте го синџирот на сертификати за да ја осигурите валидноста и интегритетот на синџирот на доверба.
Заклучок и мисли: Дали вашиот бизнис е навистина безбеден?
Од HTTP со обичен текст до целосно шифриран HTTPS, безбедносните барања еволуирале зад секое надградување на протоколот. Како камен-темелник на шифрираната комуникација во современите мрежи, TLS постојано се подобрува за да се справи со сè посложената средина за напади.
Дали вашиот бизнис веќе користи HTTPS? Дали вашата крипто конфигурација е во согласност со најдобрите практики во индустријата?
Време на објавување: 22 јули 2025 година
