Proxy üzerinden güvenli bağlantı, TLS handshake ile kurulur: istemci ile nihai sunucu (yapılandırmaya bağlı olarak origin sunucu ya da proxy'nin kendisi) kimlikleri doğrular ve şifreli bir iletişim kanalı oluşturmak için kriptografik parametreleri müzakere eder. Bu süreç, ağlar üzerinden haberleşen uygulamalar için verinin gizliliğini, bütünlüğünü ve özgünlüğünü güvence altına alır.
TLS handshake'i anlamak
Transport Layer Security (TLS) protokolü, internet iletişiminin güvenliği için temeldir. Taşıma katmanının (TCP) üzerinde çalışır ve uçtan uca şifreleme ile kimlik doğrulama sağlar. TLS handshake, uygulama verisi alışverişi başlamadan önce istemci ile sunucunun kriptografik parametrelerde anlaşıp güvenli bir oturum kurduğu ilk müzakere aşamasıdır.
TLS handshake'in başlıca amaçları şunlardır:
* Kimlik doğrulama: Dijital sertifikalar kullanarak sunucunun (ve isteğe bağlı olarak istemcinin) kimliğini doğrulamak.
* Anahtar değişimi: Simetrik şifreleme için paylaşılan gizli anahtar üzerinde güvenli biçimde anlaşmak.
* Cipher suite müzakeresi: Şifreleme, hashing ve anahtar değişimi algoritmalarını seçmek.
Doğrudan TLS handshake adımları
Proxy'siz doğrudan bir bağlantıda TLS handshake şu şekilde ilerler:
- Client Hello: İstemci,
Client Hellomesajı göndererek handshake'i başlatır. Bu mesaj şunları içerir:- Desteklenen TLS sürümleri.
- Desteklenen cipher suite listesi.
- Rastgele bir bayt dizisi (Client Random).
- Desteklenen sıkıştırma yöntemleri.
- Sanal barındırma için Server Name Indication (SNI).
- Server Hello: Sunucu bir
Server Hellomesajıyla yanıt verir ve şunları seçer:- Kullanılacak TLS sürümü.
- İstemcinin listesinden seçilen bir cipher suite.
- Rastgele bir bayt dizisi (Server Random).
- Certificate: Sunucu, açık anahtarını içeren ve bir Sertifika Otoritesi (CA) tarafından imzalanmış dijital sertifikasını gönderir. İstemci bu sertifikayı doğrular.
- Server Key Exchange (isteğe bağlı): Seçilen cipher suite gerektiriyorsa (örneğin ephemeral Diffie-Hellman için), sunucu anahtar değişimi parametrelerini gönderir.
- Server Hello Done: Sunucu, ilk handshake'teki kendi payını tamamladığını bildirir.
- Client Key Exchange: İstemci bir pre-master secret üretir, bunu sunucunun (sertifikasındaki) açık anahtarıyla şifreler ve sunucuya gönderir.
- Change Cipher Spec (istemci): İstemci, sonraki tüm mesajların müzakere edilen anahtarlar ve cipher suite ile şifreleneceğini belirten bir
Change Cipher Specmesajı gönderir. - Encrypted Handshake Message (istemci): İstemci, handshake bütünlüğünü doğrulamak için yeni oluşturulan simetrik anahtarla şifrelenmiş bir
Finishedmesajı gönderir. - Change Cipher Spec (sunucu): Sunucu kendi
Change Cipher Specmesajını gönderir. - Encrypted Handshake Message (sunucu): Sunucu, yine şifrelenmiş
Finishedmesajını gönderir. - Application Data: Artık her iki taraf şifreli uygulama verisi alışverişi yapabilir.
Proxy tipleri ve TLS handshake etkileşimi
Proxy'ler, çalışma moduna göre TLS handshake'in nasıl başlatıldığını ve işlendiğini değiştirir.
Forward proxy (araya girmeyen)
Forward proxy, dış kaynaklara erişmek isteyen istemciler için aracı görevi görür. HTTPS trafiğinde araya girmeyen bir forward proxy tipik olarak TCP tüneli gibi çalışır. İstemci, proxy'yi kullanmak üzere kendisini açıkça yapılandırır.
Mekanizma:
İstemci, origin sunucuya bir TCP tüneli kurmak için proxy'ye HTTP CONNECT isteği gönderir. Tünel kurulduktan sonra istemci ve origin sunucu, TLS handshake'i doğrudan bu tünelin içinden gerçekleştirir. Proxy şifreli baytları çözmeden iletir.
TLS handshake akışı:
1. İstemciden proxy'ye (TCP): İstemci proxy ile TCP bağlantısı kurar.
2. İstemcinin CONNECT isteği: İstemci, origin sunucunun hostname ve portunu belirterek proxy'ye HTTP CONNECT isteği gönderir (örneğin CONNECT example.com:443 HTTP/1.1).
3. Proxy'den origin'e (TCP): Proxy, belirtilen origin sunucuyla TCP bağlantısı kurar.
4. Proxy 200 OK: Origin sunucuya bağlantı başarılıysa proxy, istemciye HTTP/1.1 200 Connection established yanıtını verir.
5. İstemciden origin'e (tünel üzerinden TLS): İstemci, 200 OK yanıtını aldıktan sonra kurulan TCP tüneli üzerinden doğrudan origin sunucuyla standart TLS handshake'i başlatır.
6. Proxy yönlendirmesi: Proxy, istemci ile origin sunucu arasındaki sonraki tüm şifreli baytları şeffaf biçimde iletir. TLS handshake'e katılmaz ve trafiği çözmez.
Kod örneği: istemcinin CONNECT isteği
CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
Proxy-Connection: Keep-Alive
Proxy yanıtı
HTTP/1.1 200 Connection established
Reverse proxy (TLS sonlandırma)
Reverse proxy, bir veya birden çok origin sunucunun önünde konumlanır ve istemcilerin bu sunuculara yönelik isteklerini karşılar. HTTPS trafiğinde reverse proxy çoğu zaman TLS sonlandırma yapar.
Mekanizma:
Reverse proxy, istemcinin HTTPS isteğini alır, TLS bağlantısını sonlandırır, trafiği çözer ve ardından backend'deki origin sunucuya yeni bir bağlantı kurar (bu bağlantı TLS ile şifrelenmiş olabilir de olmayabilir de).
TLS handshake akışı:
1. İstemciden reverse proxy'ye (TLS handshake 1):
* İstemci, doğrudan reverse proxy ile standart bir TLS handshake gerçekleştirir.
* Reverse proxy, istemciye kendi dijital sertifikasını sunar.
* İstemci ile reverse proxy arasında güvenli, şifreli bir kanal kurulur.
2. Reverse proxy'de çözme: Reverse proxy, istemcinin isteğini deşifre eder.
3. Reverse proxy'den origin'e (TLS handshake 2 veya HTTP):
* Reverse proxy, ardından uygun backend origin sunucuya yeni bir bağlantı başlatır.
* Bu bağlantı düz HTTP (güvenilen iç ağlarda yaygındır) ya da başka bir TLS şifreli bağlantı (uçtan uca şifreleme için) olabilir.
* TLS kullanılıyorsa reverse proxy istemci gibi davranır ve kendi sertifikasını sunan origin sunucuyla ikinci bir TLS handshake gerçekleştirir.
4. Origin işleme: Origin sunucu isteği işler ve yanıtı reverse proxy'ye geri gönderir.
5. Reverse proxy'de şifreleme: İstemciyle bağlantı TLS ise, reverse proxy yanıtı istemciye bakan TLS oturum anahtarlarıyla yeniden şifreler.
6. Reverse proxy'den istemciye: Şifreli yanıt istemciye geri gönderilir.
Transparent proxy (MITM TLS araya girme)
Transparent proxy, istemci onu kullanmak üzere açıkça yapılandırılmadan trafiği yakalar. HTTPS için bu tipik olarak Man-in-the-Middle (MITM) yaklaşımını içerir.
Mekanizma:
İstemci bir HTTPS sitesine bağlanmaya çalıştığında transparent proxy bağlantıyı yakalar. İstenen alan adı için kendi root CA'sı tarafından imzalanmış sahte bir sertifika üretir. İstemci proxy ile TLS handshake yapar, proxy de origin sunucuyla ayrı bir TLS handshake gerçekleştirir. Bu, proxy'nin trafiği çözmesine, incelemesine ve gerekirse değiştirmesine olanak tanır. Sertifika hatası oluşmaması için proxy'nin root CA sertifikasının istemci tarafından güvenilir kabul edilmesi gerekir. Bu yöntem, güvenlik izleme amacıyla kurumsal ortamlarda yaygındır.
Proxy tipleri ve TLS etkileşiminin karşılaştırması
| Özellik | Doğrudan TLS bağlantısı | Forward proxy (araya girmeyen) | Reverse proxy (TLS sonlandırma) | Transparent proxy (MITM) |
|---|---|---|---|---|
| TLS handshake konumu | İstemci ↔ origin sunucu | İstemci ↔ origin sunucu (tünel üzerinden) | İstemci ↔ proxy; proxy ↔ origin sunucu | İstemci ↔ proxy; proxy ↔ origin sunucu |
| Proxy'de çözme | Yok | Hayır | Evet (istemci tarafı bağlantı) | Evet |
| Proxy sertifikası | Yok | Yok | Proxy'nin sertifikası | Proxy'nin dinamik olarak ürettiği sertifika |
| Uçtan uca şifreleme | Evet | Evet | Hayır (proxy düz metni görür) | Hayır (proxy düz metni görür) |
| İstemcinin farkındalığı | Doğrudan | Açıkça yapılandırılmış | Farkında değil (proxy'yi origin sanır) | Farkında değil (şeffaf yönlendirme) |
| Başlıca kullanım alanı | Standart web'de gezinme | İstemci tarafı erişim kontrolü, önbellekleme | Yük dengeleme, WAF, API gateway | Kurumsal güvenlik, içerik filtreleme |
Güvenlik değerlendirmeleri
Proxy üzerinden güvenli bağlantı kurarken birkaç güvenlik sonucu ortaya çıkar:
- Proxy'ye duyulan güven:
- Forward proxy: Proxy yalnızca şifreli veriyi tünellediği için veri gizliliği açısından güven gereksinimi asgaridir. Yine de proxy, bağlantı meta verilerini (IP'ler, alan adları) kaydedebilir.
- Reverse proxy / transparent proxy (MITM): Bu proxy'ler trafiği çözer. Şifresi çözülmüş hassas veriye erişimleri olduğundan proxy işletmecisine duyulan güven kritik hale gelir. Transparent MITM proxy'lerde istemcinin, proxy'nin root CA'sına açıkça güvenmesi gerekir; bu genellikle sertifikayı sistemin güven deposuna kurarak yapılır.
- Certificate pinning: Certificate pinning kullanan uygulamalar, reverse proxy veya transparent MITM proxy üzerinden bağlanırken hata verebilir; çünkü proxy, beklenen origin sunucu sertifikasından farklı bir sertifika sunar. Bu, MITM saldırılarını önlemek için tasarlanmış bir güvenlik özelliğidir.
- TLS sürümü ve cipher suite zorunluluğu: Proxy'ler belirli TLS sürümlerini ve cipher suite'leri zorunlu kılacak şekilde yapılandırılabilir; böylece istemci veya origin sunucu desteklese bile kullanımdan kaldırılmış ya da zayıf kriptografik protokoller engellenerek güvenlik artırılır.
- Loglama ve denetim: Özellikle reverse ve transparent tipteki proxy'ler, çözülmüş trafik için kapsamlı loglama imkânı sunarak güvenlik denetimlerine ve olay müdahalesine katkı sağlar.
- Performans yükü: Proxy üzerinde TLS sonlandırma, şifreleme ve çözme için hesaplama yükü getirir; yüksek trafikli ortamlarda bu dikkate alınmalıdır. Bunu hafifletmek için genellikle donanım hızlandırma (örneğin SSL offloading) kullanılır.
