HTTP Message Signatures, bir HTTP isteği veya yanıtındaki seçilmiş bileşenleri dijital imza ya da MAC (Message Authentication Code) ile ilişkilendiren standart bir mekanizmadır. Doğrulayıcı, imzaya dahil edilen parçaların imza üretildikten sonra değiştirilmediğini ve imzanın uygulamanın bu gönderici için güvendiği anahtarla doğrulanabildiğini denetler.

Mekanizma, HTTP mesajının ham baytlarının tamamını tek parça olarak imzalamaz. Yöntem, hedef bilgisi, belirli HTTP alanları, durum kodu veya içerik özeti gibi uygulama açısından önemli bileşenleri ortak bir imza tabanında birleştirir. Böylece imzalayan taraf ile doğrulayıcı, HTTP'nin izin verdiği bazı biçimsel dönüşümlere rağmen aynı anlamlı bileşenlerden aynı doğrulama girdisini üretebilir.

İmza Tabanı Nasıl Oluşturulur?

İmza tabanı, imzalanacak HTTP bileşenlerinin belirli bir sırada ve standartta tanımlanan biçimde metne dönüştürülmesiyle oluşan, ASCII karakterleriyle kodlanmış girdidir. İmzalayan taraf bu girdiyi kriptografik işleme verir; doğrulayıcı da gelen mesajdan aynı girdiyi yeniden üretmeye çalışır. Her iki tarafın oluşturduğu taban aynı değilse kriptografik doğrulama başarılı olmaz.

Kapsanan Bileşenlerin Seçimi

RFC 9421, normal HTTP alanlarının yanında mesajdan türetilen bileşenlerin de imzalanmasına izin verir. İsteklerde @method GET veya POST gibi HTTP yöntemini, @authority hedef sunucunun adını veya IP adresini ve varsa portunu, @path ise adresteki yolu belirtir. @path sorgu bölümünü kapsamaz; https gibi şema bilgisi, hedef sunucu, yol ve sorgu birlikte korunacaksa @target-uri kullanılabilir. Yanıtlarda @status üç basamaklı HTTP durum kodunu temsil eder.

Uygulama ayrıca içeriğin türünü belirten content-type, kimlik doğrulama bilgisini taşıyan authorization veya içeriğin özetini taşıyan content-digest gibi HTTP alanlarını imzaya dahil edebilir.

Uygulamanın hangi bileşenleri kapsadığı, imzanın hangi değişiklikleri tespit edebileceğini belirler. İmzaya dahil edilmeyen bir alanın değiştirilmesi imzayı bozmayabilir; bu nedenle doğrulayıcı, işlem sonucunu etkileyen kritik bileşenlerin imzaya dahil edilmesini zorunlu tutmalıdır. Ancak imzalayan taraf, mesajı ileten proxy veya ağ geçidinin daha sonra değiştireceği bir alanı kapsama alırsa bu beklenen değişiklik de imzayı geçersiz kılabilir.

Bileşen Değerlerinin Ortak Biçime Getirilmesi ve İmza Parametreleri

HTTP mesajı farklı sürümlerde, kütüphanelerde veya aracılarda birebir aynı bayt dizisiyle görünmeyebilir. Bu nedenle imzalayan taraf ve doğrulayıcı, alan değerlerini standartta tanımlanan ortak biçime getirip belirli bir sırayla metne dönüştürür. Amaç, anlamı korunmuş bir mesaj için imzalayan ve doğrulayan tarafın aynı bileşen değerlerini aynı sırayla yeniden kurabilmesidir.

Tabanın sonuna @signature-params bileşeni eklenir ve böylece kapsanan bileşenlerin sırası ile imza parametreleri de kriptografik olarak bağlanır. Parametreler arasında oluşturulma zamanı için created, süre sınırı için expires, imzayı diğerlerinden ayıran rastgele ve benzersiz değer için nonce, anahtar tanımlayıcısı için keyid, algoritma bilgisi için alg ve uygulamaya özgü tag bulunabilir. Bunların hangilerinin zorunlu olduğu, RFC'nin temel kurallarına ek olarak uygulamanın kendi doğrulama politikasına bağlıdır.

Signature-Input ve Signature Birlikte Nasıl Çalışır?

Bir HTTP mesaj imzası, mesaj içinde aynı etiketle eşleştirilen iki alana dayanır. Signature-Input alanı kapsanan bileşenlerin sıralı listesini ve imza parametrelerini taşır; Signature alanı ise bu bilgilerle oluşturulan imza tabanına uygulanan kriptografik işlemin çıktısını bayt dizisi olarak içerir. Doğrulayıcı, iki alandaki eşleşen etiketi kullanarak hangi meta verinin hangi imza değerine ait olduğunu belirler.

