--- title: "HTTPS'in Rolü" source: 'https://academia.sh/tr/kurslar/internet-nasil-calisir/httpsin-rolu' course: 'İnternet Nasıl Çalışır' language: tr updated: '2026-08-17T18:07:05+00:00' license: 'CC BY-SA 4.0' --- # HTTPS'in Rolü Şifreleme, kimlik doğrulama ve bütünlük sözleri; sertifikanın adı açık anahtara bağlaması ve güven çıpalarının rolü. Önceki ders, adresin şema bölümü `https` olduğunda bir güvenlik el sıkışması yapıldığını söyleyip geçmişti. Bu ders o adımı açar. HTTP İstek ve Yanıtı dersinde görüldüğü gibi istek ve yanıt düz metindir. Bu metin, Ağ Nedir dersinde kurulan yol boyunca çok sayıda ara düğümden geçer ve bu düğümler İnternetin Yapısı dersinde belirtildiği üzere farklı kuruluşların denetimindedir. Düz metin, yol üzerindeki her düğüm tarafından okunabilir ve değiştirilebilir. **HTTPS**, HTTP'nin **TLS** adı verilen bir güvenlik katmanı üzerinden taşınmasıdır. Protokolün kendisi değişmez; taşındığı kanal değişir. ## Üç Söz TLS üç ayrı söz verir. Bunları ayırmak önemlidir, çünkü yaygın karışıklık üçünü tek bir "şifreleme" başlığı altında toplamaktan doğar. **Gizlilik.** Alışverişin içeriği, iki uç dışında kimse tarafından okunamaz. Yol üzerindeki düğümler şifreli baytları taşır, anlamlarını göremez. **Bütünlük.** İçerik yolda değiştirilirse bu değişiklik saptanır. Değişikliğin engellenmesi değil, **fark edilmesi** söz konusudur; bozulmuş veri sessizce kabul edilmez. **Kimlik doğrulama.** Bağlanılan tarafın gerçekten o ad olduğu doğrulanır. Üçüncü söz olmadan ilk ikisi anlamsızdır. Aradaki bir düğüm bağlantıyı kesip kendisini sunucu gibi tanıtabilirse, sizinle arasında şifreli bir kanal kurar; içerik gizli ve bütün olur, ancak yanlış tarafla. Kimliği doğrulanmamış bir şifreleme, konuştuğunuz kişinin kim olduğunu bilmeden fısıldamaktır. Bu yüzden zor olan bölüm şifreleme değil, kimlik doğrulamadır. Şifreleme matematiksel bir problemdir; kimlik doğrulama, hiç tanışmadığınız bir tarafın kim olduğuna nasıl karar vereceğiniz sorusudur. ## Sertifika Kimlik doğrulama **sertifika (certificate)** ile yapılır. Sertifika, üç şeyi bir arada taşıyan bir belgedir: bir ad, o ada ait bir açık anahtar ve bu ikisinin birlikteliğini onaylayan bir imza. Sertifikanın kurduğu bağ şudur: **bu açık anahtar bu ada aittir.** Sunucu, karşılık gelen özel anahtarı elinde tuttuğunu el sıkışma sırasında kanıtlar. Böylece "bu ada bağlanmak istiyorum" ile "bu anahtarın sahibiyle konuşuyorum" ifadeleri birleşir. Bir sertifika yerel olarak üretilebilir. Aşağıdaki komut, `ornek.test` adı için bir anahtar çifti ve sertifika oluşturur: ```sh openssl req -x509 -newkey rsa:2048 -nodes \ -keyout anahtar.pem -out sertifika.pem -days 3650 \ -subj "/CN=ornek.test" -addext "subjectAltName=DNS:ornek.test" ``` Üretilen sertifikanın kimlik alanları incelendiğinde: ```sh openssl x509 -in sertifika.pem -noout -subject -issuer openssl x509 -in sertifika.pem -noout -ext subjectAltName ``` ``` subject=CN=ornek.test issuer=CN=ornek.test X509v3 Subject Alternative Name: DNS:ornek.test ``` İki alan aynıdır. **Konu (subject)** sertifikanın kime ait olduğunu, **veren (issuer)** onu kimin onayladığını söyler. İkisinin aynı olması sertifikanın kendi kendini onayladığı anlamına gelir; buna **kendinden imzalı** sertifika denir. Kendinden imzalı bir sertifikanın kanıt değeri yoktur. Bu belge, "ben `ornek.test` adıyım, çünkü öyle diyorum" demektedir. Herkes aynı belgeyi herhangi bir ad için üretebilir. ## Güven Çıpaları Sorun şu hâle gelir: bir sertifikanın doğru olduğuna kim karar verecek? Yanıt, doğrudan tanımadığınız bir tarafı, tanıdığınız bir tarafın onayına dayanarak kabul etmektir. **Sertifika yetkilisi (certificate authority)**, adın gerçekten başvurana ait olduğunu sınadıktan sonra sertifikayı kendi anahtarıyla imzalayan kuruluştur. İstemcide önceden yüklü, doğrudan güvenilen bir sertifika kümesi bulunur; bunlara **güven çıpası (trust anchor)** denir. Doğrulama, sunucunun sertifikasından başlayıp imzalayanları izleyerek bu kümeden birine ulaşmayı dener. Ulaşırsa sertifika kabul edilir; ulaşamazsa edilmez. Bu, güveni bir zincire indirger. Zincirin son halkası, istemcinin önceden sahip olduğu bir şeydir; sıfırdan güven üretilmez, var olan güven aktarılır. Bu sertifikayla bir sunucu çalıştırılabilir. Sunucu, HTTP İstek ve Yanıtı dersindekiyle aynıdır; tek fark, dinleyen soketin TLS ile sarılmasıdır: ```python import ssl from http.server import BaseHTTPRequestHandler, HTTPServer class Isleyici(BaseHTTPRequestHandler): protocol_version = "HTTP/1.1" def log_message(self, bicem: str, *arg: object) -> None: pass def do_GET(self) -> None: govde = b"

