Oblivious HTTP (OHTTP), HTTP isteğinin içeriği ile istemcinin IP adresi ve bağlantı bilgilerini farklı aracılara ayıran bir protokoldür. Web istek ve yanıtlarını taşıyan HTTP mesajları burada ek olarak şifrelenir. Şifreli isteği içeriğini okuyamadan ileten aracıya relay, bu şifrelemeyi açıp isteği işleyen veya hedef hizmete ileten uca gateway denir.

Bağlantı relay'den geldiği için gateway, istemcinin doğrudan IP adresini taşıma katmanından öğrenmez. Böylece isteğin içeriğini bilen taraf ile istemcinin IP adresini gören taraf birbirinden ayrılır.

OHTTP İsteğinin Relay ve Gateway Üzerinden İlerlemesi

OHTTP, mesajı gateway'in açık anahtarı yardımıyla koruyan HPKE (Hybrid Public Key Encryption) yöntemini kullanır. Açık anahtar istemcilere dağıtılır, şifreyi açmak için gereken özel anahtar gateway'de kalır. Asıl HTTP mesajını bu korumalı veri içine yerleştirmeye kapsülleme denir. İstemci ile relay ve relay ile gateway arasındaki iki ayrı bağlantıda da HTTPS kullanılır; HTTPS, HTTP iletişimini TLS ile şifreler ve bağlantının karşı ucunun kimliğini doğrular.

  1. İstemci, kullanacağı gateway'i, relay'i ve gateway'e ait doğrulanmış anahtar yapılandırmasını bilir.
  2. İstemci, hedef kaynağa gönderilecek normal HTTP isteğini oluşturur. Yöntem, adres, başlıklar ve gövdeyi Binary HTTP denilen ikili mesaj biçiminde kodlar ve HPKE ile kapsüller.
  3. İstemci, şifrelenmiş kapsülü HTTPS üzerinden relay'e gönderdiği HTTP isteğinin gövdesinde taşır.
  4. Relay kapsülün içeriğini açmadan gateway'e iletir. Relay, gizlilik hedefini korumak için istemciyi tanımlayan kaynak bilgilerini veya benzeri başlıkları gateway'e eklememelidir.
  5. Gateway HPKE korumasını kaldırır, asıl HTTP isteğini elde eder ve hedef kaynağa yönelik işlemi gerçekleştirir. Hedef kaynak normal HTTP isteği gördüğü için OHTTP kullanıldığından haberdar olmak zorunda değildir.
  6. Gateway elde ettiği HTTP yanıtını, isteğin HPKE bağlamından türetilen yanıt anahtarıyla şifreleyip kapsüller. Relay bu şifreli yanıtı istemciye aktarır ve istemci kapsülü açarak asıl yanıtı elde eder.

OHTTP'nin mesaj koruması istemci ile gateway arasındadır; istemci hedef sunucunun kimliğini doğrudan doğrulamaz. Uygulama, bu nedenle hangi gateway'in hangi hedef adına yanıt vermesine izin verdiğini belirlemelidir. Gateway ile hedef farklı sunuculardaysa aralarındaki bağlantının da korunması gerekir; istemci ile relay arasındaki HTTPS bağlantısı bu ayrı yolu kendiliğinden şifrelemez.

OHTTP Kullanılırken İstekler Nasıl İlişkilendirilebilir?

Relay ile gateway'in yalnız farklı sunucularda çalışması yeterli değildir. Bu rolleri aynı işletmeci yürütüyorsa veya ayrı işletmeciler gözlemledikleri bilgileri birleştiriyorsa istemcinin IP adresi ile isteği eşleştirilebilir. İstemci, kaynak bilgisini gateway'e aktarmayan ve onunla bu bilgileri paylaşmayan bir relay kullanmalıdır.

Anahtar yapılandırmasını doğrudan gateway'den indirmek de ayrı bir bağlantıdır ve o sırada istemcinin IP adresini gateway'e gösterebilir. Uygulama bu adresi de gizlemeyi hedefliyorsa anahtar edinimini bağlantıya aracılık eden bir proxy üzerinden yapabilir. Ayrıca yalnız tek istemciye verilen özel bir anahtar yapılandırması, sonraki şifreli istekleri tanımak için kullanılabilir; yapılandırmanın doğrulanması yanında diğer istemcilere sunulan yapılandırmayla tutarlılığı da önemlidir.

Rollerin ayrı tutulması, gözlemcilerin erişebildiği bütün bağlantı verilerini ortadan kaldırmaz. Relay mesaj boyutunu, zamanlamayı ve hangi gateway'e trafik gönderildiğini gözlemleyebilir. RFC 9458, HTTPS kullanımının ağ gözlemcisinin iki taraftaki mesajları doğrudan eşleştirmesini zorlaştırdığını ancak zamanlama ve trafik analizi olasılığını ortadan kaldırmadığını belirtir.

Durum Bilgisi Taşımayan İstekler Neden Daha Uygundur?

OHTTP, taşıma katmanındaki bağlantı izlerini birbirinden ayırmaya çalışır ancak uygulamadaki kimlik bilgisini kendiliğinden kaldırmaz. Bir istek aynı çerezi, hesap kimliğini, kimlik doğrulama bilgisini veya istemciye özgü kalıcı bir değeri taşıyorsa gateway ya da hedef kaynak bu değerle ayrı istekleri aynı kullanıcıyla ilişkilendirebilir.

OHTTP bu nedenle birbirinden bağımsız veya çok az durum bilgisi taşıyan işlemlere daha uygundur. Örneğin kimlik bilgisi içermeyen kullanım ve performans ölçümleri, tek seferlik raporlar veya kullanıcı hesabına bağlanması gerekmeyen küçük sorgular bu amaçla gönderilebilir.

İstemci her istek için yeni anahtar malzemesiyle ayrı bir HPKE bağlamı, yani o mesajı koruyan şifreleme durumu oluşturmak zorundadır. Aynı bağlamın yeniden kullanılması yalnız isteklerin ilişkilendirilmesiyle sınırlı bir risk değildir; istek ve yanıt içeriklerinin relay tarafından açığa çıkarılmasına da yol açabilir.

OHTTP İçin Uygulama Desteği ve Ek Bağlantı Maliyeti

OHTTP'nin çalışması için istemci, relay ve gateway birlikte bu iletişim biçimini desteklemelidir. OHTTP bütün cihaz veya tarayıcı trafiğini taşımaz. Cihazın seçilen ağ trafiğini uzak bir uçla kurulan tünelden geçiren VPN bağlantısının yerine kendiliğinden geçmez.

Her asıl istek için istemci ile relay ve relay ile gateway arasında en az iki HTTP isteği gönderilir; gateway ayrı bir hedefe ulaşıyorsa o bağlantı da eklenir. Mevcut HTTP bağlantıları birden fazla istekte kullanılabilir, bu yüzden her OHTTP isteğinde bütün bağlantıların yeniden kurulması gerekmez. Buna rağmen relay üzerinden geçen ek yol gecikmeyi artırabilir.

Kapsülleme, şifreleme bilgileri ve ek HTTP alanları mesaj boyutunu büyütür. Anahtar türetme ve şifreleme işlemleri de hesaplama maliyeti ekler. Bu maliyet, istemci ile sunucuların işlem kapasitesine ve gönderilen mesajların boyutuna göre değişir.