- İnternet iletişimi, paketlerin birden çok katman tarafından ayrı ayrı işlendiği bir yapıdır ve katmanlı protokoller sayesinde geliştiricilerin iletim, yönlendirme ve güvenliğin ayrıntılı uygulamalarını doğrudan ele alması gerekmez
- HTTP isteği, tarayıcının mesaj oluşturmasıyla başlayıp DNS sorgusu, TCP 3-way handshake, router’lar üzerinden geçiş ve sunucu yanıtıyla devam eden aşamalı bir akış izler
- Temel HTTP’de header’lar ve body düz metin olarak gidip geldiği için dinlemeye ve sunucu taklidine açıktır; bu sınırlamayı gidermek için güvenlik katmanı eklenmiştir
- HTTPS, HTTP’ye TLS şifrelemesi ve doğrulaması eklenmiş halidir; TLS handshake, sürüm, cipher suite, sertifika ve anahtar değişimi bilgilerini uzlaştırarak simetrik oturum anahtarı oluşturma sürecidir
- TLS 1.3, RSA’yı ve zayıf cipher suite’leri ile parametreleri dışarıda bırakarak seçenekleri azaltır; böylece önceki yöntemlere göre daha basit, daha hızlı ve daha güvenli bir handshake sunar
İnternet iletişimine katman modeliyle bakış
- İnternet, birbirine bağlı bilgisayar ağlarının ağıdır ve “Internet” kelimesi tam anlamıyla “ağlar arası” demektir
- Paket anahtarlamalı bir mesh network olarak çalışır ve paket teslimi ya da varış süresi garanti edilmeyen bir best-effort delivery yapısına sahiptir
- Yeniden deneme, sıralama garantisi, tekrarların kaldırılması ve güvenlik gibi işlemleri arka planda çeşitli soyutlama katmanları üstlendiği için internet sanki sorunsuz çalışıyormuş gibi görünür
- Her katman belirli bir işlev sağlar ve farklı protokoller bu işlevi gerçekleştirebilir
- Bu modüler yapı sayesinde bir katmandaki protokol değiştirilse bile diğer katmanlardaki protokoller etkilenmeyebilir
Ağ katmanlarının rolleri
- Application layer, uygulamaya özgü mantığı işler; iletişim birimi mesajdır ve HTTP bunun tipik örneğidir
- Security layer, şifreleme ve kimlik doğrulama sağlar; iletişim birimi record’dur ve TLS buna örnektir
- Transport layer, güvenilir veri iletiminden sorumludur; TCP segment veya UDP datagram kullanır ve port numarasıyla tanımlanır
- Network layer, paketleri internet boyunca yönlendirir; tanımlayıcı olarak IP adreslerini kullanır
- Link layer, fiziksel ortama yakın iletişimi yönetir; frame kullanır ve MAC adresiyle tanımlanır
- Physical layer, bitleri cihazlar arasında fiziksel olarak iletir; fiber optik veya Ethernet cable buna örnektir
HTTP isteğinin akışı
Paketlerin sunucuya ulaşma biçimi
- İstemci isteği gönderdiğinde veri paketleri sunucuya doğrudan gitmez; çeşitli ağ cihazları ve router’lardan geçerek sunucu ağ geçidine ulaşacak bir yol bulur
- Ardından Link layer yerel bölümdeki iletimi üstlenir
-
Metnin interneti aşma adımları
- İstemci cihazı, HTTP istek verisini bir TCP segment içine kapsüller ve ardından bunu bir IP packet ile sarar
- Kablolu bağlantıda ise bir kez daha Ethernet frame gibi bir Link layer frame içinde kapsüllenebilir
- Frame, yerel ağ üzerinden istemcinin router’ına iletilir
- Yerel router frame’i alır, Link layer header’ını kaldırır ve IP packet’i işler
- Router, hedef IP adresine bakarak bir sonraki hop’u belirler
- Paket, bir veya daha fazla ara router’dan geçerek sonraki ağa aktarılır; her router bir sonraki hop’u seçip iletme sürecini tekrarlar
- Paket sonunda hedef sunucuyla aynı ağdaki bir router’a ulaşır
- Bu router son yönlendirme kararını verir ve paketi sunucuya karşılık gelen yerel cihaza gönderir
- Sunucunun router’ı paketi yerel ağ segmenti üzerinden sunucuya iletir
- Link layer, frame’in sunucunun ağ arayüzüne doğru şekilde ulaşmasını sağlar
- Sunucu frame’i alır, IP packet’i çıkarır ve kapsüllenmiş TCP segment’i işleyerek orijinal HTTP isteğini yeniden oluşturur
- Paketleri internet boyunca taşıyan Network layer süreci, alan adı çözümleme veya TCP handshake gibi önceki adımlarda da kullanılır
Sunucu yanıtı ve tarayıcı render işlemi
- Sunucu HTTP isteğini işledikten sonra istemciye bir HTTP yanıtı gönderir
- Yanıt; kullanılan HTTP sürümünü,
200 veya 404 gibi durum kodlarını, yanıt header’larını ve istenen sayfanın HTML’i ya da JSON verisi gibi bir body’yi içerir
HTTP/1.1 200 OK
Date: Sat, 26 May 2023 10:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html
Content-Length: 3456
Example Page
Hello, world!
- İstemci HTTP yanıtını alır ve işler
- Tarayıcı, HTML’i ayrıştırarak içeriği ekrana render eder
- Yanıtta image, CSS, JavaScript gibi ek kaynaklar varsa tarayıcı aynı süreci izleyerek ek HTTP istekleri gönderir
HTTP’nin güvenlik sorunları ve HTTPS
- Varsayılan HTTP’de hiç güvenlik yoktur
- Bağlantıyı dinleyen biri, gidip gelen verinin %100’ünü görebilir
- Biri sunucu taklidi yaparsa istemci önemli bilgileri yanlış hedefe gönderebilir
- HTTPS, HTTP’ye şifreleme ve doğrulama eklenmiş halidir
- HTTP iletişimini güvenli hale getirmenin çeşitli yolları vardır, ancak bugün yaygın olarak kullanılan uygulama TLS’dir
- TLS, istemci ile sunucunun birbirinin kimliğini doğrulamasını ve payload’un her iki tarafın da çözebileceği şekilde şifrelenmesini sağlar
- HTTPS isteğinin akışı, daha önce gördüğümüz HTTP isteği akışıyla aynıdır; ancak Application layer ile Transport layer arasına bir Security layer eklenir
- TLS handshake için genellikle TCP kullanılır
TLS handshake’te üzerinde uzlaşılan şeyler
- TLS handshake, istemci ile sunucunun iletişimde kullanacakları çeşitli unsurlar üzerinde anlaşma sürecidir
- Uzlaşılan unsurlar arasında mesaj doğrulama, sıkıştırma ve şifreleme için kullanılacak algoritma kümeleri bulunur
- Bu algoritma kümesine cipher suite denir
- Teknik olarak compression algorithm hariç geri kalan kısım cipher suite’tir, ancak bu yazıda tüm kümeye cipher suite denir
- Örnek bileşenler şunlardır
- Compression algorithm: Veriyi wire üzerinde sıkıştırma yöntemi; Gzip ve Brotli örnektir, günümüzde ağırlıklı olarak Brotli kullanılır
- Key exchange algorithm: Açık bir kanal üzerinden şifreleme anahtarlarını güvenli biçimde değiştirme yöntemi; ECDHE-RSA ve ECDHE-ECDSA örnektir, günümüzde çoğunlukla ECDHE kullanılır
- Authentication algorithm: Handshake sırasında tarafların kimliğini doğrulama yöntemi; RSA ve ECDSA örnektir, RSA yaygın olarak kullanılırken ECDSA da popülerlik kazanmıştır
- Symmetric encryption algorithm: İstemci ile sunucu arasındaki veriyi şifreleme yöntemi; AES-128-GCM ve AES-256-GCM örnektir, AES-GCM güçlü güvenlik ve verimlilik sağlar
- MAC algorithm: Mesajın bütünlüğünü ve gerçekliğini garanti etme yöntemi; HMAC-SHA256 ve HMAC-SHA384 örnektir, HMAC-SHA256 ile modern cipher suite’lerdeki GCM mode kullanılır
- İstemci ile sunucu, cipher suite üzerinde anlaşıp rastgele seed ve SSL certificate bilgilerini değiş tokuş ederek mesajları şifrelemek ve doğrulamak için kullanılacak simetrik anahtarı oluşturabilir
- TLS handshake materyalinin kaynağı Cloudflare
Geleneksel TLS handshake adımları
-
Client Hello
- İstemci, desteklediği cipher suite’leri, desteklenen TLS version’ı ve Client Random adlı bir rastgele sayıyı içeren bir TCP mesajını sunucuya gönderir
-
Server Hello
- Sunucu, seçtiği TLS version’ı, seçilen cipher suite algoritmasını ve Server Random’ı içeren bir TCP mesajıyla yanıt verir
-
Certificate Verification
- İstemci, Certificate Authority aracılığıyla sunucunun SSL certificate’ını doğrular ve sunucunun public key’ini alır
-
Premaster Secret Generation
- İstemci bir premaster secret oluşturur, bunu sunucunun public key’i ile şifreler ve sunucuya gönderir
-
Decryption
- Sunucu, premaster secret’ı private key kullanarak çözer
-
Session Key Creation
- İstemci ile sunucu, Client Random, Server Random ve premaster secret kullanarak session key oluşturur
-
Client Ready
- İstemci, session key ile şifrelenmiş
finished mesajını gönderir
-
Server Ready
- Sunucu, session key ile şifrelenmiş
finished mesajını gönderir
-
Secure HTTP Communication
- Bundan sonra taraflar, session key kullanan güvenli simetrik şifrelemeyle iletişim kurar
TLS 1.3’te değişenler
- Yukarıda açıklanan TLS handshake, eski TLS sürümlerine ait süreçtir; modern TLS 1.3 açısından artık eski bir yöntemdir
- TLS 1.3 ve üstü, güvenlik gerekçeleriyle RSA’yı ve birçok cipher suite’i desteklemez
- Yeni sürüm, seçenekleri büyük ölçüde azaltarak daha basit, daha güvenli ve daha hızlı hale gelir
- TLS 1.3’te de temel kavramlar korunur
- Handshake üzerinden sıkıştırma yöntemi, sunucu kimlik doğrulaması ve anahtar değişimi üzerinde anlaşılır
- TCP üzerinden değiş tokuş edilen paket verisini korumak için simetrik şifreleme anahtarı oluşturulur
- TLS 1.3, saldırılara açık cipher suite’leri ve parametreleri desteklemez; handshake’i kısaltarak daha hızlı ve daha güvenli bir handshake sağlar
-
TLS 1.3 handshake’in temel adımları
- Client hello: İstemci protokol sürümünü, Client Random’ı ve cipher suite listesini gönderir
- TLS 1.3’te güvenli olmayan cipher suite desteği kaldırıldığı için mümkün olan cipher suite sayısı büyük ölçüde azalır
- Client hello, premaster secret hesabında kullanılacak parametreleri de içerir
- İstemci, sunucunun tercih ettiği key exchange method’u bildiğini varsayar; daraltılmış cipher suite listesi nedeniyle bu daha olasıdır
- Bu yapı, TLS 1.0, 1.1 ve 1.2 handshake’lerine kıyasla toplam uzunluğu azaltır
- Server generates master secret: Sunucu, Client Random, istemci parametreleri ve cipher suite’i almış durumdadır; ayrıca Server Random’ı kendisi üretebildiği için master secret’ı oluşturabilir
- Server hello and
Finished: Server hello içinde sunucu certificate’ı, digital signature, Server Random ve seçilen cipher suite bulunur
- Sunucu master secret’a zaten sahip olduğundan
Finished mesajını da birlikte gönderir
- Final steps and client
Finished: İstemci, signature ve certificate’ı doğrular, master secret’ı oluşturur ve ardından Finished mesajını gönderir
- Secure symmetric encryption achieved: Bundan sonra güvenli simetrik şifreleme sağlanmış olur
1 yorum
Hacker News yorumları
Uzman olmayan biri olarak merak ediyorum: Belirli bir web sitesine ya da genel olarak internete erişilemediğinde arızanın hangi noktada olduğunu anlamak neden bu kadar zor?
Bunun yerel makinemdeki ağ ayarları hatası mı, yönlendiriciye kadar olan Wi‑Fi bağlantısında bir sorun mu, yönlendirici ile ISP arasındaki kabloda bir problem mi, ISP tarafında büyük çaplı bir kesinti mi, yoksa bağlanmaya çalıştığım web sitesinin arızası mı olduğu çoğu zaman belirsiz kalıyor.
İsteklerin deterministik olmayan rotalardan yönlendirildiğine dair muğlak bir açıklama duydum ama pek ikna edici gelmedi. Yol üzerindeki bir bağlantı koparsa, son düzgün çalışan bağlantının geriye doğru “mesajın buraya kadar geldi ama bir sonraki adıma iletmeye çalışırken başarısız oldum” diye haber verememesinin sebebini merak ediyorum.
Yapılandırmalar birbirinden farklıdır, hangi yapılandırmanın kasıtlı olduğunu bilemezsiniz ve yaygın nedenlere dayanarak varsayım yapıp tamamen yanlış bir cevap sunmak risklidir.
Örneğin DNS sunucusu da yanıt vermiyor, hedef host da yanıt vermiyorsa bunun yönlendirici ayarı hatası ya da ISP kesintisi olduğunu söyleyebilirsiniz; ama gerçek neden, bir VPN istemcisinin yerel yönlendirme tablosunu ve DNS sunucusunu değiştirip kapanırken bunları geri alamamış olması olabilir. Tanılayıcı bunun geçici bir değişiklik mi yoksa kalıcı bir ayar mı olduğunu nasıl bilebilir?
Uygulamalar soketi buna göre ayarlamazsa ICMP mesajlarını göremez. Bunlar “geçici” hata olarak ele alınır; Linux’ta bu,
IP_RECVERRsoket seçeneğiyle ayarlanır.7. katmanda çalışırken bu katmanın hatalarını toplamanın pek değeri yoktur. Yukarıya yansıyan Destination Unreachable hatası, zaten sahip olacağınız hata işleme mantığına uyacaktır; bu durumda diğer katmanlar ulaşılamayan hedefler için yeniden deneme yapacağından muhtemelen zaman aşımı gibi görünecektir.
TCP katmanının ICMP hatalarını nasıl işlediği konusunda şu RFC’ler yardımcı olur: https://www.rfc-editor.org/rfc/rfc1122#page-103
4.2.3.9’da Unreachable mesajlarının soft error koşulu olduğu, bu yüzden TCP’nin bağlantıyı sonlandırmaması ve bilgiyi uygulamaya sağlaması gerektiği belirtilir. TCP bunu ERROR_REPORT rutiniyle uygulama katmanına iletebilir ya da mesajı kaydedip yalnızca TCP bağlantısı zaman aşımına uğradığında uygulamaya raporlayabilir.
ICMP’yi bir TCP saldırı vektörü olarak incelemek için stack’lerin nasıl etkileştiğini daha ayrıntılı ele alan bir belge de var: https://www.rfc-editor.org/rfc/rfc5927
DNS sunucusunun kendisine ulaşılamıyorsa, kullanıcı ile o sunucu arasında bir ağ hatası vardır. Genelde adımlar tek tek uygulanarak tanı konur: DNS sunucusu adresine ping atılabiliyor mu, o DNS sunucusuyla ilgili host çözümlenebiliyor mu, başka DNS sunucularında durum ne? Şirket politikası nedeniyle belirli adlar dışarıda bırakılmış da olabilir.
Daha derine inmek isterseniz
ping,traceroute,diggibi komut satırı araçları kullanışlıdır.MTR, gerçek zamanlı olarak sürekli çalışan ping + traceroute gibi bir şeydir ve her hop ayrı gösterilir.
Xfinity ağında bir node’un öldüğünü ilk fark ettiğimde de aynı MTR’de en azından kendi ağımdan modeme kadar her şeyin normal olduğunu görebilmem tutarlıydı. ISP’nin ötesindeki bir hop’ta gecikmenin yüzlerce ms arttığını MTR kadar iyi gösteren çok araç görmedim.
Her sorunu çözmez ama gecikmeyi hop bazında ayırıp sunduğu için kontrol etmeye değer.
“Sorun burada” diyebilmek için işletim sistemi, donanım ve ağın nasıl yapılandırıldığına dair varsayımlar gerekir.
Bir web sitesine bağlanırken önce DNS’ten web sunucusunun IP adresini almak gerekir; tarayıcının DNS IP’sini nereden aldığı bile zaten karmaşıktır. Bu ayar tarayıcıda, işletim sisteminde, yönlendiricide veya modemde yapılabilir; ayarlanmadıysa yönlendiricinin bağlı olduğu DHCP sunucusundan alınır. Bu, ISP’nin DHCP sunucusu da olabilir, kurum içindeki başka bir yönlendirici de olabilir.
DNS garip görünüyorsa IP’nin yanlış olduğunu anlamak kolaydır, ama o IP’nin nereden geldiğini söylemek zordur. SSL’de de sunucu sertifikası hatalı olabilir ya da benim bilgisayarımdaki sertifika hatalı olabilir.
İlgili olabilir: TLSv1.2 ve TLSv1.3 için bayt bayt ayrıntılı ilerleyen etkileşimli örnekler de var.
TLS hakkında daha fazla şey öğrenmek istiyorsanız gerçekten sevdiğim bir kaynak, kesinlikle öneririm.
[0]: https://tls12.xargs.org/
[1]: https://tls13.xargs.org/
Bu bakış açısıyla yazılmış daha fazla yazı örneği var mı merak ediyorum. Uzmanlık düzeyinden bağımsız olarak, “idare eder bir mühendise anlatır gibi” açıklayan yazıları seviyorum.
Tam olarak netleşmemiş parçaları yeni öğrenebildiğim ya da başkalarına anlatırken kullanabileceğim daha fazla örnek edinebildiğim için genelde çok faydalı oluyor.
Örnekler:
https://www.cloudflare.com/learning/dns/what-is-dns/
https://www.cloudflare.com/learning/ssl/transport-layer-secu...
https://www.cloudflare.com/learning/performance/what-is-http...
“İstemci premaster secret oluşturur, bunu sunucunun açık anahtarıyla şifreleyip sunucuya gönderir” açıklaması çok uzun zamandır doğru değil.
Az önce açıklanan sürecin, modern TLS 1.3 ile karşılaştırıldığında eski TLS ilk sürümlerinin süreci olduğu da eklenmiş.
“Mevcut TLS sürümleri (>1.3), güvenlik gerekçeleriyle RSA’yı ve çeşitli şifre takımlarını desteklemez” ifadesi anahtar değişimi kısmı için doğru. Çünkü RSA forward secrecy sağlamaz.
İmzalarda RSA hâlâ kullanılıyor ve muhtemelen x509 sertifikalarında en yaygın türdür.
Bildiğim kadarıyla Safari de kısa süre önce RSA imzaları için 2048 bit anahtar gereksinimini yükseltti.
Bu yazı, gerçek bir HTTPS açıklama yazısını yapay zeka özetlemiş gibi okunuyor. Terimler bağlam olmadan ortaya çıkıyor.
Sertifikanın ne olduğunu, güven zincirinin nasıl çalıştığını açıklamıyor; okuyucunun açık anahtarlı kriptografiyi bildiğini varsayıyor. OSI’nin 7 katmanından 6’sını anlatmasına rağmen terimin kendisini söylemiyor, sunum katmanı da eksik.
Gerçi başlık daha en baştan “mediocre” diyor.
Yazmak güçlü yanım değil, bu yüzden eleştirileri memnuniyetle kabul ediyorum. Yazımın “kötü”den “yapay zeka mı?”ya geçmesi bir ilerleme.
Açıklamayı nerede keseceğimi düşündüm ve açık anahtarlı kriptografinin başka yerlerde daha iyi açıklanabilecek iyi bir sınır olduğunu düşündüm. OSI’nin çeşitli katmanları için de aynı şey geçerliydi.
Sertifikaları ve belki de tüm güven zincirini ele almalıydım; bunu kabul ediyorum.
SHA256(client_hello_random + server_hello_random + curve_info + public_key)için imza doğrulamayı gösteren kod bulamıyorum.Teoriyi biliyorum ama uygulamaya çalışınca bir yerlerde sorun çıkıyor. Bunun pratikte nasıl yapıldığını gösteren oyuncak bir program bağlantısı olsa güzel olurdu.
“Sunucunun SSL sertifikasında özel anahtar vardır” gibi bir ifade umarım yoktur. Yine de başlık “Mediocre Engineer” elbette.
TLS <1.3 de yazıda anlatıldığı şekilde çalışmıyor; buna rağmen 1.3’ün daha yeni unsurlarını araya katmaya çalışıyor. DNS kısmı recursive resolver’ı anlatıyor ama istemci bunu yapmaz; muhtemelen bir stub resolver ile iletişim kurar.
“Internet Layer”, brotli’nin TLS sıkıştırmasında ya da şifre takımlarında yaygın kullanılan bir algoritma olduğu iması, “mevcut TLS sürümleri (>1.3) RSA’yı desteklemez” gibi hatalar sürüp gidiyor.
Bu tür blogspam yüzünden bazen keşke downvote olsaydı diyorum. Reklam, flaglenecek kadar rahatsız edici değil ama seviyesi düşük. Belki de daha az mediocre bir yazı yazıp HN ana sayfasına çıkarmalıyım. Yılda $300K kazanmış olsaydım daha çok zamanım olurdu.
Yazının içeriği genel olarak biraz eskimiş. Günümüzde web isteklerinin %30’u HTTP/3 ve CORS da var; yayımlanma tarihi yok.
Ben genelde şirket ağları içinde dağıtılan SaaS sistemleri geliştiriyorum; CORS istekleri neredeyse %0’a yakın. HTTP/3 için de aynı şey geçerli.