Ornek Sayfa

\n" self.send_response_only(200) self.send_header("Content-Type", "text/html; charset=utf-8") self.send_header("Content-Length", str(len(govde))) self.end_headers() self.wfile.write(govde) baglam = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER) baglam.load_cert_chain("sertifika.pem", "anahtar.pem") sunucu = HTTPServer(("127.0.0.1", 8443), Isleyici) sunucu.socket = baglam.wrap_socket(sunucu.socket, server_side=True) sunucu.serve_forever() ``` Sunucu çalışırken bağlanıldığında doğrulama başarısız olur: ```sh curl -sS --resolve ornek.test:8443:127.0.0.1 https://ornek.test:8443/ ``` ``` curl: (60) SSL certificate problem: self signed certificate More details here: https://curl.se/docs/sslcerts.html ``` İstek yanıtsız kaldı; çıkış kodu 60'tır. Sertifika geçerli bir belgedir, ad da doğrudur — ancak imzalayanı istemcinin güven kümesinde yoktur. İleti metni araca göre değişebilir; değişmeyen, doğrulamanın başarısız olması ve bağlantının kurulmamasıdır. Aynı sertifika güven çıpası olarak verildiğinde bağlantı kurulur: ```sh curl -s --cacert sertifika.pem --resolve ornek.test:8443:127.0.0.1 https://ornek.test:8443/ ``` ```

Ornek Sayfa

