HTTP ve HTTPS Nedir? Aradaki Fark ve Şifreleme
HTTP ve HTTPS nedir, farkı ne? İstek ve yanıt anatomisi, durum kodları, şifresiz bağlantıda ne sızdığı ve TLS el sıkışması adım adım.
- HTTP Nedir? İstek ve Yanıtın Anatomisi
- İstemci Sorar, Sunucu Cevaplar: Tek Turluk Bir Konuşma
- HTTP Durumsuzdur: Her İstek Kendi Başına
- Port 80 ve Port 443: İki Kapı, Tek Protokol
- HTTP İsteğinin İçinde Ne Var? Metot, Yol ve Başlıklar
- HTTP Metotları: GET, POST ve Diğerleri
- HTTP Başlıkları: Host, User-Agent, Authorization, Cookie
- İstek Gövdesi: Formun ve Parolanın Taşındığı Yer
- HTTP Yanıtı ve Durum Kodları: 200, 301, 404, 502
- Beş Sınıf: 1xx’ten 5xx’e
- Sahada Ayırt Edilmesi Gereken Çiftler: 301/302, 401/403, 502/504
- Bu Sitenin Kendi Kararı: 301 mi 308 mi?
- Şifresiz HTTP’de Ne Sızıyor? Paket Yakalamayla
- Aynı Girişi İki Kez Yakalamak: Port 80 ve Port 443
- Düz Metin Parolanın Paket Dökümündeki Hali
- ”İç Ağdayız, Sorun Olmaz” Neden Yanlış?
- HTTPS Nedir? TLS El Sıkışması Adım Adım
- El Sıkışmada Ne Konuşulur? Sürüm, Şifre Takımı, Anahtar
- Şifreleme Neyi Gizler, Neyi Gizlemez: SNI ve DNS
- Kilit Simgesi Ne Söyler, Ne Söylemez?
- HTTP/1.1, HTTP/2 ve HTTP/3: Neyin Değiştiği
- HTTP/1.1’in Sınırı: Sıra Bekleyen İstekler
- HTTP/2 ve Sözde Başlıklar: Host Nasıl :authority Oldu?
- HTTP/3 ve QUIC: TCP’nin Bırakıldığı Yer
- Kurumsal Ağda HTTP Nerede Kalmış Olur?
- Şifresiz Kalan Tipik Yerler: Yönetim Panelleri, Yazıcılar, İç Araçlar
- HTTP’den HTTPS’e Taşırken Atlanan Adımlar
- HSTS: Tarayıcıya “Bir Daha Sorma” Demek
- Sonuç: Tek Harf, İki Ayrı Güvenlik Modeli
- Ek: Tüm HTTP Durum Kodları
- 1xx: Bilgilendirme
- 2xx: Başarı
- 3xx: Yönlendirme
- 4xx: İstemci Hatası
- 5xx: Sunucu Hatası
- HTTP ve HTTPS Hakkında Sık Sorulan Sorular
HTTP, tarayıcınız ile sunucu arasında sayfaları ve verileri taşıyan uygulama katmanı protokolüdür. HTTPS ise aynı protokolün TLS ile şifrelenmiş halidir. Aradaki tek harf, taşınan şeyin yol boyunca okunup okunamayacağını belirler.
Farkı en iyi posta anlatır. Düz HTTP bir kartpostaldır: adres de mesaj da açıkta durur, onu taşıyan herkes ve yolda eline alan herkes okuyabilir. HTTPS ise mühürlü zarftır. Taşıyanlar zarfı görür, nereye gittiğini bilir, ama içindekini okuyamaz.
Adların kendisi de bunu zaten söylüyor. HTTP, HyperText Transfer Protocol kelimelerinin kısaltmasıdır: Türkçesiyle hiper metin aktarım protokolü. “Hiper metin”, içinde başka sayfalara giden bağlantılar taşıyan metin demektir; yani protokol, adında taşıdığı şeyi tarif eder. HTTPS ise aynı adın sonuna bir S eklenmiş halidir ve o harf Secure kelimesinden gelir: güvenli hiper metin aktarım protokolü. Sondaki tek harfin anlattığı şey budur; yeni bir protokol icat edilmemiş, var olanın üstüne bir güvenlik katmanı konmuştur.
Bu rehber protokolün kendisini anlatıyor: bir isteğin içinde tam olarak ne olduğunu, sunucunun hangi durum kodlarıyla cevap verdiğini, şifresiz bir bağlantıda neyin sızdığını ve TLS’in bunu nasıl kapattığını. Şifresiz bir bağlantıda tam olarak neyin sızdığını merak ederek geldiyseniz doğrudan paket yakalama bölümüne geçebilirsiniz. Zarfın gerçekten yazdığınız kişiden gelip gelmediği, yani güven zincirinin kendisi ayrı bir konudur ve sertifika otoritesi nedir rehberinde ele alınıyor. Web sunucusu tarafında sertifikayı siteye bağlama işi de ayrıdır; onu IIS rehberinde adım adım gösteriyoruz.
Bu makale Kurumsal Ağ Kurulumu hizmetimizin protokol katmanına odaklanır ve kurumsal ağ protokolleri rehberinin web ayağını oluşturur.
HTTP Nedir? İstek ve Yanıtın Anatomisi
Kartpostalı bir adım yakından inceleyelim. Bir kartpostalda iki şey vardır: adres ve mesaj. HTTP de böyle çalışır. Her alışveriş bir istek ile bir yanıttan ibarettir ve ikisi de aynı üç parçadan kurulur: bir başlangıç satırı, bir başlık bloğu, bir de gövde.
İstemci Sorar, Sunucu Cevaplar: Tek Turluk Bir Konuşma
HTTP’de konuşmayı her zaman istemci başlatır. Sunucu kendiliğinden konuşmaz; sorulmadan cevap vermez, bir şey değiştiğinde haber göndermez. Tarayıcınız bir bağlantı açar, isteğini yazar, cevabı bekler.
Bir isteğin ham hali şuna benzer:
GET /iletisim HTTP/1.1
Host: sercebilisim.com
User-Agent: Mozilla/5.0
Accept: text/htmlİlk satır istek satırıdır ve üç şey söyler: ne yapılacak (GET), neye yapılacak (/iletisim), hangi sürümle konuşuluyor (HTTP/1.1). Altındaki satırlar başlıklardır. Sonra boş bir satır gelir ve o boş satır bir ayraçtır: altında kalan her şey gövdedir. GET isteğinde gövde genellikle boştur, çünkü siz bir şey göndermiyorsunuz, istiyorsunuz.
Sunucunun cevabı aynı kalıbı izler:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 5312
<!doctype html>...Değişen tek şey ilk satır. İstekte “ne yapayım” yazıyordu, yanıtta “ne oldu” yazıyor: 200 OK. Başlıklar yine başlık, boş satır yine ayraç, altındaki de sayfanın kendisi.
Şu anda okuduğunuz bu sayfa da tam olarak böyle geldi. Sunucu gövdeye sayfanın HTML kodunu koydu, tarayıcınız o kodu aldı ve ekrana bu yazıyı çizdi. Yani bu cümleyi görüyor olmanız, birkaç yüz milisaniye önce buna benzer bir yanıtın ağdan geçmiş olması demektir.
Bu kadar. Web’in tamamı, milyarlarca kez tekrarlanan bu tek turluk konuşmanın üstünde duruyor.
HTTP Durumsuzdur: Her İstek Kendi Başına
HTTP durumsuz (stateless) bir protokoldür: sunucu, iki istek arasında sizi hatırlamaz. Az önce giriş yapmış olmanız, bir sonraki isteğinizde sunucu için hiçbir şey ifade etmez. Her istek, kendisinden önce hiçbir şey olmamış gibi karşılanır.
Postacı benzetmesi burada da tutuyor: postacı, dün size bir kart getirdiğini hatırlamak zorunda değildir. Her kartı üstündeki adrese göre taşır, öncekilerle ilişkilendirmez.
Peki o zaman bir site sizi nasıl “tanıyor”? Cevap, sitenin hatırlaması değil, sizin her seferinde yeniden kanıt göndermenizdir. Giriş yaptığınızda sunucu size bir oturum bileti verir ve tarayıcınız o bileti sonraki her isteğe bir başlıkta ekler. Sayfayı yenilediğinizde, bir görsel yüklendiğinde, arka planda bir istek gittiğinde: her birinde o bilet yeniden yola çıkar.
Bu cümleyi aklınızda tutun, çünkü ilerideki bölümlerden birinin tamamı bunun üstüne kurulu. Şifresiz bir bağlantıda sızan şey yalnız giriş anındaki parola değildir; o parolanın yerine geçen bilet, ondan sonraki her istekte tekrar tekrar açıkta gider. Parolayı bir kez yakalamak için doğru anı beklemek gerekir, bileti yakalamak için herhangi bir an yeterlidir.
Durumsuzluk bir eksiklik değil, bilinçli bir tasarım tercihidir ve web’in ölçeklenmesini mümkün kılan şeydir: sunucunun milyonlarca ziyaretçinin nerede kaldığını hafızasında tutması gerekmez, her isteği bağımsız karşılar. Bu olmasaydı, bir sitenin önüne ikinci bir sunucu koymak bile başlı başına bir proje olurdu, çünkü ikinci sunucu birincisinin hafızasını bilemezdi.
Port 80 ve Port 443: İki Kapı, Tek Protokol
HTTP’nin varsayılan kapısı 80, HTTPS’in 443’tür. Aradaki fark protokolün kendisinde değildir: iki kapıdan da aynı HTTP konuşulur, aynı istek satırı, aynı başlıklar, aynı gövde. Değişen tek şey, 443’te bu konuşmanın etrafına bir TLS katmanı sarılmasıdır.
Yani kartpostalın metni ikisinde de aynıdır. 80’de kart açık gider, 443’te zarfa konur.
Port numaraları bir kural değil bir uzlaşıdır; bir web sunucusunu 8080 üzerinde de çalıştırabilirsiniz. Ama tarayıcı, adres çubuğuna http:// yazdığınızda 80’e, https:// yazdığınızda 443’e gideceğini varsayar. Kurumsal ağlarda karşılaşacağınız yönetim panellerinin 8443 gibi adreslerde durmasının sebebi de budur: aynı protokol, uzlaşı dışında bir kapı.
Ağdaki diğer protokollerin hangi portlarda dinlediğini ve bu numaraların neye göre dağıtıldığını kurumsal ağ protokolleri rehberinin port tablosunda topluca bulabilirsiniz.
HTTP İsteğinin İçinde Ne Var? Metot, Yol ve Başlıklar
Bir isteğin üç parçadan kurulduğunu gördük: istek satırı, başlıklar, gövde. Şimdi her birinin içine bakalım, çünkü şifresiz bir bağlantıda sızan şey tam olarak bu üç parçadır.
HTTP Metotları: GET, POST ve Diğerleri
İstek satırının ilk kelimesi metottur ve sunucuya niyetinizi söyler. En sık ikisiyle karşılaşırsınız:
GET: bir şey isterim. Gövdesi yoktur, taşıdığı tek bilgi adresin kendisindedir.POST: bir şey gönderirim. Gönderilen veri gövdede durur.
Geri kalanlar aynı mantığın devamıdır: PUT bir kaydın tamamını değiştirir, PATCH bir parçasını, DELETE siler, HEAD yalnız başlıkları ister (dosyayı indirmeden boyutunu öğrenmek gibi), OPTIONS “bu adres hangi metotları kabul ediyor” diye sorar.
Ama metotlar arasındaki asıl ayrım isim listesi değil, güvenli olup olmadıklarıdır. GET güvenli sayılır: hiçbir şeyi değiştirmediği varsayılır. Bu varsayım teorik değil, işletim sonuçları vardır. Güvenli kabul edildiği için bir GET isteği önbelleğe alınabilir, tarayıcı tarafından önceden çekilebilir, hata durumunda otomatik olarak yeniden denenebilir ve adresi olduğu gibi kayıt altına alınabilir.
Sahada bunun pahalı karşılığı şudur ve şifreleme onu çözmez: bir parolayı, oturum biletini ya da tek kullanımlık bağlantı anahtarını adres satırına koyarsanız, o değer HTTPS kullansanız bile sunucunun erişim kayıtlarına, tarayıcı geçmişine, aradaki vekil sunucuların günlüklerine ve dışarıya verilen linklerin Referer başlığına düşer. Zarf içeriği korur, zarfın üstüne yazdığınızı korumaz.
GET /sifre-sifirla?token=8f2c19ab HTTP/1.1 ← kayıtlara düşer
POST /sifre-sifirla HTTP/1.1 ← gövdede kalırKural basit: bir değer gizliyse adres satırında değil, gövdede ya da bir başlıkta taşınır.
HTTP Başlıkları: Host, User-Agent, Authorization, Cookie
Başlıklar, ad: değer biçiminde yazılan satırlardır ve isteğin kendisi hakkındaki her şeyi taşır. Kartpostalın üstündeki adres, pul ve kenara düşülmüş notlar gibi düşünün: mesajın parçası değildirler ama mesajın nasıl işleneceğini belirlerler.
Kurumsal ağda karşınıza en çok çıkacak olanlar:
| Başlık | Ne söyler |
|---|---|
Host | İsteğin hangi site adına yapıldığı |
User-Agent | İstemcinin kendini nasıl tanıttığı (tarayıcı, ajan, betik) |
Accept | Hangi biçimde cevap beklendiği |
Content-Type | Gövdenin hangi biçimde yazıldığı |
Authorization | Kimlik kanıtı (token, temel kimlik doğrulama) |
Cookie | Oturum bileti |
Bu listede Host başlığı özel bir yer tutar ve çoğu anlatımda hiç açıklanmaz. Bir sunucunun tek IP adresi üstünde onlarca farklı site barındırabilmesinin sebebi odur: paket IP’ye ulaşır, ama sunucunun hangi siteyi sunacağını Host satırı söyler. Bu satır olmadan sunucu, aynı adrese gelen iki farklı site isteğini birbirinden ayıramaz.
Bu, teorik bir ayrıntı değil, doğrudan yapılandırma karşılığı olan bir şeydir: bir web sunucusunda site tanımlarken girdiğiniz konak adı (host header) tam olarak bu başlıkla eşleşir. Bir sürümü tarihe gömen şey de bu satır oldu: Host başlığı HTTP/1.1 ile geldi (Ocak 1997) ve iki ay önce yayınlanmış olan HTTP/1.0’ı fiilen bitirdi. Sebebi mühendislik değil ekonomiydi: Host olmadan bir IP adresi yalnız tek bir siteye yetiyordu ve barındırma sektörünün alternatifi, her müşteriye ayrı IP satın almaktı. IIS tarafında sitenin nasıl bağlandığını IIS rehberimizde adım adım gösteriyoruz.
Authorization ve Cookie başlıkları ise bu makalenin omurgasına bağlanır. İkisi de kimlik kanıtı taşır ve ikisi de düz metindir. Şifreleme yoksa, bu iki satır isteğin geri kalanı kadar açıktadır.
İstek Gövdesi: Formun ve Parolanın Taşındığı Yer
Başlık bloğundan sonraki boş satırın altında kalan her şey gövdedir. Bir formu doldurup gönderdiğinizde yazdıklarınız buraya yerleşir.
Bir giriş formunun gövdesi genellikle şuna benzer:
POST /giris HTTP/1.1
Host: portal-http.ad.sercebilisim.com
Cookie: oturum=8f2c19ab4e7d
Content-Type: application/x-www-form-urlencoded
Content-Length: 31
user=ahmet.yilmaz&pass=Yaz2026.Son satıra dikkat edin. Orada bir şifreleme, bir kodlama ya da bir gizleme yok. application/x-www-form-urlencoded bir güvenlik biçimi değil, yalnızca alanların ad=değer çiftleri halinde ve & ile ayrılarak yazıldığını söyleyen bir yazım kuralıdır. Modern uygulamalarda sık görülen application/json da aynı şeydir: farklı bir yazım, aynı açıklık.
Yani parola, isteğin gövdesinde okunabilir halde durur. Bu, HTTP’nin bir kusuru değildir; HTTP’nin işi taşımaktır, saklamak değil. Saklama işi bir alt katmana, TLS’e aittir ve bu rehberin ilerleyen bölümlerinde onu ele alacağız. Yukarıdaki döküm bir örnek değil: birazdan aynı isteği kendi lab ağımızda gerçekten yakalayıp size göstereceğiz.
Buraya kadar anlattığımız her şey, bu bölümün başındaki cümleyi hak eder hale getirdi: bir istekte metot, adres, başlıklar ve gövde vardır; şifresiz bir bağlantıda dördü de yol boyunca okunabilir. Bunun bir paket dökümünde nasıl göründüğünü dördüncü bölümde satır satır göstereceğiz.
HTTP Yanıtı ve Durum Kodları: 200, 301, 404, 502
İsteğin içini gördük. Şimdi sunucunun cevabına geçiyoruz ve o cevabın en değerli parçası ilk satırındaki üç haneli sayıdır. Bir arıza incelemesinde bakılacak ilk yer burasıdır, çünkü durum kodu size sorunun kimde olduğunu söyler.
Beş Sınıf: 1xx’ten 5xx’e
Durum kodları beş sınıfa ayrılır ve ilk rakam sınıfı belirler:
| Sınıf | Anlamı | Pratik karşılığı |
|---|---|---|
1xx | Bilgilendirme | Nadiren görürsünüz, konuşma sürüyor demektir |
2xx | Başarı | İstek karşılandı |
3xx | Yönlendirme | Aradığın şey başka bir adreste |
4xx | İstemci hatası | Sorun isteği yapan tarafta |
5xx | Sunucu hatası | Sorun cevap veren tarafta |
Son iki satır, bu tablonun asıl işe yarayan yeridir. Bir arızada 4xx görüyorsanız sunucu ayaktadır ve ne istediğinizi anlamıştır; itiraz ettiği şey isteğin kendisidir. 5xx görüyorsanız istek doğruydu, sunucu onu yerine getiremedi. Bu tek ayrım, “kimde arayacağım” sorusunu daha ilk saniyede yarıya indirir.
Ezberlenecek kod listesi çıkarmanın anlamı yok; gerçekten iş gören şey, birbirine benzeyen kodların arasındaki farktır. Kayıtlı kodların tamamını tek satırlık açıklamalarla görmek isterseniz makalenin sonundaki tam listeye bakabilirsiniz.
Sahada Ayırt Edilmesi Gereken Çiftler: 301/302, 401/403, 502/504
301 ile 302: kalıcı mı geçici mi. İkisi de “başka adrese git” der, ama 301 kalıcıdır ve bunun geri dönüşü zordur. Tarayıcı kalıcı yönlendirmeyi agresif biçimde önbelleğe alır; yani yanlışlıkla 301 verdiyseniz, sunucudaki hatayı düzeltmeniz yetmez. Ziyaretçinin tarayıcısı sunucuya bir daha sormadan eski kararı uygulamaya devam eder. 302 ise geçicidir, önbelleğe alınmaz ve arama motorları hedefi kalıcı adres saymaz.
401 ile 403: tanımıyorum mu, tanıyorum ama yetkin yok mu. Bu ikisi sürekli karıştırılır ve karıştırıldığında yanlış yerde arama yapılır.
401: sunucu sizi tanımıyor. Kimlik bilgisi hiç gelmemiş ya da geçersiz. Aranacak yer kimlik doğrulama yapılandırmasıdır.403: sunucu sizi tanıyor, kim olduğunuzu biliyor ve yine de hayır diyor. Aranacak yer yetki ve izinlerdir.
Bir kullanıcı “giriş yapamıyorum” dediğinde bu iki koddan hangisini aldığı, sorunun parolada mı yoksa grup üyeliğinde mi olduğunu doğrudan söyler.
502 ile 504: arka uç çökmüş mü, yavaş mı. İkisi de bir ara sunucunun (vekil sunucu, yük dengeleyici, ters proxy) verdiği cevaptır ve ikisi de “asıl sunucuya ulaşamadım” demek gibi görünür. Fark can alıcıdır:
502: arka uçtan cevap geldi ama anlamsızdı, ya da bağlantı reddedildi. Genellikle arka uç servisi çalışmıyordur.504: arka uç bağlantıyı kabul etti, ama zamanında cevap vermedi. Servis ayaktadır ve yavaştır.
Birincisinde servisin durup durmadığına, ikincisinde neyin yavaşlattığına bakarsınız. Bu iki kodu ayırmayan bir ekip, çalışan bir servisi boşuna yeniden başlatarak yarım saat harcayabilir.
Bu Sitenin Kendi Kararı: 301 mi 308 mi?
Durum kodları soyut kalmasın. Bu sitede hizmet adreslerinden biri geçmişte değişti ve eski adres için kalıcı bir yönlendirme tanımlandı. Yönlendirmenin canlıdaki hali şu:
curl -I https://sercebilisim.com/hizmetler/network-cozumleriHTTP/2 308
location: /hizmetler/kurumsal-network-kurulumuYapılandırmada 301 yazmıyor, 308 dönüyor. Sebep şu: barındırma katmanında bir yönlendirmeyi “kalıcı” olarak işaretlediğinizde üretilen kod 308’dir.
Peki bu bir sorun mu? Hayır, ve nedenini bilmek bir sonraki yönlendirmeyi kurarken işinize yarar. 301 ile 308 arasındaki fark kalıcılık değil, metodun korunmasıdır. Eski tanımıyla 301, istemcinin yönlendirme sırasında POST isteğini GET’e çevirmesine izin verir. 308 bunu yasaklar: hangi metotla geldiyseniz yeni adrese de aynı metotla gidersiniz. Aynı ayrım geçici tarafta da vardır: 302 metodu değiştirebilir, 307 değiştiremez.
| Metot değişebilir | Metot korunur | |
|---|---|---|
| Kalıcı | 301 | 308 |
| Geçici | 302 | 307 |
Arama motorları açısından 301 ile 308’in ikisi de kalıcı sayılır ve hedefi asıl adres kabul eder. Yani doğru sütun ikisi de olabilir; yeni olan çift yalnızca daha kesin davranır.
İkinci bir 308, bambaşka bir sebep. Aynı sitede şu ölçüm de 308 döner, ama burada taşınan bir adres yok. Bu sefer aynı işi Windows tarafından yapalım:
curl.exe -s -I https://sercebilisim.com/hizmetler/siber-guvenlik/HTTP/1.1 308 Permanent Redirect
Location: /hizmetler/siber-guvenlik
Server: VercelBurada değişen bir adres yok, yalnız sondaki eğik çizgi var. Aynı sayfaya iki farklı adresle ulaşılabilmesi arama motorları için ikilik yaratır, bu yüzden bir biçim tek kanonik biçim seçilir ve diğeri kalıcı olarak ona yönlendirilir. Durum kodları yalnız arıza anlatmaz; bu örnekte olduğu gibi, bir karar da anlatırlar.
İki çıktının ilk satırı da farklı: yukarıdaki Linux ölçümü HTTP/2, buradaki Windows ölçümü HTTP/1.1 diyor. Sunucu ikisinde de aynı sunucu; değişen, istemcinin hangi sürümü konuşabildiği. Sürümlerin neden ve nasıl anlaşıldığını birazdan HTTP/1.1, HTTP/2 ve HTTP/3 bölümünde ele alacağız.
Buraya kadar HTTP’nin tamamını gördünüz: istek nasıl kurulur, içinde ne taşınır, sunucu hangi kodla cevap verir. Ama bu bölümlerin hepsinde sessizce doğru kabul ettiğimiz bir şey var. İstek satırı, başlıklar, gövde, oturum bileti ve az önceki Location satırı: hepsi yol boyunca düz metin olarak gitti. Sıradaki bölüm tam olarak bunun ne demek olduğunu gösteriyor.
Şifresiz HTTP’de Ne Sızıyor? Paket Yakalamayla
“Düz metin gidiyor” cümlesi anlatıldığında soyut kalır, görüldüğünde kalmaz. Bu bölümün amacı onu görülebilir hale getirmek: aynı giriş işlemini iki kez yakalayıp, birinde ne okunduğunu diğerinde ne okunamadığını yan yana koymak.
Bunu kendi ağınızda deneyebilirsiniz ve denemelisiniz de. Anlatılan riskin gerçekten var olup olmadığını, kendi kurumunuzun trafiğinde bir kez görmek, on sayfa okumaktan daha ikna edicidir.
Aynı Girişi İki Kez Yakalamak: Port 80 ve Port 443
Bunu anlatmak yerine ölçtük. Lab ortamımızda web01 adlı Windows sunucusunda aynı giriş sayfası iki ayrı adresle yayında: biri iç sertifika otoritemizin imzaladığı sertifikayla 443 üzerinde, diğeri bilerek şifresiz bırakılmış halde 80 üzerinde. Trafiği aynı ağdaki üçüncü bir makineden, ntp01 adlı Linux sunucusundan kaydettik.
Kayıt için fazladan bir şey kurmaya gerek olmadı, tcpdump her dağıtımda hazır gelir:
sudo tcpdump -i ens33 -s 0 -w giris-80.pcap 'tcp port 80 and host 192.168.1.40'Kayıt açıkken aynı kullanıcı adı ve parolayı giriş adresine gönderdik:
curl -X POST -d 'user=ahmet.yilmaz&pass=Yaz2026.' \
http://portal-http.ad.sercebilisim.com/girisSonra aynı işi 443 üzerinde tekrarladık. İki kayıt elde ettik ve aralarındaki farkı aşağıda yan yana koyuyoruz.
Windows tarafındaysanız kayıt için ayrıca bir şey kurmanız gerekmez, işletim sistemiyle gelen pktmon aynı işi görür:
pktmon start --capture --pkt-size 0 --file giris-80.etl
pktmon stop
pktmon etl2pcap giris-80.etl --out giris-80.pcapngDüz Metin Parolanın Paket Dökümündeki Hali
Kaydı okumadan önce nereye bakacağınızı söyleyelim, çünkü döküm ilk bakışta kalabalık görünür. Üç şey aranıyor:
- İstek satırı: hangi metotla, hangi yola gidildiği.
- Başlıklar: isteğin kendisi hakkındaki bilgiler.
- En alttaki gövde satırı: formda ne yazıldıysa o.
80 numaralı porttaki kaydı açtığımızda çıkan şey aynen şu:
POST /giris HTTP/1.1
Host: portal-http.ad.sercebilisim.com
User-Agent: curl/8.5.0
Accept: */*
Content-Length: 31
Content-Type: application/x-www-form-urlencoded
user=ahmet.yilmaz&pass=Yaz2026.Satır satır ne olduğuna bakalım:
POST /giris HTTP/1.1: istek satırı. Sunucuya bir şey gönderildiğini ve hangi yola gittiğini söylüyor.Host:: hangi site adına konuşulduğu. İkinci bölümde anlattığımız, tek IP’de çok site barındırmayı mümkün kılan satır bu.Content-Type: application/x-www-form-urlencoded: gövdenin hangi yazım kuralıyla yazıldığı. Bir güvenlik biçimi değil, yalnızca bir biçim bildirimi.- Son satır : kullanıcı adı ve parola, hiçbir kodlama ya da gizleme olmadan, olduğu gibi.
Burada kırılan bir şifreleme yok, çünkü kurulan bir şifreleme de yoktu. Kartpostal, üstünde ne yazıyorsa onu taşıdı.
Sunucunun bu isteği reddetmesi hiçbir şeyi değiştirmiyor. Demo sayfası statik olduğu için sunucu 404 Not Found döndü, yani “böyle bir yol yok” dedi. Ama parola o cevaptan önce ağa çıkmıştı bile. Yolda dinleyen biri için sunucunun ne cevap verdiği önemsizdir; okunacak şey zaten gitmiştir. “Ama giriş başarısız oldu ki” itirazının cevabı budur.
Bir de dökümde görünmeyen ama gerçek hayatta orada olacak bir satır var: Cookie. Bizim isteğimizi bir komut satırı istemcisi gönderdiği için oturum bileti taşımıyordu. Tarayıcıdan gelen her istekte o başlık da bulunur ve birinci bölümde anlattığımız gibi her istekte yeniden yola çıkar.
Şimdi aynı gönderimi 443 üzerinden tekrarlayalım ve dökümün tam olarak aynı yerine bakalım. İsteğin gitmesi gereken pakette şu var:
IP 192.168.1.15.50138 > 192.168.1.40.443: Flags [P.], length 517
E..9..@.@..|.......(....1p.mkV^R...........
......cD...........b/...?...j>.cS.(...(k;.6u..K(.*!
...9.....3.....=.<.5./.....u.........portal.ad.sercebilisim.com....
.................h2.http/1.1.........1.....*.(...........Karşılaştırmayı yan yana koyun. Şifresiz kayıtta POST /giris, Host:, Content-Type: ve en altta parola vardı. Burada hiçbiri yok: istek satırı yok, başlık yok, gövde yok. Yaz2026 ve ahmet.yilmaz dizelerini bütün kayıtta arattık, sıfır sonuç.
İki kayıt arasında ölçülen ikinci bir fark daha var ve şifrelemenin bedelini gösteriyor: 80 tarafında 10 paket, 443 tarafında 31 paket. Aradaki fark, konuşmaya başlamadan önce yapılan pazarlıktır.
Ama şifreli kayıt tamamen okunmaz da değil, ve okunanlar rastgele değil. Yukarıdaki çöplüğün içinde iki dize seçiliyor:
portal.ad.sercebilisim.com: bağlanılmak istenen sitenin adı. Bu, el sıkışmanın ilk mesajında açık gitmek zorundadır, çünkü sunucu hangi sertifikayı sunacağını ancak adı öğrenirse bilir. Şifreleme daha kurulmamıştır.h2.http/1.1: istemcinin “şu sürümleri konuşabiliyorum” listesi. Protokol sürümü pazarlığı burada yapılır; makalenin ilerleyen bölümünde ele alacağımız HTTP/2 seçimi tam olarak bu satırda başlıyor.
Aynı kayıt üçüncü bir kategoriyi de gösteriyor. tcpdump yalnız bizim isteğimizi değil, o arayüzden geçen her şeyi kaydettiği için dökümde web01 sunucusunun bizimle hiç ilgisi olmayan başka bir adrese açtığı HTTPS bağlantısı da yer aldı. İçeriğini okuyamadık ama kimin kiminle konuştuğunu gördük. Yani içerik kapansa bile hedef IP adresi, port, zaman damgaları ve paket boyutları okunmaya devam ediyor: ne konuşulduğu gizlenir, ne zaman ve ne kadar konuşulduğu gizlenmez.
Yani şifreleme içeriği kapattı, kiminle ve nasıl konuşulduğunu kapatmadı. Zarf mesajı gizler, zarfın üstündeki adresi gizlemez: postacı ne yazdığınızı bilmez ama kime yazdığınızı bilir.
”İç Ağdayız, Sorun Olmaz” Neden Yanlış?
Bu noktada en sık duyulan itiraz şudur: uygulama internete açık değil, yalnız şirket içinden erişiliyor, o zaman şifrelemeye gerek yok.
Bu itirazın üç ayrı zayıf noktası var.
Birincisi, okumak için dışarıdan gelmek gerekmiyor. Yukarıdaki yakalama, hedef sunucuya değil aynı ağdaki bir makineye ihtiyaç duyar. Ele geçirilmiş tek bir bilgisayar, misafir ağından şirket ağına geçebilmiş bir cihaz, yanlış yapılandırılmış bir kablosuz erişim noktası ya da yönetim amacıyla açılmış bir yansıtma portu; hepsi aynı kapıyı açar. İç ağ, güvenilen ağ demek değildir.
İkincisi, sızan şey o uygulamayla sınırlı kalmıyor. Kurumsal iç uygulamalarda kullanıcılar genellikle domain hesaplarıyla oturum açar. Yani şifresiz bir iç panelden yakalanan parola, yalnız o paneli değil, aynı kimlikle erişilen her şeyi açar: dosya sunucusunu, e-postayı, uzak masaüstünü. Küçük görünen bir yönetim arayüzü, kimlik altyapısının tamamına açılan bir kapı haline gelir.
Üçüncüsü, saldırganın doğru anı beklemesi gerekmiyor. Birinci bölümde HTTP’nin durumsuz olduğunu ve oturum biletinin her isteğe yeniden eklendiğini görmüştük. Sonucu şu: parolayı yakalamak için tam giriş anını yakalamak gerekir, ama Cookie başlığını yakalamak için o oturum süresince herhangi bir an yeterlidir. Sayfa yenilemesi, arka planda giden bir istek, yüklenen bir görsel; her biri bileti tekrar yola çıkarır.
Bir de az konuşulan ikinci taraf var. Şifresiz bağlantıda risk yalnız okunmak değil, değiştirilmektir. Yol üstündeki bir taraf içeriği okuyabildiği gibi değiştirebilir de: sayfaya bir betik ekleyebilir, indirdiğiniz dosyayı başkasıyla değiştirebilir, formun gittiği adresi kendi adresiyle çevirebilir. TLS bu yüzden yalnız gizlilik değil, aynı zamanda bütünlük sağlar.
Ne zaman gerçekten önemsizdir: girişi olmayan, çerez kullanmayan, tamamen herkese açık ve salt okunur bir sayfada gizlilik açısından kaybedilecek bir şey yoktur. Ama yukarıdaki değiştirilme sorunu orada da geçerlidir; bu yüzden pratikte “şifresiz kalabilir” diyebileceğiniz sayfa neredeyse kalmamıştır.
Sorunun ne olduğunu gördük. Sıradaki bölüm, bu kartpostalı zarfa koyan mekanizmanın nasıl çalıştığını anlatıyor.
HTTPS Nedir? TLS El Sıkışması Adım Adım
Sorunu gördükten sonra çözüm sadeleşiyor. HTTPS ayrı bir protokol değildir. Aynı HTTP’dir: aynı istek satırı, aynı başlıklar, aynı durum kodları. Tek fark, bu konuşmanın TLS adlı bir katmanın içine alınmasıdır.
Kartpostal aynı kartpostaldır. Değişen tek şey, yola çıkmadan önce bir zarfa konması ve zarfın mühürlenmesidir.
El Sıkışmada Ne Konuşulur? Sürüm, Şifre Takımı, Anahtar
Zarf kendiliğinden oluşmaz. Taraflar veri alışverişine başlamadan önce kısa bir pazarlık yapar; buna el sıkışma (handshake) denir ve dört işi vardır:
- İstemci kendini tanıtır. Hangi TLS sürümlerini konuşabildiğini, hangi şifreleme yöntemlerini desteklediğini ve rastgele ürettiği bir sayıyı gönderir. Bu ilk mesajda ayrıca hangi siteye bağlanmak istediğini de söyler.
- Sunucu seçim yapar. Ortak listeden bir sürüm ve bir şifre takımı (cipher suite) seçer, kendi rastgele sayısını gönderir ve sertifikasını sunar.
- İki taraf ortak anahtarı üretir. Buranın altını çizmek gerekiyor, çünkü mekanizmanın en şaşırtıcı yeri burasıdır.
- Konuşma şifreye geçer. Bu noktadan sonra ağdan geçen her şey tek bir etikete iner: uygulama verisi.
Üçüncü maddeyi açalım. Sezgi der ki: bir tarafın diğerine şifreleme anahtarını göndermesi gerekir. Öyle olmuyor. Anahtar hiçbir zaman ağdan geçmez. İki taraf, açıkça değiş tokuş ettikleri parçalardan aynı sonucu ayrı ayrı hesaplar. Yolda dinleyen biri gidip gelen her şeyi kaydetse bile, o parçalardan ortak sonuca ulaşamaz.
Bu yüzden bir TLS bağlantısını “dinleyip sonra çözerim” diye kaydetmek işe yaramaz: kayıtta anahtar yoktur, çünkü anahtar hiç yola çıkmamıştır.
TLS sürümü arasındaki fark pratikte hissedilir. TLS 1.2’de el sıkışma iki gidiş dönüş sürer. TLS 1.3 bunu tek gidiş dönüşe indirdi, eski ve zayıf şifreleme yöntemlerini listeden tamamen çıkardı ve el sıkışmanın daha büyük bir kısmını şifreledi. Yani yeni sürüm hem daha güvenli hem daha hızlıdır; HTTPS’e geçmenin siteyi yavaşlatacağı endişesinin karşılığı büyük ölçüde burada kalkar. Bu farkın paket dökümündeki karşılığını, aynı sertifikayla iki sürüme bağlanıp 1.2 ile 1.3 arasında ağda neyin değiştiğini ölçtüğümüz yazıda gösterdik.
Şifreleme Neyi Gizler, Neyi Gizlemez: SNI ve DNS
Bir önceki bölümde şifreli kayıtta hâlâ görünen şeyler olduğunu söylemiştik. Şimdi bunun sebebini adlandırabiliriz.
| Görünmez | Görünür |
|---|---|
| İstek satırı ve adres yolu | Hedef IP adresi ve port |
Başlıklar (Cookie, Authorization dahil) | Zaman damgaları ve paket boyutları |
| İstek ve yanıt gövdesi | El sıkışmadaki site adı |
| Durum kodu | Öncesindeki DNS sorgusu |
Sağ sütunun son iki satırı en çok yanlış anlaşılan yerdir.
Site adı, el sıkışmanın ilk mesajında açık gider. Protokolde bu alanın adı SNI’dır (Server Name Indication); adında “sunucu” geçse de taşıdığı değer, sunucunun kendi adı değil istenen sitenin adıdır. Zaten sebebi de bu: tek IP adresinde birden çok site barındığında, sunucunun hangi sertifikayı sunacağını bilmesi gerekir ve bunu ancak istemci hangi siteyi istediğini söylerse bilebilir. Yani şifreleme kurulmadan önce adın söylenmesi lazımdır. Bunu da şifreleyen bir uzantı vardır ama henüz her yerde yaygın değildir.
DNS sorgusu ise bağlantıdan önce gider. Tarayıcı adresi çözmek için ismi sorar ve bu sorgu, ayrıca yapılandırılmadıysa düz metindir. Yani TLS kusursuz çalışsa bile, hangi siteye gittiğiniz bir katman aşağıda zaten söylenmiştir. İsim çözümünün nasıl işlediğini DNS nedir rehberinde ele alıyoruz.
Pratik sonuç şudur ve kurumsal ortamda doğrudan karşılığı vardır: TLS içeriği korur, kiminle konuştuğunuzu gizlemez. Bir güvenlik duvarı ya da kayıt sistemi, trafiği çözmeden de hangi sitelere gidildiğini görebilir.
Kilit Simgesi Ne Söyler, Ne Söylemez?
Adres çubuğundaki kilit, sanıldığından daha dar bir şey söyler. Tam olarak iki şeyi garanti eder:
- Bağlantı şifrelenmiştir, yol üstündeki taraflar içeriği okuyamaz ve değiştiremez.
- Sunucunun sunduğu sertifikadaki ad, adres çubuğundaki adla eşleşir ve sertifika tarayıcınızın güvendiği bir makam tarafından imzalanmıştır.
Söylemediği şey ise şudur: sitenin kendisinin dürüst olduğu. Bir saldırgan da kendi alan adı için geçerli bir sertifika edinebilir ve o sitede kilit sorunsuz görünür. Kilit “kimse dinlemiyor” demektir, “karşı taraf iyi niyetli” demek değildir. İki cümle sık sık birbirinin yerine kullanılır ve aradaki fark, kullanıcı eğitiminin en çok atladığı noktadır.
Bunun aynadaki görüntüsü de önemlidir. Sertifikadaki ad adresle eşleşmediğinde ya da imzalayan makam tanınmadığında tarayıcı uyarı basar. Kurum içinde kendinden imzalı sertifikalarla çalışan yönetim panelleri bu uyarıyı her gün ürettiği için, kullanıcılar zamanla o uyarıyı okumadan geçmeye alışır. Uyarı böylece işlevini kaybeder ve gerçekten önemli olduğu gün de tıklanıp geçilir.
İmzalayan makamın kim olduğu, bir imzanın neden taklit edilemediği ve kurumun kendi sertifika otoritesini nasıl kurduğu bu makalenin konusu değil; hepsi sertifika otoritesi nedir rehberinde ele alınıyor. Buradaki iş protokolü anlamaktı: zarf nasıl kapanıyor, içine ne giriyor, dışarıda ne kalıyor.
Zarfın nasıl kapandığını gördük. Sıradaki bölüm, aynı konuşmanın yıllar içinde nasıl hızlandığını anlatıyor.
HTTP/1.1, HTTP/2 ve HTTP/3: Neyin Değiştiği
Buraya kadar gördüğünüz her örnek HTTP/1.1’di ve bunun bir sebebi var: okunabilir olan sürüm o. Az önceki paket dökümünde POST /giris satırını gözünüzle okuyabildiniz. Bu bir şans değil, sürümün özelliği. Birazdan o özelliğin nasıl kaybolduğunu göreceğiz.
Bu bölüm aslında tek bir hikâye: bir sıra probleminin otuz yıl boyunca kovalanması. Her sürüm sırayı çözüyor, sonra altından bir sıra daha çıkıyor.
HTTP/1.1’in Sınırı: Sıra Bekleyen İstekler
Kural şuydu: bir bağlantı, aynı anda bir istek. İkinci istek, birincinin cevabı tamamen gelmeden yola çıkamaz.
Postacı benzetmesiyle: elinde tek kart taşıyan bir kurye. İkinci kartı almak için önce birinciyi teslim edip geri dönmesi gerekiyor. Kartlardan biri uzak bir adrese gidiyorsa, arkadaki bütün kartlar o dönene kadar bekliyor. Buna sıra başı tıkanması denir ve adı ne kadar teknik dursa da anlattığı şey bu kadar basit.
Tarayıcıların bu soruna bulduğu çözüm, çözüm olduğu kadar itiraf da: aynı siteye altı ayrı bağlantı açtılar. Bir kurye yetmiyorsa altı kurye tutarsınız. Bu sayı hâlâ geçerli, tarayıcılar bugün de aynı sınırla çalışıyor.
Bu, indirme yöneticilerinin ve torrent istemcilerinin yaptığı parça parça indirmeyle karıştırılmamalı: orada aynı dosyanın farklı aralıkları istenir (durum kodu 206), burada ise her bağlantı farklı bir dosya getirir.
Geliştiriciler de kendi taraflarında çareler üretti ve bugün geriye dönüp bakınca hepsi aynı cümleyi söylüyor: protokol izin vermiyorsa, dosya sayısını azaltalım. Küçük görseller tek bir dosyada birleştirildi. Betikler ve stiller tek pakete toplandı. Kaynaklar birden çok alan adına dağıtıldı, çünkü altı bağlantı sınırı alan adı başınaydı ve iki alan adı on iki bağlantı demekti.
Bu çözümlerin hepsi bugün gereksiz, bir kısmı zararlı. Çözdükleri sorun ortadan kalktı ama getirdikleri maliyet duruyor: tek dosyada birleştirilmiş bir paket, içindeki tek satır değiştiğinde tamamen yeniden indirilir. İnternette hâlâ dolaşan bu tavsiyelere denk gelirseniz, sorulacak soru “doğru mu” değil, “hangi sürüm için yazılmış”. Bu yazıların çoğu yazıldığı gün doğruydu; 2015’te HTTP/2 ile geçersizleştiler. Ama internet unutmaz: o sayfalar hâlâ orada duruyor, ve yapay zekayla üretilen yeni içerikler onları kaynak alıp bayat tavsiyeyi bayat olduğunu bilmeden yeniden dolaşıma sokuyor. Yani bugün karşınıza çıkan taze görünümlü bir “performans ipucu”, on yıl önce doğru olan bir cümlenin kopyasının kopyası olabilir. Bir tavsiyenin tarihine bakmak, doğruluğuna bakmak kadar önemli hale geldi.
HTTP/2 ve Sözde Başlıklar: Host Nasıl :authority Oldu?
HTTP/2 gökten inmedi. Google 2010’ların başında SPDY adlı deneysel bir protokol yazdı, kendi tarayıcısında ve sunucularında çalıştırdı, işe yaradığını sahada gösterdi; IETF de bunu HTTP/2’nin temeli olarak aldı. Aynı hikâye birazdan QUIC’te tekrar edecek. Kalıp şu: büyük bir uygulayıcı protokolü sahada kanıtlıyor, standart kurumu sonra yazıyor.
HTTP/2 sorunu bağlantı sayısını artırarak değil, tek bağlantıyı bölerek çözdü. Aynı bağlantı üzerinde onlarca istek iç içe geçmiş halde ilerler; biri yavaşladığında diğerleri beklemez. Kurye artık bütün kartları aynı anda taşıyor.
Bunu mümkün kılmak için protokol biçim değiştirdi ve metin olmaktan çıkıp ikili hale geldi. MDN bu değişikliği tek cümleyle özetliyor: HTTP/2 “elle okunamaz ve elle yazılamaz”.
O cümlenin bedelini aslında bu makalede zaten ödediniz. Dördüncü bölümdeki yakalamada parolayı okuyabildik. Aynı istek HTTP/2 üzerinden gitseydi, şifresiz bile olsa o dökümde POST /giris diye bir satır göremezdiniz; ikili çerçeveler ve sıkıştırılmış başlıklar görürdünüz. Yani o gösterimin çalışmasının sessiz bir ön koşulu vardı: düz HTTP’nin HTTP/1.1 olması.
Başlıklar da sıkıştırıldı, çünkü aynı sayfaya giden yüzlerce istek neredeyse aynı başlıkları tekrar tekrar taşıyor. Ve biçim değişince metinsel istek satırı ortadan kalktı; içindeki bilgiler ayrı alanlara dağıldı. Bu alanlara sözde başlık denir, adlarının başındaki iki nokta onları normal başlıklardan ayırır:
| HTTP/1.1 | HTTP/2 karşılığı |
|---|---|
GET /iletisim HTTP/1.1 | :method: GET + :path: /iletisim |
Host: sercebilisim.com | :authority: sercebilisim.com |
| (adres çubuğundaki şema) | :scheme: https |
Ayrıca HTTP/2’de başlık adlarının tamamı küçük harftir, bu bir üslup tercihi değil kuraldır.
Bunun günlük karşılığı şu: tarayıcınızın geliştirici araçlarında bir isteğin başlıklarına baktığınızda, bu makalenin ikinci bölümündeki ham dökümden farklı bir şey görürsünüz. Host yoktur, yerinde :authority durur. İlk kez karşılaşan biri gördüğüyle okuduğunun uyuşmadığını sanır; oysa ikisi de doğrudur, yalnız farklı sürümlerdir. Başında iki nokta olan bir alan gördüyseniz, baktığınız şey HTTP/1.1 değildir.
Bir de sessiz bir ön koşul var. HTTP/2 tanımı gereği şifresiz de çalışabilir, ama tarayıcıların hiçbiri bunu desteklemez. Pratikte HTTP/2 yalnız TLS üzerinden kullanılır. Yani “HTTPS’e geçersem sitem yavaşlar mı” sorusunun cevabı yalnız “hayır” değil, tam tersi: şifrelemeyi reddetmek, aynı zamanda hız kazancını da reddetmektir.
HTTP/3 ve QUIC: TCP’nin Bırakıldığı Yer
Şimdi hikâyenin en güzel yeri geliyor. HTTP/2 sırayı çözdü, herkes rahatladı, ve sonra bir katman aşağıya bakıldı.
Sıra oradaydı.
TCP verileri sırayla teslim etmek zorundadır. Tek bir paket kaybolduğunda, arkasından gelen her şey o paket yeniden gönderilene kadar bekletilir. Yani aynı bağlantıda taşınan onlarca istek, ilgisiz bir paket kaybı yüzünden hep birlikte durur. MDN bunu açıkça yazıyor: HTTP/2 tek bir TCP bağlantısı üzerinden koştuğu için, TCP katmanındaki kayıp yönetimi “bütün akışları bloke edebilir”.
Otuz yıllık kovalamacanın özeti: HTTP katmanındaki sırayı çözdük, altında TCP’nin sırası çıktı.
HTTP/3 bu yüzden TCP’yi bıraktı ve QUIC adlı bir taşımaya geçti. QUIC, UDP üstünde çalışır ve kayıp yönetimini her akış için ayrı yapar: kaybolan paket yalnız kendi akışını bekletir, komşularına dokunmaz.
Yanında üç şey daha geldi:
- El sıkışma birleşti. Cloudflare’in ifadesiyle QUIC “kriptografik ve taşıma el sıkışmalarını birleştirir”. Daha önce bağlandığınız bir sunucuya dönerken el sıkışmayı tamamen atlayabilirsiniz.
- Şifreleme bir katman aşağı indi. TLS artık üstüne sarılan ayrı bir katman değil, taşımanın içinde. Bunun beklenmedik bir yan etkisi var ve dördüncü bölümdeki gözlemimizi inceltiyor: QUIC paket numaralarını ve başlığın bir kısmını da şifreliyor. Yani şifreli bir kayıtta görünen üstveri, HTTP/3’te TLS-over-TCP’ye göre daha az.
- Bağlantı ağ değişince kopmuyor. Klasik bir bağlantı kaynak IP ve port çiftiyle tanımlanır; telefonunuz kablosuz ağdan mobil veriye geçtiğinde bu çift değişir ve bağlantı ölür. QUIC bağlantıyı adresten ayırıp bir kimlikle tanır, dolayısıyla ağ değişse de oturum devam eder. Bu, protokolün ilk tasarlandığı yıllarda var olmayan bir ihtiyaç: o zaman cihazlar cepte gezmiyordu.
Kurumsal ağda bilinmesi gereken tarafı ise güvenlik duvarındadır ve burada işler tersine döner. QUIC, 443 numaralı UDP portunu kullanır. Kurumların büyük kısmı dışarı çıkan trafikte TCP 443’e izin verir, UDP 443’ü ya hiç düşünmemiştir ya da bilerek kapatmıştır: kurumsal güvenlik ürünleri QUIC’i engellemeyi açıkça öneriyor, çünkü UDP üstündeki şifreli taşımayı vekil sunucuyla denetlemek zor.
Kapalıysa ortalıkta bir arıza görünmez. Tarayıcı sessizce HTTP/2’ye düşer ve her şey çalışmaya devam eder. Sorun tam olarak burada: hata mesajı yoktur, yalnız yavaşlık vardır. Bu yüzden “QUIC engelli mi” sorusu genellikle bir performans şikayeti üzerine, aylar sonra sorulur. Kendi ağınızda hangi sürümün kullanıldığını merak ediyorsanız, güvenlik duvarı kurallarınızda UDP 443’ün durumuna bakmak iyi bir başlangıçtır.
Bugün gelinen nokta ölçülü: W3Techs’in Ağustos 2026 ölçümüne göre sitelerin %40,1’i HTTP/3, %34,7’si HTTP/2 ile sunuluyor. Yani hikâyenin son perdesi hâlâ oynuyor.
Ve bütün bu değişim, sizin uygulamanız haberi olmadan yaşandı. Sürüm anlaşması tarayıcı ile sunucu arasında yapılır; kodunuza dokunmanız gerekmez. Protokolün otuz yılda üç kez biçim değiştirmesine rağmen GET, POST ve 404 hiç değişmedi. Değişen taşıma oldu, konuşmanın kendisi değil.
HTTP/1.1'de bir merdiven, HTTP/2'de tek bir sütun, HTTP/3'te yalnız bir çentik.Kurumsal Ağda HTTP Nerede Kalmış Olur?
Kurumların neredeyse tamamı web sitesini yıllar önce HTTPS’e taşıdı. Şifresiz kalan yer orası değil; iç ağ. Dışarıya bakan tek bir adres için sertifika alınır, iç ağdaki onlarca arayüz ise kimsenin listesinde olmadığı için olduğu gibi kalır.
Bu bölümün amacı o listeyi çıkarmanıza yardım etmek.
Şifresiz Kalan Tipik Yerler: Yönetim Panelleri, Yazıcılar, İç Araçlar
Danışmanlık verdiğim kurumlarda bu konuda iki ayrı tutum görüyorum ve aradaki fark, sanılanın aksine kurumun büyüklüğü değil.
Birinci tutum “çalışıyorsa elleme”. Sanallaştırma arayüzüne düz HTTP ile giriliyor, kimse rahatsız olmuyor, çünkü ekran açılıyor ve iş yürüyor. Bu kurumlardan gece ve hafta sonu telefon alıyorum. Aramalarında bir sakınca yok, işin parçası; ama tonu hep aynı oluyor: panik. Ve gün kurtarıldıktan sonra kalıcı çözüm bir daha gündeme gelmiyor.
İkinci tutumu ise en net, on beş kişilik bir işyerinde gördüm. Kendi sertifika sunucuları vardı ve sunucu sertifikalarına gösterdikleri özen orada kalmadı; zamanla başka her şeye yayıldı. Bir şeyi düzgün yapmaya başlayınca sıradakiler de sıraya giriyor.
Aradaki fark bütçe ya da çalışan sayısı değil. Aynı sektörde iki hekimli bir klinikle koca bir hastane aynı şey değildir, ama ikisi de kendi ölçeğinde ciddi olabilir. Belirleyici olan elindekiyle en iyisini yapma niyeti.
Bu iki tutumun ayrıldığı yer de şaşırtıcı biçimde hep aynı cihazlarda görünüyor:
- Ağ cihazlarının yönetim arayüzleri. Yönetilebilir switch’ler, güvenlik duvarları ve erişim noktaları çoğu zaman kutudan HTTP açık çıkar; kurulum sırasında hızlı olsun diye öyle bırakılır ve bir daha dönülmez.
- Yazıcılar ve çok fonksiyonlu cihazlar. Aşağıda ayrıca duracağım, çünkü en çok küçümsenen ve en pahalı olanı bu.
- Sunucuların bant dışı yönetim kartları. Makine kapalıyken bile ayakta olan, doğrudan donanıma erişim veren arayüzler.
- Kesintisiz güç kaynakları ve dağıtım üniteleri, kameralar, kayıt cihazları.
- İç uygulamalar. İzleme panoları, talep sistemleri, kurum içi wiki’ler ve yıllar önce yazılmış, kimsenin dokunmaya cesaret edemediği araçlar.
- Sanallaştırma yönetim arayüzleri.
Kendi ağınızda listeyi çıkarmak için başlangıç noktası, 80 dinleyip 443’e yönlendirmeyen cihazları bulmaktır:
nmap -p 80,443 --open 192.168.1.0/24Yazıcı maddesine geri dönelim, çünkü buradaki kayıp cihazın kendisiyle sınırlı değil. Kurumsal bir yazıcının web panelinde genellikle iki şey kayıtlıdır: tarama sonucunu bir paylaşıma yazabilmek için bir dosya sunucusu hesabı, ve kullanıcıları listeleyebilmek için bir dizin sorgu hesabı. İkisi de çoğu zaman domain hesabıdır. Yani panel şifresizse, o panele giden trafiği yakalayan biri yalnız yazıcının ayarlarını değil, kurumun dizinine bağlanan bir hesabı ele geçirir. Cihazın önemsizliği ile hesabın önemi arasındaki bu uçurum, listeyi çıkarmayı zorunlu kılan asıl sebeptir.
HTTP’den HTTPS’e Taşırken Atlanan Adımlar
Bir arayüzü HTTPS’e taşımak sertifikayı bağlamakla bitmiyor. Sık atlanan dört adım var:
1. Port 80 açık bırakılır. Sertifika bağlanır, https:// çalışır, ama http:// de çalışmaya devam eder. İki adres de açık olduğu sürece kimse yenisine geçmez; eski yer imleri, eski dokümanlar ve eski betikler eskisini kullanmaya devam eder. 80, ya kapatılmalı ya da kalıcı olarak 443’e yönlendirilmelidir.
2. Yönlendirme ilk isteği korumaz. Bu, en çok gözden kaçan ve en önemli maddedir. http:// adresine gidildiğinde tarayıcı önce şifresiz bir istek gönderir, yönlendirmeyi ondan sonra alır. O ilk istek boş değildir: tarayıcıda o site için bir çerez varsa, Cookie başlığı yönlendirmeden önce açıkta gitmiştir. Yani yönlendirme kullanıcıyı doğru yere taşır ama ilk paketi kurtarmaz.
3. Karışık içerik unutulur. Sayfanın kendisi HTTPS üzerinden gelirken içindeki bir betik, görsel veya çerçeve hâlâ http:// adresinden çekiliyorsa, tarayıcı ya o kaynağı engeller ya da uyarı verir. Adres çubuğu güvenli görünürken sayfanın bir parçası şifresiz gelmeye devam eder.
4. Arayüzü kullanan tek şeyin tarayıcı olmadığı unutulur. Bir panelin adresi değiştiğinde ona bağlanan ajanlar, yedekleme betikleri, izleme sistemleri ve entegrasyonlar da güncellenmelidir. Bunlar hata vermeden susar: ekranda hiçbir şey görünmez, yalnız veri akmaz olur. Taşıma planına bu tüketicilerin listesi de girmelidir.
Bir de sertifikanın kendisi bir bakım kalemidir. Süresi dolduğunda uyarı basan bir arayüz, kullanıcıları uyarıyı tıklayıp geçmeye alıştırır ve beşinci bölümde anlattığımız körelme başlar. İç sertifikaların bitiş tarihleri izlenmelidir; iç sertifika otoritesinin nasıl kurulduğu ve sertifikaların nasıl yenilendiği sertifika otoritesi nedir rehberinde ele alınıyor.
HSTS: Tarayıcıya “Bir Daha Sorma” Demek
İkinci maddedeki açığı, yani yönlendirmeden önceki o ilk şifresiz isteği kapatan mekanizmanın adı HSTS’tir (HTTP Strict Transport Security).
Çalışma biçimi basittir. Sunucu, HTTPS yanıtına bir başlık ekler:
Strict-Transport-Security: max-age=31536000; includeSubDomainsBu satır tarayıcıya şunu söyler: bu alan adı için bundan sonraki bir yıl boyunca, kullanıcı http:// yazsa bile hiç denemeden doğrudan https:// kullan. Tarayıcı bunu bir kez öğrendikten sonra artık şifresiz ilk istek diye bir şey kalmaz; yönlendirmeye de gerek kalmaz, çünkü istek zaten şifreli çıkar.
Zarf benzetmesinde HSTS, postaneye “bu adrese giden hiçbir şeyi kartpostal olarak kabul etme” talimatı vermektir.
Ama bu talimat yapışkandır ve geri alması zordur. İki tuzağı baştan bilin:
max-agesüresi tarayıcıda saklanır. Bir yıl verdikten sonra o alan adında şifresiz bir şey sunmanız gereken bir durum çıkarsa, kullanıcıların tarayıcıları bunu reddeder ve süre dolana kadar da reddetmeye devam eder. Bu yüzden doğru yol, önce kısa bir süreyle (birkaç dakika) yayınlayıp her şeyin çalıştığını doğrulamak, sonra süreyi uzun değere çıkarmaktır.includeSubDomainsgerçekten hepsini kapsar. Unuttuğunuz, yalnız HTTP konuşan eski bir alt alan adı varsa o da erişilemez hale gelir. Bu seçeneği açmadan önce alt alan adlarının tam listesini çıkarın.
Buradaki üç iş, aslında tek bir cümlenin karşılığıdır: kurumda hangi arayüzün hangi kapıdan konuştuğunu bilmek. O liste çıkarılmadan yapılan her iyileştirme, listede olmayan cihazı atlar.
Sonuç: Tek Harf, İki Ayrı Güvenlik Modeli
Baştan sona tek bir protokol anlattık. İstek satırı, başlıklar, gövde, durum kodu: HTTP’de ne varsa HTTPS’te de aynısı var. Adres çubuğundaki tek harflik fark taşınan şeyi değiştirmiyor, taşınma biçimini değiştiriyor. Kartpostalın metni zarfa girdiğinde de aynı metindir; değişen, yol boyunca kaç kişinin okuyabildiğidir.
Bu yüzden HTTP kusurlu bir protokol değildir. İşi taşımaktır, saklamak değil, ve taşıma işini otuz yılı aşkın süredir yapıyor. Saklama işi bir alt katmana aittir; o katman eklenmediğinde protokol bozulmaz, yalnızca yazdığınız her şeyi yazdığınız gibi taşır.
Anlatımların çoğu tam burada duruyor. Bir isteğin gövdesinde kullanıcı adının ve parolanın taşındığı yazılır, o gövdenin şifresiz bir bağlantıda okunabildiği yazılmaz. İki cümle arasındaki mesafe kısadır ve bütün mesele oradadır; paket yakalama bölümündeki yöntem de zaten o mesafeyi kapatmak için var, anlatılan riski görülebilir kılmak için.
Kurumsal tarafta ise iş protokolü anlamakla bitmiyor. Şifresiz kalan arayüzlerin listesi teknik bir ödev değil, bir envanter sorusudur:
Kurumunuzda kaç arayüz hâlâ kartpostalla konuşuyor?
Bu sorunun dürüst cevabı çoğu kurumda “bilmiyorum”dur, ve bu kötü bir cevap değil, doğru başlangıç noktasıdır. Listede olmayan cihaz iyileştirilemez; şifresiz olduğu fark edilmeyen bir panel de yıllarca öyle kalır. Kaybın büyüklüğünü belirleyen şey de o panelin önemi değil, üstünde kayıtlı hesabın yetkisidir.
Ağdaki diğer protokollerin birbirine nasıl bağlandığını kurumsal ağ protokolleri rehberinde, bu bağlantıları mümkün kılan güven zincirini sertifika otoritesi nedir makalesinde, bir web sunucusunda sertifikanın siteye nasıl bağlandığını ise IIS rehberimizde bulabilirsiniz.
Ek: Tüm HTTP Durum Kodları
Yukarıdaki bölüm hangi kodların birbirinden ayrılması gerektiğini anlatıyordu. Bu ek ise farklı bir soruyu cevaplıyor: başka hangi kodlar var?
Sayı sanıldığı kadar büyük değil. 100 ile 599 arasında beş yüz numara bulunmasına rağmen IANA kayıtlarında 64 girdi var, yani alanın yalnızca %13’ü kullanılıyor. Aradaki boşluklar Unassigned olarak duruyor ve ileride tanımlanmak üzere bekliyor. Kayıtlı 64 girdinin ikisi “kullanılmıyor” işaretli, biri geçici, biri de artık geçersiz; yani fiilen anlamı olan kod sayısı 60.
Listedeki kalın satırlar, makalede ayrıca ele alınanlardır.
1xx: Bilgilendirme
Sınıfların en az görüleni ve yaş olarak en bölünmüşü. Tarayıcı bunları kullanıcıya hiç göstermez, çünkü hepsi makineler arası bir el sıkışmanın parçasıdır. İlginç olan, aynı sınıfın otuz yıl arayla birbirinin zıddı iki problemi çözüyor olması. 100, bant genişliğinin pahalı olduğu yılların çözümüdür: büyük bir gövdeyi boşuna yüklememek için önce izin ister. Bugün çoğu istemci onu kapatıyor, çünkü fazladan bir gidiş dönüş artık boşa giden yüklemeden daha pahalı. 103 ise 2017’nin ürünüdür ve tam tersi bir dünyaya aittir: bant genişliği bollaşınca geriye kalan gecikmeyi kapatmak için, sayfa daha hazır değilken tarayıcıya “şu dosyaları şimdiden indirmeye başla” der.
| Kod | İngilizce adı | Ne demek |
|---|---|---|
100 | Continue | İsteğin başlığını aldım, gövdeyi göndermeye devam et |
101 | Switching Protocols | Başka bir protokole geçiyoruz; WebSocket el sıkışması burada olur |
102 | Processing | İşliyorum, bağlantıyı kapatma |
103 | Early Hints | Sayfa hazır değil ama şu kaynakları şimdiden indirmeye başla |
104 | Upload Resumption Supported | Yarım kalan yükleme sürdürülebilir; kayıt geçici |
2xx: Başarı
Kullanıcının fiilen gördüğü tek sınıf, çünkü bu sınıf çalıştığında ekranda bir şey belirir. Ama “başarılı” tek bir şey demek değil ve aradaki fark özellikle API yazarken önemlidir: 200 “işte cevap” der, 201 “yeni kayıt oluşturdum” der, 204 “yaptım ama gösterecek bir şey yok” der. Bir silme işleminin 200 yerine 204 dönmesi, kaprisli bir tercih değil, istemciye “gövdeyi okumaya çalışma” bilgisini vermektir.
| Kod | İngilizce adı | Ne demek |
|---|---|---|
200 | OK | İstek karşılandı, cevap gövdede |
201 | Created | Yeni kayıt oluşturuldu |
202 | Accepted | Aldım, sıraya koydum, sonucu henüz bilmiyorum |
203 | Non-Authoritative Information | Cevap doğru ama araya giren bir vekil sunucu onu değiştirdi |
204 | No Content | Başarılı, ama gösterilecek bir gövde yok |
205 | Reset Content | Başarılı, formu temizleyip yeniden başlat |
206 | Partial Content | Dosyanın istenen parçası gönderildi; indirmeye devam etme ve videoda atlama bunu kullanır |
207 | Multi-Status | Tek istekte birden çok işlem yapıldı, her birinin sonucu ayrı |
208 | Already Reported | Bu kaydın durumu aynı cevapta zaten bildirildi |
226 | IM Used | Cevap, dosyanın tamamı değil üstüne uygulanan fark |
3xx: Yönlendirme
Bu sınıf içeriğin kendisiyle değil kimliğiyle ilgilenir: aradığın şey aslında nerede duruyor? İçindeki dört kodun ikişerli bir ızgara oluşturması bu yüzden tesadüf değil. Bir eksende kalıcı mı geçici mi (301/308 karşısında 302/307), diğer eksende metot korunuyor mu (307/308 karşısında 302/301). Yönlendirme kurarken verilecek karar tek soru değil, bu iki sorudur.
| Kod | İngilizce adı | Ne demek |
|---|---|---|
300 | Multiple Choices | Birden çok karşılık var, seçim sende |
301 | Moved Permanently | Kalıcı olarak taşındı; tarayıcı bu kararı önbelleğe alır |
302 | Found | Geçici olarak başka adreste |
303 | See Other | İşlemi yaptım, sonucu şu adresten GET ile al |
304 | Not Modified | Değişmedi, elindeki kopyayı kullan |
305 | Use Proxy | Vekil sunucu üzerinden git; artık kullanılmıyor |
306 | (Unused) | Ayrılmış, kullanımda değil |
307 | Temporary Redirect | Geçici, ve metot korunur |
308 | Permanent Redirect | Kalıcı, ve metot korunur. Bu sitenin yönlendirmeleri bu kodu döner |
4xx: İstemci Hatası
Kayıtlı 64 kodun 29’u burada, yani listenin neredeyse yarısı. Bu bir tesadüf değil: bir istemcinin isteği bozmasının çok sayıda ayrı yolu var (yanlış metot, eksik başlık, kabul edilmeyen biçim, aşılan sınır, geçmeyen şart) ve protokol her birine ayrı bir numara vermeyi tercih etmiş. Nedeni pratik: sunucu ne yapmadığını ne kadar kesin söylerse, karşı taraf o kadar hızlı düzeltir. Bu sınıfta bol kod olması, istemcilerin çok hata yaptığı anlamına gelmez; hataların çok çeşitli olduğu anlamına gelir.
| Kod | İngilizce adı | Ne demek |
|---|---|---|
400 | Bad Request | İstek bozuk, sunucu ayrıştıramadı |
401 | Unauthorized | Seni tanımıyorum, kimlik göster |
402 | Payment Required | Ödeme gerekli; pratikte neredeyse hiç kullanılmaz |
403 | Forbidden | Seni tanıyorum ama bu işe yetkin yok |
404 | Not Found | Böyle bir adres yok |
405 | Method Not Allowed | Adres var ama bu metodu kabul etmiyor |
406 | Not Acceptable | İstediğin biçimde cevap üretemiyorum |
407 | Proxy Authentication Required | Önce vekil sunucuya kimlik göster |
408 | Request Timeout | İsteği tamamlamadın, bekleyemedim |
409 | Conflict | Kaydın güncel hali seninkiyle çakışıyor |
410 | Gone | Vardı, kalıcı olarak kaldırıldı. 404 ile farkı budur |
411 | Length Required | Gövde uzunluğunu bildirmen gerekiyor |
412 | Precondition Failed | Öne sürdüğün şart tutmadı |
413 | Content Too Large | Gönderdiğin gövde fazla büyük |
414 | URI Too Long | Adres fazla uzun |
415 | Unsupported Media Type | Bu biçimi kabul etmiyorum |
416 | Range Not Satisfiable | İstediğin aralık dosyanın dışında |
417 | Expectation Failed | Expect başlığındaki beklentiyi karşılayamam |
418 | (Unused) | Ayrılmış. Hikâyesi aşağıdaki kutuda |
421 | Misdirected Request | Bu istek bu sunucuya ait değil |
422 | Unprocessable Content | Biçim doğru ama içerik anlamsız; doğrulama hatalarında kullanılır |
423 | Locked | Kaynak kilitli |
424 | Failed Dependency | Bağlı olduğu işlem başarısız oldu |
425 | Too Early | Çok erken, şimdi işlemek riskli |
426 | Upgrade Required | Protokolü yükseltmeden devam edemezsin |
428 | Precondition Required | Şartsız gönderme, çakışma riski var |
429 | Too Many Requests | Çok sık istek attın, yavaşla |
431 | Request Header Fields Too Large | Başlıkların fazla büyük; genellikle şişmiş çerez |
451 | Unavailable For Legal Reasons | Hukuki sebeple erişime kapalı. Türkiye’deki erişim engellerinin karşılığı budur; hukuki çerçeve 5651 log yönetimi rehberimizde |
5xx: Sunucu Hatası
4xx’in tam tersi: 29’a karşı yalnız 11 kod, çünkü bir sunucunun başarısız olma biçimleri o kadar çeşitli değildir. Ama bu sınıfın asıl ayrımı sayıda değil, hatanın nerede olduğunda. 500 ile 501 sunucunun kendi arızasıdır. 502, 503 ve 504 ise çoğu zaman sunucunun kendisini değil, bağlı olduğu bir şeyi anlatır: arka uç uygulaması, veritabanı, başka bir servis. Bir arızada ilk soru bu yüzden “hangi kod” değil, “bu kod sunucuyu mu yoksa arkasındakini mi işaret ediyor” olmalıdır.
| Kod | İngilizce adı | Ne demek |
|---|---|---|
500 | Internal Server Error | Sunucuda beklenmedik bir hata; ayrıntı loglarda |
501 | Not Implemented | Bu metodu hiç desteklemiyorum |
502 | Bad Gateway | Arka uçtan anlamsız cevap geldi ya da bağlantı reddedildi |
503 | Service Unavailable | Servis geçici olarak kapalı ya da aşırı yüklü |
504 | Gateway Timeout | Arka uç bağlantıyı kabul etti ama zamanında cevap vermedi |
505 | HTTP Version Not Supported | Bu HTTP sürümünü konuşmuyorum |
506 | Variant Also Negotiates | Sunucunun içerik pazarlığı yapılandırması hatalı |
507 | Insufficient Storage | Depolama yetmedi |
508 | Loop Detected | İşlem kendi kendine döngüye girdi |
510 | Not Extended | Artık geçersiz sayılan bir uzantı isteniyor |
511 | Network Authentication Required | Ağa giriş yapman gerekiyor. Otel ve misafir ağlarındaki giriş sayfaları bunu kullanır; kurumsal tarafta aynı işi RADIUS ile 802.1X yapar |
Bu tablodaki kodların çoğunu meslek hayatınız boyunca hiç görmezsiniz. Kalın yazılanlar ise haftada birkaç kez karşınıza çıkar ve aralarındaki farkı bilmek, bir arızada nereye bakacağınızı doğrudan belirler. Onları ayırt edilmesi gereken çiftler bölümünde tek tek ele aldık.
HTTP ve HTTPS Hakkında Sık Sorulan Sorular
Yazan
İlker PehlivanBT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi
İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.
Benzer Makaleler
Kurumsal Ağ Protokolleri: DHCP'den LDAP'a
Bir şirketi ayakta tutan ağ protokolleri: DHCP, DNS, Kerberos, LDAP, SMB, RDP, SSH ve BGP. Hangisi ne yapar, nasıl zincirlenir, bozulduğunda nereden anlaşılır.
ARP Nedir? MAC Adresi, ARP Tablosu ve Spoofing
ARP, IP adresini MAC adresine çeviren protokoldür. ARP tablosu durumları, yayın alanı sınırı ve ARP spoofing, gerçek makineden alınmış paket dökümleriyle.
DHCP Nedir? Ağda IP Adresi Nasıl Dağıtılır?
DHCP nedir, nasıl çalışır? Ağdaki cihazlara IP adresi, subnet, gateway ve DNS bilgisinin otomatik dağıtımı: DORA akışı, kira süresi, APIPA ve DHCP relay.
DNS Nedir, Nasıl Çalışır? Kayıt Türleri ve TTL
DNS nedir, nasıl çalışır? Kök, TLD ve yetkili sunucu zinciri; A, CNAME, MX, TXT kayıtları; nameserver devri, TTL ve önbellek, nslookup ile arıza teşhisi.
Kurumsal Firewall Kurulumu, Yönetimi ve Danışmanlığı
Kurumsal firewall kurulumu, yönetimi ve danışmanlığı: Fortinet, Palo Alto ve pfSense ile kural yönetimi, IPS/IDS, VPN ve sürekli izleme hizmeti sunuyoruz.
ICMP Nedir? Ping, TTL ve Tracert Komutu
ICMP, ping ve tracert komutunun altında çalışan protokoldür. Request timed out, Destination host unreachable ve General failure farkı, lab ölçümleriyle.
IP Adresi Nedir? Subnet Maskesi, CIDR ve IPv6
IP adresi nedir, subnet maskesi ne işe yarar, /24 ne demek? Ağ ve host kısmı ayrımını, özel adres aralıklarını ve IPv6'yı gerçek lab ölçümleriyle anlatıyoruz.
Kurumsal Kablosuz Ağ Tasarımı: Survey'den Kuruluma
Kurumsal kablosuz ağ tasarımı: survey planlamadan access point yerleşimine, PoE kablolamadan kanal planına kadar 63 AP'lik bir projede izlenen gerçek sıra.
Kerberos Nedir? Kimlik Doğrulama ve Bilet Mantığı
Kerberos nedir, nasıl çalışır? Bilet mantığını, paket düzeyinde yakalanmış gerçek akışı ve oturum açılamadığında izlenecek teşhis sırasını adım adım gösteriyoruz.
LDAP ve LDAPS Nedir? Dizin Sorgulama ve 636 Portu
LDAP nedir, nasıl çalışır? Dizin yapısı, DN ve base DN mantığı, bind türleri ve 389 ile 636 farkı; gerçek paket yakalamalarıyla anlatıyoruz.
NFS Nedir? NAS ve Sanallaştırmada Dosya Paylaşımı
NFS nedir, nasıl çalışır? UID/GID kimlik modeli, root_squash ayarı, NFS ile SMB'nin aynı klasörde çakışması ve izin sorunlarının teşhisi, lab ölçümleriyle.
NTP Nedir? Kurumsal Ağda Saat Senkronizasyonu
NTP nedir, nasıl çalışır? Stratum hiyerarşisi, ağda tek saat kaynağı, Kerberos'un beş dakikalık toleransı ve saat arızalarında teşhis sırası.
Port Nedir? TCP ve UDP Farkı, Bağlantı Arızası Tespiti
Port numarası ne işe yarar, TCP ve UDP farkı nasıl işler, açık port nasıl kontrol edilir ve bağlantı kurulmadığında arıza hangi tarafta, nasıl kanıtlanır?
RADIUS Sunucusu Nedir? 802.1X ile Ağ Kimlik Doğrulama
RADIUS sunucusu nedir, nasıl çalışır? 802.1X akışını, EAP yöntemlerini ve ağa bağlanamayan kullanıcıda izlenecek teşhis sırasını paket düzeyinde gösteriyoruz.
SMB Nedir? Dosya Paylaşımı ve SYSVOL Bağımlılığı
SMB nedir, nasıl çalışır? Dosya ve yazıcı paylaşımı, sürüm farkları, SMBv1 riski ve grup ilkelerinin SYSVOL üzerinden dağıtımı.
SSH Nedir? Şifreli Yönetim ve Anahtar Tabanlı Giriş
SSH nedir, port 22'de el sıkışma nasıl olur, ana bilgisayar anahtarı neyi kanıtlar, sürüm 1 neden kapatılmalı ve parola yerine anahtarla giriş nasıl kurulur.
Kurumsal Switch, Router Kurulumu ve VLAN Yapılandırma
Kurumsal switch, router kurulumu ve VLAN yapılandırma: HSRP/VRRP yedekliliği, port güvenliği ve doğru mimari danışmanlığıyla güvenilir ağ altyapısı kuruyoruz.
Telnet Nedir? Şifresiz Yönetim Protokolü ve Riskleri
Telnet nedir, port 23 nasıl çalışır, parolayı neden düz metin taşır ve hâlâ açık bulunan cihazlarda ne yapılmalı: kapatma, SSH'a geçiş ve yönetim VLAN'ı.
VLAN Nedir? 802.1Q Etiketi, Access ve Trunk Farkı
VLAN tek switch'i mantıksal ağlara böler. 802.1Q etiketi, access ile trunk portun farkı ve native VLAN riski, gerçek paket dökümleriyle anlatılıyor.
NAT Nedir? Ağ Adresi Çevirisi Nasıl Çalışır?
NAT (Network Address Translation) nedir, SNAT ile DNAT farkı nedir, PAT nasıl çalışır ve NAT tablosu ne tutar? Çeviri tablosunu lab ortamında açıp gösteriyoruz.
RDP Nedir? Uzak Masaüstü Protokolü ve Güvenliği
RDP (Remote Desktop Protocol) nedir, 3389 portu ne yapar ve NLA ne işe yarar? Uzak masaüstü protokolünü Windows sunucuda ölçtük, güvenlik tarafıyla birlikte.
SNMP Nedir? MIB, OID ve Trap Mekanizması
SNMP nedir ve nasıl çalışır? Yönetici ve ajan mimarisi, MIB ile OID kataloğu, poll ve trap arasındaki fark, community string riski ve SNMPv3 ile çözümü.
Syslog Nedir? Facility, Severity ve 514 Portu
Syslog nedir, log satırı neye benzer? Facility ile severity tek sayıya nasıl sıkışır, 514 portu neden UDP: gerçek switch çıktısıyla anlatıyoruz.
FTP, FTPS ve SFTP Nedir? Aralarındaki Fark
FTP, FTPS ve SFTP arasındaki fark: iki kanallı mimari, aktif ve pasif mod, firewall arkasında kırılan aktarımlar ve paket düzeyinde şifresiz dosya kanıtı.
TFTP Nedir? Port 69, Switch Yedeği ve PXE
TFTP nedir, UDP 69 üzerinden nasıl çalışır ve switch yapılandırma yedeği neden bu protokolle alınır? Gerçek paket dökümü, PXE boot ve SFTP karşılaştırması.
TLS Nedir? SSL ile Farkı, Sürüm Pazarlığı ve Ölçümü
TLS nedir, SSL ile farkı ne? El sıkışmada sürüm ve şifre takımı nasıl seçilir, TLS 1.2 ile 1.3 arasında pakette ne değişir, sunucunuz hangisini konuşuyor?
IMAP Nedir, POP3 Nedir? Aralarındaki Fark
IMAP ile POP3 arasındaki fark: durumun sunucuda mı cihazda mı tutulduğu, 993 ve 995 portları, kota dolunca ne olur ve POP3'ten IMAP'a geçişin gerçek maliyeti.
SMTP Nedir? Mail Nasıl Gönderilir ve Neden Gitmez?
SMTP nedir, mail nasıl gönderilir: zarf ile başlık ayrımı, 25/587/465 portlarının farkı, STARTTLS öncesi düz metin okunan oturum ve gitmeyen mailin teşhisi.
Yapısal Kablolama ve Zayıf Akım: Kurumsal Bina Altyapısı
Kurumsal binada yapısal kablolama ve zayıf akım sistemleri nasıl kurulur? Kat kablolaması, kabinet düzeni, CAT6 ve fiber seçimi, test raporu ve saha hataları.
İçindekiler
Ücretsiz Değerlendirme
Kaç iç arayüzünüz hâlâ şifresiz HTTP'de? Envanteri çıkarıp HTTPS'e taşıyalım.
Ana Hizmet
Kurumsal Network Kurulumuİlgili Makaleler
- Kurumsal Ağ Protokolleri: DHCP'den LDAP'a
- ARP Nedir? MAC Adresi, ARP Tablosu ve Spoofing
- DHCP Nedir? Ağda IP Adresi Nasıl Dağıtılır?
- DNS Nedir, Nasıl Çalışır? Kayıt Türleri ve TTL
- Kurumsal Firewall Kurulumu, Yönetimi ve Danışmanlığı
- ICMP Nedir? Ping, TTL ve Tracert Komutu
- IP Adresi Nedir? Subnet Maskesi, CIDR ve IPv6
- Kurumsal Kablosuz Ağ Tasarımı: Survey'den Kuruluma
- Kerberos Nedir? Kimlik Doğrulama ve Bilet Mantığı
- LDAP ve LDAPS Nedir? Dizin Sorgulama ve 636 Portu
- NFS Nedir? NAS ve Sanallaştırmada Dosya Paylaşımı
- NTP Nedir? Kurumsal Ağda Saat Senkronizasyonu
- Port Nedir? TCP ve UDP Farkı, Bağlantı Arızası Tespiti
- RADIUS Sunucusu Nedir? 802.1X ile Ağ Kimlik Doğrulama
- SMB Nedir? Dosya Paylaşımı ve SYSVOL Bağımlılığı
- SSH Nedir? Şifreli Yönetim ve Anahtar Tabanlı Giriş
- Kurumsal Switch, Router Kurulumu ve VLAN Yapılandırma
- Telnet Nedir? Şifresiz Yönetim Protokolü ve Riskleri
- VLAN Nedir? 802.1Q Etiketi, Access ve Trunk Farkı
- NAT Nedir? Ağ Adresi Çevirisi Nasıl Çalışır?
- RDP Nedir? Uzak Masaüstü Protokolü ve Güvenliği
- SNMP Nedir? MIB, OID ve Trap Mekanizması
- Syslog Nedir? Facility, Severity ve 514 Portu
- FTP, FTPS ve SFTP Nedir? Aralarındaki Fark
- TFTP Nedir? Port 69, Switch Yedeği ve PXE
- TLS Nedir? SSL ile Farkı, Sürüm Pazarlığı ve Ölçümü
- IMAP Nedir, POP3 Nedir? Aralarındaki Fark
- SMTP Nedir? Mail Nasıl Gönderilir ve Neden Gitmez?
- Yapısal Kablolama ve Zayıf Akım: Kurumsal Bina Altyapısı