SSL/TLS — шта је то, протоколи и принцип рада шифровања

Шта је SSL/TLS?

SSL (Secure Sockets Layer) — протокол који је развила компанија Netscape 1995. године за заштиту веб саобраћаја. Прва верзија SSL 1.0 никада није објављена, SSL 2.0 (1995) и SSL 3.0 (1996) су коришћени до почетка 2000-их, али су садржали критичне рањивости. На место SSL-а дошао је TLS (Transport Layer Security) — побољшана верзија стандардизована од стране IETF-а. TLS 1.0 (1999) је заснован на SSL 3.0, а касније верзије TLS 1.1 (2006), TLS 1.2 (2008) и TLS 1.3 (2018) су постепено одступале од оригиналне архитектуре, додајући нове алгоритме шифровања и отклањајући рањивости. Данас се SSL сматра застарелим и сви модерни системи користе TLS, иако се из инерције оба протокола често помињу заједно као SSL/TLS.

Историја настанка протокола

Историја SSL/TLS почела је са потребом за сигурним преносом података у раном вебу. Године 1994, компанија Netscape је развила SSL 1.0 за свој прегледач Navigator, али протокол никада није објављен због озбиљних сигурносних проблема. SSL 2.0 је изашао 1995. године и коришћен је у пракси, али је садржао бројне рањивости: недостатак заштите од Man-in-the-Middle напада, слабе алгоритме шифровања и рањивост на truncation нападе. SSL 3.0 (1996) је исправио већину проблема, али је до 2014. године откривена рањивост POODLE, након чега је IETF званично прогласио све верзије SSL-а застарелим. TLS 1.0–1.3 су сукцесивно побољшавали криптографску чврстину, перформансе и поверљивост, при чему је TLS 1.3 смањио handshake са два round-trip-а на један, што је критично за мобилне апликације са нестабилном везом.

Како ради SSL/TLS Handshake

Handshake — процес успостављања сигурне везе између клијента и сервера. Састоји се од неколико узастопних корака током којих стране усаглашавају верзију протокола, бирају алгоритме шифровања, размењују кључеве и аутентификују једна другу. У TLS 1.3, handshake траје само једну мрежну интеракцију (1-RTT), док је у TLS 1.2 било потребно две (2-RTT).

Први корак: клијент шаље ClientHello — поруку која садржи листу подржаних TLS верзија, скуп шифара (cipher suites) и случајни број. Сервер одговара ServerHello-ом са изабраном верзијом и шифром, својим X.509 сертификатом и дигиталним потписом. Клијент проверава сертификат кроз ланац сертификационих тела (CA), генерише сесијски кључ и шаље га шифрованог јавним кључем сервера из сертификата. Након потврде од стране сервера, почиње сигурни пренос података. Цео handshake се изводи за 1–3 милисекунде на модерним уређајима, што га чини невидљивим за корисника.

X.509 сертификати и ланац поверења

Основа TLS аутентификације је инфраструктура јавних кључева (PKI) изграђена на сертификатима формата X.509. Сваки сертификат садржи: назив домена (Common Name или Subject Alternative Name), јавни кључ сервера, назив издаваоца (Certificate Authority), период важења и дигитални потпис CA. Клијент проверава сертификат сервера кроз ланац поверења: од сертификата сервера до коренског CA, чији је сертификат уграђен у оперативни систем. На Android уређајима, коренски сертификати се чувају у системском складишту које се ажурира путем Google Play Services-а; у iOS-у — путем iOS Updates-а. При нарушавању било које карике у ланцу (истекао сертификат, неусаглашеност домена, непознати CA), клијент прекида везу. За самопотписане сертификате (коришћене у развоју) потребно је експлицитно поверење — у Android-у путем Network Security Config-а, у iOS-у путем NSExceptionDomains-а у Info.plist-у. Процес валидације ланца сертификата такође укључује проверу статуса опозива путем CRL (Certificate Revocation List) или OCSP (Online Certificate Status Protocol), иако се на мобилним уређајима OCSP захтеви често прескачу ради убрзавања везе — ово је компромис између сигурности и перформанси који архитекте треба да узму у обзир.