``` Sunucu, sertifika ve anahtar aynıdır. Değişen tek şey istemcinin neye güvendiğidir. Bu, güvenin sertifikanın bir özelliği değil, **istemcinin bir kararı** olduğunu gösterir. ## Ad Denetimi Sertifikanın geçerli olması yetmez; taşıdığı adın bağlanılan adla eşleşmesi de gerekir. Yukarıdaki sertifika güvenilir sayılırken başka bir adla bağlanıldığında: ```sh curl -sS --cacert sertifika.pem --resolve baska.test:8443:127.0.0.1 https://baska.test:8443/ ``` ``` curl: (60) SSL: no alternative certificate subject name matches target host name 'baska.test' More details here: https://curl.se/docs/sslcerts.html ``` Sertifika güvenilir bir imza taşıyor, ancak `ornek.test` adı için düzenlenmiş. `baska.test` adına bağlanan istemci bunu kabul etmez. Bu denetim olmasaydı, herhangi bir ad için geçerli sertifikası olan bir taraf, başka her adın yerine geçebilirdi. Sertifika bir anahtarı **belirli bir ada** bağlar; bağ, adı da kapsar. ## El Sıkışma El sıkışma iki işi birlikte yürütür. **Anahtar üzerinde anlaşma.** İki taraf, o oturuma özgü bir şifreleme anahtarı üretir. Bu anahtar ağ üzerinden gönderilmez; iki tarafın alışverişinden türetilir. Yolda dinleyen biri tüm alışverişi kaydetse bile anahtarı hesaplayamaz. **Kimliğin kanıtlanması.** Sunucu sertifikasını gönderir ve karşılık gelen özel anahtara sahip olduğunu, o anahtarla yapabileceği bir işlemle gösterir. Sertifikayı kopyalamak yeterli değildir; özel anahtar olmadan kimlik kanıtlanamaz. Bunlar tamamlandıktan sonra HTTP alışverişi başlar ve bu noktadan sonra protokol, önceki derslerde tanımlanan biçimin aynısıdır. Şifreleme HTTP'yi değiştirmez, sarar. Oturum anahtarının her bağlantı için yeniden üretilmesinin bir sonucu vardır: özel anahtar sonradan ele geçirilse bile, önceden kaydedilmiş alışverişler çözülemez. Bu özellik, anahtar anlaşma yönteminin seçimine bağlıdır. ## HTTPS Neyi Gizlemez Verilen sözlerin sınırlarını bilmek, sözlerin kendisini bilmek kadar önemlidir. **Ad çözümleme gizlenmez.** Bağlantı kurulmadan önce Alan Adı Sistemi dersindeki sorgu yapılır ve bu sorgu TLS'in dışındadır. Hangi ada bağlanmak istediğiniz, o sorguyu gören taraflarca bilinir. **Hedef adres gizlenmez.** Paketlerin başlıkları şifrelenemez; şifrelenselerdi yönlendirilemezlerdi. Kiminle konuştuğunuz yol üzerindeki düğümlerce görülür. **Trafiğin büyüklüğü ve zamanlaması gizlenmez.** Ne kadar veri gittiği ve ne zaman gittiği gözlenebilir. Bu bilgiler tek başına içeriği vermez ama çıkarım yapmaya elverişlidir. **İçeriğin doğruluğu güvence altında değildir.** TLS, karşı tarafın iddia ettiği ad olduğunu doğrular; söylediğinin doğru olduğunu değil. Doğrulanmış bir sitenin yanlış bilgi vermesi protokolün ilgi alanında değildir. Bu ayrım pratik bir sonuç doğurur: bir bağlantının şifreli olması, karşı tarafın güvenilir olduğu anlamına gelmez. Doğrulanan şey kimliktir, niyet değil. ## Özet - HTTPS, HTTP'nin TLS üzerinden taşınmasıdır; protokolün biçimi değişmez, kanal değişir. - TLS gizlilik, bütünlük ve kimlik doğrulama sözlerini birlikte verir; kimlik doğrulama olmadan ilk ikisi yanlış tarafla kurulabilir. - Sertifika, bir açık anahtarı belirli bir ada bağlar ve bu bağı bir imzayla onaylar. - Kendinden imzalı sertifikada konu ile veren aynıdır ve kanıt değeri yoktur; doğrulama, imza zincirini istemcideki güven çıpalarından birine ulaştırmayı dener. - Sertifikanın geçerliliği yetmez; taşıdığı adın bağlanılan adla eşleşmesi ayrıca sınanır. - HTTPS ad çözümleme sorgusunu, hedef adresi, trafik büyüklüğünü ve zamanlamasını gizlemez; içeriğin doğruluğuna ilişkin bir söz de vermez. ## Sonraki Adım Zincirin bütün halkaları artık ayrı ayrı kurulmuş durumda: paket anahtarlama, adresleme, ad çözümleme, barındırma, HTTP alışverişi ve güvenli kanal. Son ders bunları tek bir isteğin üzerinde baştan sona birleştirecek, her aşamanın hangi bilgiyi bir sonrakine devrettiğini gösterecek ve her halkanın kopması durumunda ortaya çıkan belirtileri sıralayacak.