HTTPS Hakkında¶

HTTPS’in sadece "açık" ya da "kapalı" olan bir şey olduğunu düşünmek kolaydır.

Ancak bundan çok daha karmaşıktır.

Bir kullanıcı gözüyleHTTPS’in temellerini öğrenmek içinhttps://howhttps.works/ adresine bakın.

Şimdi degeliştirici perspektifinden, HTTPS hakkında düşünürken akılda tutulması gereken birkaç nokta:

• HTTPS içinserver’ın,üçüncü bir taraf tarafından verilen"sertifikalara" sahip olması gerekir.
  • Bu sertifikalar aslında üçüncü tarafça "üretilmez", üçüncü taraftantemin edilir.
• Sertifikaların birgeçerlilik süresi vardır.
  • Süresidolar.
  • Sonrasındayenilenmeleri, üçüncü taraftanyeniden temin edilmeleri gerekir.
• Bağlantının şifrelenmesiTCP seviyesinde gerçekleşir.
  • Bu,HTTP’nin bir katman altıdır.
  • Dolayısıylasertifika ve şifreleme işlemleriHTTP’den önce yapılır.
• TCP "domain"leri bilmez. Yalnızca IP adreslerini bilir.
  • İstenenspesifik domain bilgisiHTTP verisinin içindedir.
• HTTPS sertifikaları belirli birdomain’i "sertifikalandırır"; ancak protokol ve şifreleme TCP seviyesinde, hangi domain ile çalışıldığıhenüz bilinmeden gerçekleşir.
• Varsayılan olarak bu, IP adresi başına yalnızcabir HTTPS sertifikası olabileceği anlamına gelir.
  • Server’ınız ne kadar büyük olursa olsun ya da üzerindeki her uygulama ne kadar küçük olursa olsun.
  • Ancak bunun birçözümü vardır.
• TLS protokolüne (TCP seviyesinde, HTTP’den önce şifrelemeyi yapan) eklenenSNI adlı birextension vardır.
  • Bu SNI extension’ı, tek bir server’ın (tek birIP adresiyle)birden fazla HTTPS sertifikası kullanmasına vebirden fazla HTTPS domain/uygulama sunmasına izin verir.
  • Bunun çalışması için server üzerinde,public IP adresini dinleyen tek bir bileşenin (programın) server’dakitüm HTTPS sertifikalarına sahip olması gerekir.
• Güvenli bir bağlantı elde edildiktensonra, iletişim protokolühâlâ HTTP’dir.
  • İçerikler,HTTP protokolü ile gönderiliyor olsa bileşifrelenmiştir.

Yaygın yaklaşım, server’da (makine, host vb.) çalışantek bir program/HTTP server bulundurupHTTPS ile ilgili tüm kısımları yönetmektir:şifreli HTTPS request’leri almak, aynı server’da çalışan gerçek HTTP uygulamasına (bu örnekteFastAPI uygulaması)şifresi çözülmüş HTTP request’leri iletmek, uygulamadan gelenHTTP response’u almak, uygunHTTPS sertifikası ileşifrelemek veHTTPS ile client’a geri göndermek. Bu server’a çoğu zamanTLS Termination Proxy denir.

TLS Termination Proxy olarak kullanabileceğiniz seçeneklerden bazıları:

• Traefik (sertifika yenilemelerini de yönetebilir)
• Caddy (sertifika yenilemelerini de yönetebilir)
• Nginx
• HAProxy

Let's Encrypt¶

Let's Encrypt’ten önce buHTTPS sertifikaları, güvenilen üçüncü taraflar tarafından satılırdı.

Bu sertifikalardan birini temin etme süreci zahmetliydi, epey evrak işi gerektirirdi ve sertifikalar oldukça pahalıydı.

SonraLet's Encrypt ortaya çıktı.

Linux Foundation’ın bir projesidir.HTTPS sertifikalarını ücretsiz ve otomatik bir şekilde sağlar. Bu sertifikalar tüm standart kriptografik güvenliği kullanır ve kısa ömürlüdür (yaklaşık 3 ay). Bu yüzden, ömürleri kısa olduğu içingüvenlik aslında daha iyidir.

Domain’ler güvenli şekilde doğrulanır ve sertifikalar otomatik üretilir. Bu sayede sertifikaların yenilenmesini otomatikleştirmek de mümkün olur.

Amaç, bu sertifikaların temin edilmesi ve yenilenmesini otomatikleştirerekücretsiz, kalıcı olarak güvenli HTTPS sağlamaktır.

Geliştiriciler İçin HTTPS¶

Burada, bir HTTPS API’nin adım adım nasıl görünebileceğine dair, özellikle geliştiriciler için önemli fikirlere odaklanan bir örnek var.

Domain Adı¶

Muhtemelen her şey, birdomain adıtemin etmenizle başlar. Sonra bunu bir DNS server’ında (muhtemelen aynı cloud provider’ınızda) yapılandırırsınız.