Örneğin bir uygulamanın başka bir hizmetle veri alışverişi yaptığı API isteği @method, @target-uri, content-type ve content-digest bileşenlerini kapsayabilir. Bu seçim, isteğin yöntemini, sorgu bölümü dahil hedef adresini, içeriğin türünü ve özetini imzaya dahil eder. Uygulama, işlemin sonucunu etkileyen başka alanlar varsa onları da kapsamalıdır.

Doğrulama Süreci Ne Kontrol Eder?

Kriptografik imzanın matematiksel olarak geçerli olması tek başına yeterli değildir. Doğrulayıcı, imza biçiminin yanı sıra uygulamanın hangi bileşenleri zorunlu tuttuğunu, anahtarın bu gönderici bağlamında güvenilir olup olmadığını ve imzanın süre ve tekrar kullanım kurallarına uyup uymadığını da kontrol eder.

  1. Doğrulayıcı önce Signature-Input ve Signature alanlarını ayrıştırarak eşleşen imzayı seçer.
  2. Ardından kapsanan bileşenleri ve created, expires, nonce gibi parametreleri uygulama kurallarıyla karşılaştırır.
  3. keyid veya önceden yapılandırılmış başka bir yöntemle anahtarı belirler ve bu anahtarın ilgili bağlamda güvenilir olduğunu denetler.
  4. Uygulamanın izin verdiği kriptografik algoritmayı belirleyip anahtarın bu algoritmayla uyumlu olduğunu kontrol eder.
  5. Son olarak gelen HTTP mesajından imza tabanını yeniden oluşturur ve imza değerini kriptografik doğrulama işleviyle denetler.

Buradaki önemli ayrım, geçerli bir imzanın göndereni tek başına güvenilir kılmamasıdır. Bir saldırgan kendi anahtarıyla matematiksel olarak geçerli bir imza üretebilir; doğrulayıcı, anahtarın beklenen göndericiye ait olduğunu ve bu işlemde kullanılmaya yetkili olduğunu ayrıca bilmelidir. RFC, anahtar keşfi ve güven ilişkisinin nasıl kurulacağını tek bir yöntemle belirlemez.

Mesaj İçeriği İmzaya Nasıl Dahil Edilir?

HTTP Message Signatures, mesaj gövdesini doğrudan imza tabanına kopyalayan bir mekanizma tanımlamaz. İçeriğin bütünlüğü gerekiyorsa imzalayan taraf gövdenin kriptografik özetini Content-Digest alanına yazar ve bu alanı kapsanan bileşenler arasına ekler. Böylece imza, içerik özetinin değiştirilmesini tespit eder.

Doğrulayıcı HTTP mesaj imzasını kontrol eder ve Content-Digest değerini alınan içerikten yeniden hesapladığı özetle karşılaştırır. Yalnızca imzayı kontrol edip içerik özetini gövdeye karşı doğrulamamak yeterli değildir; aksi durumda gövde değiştirilmiş olsa bile imzalanmış eski özet değeri yerinde kalabilir.

HTTP Message Signatures ile TLS Arasındaki Farklar

HTTP Message Signatures, TLS'nin sağladığı aktarım gizliliğini sağlamaz. Bağlantıyı şifreleyen TLS, kendi uç noktaları arasındaki trafiği gizlerken HTTP mesaj imzası seçilmiş bileşenlerin bütünlüğünü denetlemeye ve imzayı bir anahtarla doğrulamaya yarar. Bu iki mekanizma farklı katmanlarda çalışır; uygulama bunları birbirinin yerine kullanmamalıdır.

Tekrar Saldırılarına Karşı Bileşen, Zaman ve Nonce Kontrolleri

Bir saldırgan, ele geçirdiği imzalı isteği değişiklik yapmadan yeniden gönderebilir. Doğrulayıcı created ve expires ile kabul süresini sınırlayabilir; ancak süre dolmadan gelen tekrarları yalnız bu zaman denetimiyle ayıramaz. Tekrarı reddetmek için uygulama, daha önce kabul ettiği nonce değerlerini gerekli süre boyunca saklayıp aynı değerin yeniden kullanılmasını denetleyebilir. Kabul edilen imza yaşı, saat farkı toleransı ve nonce saklama süresi birlikte belirlenmelidir. Nonce değerini imzaya eklemek, doğrulayıcı bu denetimi yapmıyorsa tekrarı önlemez.

Anahtar Güveni ve Anahtarların Korunması

İmza anahtarı ele geçirilirse saldırgan aynı anahtarla yeni ve geçerli görünen imzalar üretebilir; bu nedenle uygulama anahtarları korumalı, gerektiğinde yenilemeli ve doğrulayıcının hangi anahtarları hangi göndericiler için kabul edeceğini açıkça belirlemelidir. Simetrik bir MAC kullanıldığında doğrulayıcı aynı gizli anahtarı bildiği için geçerli imza da üretebilir.