HTTP/HTTPS: какво е това, протоколи за предаване на данни и TLS криптиране

Какво са HTTP и HTTPS?

HTTP (HyperText Transfer Protocol) — е протокол на приложния слой на модела OSI, предназначен за предаване на хипертекстови документи и други данни в World Wide Web. Разработен от Тим Бърнърс-Лий през 1989 г., HTTP преминава през няколко версии: от HTTP/0.9 (само GET заявки и HTML отговори) до съвременните HTTP/2 и HTTP/3. Протоколът работи по схемата заявка-отговор: клиентът изпраща заявка към сървъра, сървърът я обработва и връща отговор.

HTTPS (HTTP Secure) — е разширение на протокола HTTP, което добавя слой на криптиране чрез TLS (Transport Layer Security). HTTPS не е отделен протокол — това е комбинация от HTTP и TLS. Данните, предавани чрез HTTPS, се криптират от страна на клиента и се декриптират на сървъра, което ги прави недостъпни за прихващане и фалшифициране. HTTPS също така осигурява удостоверяване на сървъра чрез SSL/TLS сертификати, гарантирайки, че клиентът се свързва с истинския сървър, а не с нападател.

Ключовата разлика между HTTP и HTTPS е сигурността. HTTP предава данни в открит вид: всеки мрежов възел между клиента и сървъра може да прочете съдържанието на заявката или отговора. HTTPS криптира цялото съдържание, включително URL, хедъри и тялото на заявката, оставяйки видими само IP адреса на сървъра и порта на свързване. За мобилни приложения, работещи чрез обществени Wi-Fi мрежи, HTTPS е задължително изискване за сигурност.

Как работи HTTP

HTTP — е протокол без състояние (stateless), работещ върху TCP/IP. Клиентът установява TCP връзка със сървъра (обикновено на порт 80 за HTTP или 443 за HTTPS), изпраща HTTP заявка, получава HTTP отговор и затваря връзката (в HTTP/1.1 връзката може да бъде повторно използвана). Всяко взаимодействие между клиент и сървър се състои от заявка и отговор. Без състояние означава, че сървърът не съхранява информация за предишни заявки на клиента — всяка заявка се обработва независимо.

Процесът на HTTP взаимодействие включва следните стъпки:

• DNS резолюция — браузърът или клиентът преобразува домейн името в IP адрес чрез DNS
• TCP ръкостискане — TCP връзката се установява чрез тристранно ръкостискане (SYN, SYN-ACK, ACK)
• TLS ръкостискане — за HTTPS допълнително се установява криптирана връзка (обмен на сертификати и ключове)
• HTTP заявка — клиентът изпраща метод, URL, хедъри и опционално тяло на заявката
• HTTP отговор — сървърът връща код на състоянието, хедъри и тяло на отговора

Важна характеристика на HTTP е идемпотентността на методите. GET, HEAD, PUT, DELETE и OPTIONS са идемпотентни: многократното изпълнение на една и съща заявка не променя състоянието на сървъра след първото изпълнение. POST, PATCH и CONNECT не са идемпотентни — всяко извикване може да създаде нов ресурс или да промени състоянието. За мобилното разработване разбирането на идемпотентността е критично: при повторно изпращане на заявка поради мрежова грешка, клиентът трябва да знае дали е безопасно да повтори заявката.

HTTPS и TLS криптиране

HTTPS използва криптографския протокол TLS (Transport Layer Security) за защита на предаваните данни. TLS — наследник на SSL (Secure Sockets Layer), който е разработен от компанията Netscape през 1995 г. Версиите SSL 2.0 и 3.0 се считат за остарели и несигурни; съвременните версии TLS 1.2 (пуснат през 2008 г.) и TLS 1.3 (пуснат през 2018 г.) се използват широко. TLS 1.3, по-специално, намалява времето за установяване на връзка от 2 round-trips на 1, което значително ускорява зареждането на мобилни устройства.

Процесът на TLS ръкостискане (handshake) включва следните етапи:

• Client Hello — клиентът изпраща списък на поддържаните TLS версии и набори от шифри
• Server Hello — сървърът избира TLS версия и набор от шифри, изпраща своя SSL/TLS сертификат
• Проверка на сертификата — клиентът проверява сертификата на сървъра чрез веригата на доверие до коренния CA
• Обмен на ключове — клиентът и сървърът генерират общ таен ключ (сесиен ключ)
• Switch Cipher — двете страни потвърждават прехода към криптирана връзка

Проверката на SSL/TLS сертификата — критичен етап за сигурността. Клиентът проверява дали сертификатът: не е изтекъл, е подписан от доверен сертификационен орган (CA), съответства на домейна в URL и не е оттеглен (чрез CRL или OCSP). В мобилните приложения се препоръчва използването на Certificate Pinning — привързване към конкретен сертификат или публичен ключ на сървъра. Това предотвратява MITM атаки дори в случай на компрометиране на CA. Въпреки това, pinning изисква внимание: при смяна на сертификата, приложението трябва да бъде предварително актуализирано.

Структура на HTTP заявка и отговор

HTTP заявката се състои от три части: начален ред (request line), хедъри (headers) и опционално тяло (body). Началният ред съдържа HTTP метод, URL на заявката и версия на HTTP. Хедърите предават метаинформация: тип на съдържанието, удостоверителни токени, настройки за кеширане. Тялото присъства само в методите, предаващи данни (POST, PUT, PATCH), и отсъства в GET и DELETE.

