HTTP/HTTPS: nedir, veri aktarım protokolleri ve TLS şifrelemesi

HTTP ve HTTPS Nedir?

HTTP (HyperText Transfer Protocol), World Wide Web'de hiper metin belgelerini ve diğer verileri aktarmak için tasarlanmış OSI modelinin uygulama katmanı protokolüdür. Tim Berners-Lee tarafından 1989'da geliştirilen HTTP, HTTP/0.9'dan (yalnızca GET istekleri ve HTML yanıtları) modern HTTP/2 ve HTTP/3'e kadar birkaç sürümden geçmiştir. Protokol, istek-yanıt modeline göre çalışır: istemci sunucuya bir istek gönderir, sunucu bunu işler ve bir yanıt döndürür.

HTTPS (HTTP Secure), TLS (Transport Layer Security) aracılığıyla bir şifreleme katmanı ekleyen HTTP protokolünün bir uzantısıdır. HTTPS ayrı bir protokol değildir — HTTP ve TLS'nin birleşimidir. HTTPS üzerinden iletilen veriler istemci tarafında şifrelenir ve sunucuda çözülür, bu da onları ele geçirme ve tahrif etmeye karşı erişilemez kılar. HTTPS ayrıca SSL/TLS sertifikaları aracılığıyla sunucu kimlik doğrulaması sağlayarak istemcinin bir saldırgana değil gerçek sunucuya bağlandığını garanti eder.

HTTP ve HTTPS arasındaki temel fark güvenliktir. HTTP, verileri düz metin olarak iletir: istemci ve sunucu arasındaki herhangi bir ağ düğümü, bir isteğin veya yanıtın içeriğini okuyabilir. HTTPS, URL, başlıklar ve istek gövdesi dahil tüm içeriği şifreler ve yalnızca sunucunun IP adresi ile bağlantı noktasını görünür bırakır. Genel Wi-Fi ağları üzerinden çalışan mobil uygulamalar için HTTPS zorunlu bir güvenlik gereksinimidir.

HTTP Nasıl Çalışır