Muhtemelen bir cloud server (virtual machine) ya da benzeri bir şey alırsınız ve bununsabit birpublic IP adresi olur.

DNS server(lar)ında, bir kaydı ("A record")domain’inizi server’ınızınpublic IP adresine yönlendirecek şekilde yapılandırırsınız.

Bunu büyük olasılıkla ilk kurulumda, sadece bir kez yaparsınız.

DNS¶

Şimdi gerçek HTTPS parçalarına odaklanalım.

Önce tarayıcı, bu örnektesomeapp.example.com olan domain içinIP’nin ne olduğunuDNS server’larına sorar.

DNS server’ları tarayıcıya belirli birIP adresini kullanmasını söyler. Bu, DNS server’larında yapılandırdığınız ve server’ınızın kullandığı public IP adresidir.

TLS Handshake Başlangıcı¶

Tarayıcı daha sonra bu IP adresiyle443 portu (HTTPS portu) üzerinden iletişim kurar.

İletişimin ilk kısmı, client ile server arasında bağlantıyı kurmak ve hangi kriptografik anahtarların kullanılacağına karar vermek vb. içindir.

Client ile server arasındaki, TLS bağlantısını kurmaya yönelik bu etkileşimeTLS handshake denir.

SNI Extension’ı ile TLS¶

Server’da, belirli birIP adresindeki belirli birportu dinleyenyalnızca bir process olabilir. Aynı IP adresinde başka portları dinleyen başka process’ler olabilir, ancak IP+port kombinasyonu başına yalnızca bir tane olur.

TLS (HTTPS) varsayılan olarak443 portunu kullanır. Yani ihtiyaç duyacağımız port budur.

Bu portu yalnızca bir process dinleyebileceği için, bunu yapacak processTLS Termination Proxy olur.

TLS Termination Proxy, bir ya da daha fazlaTLS sertifikasına (HTTPS sertifikası) erişebilir.

Yukarıda bahsettiğimizSNI extension’ını kullanarak TLS Termination Proxy, bu bağlantı için elindeki TLS (HTTPS) sertifikalarından hangisini kullanacağını kontrol eder; client’ın beklediği domain ile eşleşen sertifikayı seçer.

Bu örnektesomeapp.example.com sertifikasını kullanır.