Пример за HTTP заявка към REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Анна",
    "email": "anna@example.com"
}

HTTP отговорът има аналогична структура: начален ред с версия на HTTP и код на състоянието, хедъри и тяло. Кодът на състоянието — трицифрено число, определящо резултата от обработката на заявката. Хедърите на отговора включват Content-Type, Content-Length, Cache-Control, Set-Cookie и други. Тялото на отговора съдържа поисканите данни във формата, посочен в Content-Type (обикновено JSON за API, HTML за уеб страници, изображения за медийно съдържание).

Хедърите играят критична роля в работата на HTTP. Content-Type и Accept управляват формата на данните. Authorization предава токени за достъп. Cache-Control управлява кеширането. CORS хедърите (Access-Control-Allow-Origin) контролират достъпа от други домейни в браузърите. User-Agent идентифицира клиентското приложение. За мобилните приложения хедърите за управление на кеширането са особено важни — те намаляват обема на предаваните данни и подобряват работата при слаб сигнал.

Кодове на състоянието на HTTP

Кодовете на състоянието на HTTP се групират в пет класа, обозначени с първата цифра: 1xx (информационни), 2xx (успех), 3xx (пренасочване), 4xx (грешка на клиента), 5xx (грешка на сървъра). Разбирането на тези кодове е необходимо за правилната обработка на отговорите в мобилно приложение: 2xx означава успех и данните могат да се покажат, 4xx показва проблем в заявката (трябва да се покаже грешка на потребителя), 5xx — проблем на сървъра (заявката трябва да се повтори по-късно).

За мобилните приложения обработката на код 401 Unauthorized има особено значение. При получаване на този код, клиентът трябва да опита да обнови токена за достъп чрез Refresh Token и да повтори оригиналната заявка. Ако обновяването на токена също върне 401, потребителят трябва да бъде пренасочен към екрана за вход. Тази логика обикновено се имплементира в Interceptor (OkHttp) или в middleware слоя на мрежовия клиент.

HTTP/1.1, HTTP/2 и HTTP/3

HTTP/1.1, публикуван през 1999 г., все още остава широко използвана версия на протокола. Основният му недостатък — head-of-line blocking: заявките към един и същ сървър се изпълняват последователно, всяка следваща чака завършването на предходната. За заобикаляне на това ограничение, браузърите отварят 6–8 паралелни TCP връзки към един и същ домейн, което увеличава натоварването на сървъра и консумацията на памет. HTTP/1.1 също предава хедърите в некриптиран вид и не поддържа server push.

HTTP/2 (2015) решава проблема с блокирането чрез мултиплексиране — множество потоци от данни се предават едновременно по една TCP връзка. Сървърът може да изпраща ресурси на клиента, преди клиентът да ги поиска (server push). HTTP/2 също компресира хедърите чрез HPACK, което намалява обема на предаваните данни. За мобилните приложения HTTP/2 е особено полезен: една връзка замества няколко, намалявайки времето за TLS ръкостискане и консумацията на батерия.

HTTP/3 (2022) — най-новата версия на протокола, която използва QUIC (Quick UDP Internet Connections) вместо TCP. QUIC работи върху UDP, елиминирайки проблема head-of-line blocking на ниво транспортен протокол. HTTP/3 намалява времето за установяване на връзка до 0 round-trips в най-добрия случай (при повторни свързвания) и до 1 round-trip при първо свързване, което е значително по-бързо от HTTP/2 с неговите 2–3 round-trips. За мобилни устройства HTTP/3 е особено ефективен при превключване между Wi-Fi и мобилна мрежа — връзката не се прекъсва, тъй като QUIC използва идентификатор на връзката, а не IP адрес.

HTTPS в мобилното разработване

Използването на HTTPS в мобилните приложения — не е препоръка, а задължително изискване. Започвайки от Android 9 (API 28) и iOS 9 (ATS — App Transport Security), всички мрежови заявки по подразбиране трябва да използват HTTPS. HTTP заявките се блокират от системата и за разрешаването им е необходимо изрично изключение в конфигурацията на приложението. Google Play Store и App Store отхвърлят приложения, предаващи поверителни данни чрез HTTP, включително пароли, токени и лични данни.

Конфигурацията на HTTPS в мобилно приложение на Android включва:

<!-- AndroidManifest.xml — разрешение за мрежови заявки -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — HTTPS конфигурация -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

На iOS аналогична конфигурация се извършва чрез Info.plist с ключа NSAppTransportSecurity. За отстраняване на грешки в HTTPS трафика на мобилни приложения се използват прокси инструменти: Charles Proxy, Proxyman или mitmproxy. Те изискват инсталиране на доверен SSL сертификат на устройството. В продукционните версии трябва да се изключи възможността за отстраняване на грешки и да се провери дали Certificate Pinning е конфигуриран правилно. Използването на OkHttp на Android с неговия CertificatePinner или TrustManager на iOS с SecTrustEvaluate — стандартни подходи за имплементиране на pinning.

Важен аспект на сигурността на HTTPS в мобилното разработване — SSL Pinning. Без pinning приложението се доверява на всеки сертификат, подписан от известен CA. Ако CA бъде компрометиран, нападател може да прихване трафика на приложението. Pinning привързва приложението към конкретен сертификат или публичен ключ на сървъра. При смяна на сертификата на сървъра трябва да се пусне актуализация на приложението, затова pinning се планира с резерв — привързва се към сертификата на по-горния CA или се използват няколко резервни ключа.