HTTP, TCP/IP üzerinde çalışan durumsuz (stateless) bir protokoldür. İstemci, sunucuyla bir TCP bağlantısı kurar (genellikle HTTP için 80 veya HTTPS için 443 numaralı portta), bir HTTP isteği gönderir, bir HTTP yanıtı alır ve bağlantıyı kapatır (HTTP/1.1'de bağlantı yeniden kullanılabilir). İstemci ve sunucu arasındaki her etkileşim bir istek ve yanıttan oluşur. Durumsuz olması, sunucunun önceki istemci istekleri hakkında bilgi saklamadığı anlamına gelir — her istek bağımsız olarak işlenir.

HTTP etkileşim süreci aşağıdaki adımları içerir:

• DNS çözümlemesi — tarayıcı veya istemci, DNS aracılığıyla alan adını IP adresine dönüştürür
• TCP el sıkışması — üç yönlü el sıkışma (SYN, SYN-ACK, ACK) ile TCP bağlantısı kurulur
• TLS el sıkışması — HTTPS için ayrıca şifreli bir bağlantı kurulur (sertifika ve anahtar değişimi)
• HTTP isteği — istemci yöntemi, URL'yi, başlıkları ve isteğe bağlı olarak istek gövdesini gönderir
• HTTP yanıtı — sunucu durum kodu, başlıklar ve yanıt gövdesini döndürür

HTTP'nin önemli bir özelliği yöntem güçsüzlüğü (idempotency)dir. GET, HEAD, PUT, DELETE ve OPTIONS güçsüzdür: aynı isteğin tekrar tekrar yürütülmesi, ilk yürütmeden sonra sunucu durumunu değiştirmez. POST, PATCH ve CONNECT güçsüz değildir — her çağrı yeni bir kaynak oluşturabilir veya durumu değiştirebilir. Mobil geliştirme için güçsüzlüğü anlamak kritiktir: bir ağ hatası nedeniyle isteği yeniden gönderirken, istemci isteği tekrarlamanın güvenli olup olmadığını bilmelidir.

HTTPS ve TLS Şifrelemesi

HTTPS, iletilen verileri korumak için kriptografik protokol TLS'yi (Transport Layer Security) kullanır. TLS, 1995 yılında Netscape tarafından geliştirilen SSL'nin (Secure Sockets Layer) halefidir. SSL 2.0 ve 3.0 sürümleri eski ve güvensiz kabul edilir; modern sürümler TLS 1.2 (2008'de piyasaya sürüldü) ve TLS 1.3 (2018'de piyasaya sürüldü) her yerde kullanılır. Özellikle TLS 1.3, bağlantı kurulum süresini 2 round-trip'ten 1'e düşürerek mobil cihazlarda yüklemeyi önemli ölçüde hızlandırır.

TLS el sıkışma süreci aşağıdaki aşamaları içerir:

• Client Hello — istemci desteklenen TLS sürümlerinin ve şifre paketlerinin listesini gönderir
• Server Hello — sunucu TLS sürümünü ve şifre paketini seçer, SSL/TLS sertifikasını gönderir
• Sertifika doğrulaması — istemci, kök CA'ya kadar olan güven zinciri aracılığıyla sunucu sertifikasını doğrular
• Anahtar değişimi — istemci ve sunucu paylaşılan bir gizli anahtar (oturum anahtarı) oluşturur
• Şifre değişimi — her iki taraf da şifreli iletişime geçişi onaylar

SSL/TLS sertifikası doğrulaması güvenlik için kritik bir adımdır. İstemci, sertifikanın: süresinin dolmadığını, güvenilir bir Sertifika Yetkilisi (CA) tarafından imzalandığını, URL'deki alan adıyla eşleştiğini ve iptal edilmediğini (CRL veya OCSP aracılığıyla) kontrol eder. Mobil uygulamalarda, Sertifika Sabitleme (Certificate Pinning) kullanılması önerilir — belirli bir sunucu sertifikasına veya ortak anahtara bağlama. Bu, bir CA'nın ele geçirilmesi durumunda bile MITM saldırılarını önler. Ancak sabitleme dikkat gerektirir: sertifika değiştiğinde, uygulamanın önceden güncellenmesi gerekir.

HTTP İstek ve Yanıt Yapısı

Bir HTTP isteği üç bölümden oluşur: istek satırı, başlıklar ve isteğe bağlı bir gövde. İstek satırı HTTP yöntemini, istek URL'sini ve HTTP sürümünü içerir. Başlıklar meta bilgileri iletir: içerik türü, kimlik doğrulama belirteçleri, önbellek ayarları. Gövde yalnızca veri ileten yöntemlerde (POST, PUT, PATCH) bulunur ve GET ile DELETE'te bulunmaz.

Bir REST API'sine HTTP isteği örneği:

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

{
    "name": "Anna",
    "email": "anna@example.com"
}

Bir HTTP yanıtı benzer bir yapıya sahiptir: HTTP sürümü ve durum kodu içeren bir durum satırı, başlıklar ve gövde. Durum kodu, istek işlemenin sonucunu belirleyen üç basamaklı bir sayıdır. Yanıt başlıkları Content-Type, Content-Length, Cache-Control, Set-Cookie ve diğerlerini içerir. Yanıt gövdesi, Content-Type'da belirtilen biçimde (genellikle API'ler için JSON, web sayfaları için HTML, medya içeriği için görseller) istenen verileri içerir.

Başlıklar HTTP işleyişinde kritik bir rol oynar. Content-Type ve Accept veri biçimini kontrol eder. Authorization erişim belirteçlerini iletir. Cache-Control önbellekleme yönetir. CORS başlıkları (Access-Control-Allow-Origin) tarayıcılarda diğer alan adlarından erişimi kontrol eder. User-Agent istemci uygulamasını tanımlar. Mobil uygulamalar için önbellek kontrol başlıkları özellikle önemlidir — iletilen veri miktarını azaltmaya ve zayıf sinyalde performansı iyileştirmeye yardımcı olurlar.

HTTP Durum Kodları

HTTP durum kodları, ilk basamakla belirtilen beş sınıfa ayrılır: 1xx (bilgilendirme), 2xx (başarı), 3xx (yönlendirme), 4xx (istemci hatası), 5xx (sunucu hatası). Bu kodları anlamak, bir mobil uygulamada yanıtları doğru şekilde işlemek için gereklidir: 2xx başarı anlamına gelir ve veriler görüntülenebilir, 4xx istekte bir sorun olduğunu belirtir (kullanıcıya hata gösterilir), 5xx bir sunucu sorununu belirtir (istek daha sonra tekrarlanır).

Mobil uygulamalar için 401 Unauthorized kodunun işlenmesi özellikle önemlidir. Bu kod alındığında, istemci bir Yenileme Belirteci (Refresh Token) aracılığıyla erişim belirtecini yenilemeyi denemeli ve orijinal isteği tekrarlamalıdır. Belirteç yenileme de 401 döndürürse, kullanıcı giriş ekranına yönlendirilmelidir. Bu mantık genellikle bir Interceptor (OkHttp) veya ağ istemcisinin ara katmanında uygulanır.

