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 или се користи неколико резервних кључева.