SSL vs TLS: кључне разлике

Иако се термини SSL и TLS често користе као синоними, постоје принципијелне техничке разлике између њих које утичу на сигурност и перформансе мобилних апликација.

Главна разлика TLS 1.3 у односу на претходнике — обавезна употреба Perfect Forward Secrecy (PFS) кроз протокол ECDHE. То значи да чак и ако нападач добије приступ приватном кључу сервера, неће моћи да дешифрује раније пресретнути саобраћај. За мобилне апликације, где је провала сервера реална претња, TLS 1.3 са PFS-ом је обавезан сигурносни захтев.

Познате рањивости старих верзија

Застареле верзије SSL и TLS имају документоване рањивости које их чине неподобним за продукциону употребу. POODLE (CVE-2014-3566) напада SSL 3.0 кроз padding oracle, омогућавајући дешифровање сесијског колачића у 256 захтева. BEAST (CVE-2011-3389) искоришћава рањивост TLS 1.0 у CBC режиму кроз предвидљиви IV. Heartbleed (CVE-2014-0160) — није рањивост протокола, већ грешка у имплементацији OpenSSL-а која омогућава читање меморије сервера: према Netcraft-у, 2014. године било је рањиво више од 500 хиљада сервера. Почев од Android 10 (API 29) и iOS 13, сви наведени протоколи су искључени на нивоу система. Ипак, програмери треба да провере конфигурацију сервера кроз SSL Labs Test (qualys.com) пре покретања апликације како би се уверили да нема застарелих cipher suites и да је TLS 1.3 подржан.

Како SSL/TLS штити податке у мобилним апликацијама

У мобилним апликацијама, TLS штити податке на три нивоа: шифровање садржаја (нико осим сервера не може да чита податке), провера интегритета (подаци не могу бити измењени у транзиту) и аутентификација сервера (клијент је сигуран да се повезује са правим сервером). Аутентификација је посебно критична: без ње, нападач може да замени сервер путем DNS-спуфинга или лажне Wi-Fi приступне тачке.

Према истраживању Google Play Protect (2024), 76% Android апликација користи TLS исправно са провером сертификата. Преосталих 24% прави грешке: искључује проверу сертификата за тестирање (и заборавља да је укључи у продукцији), користи самопотписане сертификате без валидације или дозвољава застареле протоколе SSL 3.0 и TLS 1.0. Apple App Transport Security (ATS) у iOS-у захтева TLS 1.2 најмање од 2017. године, а од iOS 15 подразумевано користи TLS 1.3 за све мрежне захтеве. За додатну заштиту препоручује се и имплементација Certificate Pinning-а — везивање за конкретан сертификат сервера.

Имплементација SSL/TLS-а у мобилним апликацијама

Размотримо пример подешавања сигурне HTTPS везе у Android-у коришћењем OkHttp-а — једне од најпопуларнијих библиотека за рад са мрежом. Исправна конфигурација укључује принудну употребу TLS 1.3 и проверу сертификата.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()

У овом примеру ограничавамо скуп подржаних TLS верзија само на протоколе 1.3 и 1.2, искључујући застареле TLS 1.0/1.1. Cipher suites се бирају из модерних алгоритама са AEAD режимом и обавезном Perfect Forward Secrecy. HostnameVerifier проверава подударање имена хоста са сертификатом. За iOS, аналогно подешавање се врши кроз конфигурацију URLSession-а са параметром tlsMinimumSupportedProtocolVersion, где се наводи .TLSv13. Додатно, у iOS-у се може поставити tlsMaximumSupportedProtocolVersion за ограничавање горње границе верзија — ово је корисно за компатибилност са старим серверима који још нису прешли на TLS 1.3. Таква конфигурација гарантује максимални ниво сигурности при преносу података у мобилној апликацији.