Geri donen ziyaretcilerde el sikisma gecikmesini sifira indirerek TTFB suresini kisaltin. Ancak 0-RTT'nin getirdigi Replay Saldirisi (Replay Attack) risklerini, RFC 8470 HTTP 425 Too Early mekanizmasini ve bilet onbellegi ihtiyacini analiz edin.
ssl_early_data ve map ile HTTP 425 Too Early dondurme.
# Nginx 1.25+ TLS 1.3 0-RTT ve Anti-Replay Yapilandirmasi
# /etc/nginx/conf.d/tls-0rtt.conf
ssl_protocols TLSv1.3;
ssl_early_data on; # 0-RTT Early Data'yi etkinlestir
# RFC 8470: Uygulamaya Early-Data basligini ilet
proxy_set_header Early-Data $ssl_early_data;
# Guvenlik Kurali: Eger istek Early Data ile geldiyse ve degistirici (POST/PUT/DELETE) ise
# veya sorgu parametresi iceriyorsa HTTP 425 (Too Early) dondur!
map $ssl_early_data $reject_early_data {
"1" $is_mutating_method;
default 0;
}
map $request_method $is_mutating_method {
POST 1;
PUT 1;
DELETE 1;
PATCH 1;
default 0;
}
server {
listen 443 ssl;
server_name api.siteniz.com;
if ($reject_early_data) {
return 425; # Istemci el sikismasini tamamlayip 1-RTT ile yeniden denemelidir
}
location / {
proxy_pass http://backend_upstream;
}
}Caddy v2.8+ Early-Data baslik filtreleme ve 425 yaniti.
# Caddy v2.8+ TLS 1.3 0-RTT Yapilandirmasi
# /etc/caddy/Caddyfile
api.siteniz.com {
tls {
protocols tls1.3
# Caddy otomatik olarak session ticket'lari guvenli sekilde dondurur
}
# RFC 8470 Korumasi: Mutating metodlarda Early Data reddi
@replayRisk {
header Early-Data 1
method POST PUT DELETE
}
respond @replayRisk "Too Early - Replay Protection" 425
reverse_proxy localhost:3000 {
header_up Early-Data {http.request.header.Early-Data}
}
}Uygulama katmaninda mutating istekleri 425 ile koruma.
// middleware.ts (Next.js / Node.js RFC 8470 Replay Guard)
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
export function middleware(request: NextRequest) {
const isEarlyData = request.headers.get('early-data') === '1';
const isMutating = ['POST', 'PUT', 'DELETE', 'PATCH'].includes(request.method);
// Eger istek 0-RTT Early Data icinde gelmisse ve veritabanina yazma yapiyorsa:
// Replay saldirilarini (cift para cekme / cift siparis) onlemek icin 425 dondur!
if (isEarlyData && isMutating) {
return new NextResponse('Too Early: Replay attacks not permitted on mutating endpoints.', {
status: 425,
headers: {
'Retry-After': '0',
},
});
}
return NextResponse.next();
}IETF RFC 8446 standardiyla hayatimiza giren TLS 1.3, standart bir baglantida el sikisma suresini 1 RTT'ye (gidis-donus turu) indirmistir. Ancak onceden sunucuyu ziyaret etmis istemciler icin 0-RTT (Early Data)ozelligi sunulmustur. Istemci, daha once aldigi oturum biletini (Session Ticket / PSK) kullanarak, ilk ClientHellopaketinin icinde sifrelenmis HTTP istegini gonderir. Boylece el sikisma tamamlanmadan once veri sunucuya ulasir ve1 tam RTT (15 ila 150 ms arasi) saf gecikme tasarrufu saglanir.
0-RTT verileri Perfect Forward Secrecy (PFS) garantisine sahip degildir ve ayni oturum biletiyle sifrelenmistir. Ag uzerindeki pasif bir saldirgan (man-in-the-middle, sahte Wi-Fi, ag dinleyicisi), kullanicinin gonderdigiClientHello + Early Data paketini yakalayip sunucuya tekrar tekrar iletebilir (replay edebilir). Eger bu istek bir odeme, bakiye transferi veya veritabaninda degisiklik yapan birPOST istegi ise, kullanicinin hesabindan cift para cekilebilir veya cift siparis olusturulabilir!
Bu saldiriyi onlemek icin IETF, RFC 8470 standardini tanimlamistir. Nginx veya Caddy gibi ters vekiller, gelen istek 0-RTT icinde tasiniyorsa ve hedef endpoint degistirici (mutating) bir metod ise istegi backend'e gondermez. Istemciye HTTP 425 (Too Early) durum kodu dondurur. Modern tarayicilar bu yaniti aldiklarinda kullaniciya hata gostermez; hemen 1-RTT el sikismasini tamamlayip istegi guvenle yeniden gonderir.
Sunucu seviyesinde replay engellemek icin Kayan Zaman Penceresi (Sliding Window) kullanilir. Istemci saati ile sunucu saati arasinda en fazla 10-30 saniyelik bir tolerans taninir ve bu sure icinde kullanilan her biletin tekil kimligi (nonce) bellekte tutulur. Ayni biletle gelen ikinci istek dogrudan reddedilir. Ancak Anycast veya cok dugumlu cluster yapilarinda bu biletlerin dugumler arasinda senkronize edilmesi ek ag yuku yaratacagi icin en guvenli ve hafif cozum RFC 8470 metod filtrelemesidir.
Statik icerik, blog, haber siteleri ve yalnizca idempotent GET / HEADsorgulari yapan REST API'lerde 0-RTT acmak Core Web Vitals (LCP ve TTFB) acisindan buyuk avantaj saglar. Ancak finans, bankacilik, e-ticaret odeme adimlari ve yetkilendirme (login/token) uc noktalarinda 0-RTT ya tamamen kapatilmali ya da HTTP 425 kuraliyla kesin olarak engellenmelidir.