Client, bu TLS sertifikasını üreten kuruluşa zatengüvenir (bu örnekte Let's Encrypt; birazdan ona da geleceğiz). Bu sayede sertifikanın geçerli olduğunudoğrulayabilir.

Ardından client ve TLS Termination Proxy, sertifikayı kullanarakTCP iletişiminin geri kalanını nasıl şifreleyeceklerine karar verir. BöyleceTLS Handshake kısmı tamamlanır.

Bundan sonra client ve server arasındaşifreli bir TCP bağlantısı vardır; TLS’in sağladığı şey budur. Sonra bu bağlantıyı kullanarak gerçekHTTP iletişimini başlatabilirler.

VeHTTPS de tam olarak budur: şifrelenmemiş bir TCP bağlantısı yerine,güvenli bir TLS bağlantısının içinde düzHTTP’dir.

HTTPS Request¶

Artık client ile server (özellikle tarayıcı ile TLS Termination Proxy) arasındaşifreli bir TCP bağlantısı olduğuna göre,HTTP iletişimi başlayabilir.

Dolayısıyla client birHTTPS request gönderir. Bu, şifreli bir TLS bağlantısı üzerinden giden bir HTTP request’tir.

Request’in Şifresini Çözme¶

TLS Termination Proxy, üzerinde anlaşılan şifrelemeyi kullanarakrequest’in şifresini çözer vedüz (şifresi çözülmüş) HTTP request’i uygulamayı çalıştıran process’e iletir (ör. FastAPI uygulamasını çalıştıran Uvicorn process’i).

HTTP Response¶

Uygulama request’i işler ve TLS Termination Proxy’yedüz (şifrelenmemiş) bir HTTP response gönderir.

HTTPS Response¶

TLS Termination Proxy daha sonra response’u, daha önce üzerinde anlaşılan kriptografi ile (başlangıcısomeapp.example.com sertifikasına dayanan)şifreler ve tarayıcıya geri gönderir.

Sonrasında tarayıcı response’un geçerli olduğunu ve doğru kriptografik anahtarla şifrelendiğini doğrular vb. Ardındanresponse’un şifresini çözer ve işler.

Client (tarayıcı), response’un doğru server’dan geldiğini bilir; çünkü daha önceHTTPS sertifikası ile üzerinde anlaştıkları kriptografiyi kullanmaktadır.

Birden Fazla Uygulama¶

Aynı server’da (veya server’larda) örneğin başka API programları ya da bir veritabanı gibibirden fazla uygulama olabilir.

Belirli IP ve port kombinasyonunu yalnızca bir process yönetebilir (örneğimizde TLS Termination Proxy). Ancak diğer uygulamalar/process’ler, aynıpublic IP + port kombinasyonunu kullanmaya çalışmadıkları sürece server(lar)da çalışabilir.

Bu şekilde TLS Termination Proxy, birden fazla uygulama içinbirden fazla domain’in HTTPS ve sertifika işlerini yönetebilir ve her durumda request’leri doğru uygulamaya iletebilir.

Sertifika Yenileme¶

Gelecekte bir noktada, her sertifikanın süresidolar (temin edildikten yaklaşık 3 ay sonra).

Ardından başka bir program (bazı durumlarda ayrı bir programdır, bazı durumlarda aynı TLS Termination Proxy olabilir) Let's Encrypt ile konuşup sertifika(ları) yeniler.

TLS sertifikaları bir IP adresiyle değil,domain adıyla ilişkilidir.

Bu yüzden sertifikaları yenilemek için, yenileme programı otoriteye (Let's Encrypt) gerçekten o domain’i"sahiplendiğini" ve kontrol ettiğinikanıtlamalıdır.

Bunu yapmak ve farklı uygulama ihtiyaçlarını karşılamak için birden fazla yöntem vardır. Yaygın yöntemlerden bazıları:

• BazıDNS kayıtlarını değiştirmek.
  • Bunun için yenileme programının DNS provider API’lerini desteklemesi gerekir. Dolayısıyla kullandığınız DNS provider’a bağlı olarak bu seçenek mümkün de olabilir, olmayabilir de.
• Domain ile ilişkili public IP adresindeserver olarak çalışmak (en azından sertifika temin sürecinde).
  • Yukarıda söylediğimiz gibi, belirli bir IP ve portu yalnızca bir process dinleyebilir.
  • Bu, aynı TLS Termination Proxy’nin sertifika yenileme sürecini de yönetmesinin neden çok faydalı olduğunun sebeplerinden biridir.
  • Aksi halde TLS Termination Proxy’yi kısa süreliğine durdurmanız, sertifikaları temin etmek için yenileme programını başlatmanız, sonra bunları TLS Termination Proxy ile yapılandırmanız ve ardından TLS Termination Proxy’yi tekrar başlatmanız gerekebilir. Bu ideal değildir; çünkü TLS Termination Proxy kapalıyken uygulama(lar)ınıza erişilemez.

Uygulamayı servis etmeye devam ederken tüm bu yenileme sürecini yönetebilmek, TLS sertifikalarını doğrudan uygulama server’ıyla (örn. Uvicorn) kullanmak yerine, TLS Termination Proxy ile HTTPS’i yönetecekayrı bir sistem istemenizin başlıca nedenlerinden biridir.

Proxy Forwarded Headers¶

HTTPS’i bir proxy ile yönetirken,application server’ınız (örneğin FastAPI CLI üzerinden Uvicorn) HTTPS süreci hakkında hiçbir şey bilmez;TLS Termination Proxy ile düz HTTP üzerinden iletişim kurar.

Buproxy normalde request’iapplication server’a iletmeden önce, request’in proxy tarafındanforward edildiğini application server’a bildirmek için bazı HTTP header’larını anlık olarak ekler.

Buna rağmenapplication server, güvenilen birproxy arkasında olduğunu bilmediği için varsayılan olarak bu header’lara güvenmez.

Ancakapplication server’ı,proxy’nin gönderdiğiforwarded header’larına güvenecek şekilde yapılandırabilirsiniz. FastAPI CLI kullanıyorsanız, hangi IP’lerden gelenforwarded header’lara güvenmesi gerektiğini söylemek içinCLI Option--forwarded-allow-ips seçeneğini kullanabilirsiniz.

Örneğinapplication server yalnızca güvenilenproxy’den iletişim alıyorsa, yalnızcaproxy’nin kullandığı IP’den request alacağı için--forwarded-allow-ips="*" ayarlayıp gelen tüm IP’lere güvenmesini sağlayabilirsiniz.

Bu sayede uygulama kendi public URL’inin ne olduğunu, HTTPS kullanıp kullanmadığını, domain’i vb. bilebilir.

Bu, örneğin redirect’leri doğru şekilde yönetmek için faydalıdır.

Özet¶

HTTPS kullanmak çok önemlidir ve çoğu durumda oldukçakritiktir. Geliştirici olarak HTTPS etrafında harcadığınız çabanın büyük kısmı, aslındabu kavramları ve nasıl çalıştıklarınıanlamaktır.

Ancakgeliştiriciler için HTTPS’in temel bilgilerini öğrendikten sonra, her şeyi basitçe yönetmek için farklı araçları kolayca birleştirip yapılandırabilirsiniz.

Sonraki bölümlerin bazılarında,FastAPI uygulamaları içinHTTPS’i nasıl kuracağınıza dair birkaç somut örnek göstereceğim. 🔒