- Konu sahibi
- #1
SSL offloading nedir?
SSL offloading, HTTPS bağlantısının şifre çözme ve şifreleme yükünü web sunucusundan alıp yük dengeleyici, reverse proxy veya CDN gibi öndeki bir bileşene devretme yöntemidir. Kullanıcı ile bu bileşen arasındaki bağlantı HTTPS olarak kalır; öndeki bileşen TLS sertifikasını kullanarak trafiği çözer ve isteği arka uç sunucusuna HTTP veya yeniden HTTPS üzerinden iletir.
Buradaki “SSL” ifadesi günlük kullanımda TLS bağlantısını da kapsar. Amaç yalnızca işlemci yükünü azaltmak değildir. Sertifikaları tek noktadan yönetmek, birden fazla arka uç sunucusuna dağıtımı kolaylaştırmak ve HTTP güvenlik politikalarını merkezi uygulamak da offloading kullanım nedenleridir.
Nasıl çalışır?
Varsayımsal yapıda kullanıcı
https://example.com adresine bağlanır. DNS kaydı isteği bir reverse proxy veya yük dengeleyiciye yönlendirir. TLS sertifikası bu öndeki bileşende bulunur ve istemciyle şifreli oturum burada kurulur. Daha sonra istek, örneğin özel ağdaki bir uygulama sunucusuna iletilir.Üç yaygın aktarım modeli vardır:
- HTTP ile arka uca aktarım: İstemci ile proxy arasındaki bağlantı HTTPS, proxy ile sunucu arasındaki bağlantı HTTP'dir. Bu model yalnızca güvenilen ve dışarıdan erişilemeyen ağlarda düşünülmelidir; iç ağdaki trafik de hassassa uygun olmayabilir.
- HTTPS ile yeniden şifreleme: Proxy istemci bağlantısını sonlandırır, ardından arka uç sunucusuna yeni bir TLS bağlantısı açar. Her iki ağ bölümünün de şifrelenmesi gereken yapılarda kullanılabilir; istemci ile arka uç arasında kesintisiz tek TLS oturumu değildir. Proxy açık metni görebilir; arka uç sertifikasının doğrulanması ayrıca doğru yapılandırılmalıdır.
- TLS passthrough: Proxy TLS oturumunu çözmez, bağlantıyı arka uç sunucusuna aktarır. Bu teknik gerçek anlamda SSL offloading değildir; sertifika ve TLS işlemleri arka uçta kalır.
Offloading sonrasında uygulama, isteğin başlangıçta HTTPS üzerinden geldiğini doğru anlamalıdır. Proxy genellikle bunu güvenilir bir yönlendirme başlığıyla bildirir. Uygulama bu başlığı yalnızca gerçekten güvendiği proxy'lerden gelen isteklerde kabul etmelidir; aksi hâlde saldırganlar HTTPS kullanılmış gibi görünen sahte başlıklar gönderebilir.
Hangi modeli seçmeli?
Kararı yalnızca performansa göre vermeyin. Proxy ile arka uç arasındaki ağın güven düzeyi, mevzuat veya kurum politikaları, uygulamanın mutlak HTTPS gereksinimi ve sertifika yönetimi birlikte değerlendirilmelidir.
| Model | Proxy ile arka uç | Uygun olduğu durum |
|---|---|---|
| Offload | HTTP | İç ağ güvenilir ve ek şifreleme gerekmiyor |
| Re-encryption | HTTPS | İç trafikte de şifreleme ve sunucu doğrulaması gerekiyor |
| Passthrough | TLS oturumu aktarılır | TLS sonlandırmasının doğrudan uygulama sunucusunda olması gerekiyor |
Seçtiğiniz model, proxy'nin güvenlik politikasıyla uygulamanın beklediği protokolün aynı olmasını sağlamalıdır.
Uygulama ve kontrol adımları
- TLS sertifikasını ve özel anahtarını yalnızca TLS sonlandıracak proxy, yük dengeleyici veya CDN bileşenine yerleştirin. Anahtarın arka uçlara kopyalanması gerekmiyorsa kopyalamayın.
- Proxy'de arka uç hedefini ve kullanılacak aktarım protokolünü belirleyin. HTTP seçerseniz bunun yalnızca uygun güvenlik sınırları içindeki trafik için olduğunu doğrulayın; HTTPS seçerseniz arka uç sertifikası ve güven zinciri kontrolünü tamamlayın.
- Uygulamanın güvenilir proxy listesini tanımlayın ve HTTPS durumu, istemci IP'si ile ana makine bilgisini proxy'nin kullandığı başlıklardan doğru biçimde almasını sağlayın.
- HTTP'den HTTPS'e yönlendirmeyi proxy veya uygulamada istemcinin gerçek şemasını dikkate alarak uygulayın. Uygulama yönlendirecekse güvenilir proxy başlığı önce işlenmelidir. Proxy bilgisi okunmuyorsa uygulama sürekli yönlendirme döngüsüne girebilir.
- Giriş sayfası, oturum açma, dosya yükleme ve normal sayfa isteklerini test edin. Tarayıcı geliştirici araçlarında istemci bağlantısının HTTPS olduğunu; uygulama günlüklerinde ise doğru istemci IP'si ve protokolün görüldüğünü kontrol edin.
- Başarısız durumda önce TLS sertifikası, proxy hedefi, güvenlik duvarı erişimi, güvenilir proxy ayarı ve arka uç protokolünü ayrı ayrı kontrol edin. Sertifika hatası istemcideyse sorun genellikle proxy tarafında; 502 veya benzeri bir geçit hatasıysa arka uç erişimi ya da protokol uyumsuzluğu incelenmelidir.
Başarılı sonuçta kullanıcı HTTPS ile bağlanır, uygulama güvenilir proxy bilgisinden özgün isteğin şemasını doğru belirler ve seçilen modele göre proxy ile arka uç arasındaki trafik korunur. Sonraki adım, arka uç sunucusuna doğrudan internetten erişilemediğini ve yalnızca beklenen proxy kaynaklarından bağlantı kabul edildiğini doğrulamaktır.
Sık yapılan hatalar
En yaygın hata, proxy ile arka uç arasındaki bağlantıyı otomatik olarak güvenli varsaymaktır. Dış bağlantının HTTPS olması iç bağlantının da HTTPS olduğu anlamına gelmez. Bir diğer hata, güvenilmeyen istemcilerden gelen protokol veya IP başlıklarını doğrudan uygulamaya aktarmaktır. Bu durum yanlış yönlendirme, hatalı günlükler ve erişim kontrolü sorunları oluşturabilir.
Ayrıca arka uçta HTTPS zorunluyken proxy'nin HTTP göndermesi, arka uçta HTTP zorunluyken proxy'nin HTTPS beklemesi veya uygulamanın proxy başlıklarını hiç tanımaması bağlantı hatalarına yol açabilir. Offloading, tek başına uygulama oturumlarını, çerezlerini veya arka uç ağını güvenli hâle getirmez; bunların her biri ayrıca doğru yapılandırılmalıdır.
Sık sorulan sorular
SSL offloading sertifikayı web sunucusundan kaldırmayı gerektirir mi?
TLS proxy üzerinde sonlandırılıyorsa istemci sertifikasının ve özel anahtarının arka uç web sunucusunda bulunması gerekmez. Ancak yeniden şifreleme veya passthrough kullanılıyorsa arka uçta ayrıca sertifika gerekebilir.
SSL offloading ile SSL termination aynı şey midir?
Çoğu mimaride aynı işlem kastedilir: TLS oturumunun proxy üzerinde sonlandırılması. “Offloading” işlem yükünün başka bileşene aktarılmasını, “termination” ise bağlantının o noktada çözülmesini vurgular; yeniden HTTPS bağlantısı kurulup kurulmadığı ayrıca belirtilmelidir.