HTTP/1.1, HTTP/2 ve HTTP/3

HTTP/1.1, 1999'da yayımlanmış, hala yaygın olarak kullanılan bir protokol sürümüdür. Ana dezavantajı, head-of-line blocking'dir: aynı sunucuya yapılan istekler sırayla yürütülür, her biri bir öncekinin tamamlanmasını bekler. Bu sınırlamayı aşmak için tarayıcılar aynı alan adına 6-8 paralel TCP bağlantısı açar, bu da sunucu yükünü ve bellek tüketimini artırır. HTTP/1.1 ayrıca başlıkları düz metin olarak iletir ve sunucu itmesini (server push) desteklemez.

HTTP/2 (2015), çoğullama (multiplexing) yoluyla blokaj sorununu çözer — birden çok veri akışı tek bir TCP bağlantısı üzerinden aynı anda iletilir. Sunucu, istemci talep etmeden önce kaynakları istemciye gönderebilir (server push). HTTP/2 ayrıca HPACK aracılığıyla başlıkları sıkıştırarak iletilen veri miktarını azaltır. Mobil uygulamalar için HTTP/2 özellikle yararlıdır: tek bir bağlantı birden çok bağlantının yerini alır, TLS el sıkışma süresini ve pil tüketimini azaltır.

HTTP/3 (2022), protokolün TCP yerine QUIC (Quick UDP Internet Connections) kullanan en son sürümüdür. QUIC, UDP üzerinde çalışarak taşıma protokolü seviyesinde head-of-line blocking sorununu ortadan kaldırır. HTTP/3, bağlantı kurulum süresini en iyi durumda 0 round-trip'e (tekrarlanan bağlantılarda) ve ilk bağlantıda 1 round-trip'e düşürür, bu da 2-3 round-trip'i olan HTTP/2'den önemli ölçüde daha hızlıdır. Mobil cihazlar için HTTP/3, Wi-Fi ve mobil ağlar arasında geçiş yaparken özellikle etkilidir — QUIC bir IP adresi yerine bir bağlantı tanımlayıcısı kullandığından bağlantı kesilmez.

Mobil Geliştirmede HTTPS

Mobil uygulamalarda HTTPS kullanımı bir öneri değil, zorunlu bir gerekliliktir. Android 9 (API 28) ve iOS 9'dan (ATS — App Transport Security) başlayarak, tüm ağ istekleri varsayılan olarak HTTPS kullanmalıdır. HTTP istekleri sistem tarafından engellenir ve bunlara izin vermek, uygulama yapılandırmasında açık bir istisna gerektirir. Google Play Store ve App Store, parolalar, belirteçler ve kişisel veriler dahil olmak üzere hassas verileri HTTP üzerinden ileten uygulamaları reddeder.

Bir Android mobil uygulamasında HTTPS yapılandırması şunları içerir:

<!-- AndroidManifest.xml — ağ isteği izni -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — HTTPS yapılandırması -->
<?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'ta benzer yapılandırma, NSAppTransportSecurity anahtarıyla Info.plist aracılığıyla yapılır. Mobil uygulamalarda HTTPS trafiğinde hata ayıklamak için proxy araçları kullanılır: Charles Proxy, Proxyman veya mitmproxy. Bunlar, cihaza güvenilir bir SSL sertifikası yüklenmesini gerektirir. Üretim yapılarında hata ayıklama özellikleri devre dışı bırakılmalı ve Sertifika Sabitleme'nin doğru şekilde yapılandırıldığı doğrulanmalıdır. Android'de CertificatePinner ile OkHttp veya iOS'ta SecTrustEvaluate ile TrustManager kullanmak, sabitlemeyi uygulamak için standart yaklaşımlardır.

Mobil geliştirmede HTTPS'nin önemli bir güvenlik yönü SSL Sabitleme (SSL Pinning)dir. Sabitleme olmadan uygulama, bilinen bir CA tarafından imzalanmış herhangi bir sertifikaya güvenir. CA ele geçirilirse, bir saldırgan uygulamanın trafiğini ele geçirebilir. Sabitleme, uygulamayı belirli bir sunucu sertifikasına veya ortak anahtara bağlar. Sunucu sertifikası değiştiğinde, bir uygulama güncellemesi yayımlanmalıdır, bu nedenle sabitleme bir marjla planlanır — üst düzey bir CA sertifikasına bağlama veya birden çok yedek anahtar kullanma.