SSL/TLS Nedir? Handshake Nasıl Çalışır? Detaylı HTTPS/SSL/TLS Rehberi

HTTPS, SSL/TLS ve Handshake kavramları güvenli internetin temel konularındandır ve yıllardır gelişeduran süreçlerini de göz önüne alarak bu yazımızda temelden ileri seviyeye kadar kapsamlı bir SSL/TLS rehberi sunacağız.

Tarayıcınızın URL çubuğunda neden yeşil bir kilit simgesinin göründüğünü ve çok önemli bir kriter olduğunu hiç merak ettiniz mi? Veya bu sorunun cevabını biliyorsanız nasıl çalıştığından ve arka planda neler gerçekleştiğinden haberiniz var mı? Cevaplarınız ne olursa olsun, gelin temelden başlayarak kapsamlı bir yolculuğa çıkalım.

NOT: Akışı resimlerden takip edebilmek ve resimleri büyütmek için resimlerin üzerine tıklayabilirsiniz.

Konu Başlıkları

HTTPS Nedir?
HTTPS, SSL ve TLS Arasındaki Farklar Nedir?
TLS mi yoksa SSL mi Demeliyiz?
Sertifika Otoritesi Nedir?
SSL/TLS Sertifika Çeşitleri
Domain Validation — DV
Organization Validation — OV
Extended Validation — EV
Sertifikalar nasıl doğrulanır?
Self-Signed Sertifikalar Güvenli mi?
Keys (Anahtarlar)
Handshake (El Sıkışma) Nasıl Yapılır?
TLS Handshake Özeti
TLS 1.2 ve 1.3 Handshake Farkı
Cipher Suites Nedir?
Modern Ciphers & Cipher Suites

1. HTTPS Nedir?

HTTPS (Hypertext transfer protocol secure), bir web tarayıcısı ile bir web sitesi arasında veri göndermek için kullanılan birincil protokol olan HTTP‘nin güvenli sürümüdür.

HTTPS, veri aktarımının güvenliğini artırmak için şifrelenmiştir. Bu, kullanıcılar bir banka hesabına, e-posta hizmetine veya sağlık sigortası sağlayıcısına giriş yapmak gibi hassas verileri iletirken özellikle önemlidir.

Teknik olarak baktığımızda ise 3 temel sebepten dolayı HTTPS kullanmamız gerekiyor;

Bunlar; Gizlilik (Privacy), Bütünlük (Integrity) ve Kimlik Doğrulama (Identification) dır.

İlk olarak Gizlilik konusuna bakalım. Bir haberleşme örneğinde karşıdaki sunucuya tarayıcı aracılığıyla ulaşmaya çalışalım. Tabi bu haberleşme başkaları tarafından dinleniyor olabilir.

Böylece internet üzerinden HTTPS kullanmadan yaptığınız tüm haberleşmeler, bu ağı gizlice dinleyenler tarafından rahatlıkla okunabilir ve kötü amaçlarla kullanılabilir.

Fakat HTTPS kullanırsanız, haberleşmenizdeki veriler şifrelenerek iletileceği için ağınızı dinleyenler tarafından bilgileriniz çalınamaz ve Gizlilik ilkesi sağlanmış olur.

Bu nedenle HTTPS kullanmayan sitelerden uzak durunuz. Bir sitenin HTTPS kullanıp kullanmadığını, adres barındaki kilit simgesinin olup olmadığından anlayabilirsiniz.

İkinci olarak Bütünlük konusuna bakalım. Yeni örneğimizde karşı tarafa şifrelenmemiş bir mesaj gönderelim.

HTTPS kullanılmadan gönderilen bir mesaj, ağdaki yabancılar tarafından hedef adrese gitmeden önce yakalanabilir ve değiştirelebilir.

Böylece değiştirilmiş veriler size normalmiş gibi gelip gider.

Bu kullanım şekli daha çok man-in-the-middle attack bilinir ve hem gönderdiğiniz veriler, hem aldığınız veriler değiştirilerek size sunulur.

Bütünlük, mesajın hedefine giden yolda manipüle edilmediği anlamına gelir. HTTPS kullanıldığında da, verileriniz şifreli olduğu için anlaşılamaz ve değiştirilemez bir duruma gelir.

Son olarak Kimlik Doğrulama konusuna bakalım. Bu örneğimizde karşı tarafa mesaj gönderirken veya alırken gerçekten doğru kişiye gönderdiğimizden veya doğru kişiden mesaj aldığımızdan emin olmak istiyoruz.

Ziyaret ettiğiniz bir sitenin gerçekten doğru site olup olmadığını HTTPS protokolü ile anlayabilirsiniz.

Geçerli bir sertifika otoritetesi tarafından verilen SSL sertifikasının olup olmadığı kontrol edilir ve sitenin kimliği doğrulanır.

Bu üç ana sebepten ötürü HTTPS oldukça önemlidir. HTTPS kullanmayan siteleri ziyaret etmekten kaçınmalı veya site sahibi iseniz geçerli bir SSL/TLS sertifikasını bir an önce edinmelisiniz.

2. HTTPS, SSL ve TLS Arasındaki Farklar Nedir?

HTTPS, SSL ve TLS terimleri birbirine sürekli karıştırılır. Bu bölümde üç terime de bakarak farklarını anlatacağız. İlk olarak HTTPS ile başlayalım.

HTTPS, HTTP’nin güvenli sürümüdür. Tarayıcınız ve web sunucularınız tarafından iletişim kurmak ve bilgi alışverişi yapmak için kullanılan protokoldür. Bu veri alışverişi SSL/TLS ile şifrelendiğinde, buna HTTPS diyoruz. ‘S‘ güvenli (secure) anlamına gelir.

Hazır söz SSL ve TLS ten açılmışken hemen SSL ile başlayalım.

SSL, İnternet standartlarına göre bir dinozordur. İlk sürüm hiç yayınlanmadı ve sürüm 2, 1995 yılında Netscape 1.1 tarayıcısıyla başlatıldı. O yıl daha sonra Netscape, sürüm 3’ü yayınladı çünkü sürüm 2’de bazı önemli güvenlik sorunları vardı. Ardından Netscape, SSL protokolünün kontrolünü IETF: İnternet Mühendisliği Görev Gücü’ne verdi.

1999 sona ermeden önce IETF, TLS sürüm 1.0’ı yayınladı. Artık SSL 3.1 yerine sahneye TLS 1.0 gelmiş oldu.

SSL, TLS: Taşıma Katmanı Güvenliği olarak yeniden adlandırıldı. Bu değişim hala hepimizde kafa karışıklığı ve kaos yaratıyor.

TLS 1.0 çıktı ve 1.1 sürümü 2006’da yayınlandı. Birkaç yıl sonra, 2008’de TLS 1.2, birkaç kusur ve istismarı gidermek için piyasaya sürüldü. Ancak, tarayıcıların TLS 1.2 yi desteklemeye başlaması 2013 yılına kadar mümkün olmadı. SSL ve TLS arasındaki karışıklığı gidermek için, SSL 3.0 resmi olarak 2015 yılında kullanımdan kaldırıldı. Böylece SSL’de deprecated olarak tarihe gömüldü.

TLS 1.3 Mart 2018’de onaylandı ve tarayıcınız bunu zaten destekliyor olabilir. Tarayıcınız için mevcut TLS sürümünü kontrol etmek için Tıklayın. Ama hikayeyi bitirmek için geri gelin.

Artık hayatımızda TLS 1.3 var. TLS 1.3, büyük güvenlik iyileştirmeleri getirir ve eski zayıf özellikleri kaldırır.

Son bir özetle; HTTP, sunucu (web server) ve istemci (tarayıcı) arasında veri taşınmasını sağlar. HTTPS yalnızca HTTP protokolünün SSL/TLS protokollerini kullanarak verilerin şifrelemelisi sonucu güvenli hale geldiği protokoldür. SSL, 90’ların ortalarında Netscape’te oluşturulan orjinal ve artık kullanımdan kaldırılan protokoldür. TLS, IETF tarafından sağlanan web üzerinde güvenli şifreleme için kullanılan yeni protokoldür.

2.1. TLS mi yoksa SSL mi Demeliyiz?

Yukarıda, TLS’nin SSL’nin daha yeni sürümü olduğunu ve her iki genel SSL sürümünün de birkaç yıldır kullanımdan kaldırıldığını ve bilinen güvenlik açıkları içerdiğini öğrendiniz. Öyleyse aklınıza neden buna TLS sertifikası değil de SSL sertifikası denildiği merak ve şaşkınlık içinde gelebilir. Sonuçta, TLS modern, güvenlik protokolüdür.

Bu sorunun cevabı, yani, çoğu insanın hala onlardan SSL sertifikası olarak bahsetmesinin nedeni temelde bir markalaşma sorunudur. Çoğu büyük sertifika sağlayıcısı, sertifikalara hala SSL sertifikaları olarak atıfta bulunur, bu nedenle adlandırma kuralı devam eder. Gerçekte, reklamını gördüğünüz tüm “SSL Sertifikaları” gerçekten SSL/TLS Sertifikalarıdır. Yani, sertifikanızla hem SSL hem de TLS protokollerini kullanabilirsiniz. Yalnızca bir SSL sertifikası veya yalnızca bir TLS sertifikası diye bir şey yoktur ve SSL sertifikanızı bir TLS sertifikasıyla değiştirme konusunda endişelenmenize gerek yoktur.

3. Sertifika Otoritesi Nedir?

Sertifika otoritesi veya Certificate Authorities (CA), dijital imzalama işlemi yapan ve belgeleyen kurumdur. Sertifika orotiterleri, SSL/TLS sertifikası verme yetkisine sahiptirler.

Sertifika otoriterlerinin temelde 3 ana hedefi vardır:

Sertifika vermek
Sertifikanın sahibinin kimliğini kanıtlamak
Sertifikanının geçerliliğini doğrulamak

Bir web sunucusuna SSL/TLS protokolleri üzerinden bağlanırken, ziyaretçinin kullandığı web tarayıcısı web sitesindeki SSL/TLS sertifikasının güvenilir olup olmadığına bu sertifikayı hangi CA’nın tescil ettiğine bakarak karar verir. Buna bakarken de, tarayıcıya yazılım üreticisi (Microsoft veya Netscape gibi) tarafından eklenen Certification Authority listesini inceler. Sadece iyi bilinen, uzun zamandır faaliyette olan ve güvenilirliğini kanıtlamış CA’lar bu listelere alınır. Bu nedenlerle satın alacağınız SSL/TLS sertifikasının hangi CA tarafından tescil edildiği son derece önemlidir.

Bilinen güvenilir CA’lardan bazıları şunlardır. Listede Türk firması da var;

IdenTrust
Sectigo (eski adı Comodo)
DigiCert
GoDaddy
GlobalSign
Symantec
RapidSSL
GeoTrust
Certum
Actalis
Entrust
Secom
Let’s Encrypt
GTS
E-tugra

3.1 SSL/TLS Sertifika Çeşitleri

SSL/TLS Sertifikalarının işlevselliği ve sağlamış oldukları özelliklere göre seçenekleri vardır. Bunlar;

Domain Validation – DV,
Organization Validation – OV
Extended Validation – EV

olmak üzere üçe ayrılır.

3.1.1 Domain Validation — DV

Domain Validation içerisinde yalnızca kullanılacağı web sitesinin URL adresi bulunur ve organizasyon veya kurum, kurulaşa ait herhangi bir bilgi bulunmaz. DV tipinde bir SSL/TLS sertifikası ile yalnıza URL adresinin doğruluğu kanıtlanabilir. İçerisinde bir kişi yada kuruma ait bilgi olmadığı için domain üzerinden SSL/TLS sertifikası kullanılarak web sitesinden kim hizmet veriyor, kimin web sitesi anlamak mümkün değildir. Bu nedenle çok fazla güvenliğe ihtiyaç duyulmayan ve bir organizasyona bağlı olması gerekmeyen web sitelerinde tercih edilebilir.

3.1.2 Organization Validation — OV

Organization Validation içerisinde Domain Validation yapısına ek olarak, organizasyon veya kurum kuruluş bilgileri de yazılmaktadır. Böylelikle bu tipteki bir SSL/TLS sertifikası hem domain adresinin yani URL adresinin doğruluğunu kanıtlarken hem de web sayfası üzerinden hangi organizasyon, kurum veya kuruluşun hizmet verdiğini doğrulanabilir bir şekilde gösterir. İnternet üzerinden önemli bilgileri alan, işleyen web sitelerinde en az OV tipinde SSL/TLS sertifikası olmalıdır ki kullanıcılarında güven duygusu oluşturabilsin. E-Ticaret sitelerinde minimum OV tipinde bir SSL/TLS sertifikası olmalı, böylelikle kullanıcılar kimden alışveriş yaptığını doğru bir şekilde öğrenebilmelidir.

3.1.3 Extended Validation — EV

Extended Validation sertifikalar en güçlü doğrulama verilerine sahip SSL/TLS sertifikalarıdır. Bu sertifika içerisinde domain, organizasyon bilgilerinin yanı sıra sertifikanın alındığı firmaya ait fiziksel adres bilgileri de bulunmaktadır. Güvenlik anlamında bir çok kriteri karşılayarak, bankalar ve e-ticaret siteleri gibi kullanıcıdan kritik bilgileri alan ve işleyen web siteleri için kullanılması önemli olan SSL/TLS sertifika tipidir.

Tüm geçerli sertifikalar, tarayıcının tarayıcı çubuğunda güvenli bir rozet görüntülemesiyle sonuçlanır. EV sertifikaları genellikle şirket adını da gösterir.

Ayrıca SSL/TLS sertifikaları web sitelerine verilirken kullanım alanlarına göre farklılık göstermektedir;

Standart SSL/TLS Sertifikaları, yalnızca bir adet domain adresinin doğruluğunu kanıtlayacal şekilde hazırlanan SSL/TLS sertifikalarıdır.
Multi-Domain SSL/TLS Sertifikaları, birden fazla domain’in tek bir sertifika içerisinde tanımlanmasına olanak veren SSL/TLS Sertifika tipidir.
Wildcard SSL/TLS Sertifikaları, Tüm subdomain’i kapsayacak şekilde oluşturulan SSL/TLS Sertifika tipidir. *.kerteriz.net şeklinde oluşturulur ve kerteriz.net web sitesinin limit olmadan tüm subdomain adreslerinin doğruluğunu kanıtlayabilir.

3.2 Sertifikalar nasıl doğrulanır?

Peki sertifika otoriterleri sertifikaları nasıl doğrular? Bir CA sertifika verdiğinde, sertifikayı kök deposuna önceden yüklenmiş olan kök sertifikasıyla imzalar. Çoğu zaman bir kök sertifika ile imzalanmış bir ara sertifika kullanılır. Çünkü kök sertifika tehlikeye atılırsa, kök sertifikalar her cihaza yüklendiği için ara sertifikaları iptal etmek daha kolaydır.

Bir sertifikanın nasıl doğrulandığını inceleyelim. Süreç temelinde bir ‘güven zincirine’ dayanmaktadır.

HTTPS kullanan bir siteyi ziyaret ettiğinizde tarayıcınız ilk olarak sitenin SSL/TLS sertifikasını indirir.

Ardından sırayla şu işlemler gerçekleşir;

Eğer indirilen sertifika kök sertika, bu sertifikayı imzalayan sertifika indirilir (varsa ara sertifika),
Eğer indirilen sertifika ara sertifikaysa, bunu da imzalayan kök sertifika indirilir,
Kök sertifika tarayıcınızın Certification Authority listesindeki güvenilir bir otoriteyse tüm sertifikalar güvenli olarak işaretlenir.

İndirilen son sertifikanın bir kök sertifika olmaması ve indirilecek başka sertifika olmaması durumunda, zincir güvenilmezdir. Buda her ne kadar HTTPS protokolü aktif gibi gözüküyor olsa da tehlikeli bir sitede olduğunuzun habercisidir.

3.3 Self-Signed Sertifikalar Güvenli mi?

Kendinden imzalı sertifikalar Self-Signed, herhangi bir otoriter tarafından imzalanmayan sertifikalardır. Bunları kolaylıkla üretebilir ve kullanmaya başlayabilirsiniz. Tabi test amaçlı veya lokal kullanım için değilse bu sertifikalar asla uygun değildir ve uzak durmalısınız.

Kendinden imzalı sertifikalar ücretsiz olarak üretilebilir ve bir yetkili tarafından üretilenle aynı düzeyde şifreleme sağlar. Böylece veriler yine şifrelenerek iletilir.

Fakat tarayıcınızın kendinden imzalı sertifikalar, tarayıcınızın Certification Authority listesindeki herhangi bir CA ile eşleşmeyeceği için tarayıcı sitenin güvenilir olmadığına dair uyarı verecektir. Tabi buda site sahipleri için ziyaretçi kaybı anlamına gelir.

Özetle, kendinden imzalı sertifikaları test ve intranet ortamlarınızda kullanabilirsiniz fakat sizi ziyarete gelenlere güvenilir bir CA tarafından imzalanmış SSL/TLS sertifika ile verileri şifrelediğinize dair kanıt sunmanız oldukça önemlidir.

4. Keys (Anahtarlar)

HTTPS, web’de gizlilik, bütünlük ve kimlik sağlamanın bir yoluna ihtiyaç duyar. Tüm bunları ise anahtarlar sayesinde rahatlıkla sağlayabiliriz.

İki tür şifreleme algoritması vardır. Bunlar simetrik ve asimetrik şifreleme yöntemleridir. Simetrik anahtar algoritması ile başlayalım. Bu senaryoda, bir mesajı şifrelemek ve şifresini çözmek için tek bir anahtar vardır.

BrowserBird’e mesaj göndermeden önce mesajı bir anahtarla şifrelerim. Şifreleme işlemini, mesajı bir kutuya koymak ve kutuyu bir anahtarla kilitlemek gibi düşünebilirsiniz. Yalnızca anahtarın bir kopyasına sahip olan kişi kutuyu açabilir ve mesajı okuyabilir.

Bu, kutunun doğru anahtarla kişiye ulaşana kadar açılamayacağını garanti eder. Browserbird kutuyu aldığında, anahtarı açmak ve mesajı okumak için abahtarı kullanır. Anahtarın gizli tutulması önemlidir. Anahtarı düz metin olarak paylaşmamalı veya kutu ile göndermemelisiniz.

Unutmayın, anahtara sahip olan herkes kutuyu açabilir. Bu arada kutuyu kullanmak, şifrelemeyi anlamak için güzel bir görsel, ancak gerçekten onu aşırı basitleştiriyor. Çünkü gerçekte, mesaja anahtarsız bakan biri yalnızca anlamsız metinler görür.

Alttaki resimde yer alan metin bir şifreleme algoritması ile oluşturulmuş gerçek bir örnektir. Şifreleme, metnin bir dizi adımda karıştırıldığını söylemenin havalı bir yoludur. Her seferinde mesajı daha da zorlaştırmak için mesaj birden çok kez karıştırırsınız.

Bir mesajın şifresini çözmek için, sadece aynı adımları ters sırayla uygulamamız gerekir. Şifreleme anahtarı mesajla karıştırılır, bu nedenle şifreleme algoritmasını anahtarsız olarak bilseniz bile mesaj yine de anlamsızdır. Gerçek bir anahtar aşağıdaki resimde yer aldığı görünebilir.

Simetrik anahtarlarla ilgili temel bir sorun, paylaşmanın zor olmasıdır. Anahtarı nasıl dağıtacağınıza çok dikkat etmelisiniz. Bu dağıtım sorunu bizi asimetrik anahtarlara getiriyor.

Asimetrik anahtarların temel farkı 2 anahtara sahip olmanızdır. Bir anahtar public (genel), diğeri private (özeldir). Eşlenirler ve birlikte çalışırlar. Genel anahtarınızı herkesle paylaşabilirsiniz.

Örnekte; BrowserBird, Compugter’e mesaj gönderebilmek için yazdığı mesajı Compugter’in genel anahtarıyla şifreler. Bu mesajı sadece Compugter’in özel anahtarı çözebilir.

İşin özeti de budur. Genel anahtarın şifrelediği bir mesajı sadece onun gizli anahtarı, gizli anahtarın şifrelediği mesajı ise yine sadece onun genel anahtarı çözebilir.

Böylece bir kişinin gizli anahtarıyla şifrelediği mesajı aldığınızda o kişinin genel anahtarıyla çözebiliyorsanız, mesaj gerçekten o kişiden gelmiş demektir. Ve kimlik doğrulama işlemi de sağlanmış olur.

Simetrik ve asimetrik şifreleme hakkında çok daha detaylı bir yazı okumak isterseniz Modern Şifreleme Yöntemleri isimli yazımızı okuyabilirsiniz.

5. Handshake (El Sıkışma) Nasıl Yapılır?

“SSL/TLS handshake”, HTTPS bağlantısını kuran işlemin teknik adıdır. SSL/TLS protokolünde yer alan zor işlerin çoğu burada yapılır. Bu, orijinal SSL protokolünün ilk olarak 1996’da oluşturulmasından bu yana gelişen ve her yeni yinelemenin daha az ek yük ile daha hızlı hale geldiği bir süreçtir. Mart 2018’de, IETF, tamamen elden geçirilmiş bir handshake içeren TLS 1.3 ile birlikte artık handshake işlemleri de daha hızlı gerçekleşebiliyor.

5.1. TLS Handshake Özeti

Bir HTTPS bağlantısı iki tarafı içerir: istemci (bağlantıyı başlatan kişi, genellikle web tarayıcınız) ve sunucu. Bu iki taraf, “el sıkışanlardır”. SSL/TLS hanshake amacı, güvenli bir bağlantıya sahip olmak için gereken tüm kriptografik işleri gerçekleştirmektir. Buna kullanılan SSL sertifikasının doğrulanması ve bir şifreleme anahtarı oluşturulması da dahildir.

Yukarıda söylediğimiz gibi, SSL/TLS handshake 3 ana şeyi yapar:

Cipher suites ve parametrelerinin değiş tokuşu
Taraflardan birinin veya her ikisinin kimlik doğrulaması
Simetrik oturum anahtarlarını oluşturma/değiştirme

Her birinde neler olduğunu kavramsal olarak açıklayarak başlayalım.

Yazılımın her parçası farklıdır. Web tarayıcıları en yaygın istemcilerdir ve özellikler Google Chrome, Mozilla Firefox ve Microsoft Internet Explorer gibi popüler tarayıcılar arasında farklılık gösterebilir. Aynı şekilde, sunucu tarafında, Windows Server, Apache ve NGINX gibi popüler işletim sistemlerinin hepsi çok farklı özellik desteğine sahiptir. Ve özel konfigürasyonlar eklediğinizde tüm bunlar daha da karmaşık hale gelir. Dolayısıyla, TLS anlaşmasının ilk adımları, istemcinin ve sunucunun yeteneklerini paylaşmasını gerektirir, böylece karşılıklı olarak destekledikleri kriptografik özellikleri bulabilirler.

İlk mesaj “ClientHello” olarak adlandırılır. Bu mesaj, sunucunun, ikisinin de iletişim kurmak için kullanacağı cipher suiti seçebilmesi için istemcinin yeteneklerini listeler. Ayrıca “random client” adı verilen büyük, rastgele seçilmiş bir asal sayı içerir.

Sunucu nazikçe “ServerHello” mesajıyla yanıt verir. Bu mesajda, istemciye sağlanan listeden hangi bağlantı parametrelerini seçtiğini söyler ve “random server” adı verilen kendi rastgele seçilmiş asal numarasını döndürür. İstemci ve sunucu ortak herhangi bir yeteneği paylaşmazsa, bağlantı başarısız bir şekilde sona erer. Bir istemci ve sunucu, kullanacakları tam şifreleme yöntemleri üzerinde anlaştıktan sonra – buna cipher suites denir – sunucu istemciye SSL sertifikasını gönderir.

“Sertifika” mesajında Sunucu, istemciye kendi SSL sertifika zincirini (yaprak sertifikasını ve ara sertifikalarını içerir) gönderir. Bağlantıya kimlik doğrulama sağlamak için, istemcinin sertifikanın meşru olduğunu doğrulamasına yardımcı olmak adına SSL sertifikası bir CA tarafından imzalanır. Alıcı, sertifikayı doğrulamak için birçok kontrol gerçekleştirir. Bu, sertifikanın dijital imzasının kontrol edilmesini, sertifika zincirinin doğrulanmasını ve sertifika verileriyle ilgili diğer olası sorunların (süresi dolan sertifika, yanlış alan adı vb.) kontrol edilmesini içerir. İstemci ayrıca, sunucunun sertifika private keyine sahip olduğundan emin olacaktır. Bu, anahtar değişimi/oluşturma süreci sırasında yapılır.

“Server Hello Done” mesajı istemciye tüm mesajlarını gönderdiğini söyler. Client daha sonra sesion keye katkı sağlar. Bu adımın ayrıntıları, ilk “Hello” mesajlarında kararlaştırılan anahtar değişim yöntemine bağlıdır. Bu örnekte, RSA’ya bakıyoruz, bu nedenle istemci, pre-master key olarak adlandırılan rastgele bir bayt dizisi oluşturacak, ardından bunu sunucunun public anahtarıyla şifreleyecek ve iletecektir.

“Change Cipher Spec” (Şifre Özelliklerini Değiştir) mesajında sunucu ilk olarak kendi private keyini kullanarak pre-master keyi elde edecektir. Bu aşamaya kadar olan süreçte asimetrik şifreleme kullanıldı. Böylece pre-master key güvenle paylaşılmış oldu.

İki tarafta pre-master key sahibi olduktan sonra, yine her ikisi de simetrik anahtar olarak kullanacakları aynı ‘shared secret key (oturum anahtarını) üretirler.

Daha sonra, client tarafında anlaşmanın tamamlandığını belirtmek için “Finished” mesajı gönderilir. Bitti mesajı şifrelenmiştir ve oturum anahtarıyla korunan ilk veridir. Mesaj, her bir tarafın anlaşmanın kurcalanmadığından emin olmasını sağlayan verileri de (MAC) içerir. Sunucu da, oluşturduğu simetrik oturum anahtarını kullanarak “Finished” mesajını gönderir, ayrıca handshake’in bütünlüğünü doğrulamak için aynı kontrol toplamını gerçekleştirir.

Artık handshake aşaması tamamlandı ve bundan sonraki tüm veriler güvenli bir şekilde şifrelenerek iletilecektir.

5.2. TLS 1.2 ve 1.3 Handshake Farkı

TLS 1.2’ye göre 1.3 gelişmiş güvenlik hizmeti ve çok daha hızlı bir servis hizmeti sunar. TLS 1.2 şifrelenmiş bağlantılar ile ekstra yük oluşturmaktaydı. TLS 1.3 şifrelenmiş bağlantıları hızlandırmaya yardımcı olur.

Basitçe, TLS 1.2’de Handshake için 2 Round Trip gerekirken, TLS 1.3’de bu işlem için yalnızca 1 Round Trip yeterlidir. Gecikmeler %50 azalır, performans artar. 1.3’ün diğer bir özelliğinde de önceden ziyaret edilen sitelere, site yüklenmesi için gerekli datalar ilk mesajdan gönderilir (0-RTT). Tek seferde bu işlem yapıldığından handshake için ayrı bir RTT gecikmesi oluşmaz. Böylece web sitelerinin yüklenme hızı artmış olur.

Ayrıca eski sürüm olan TLS 1.2’den güvenli olmayan ve eski şifreleme algoritmalarının birkaçı kaldırılmıştır. Bunlar:

SHA-1
RC4
DES
3DES
AES-CBC
MD5

5.3. Cipher Suites Nedir?

Yukarıda anlatılan olay örgüsünde istemci ve sunucu handshake aşamasında kullanacakları cipher suite’leri belirlemişlerdi. Peki nedir bu cipher suites?

Cipher suites, bir ağın SSL (Güvenli Yuva Katmanı) veya TLS (Taşıma Katmanı Güvenliği) aracılığıyla nasıl güvenli hale getirileceğine ilişkin talimatların dizisidir. Cipher suites; HTTPS, FTPS, SMTP ve diğer ağ protokollerini kullanırken güvenli bir şekilde nasıl iletişim kuracağımıza dair önemli bilgiler sağlar. Bu bilgiler, bir web sunucusunun istemcinin web trafiğini nasıl güvence altına aldığını belirlemeye yardımcı olan algoritmalar ve protokollerdir.

Ciphers, kısaca algoritmalardır. Daha spesifik olarak bir kriptografik işlevi gerçekleştirmek için şifreleme, şifre çözme, karma ve dijital imzalardan oluşan bir dizi adımdır. Günümüzde şifreler, bilgisayarların gelişmiş işlem yeteneklerine bağlıdır. Fakat bu her zaman böyle olmadı. İlk tanınmış tarihi şifrelerden biri, Roma’nın ilk imparatoru ve süslü meze salatalarının tedarikçisi olan Sezar’a aitti ve onu askeri operasyonlar sırasında generalleriyle iletişim kurmak için kullanıyordu. En eski ilkel şifreleme yöntemleri hakkında bilgi edinmek için şu eğlenceli yazımızı okuyabilirsiniz: En Eski İlkel Şifreleme Yöntemleri (Kriptoloji)

Yıllar geçtikçe şifreler daha karmaşık hale geldi, ancak arkasındaki mantık aynı kaldı. İster Sezar’ın Rubicon’u, ister II.Dünya Savaşı’nın kötü şöhretli Enigma şifresini istersede bugünün bazı algoritmalarını geçmesi olsun – fikir her zaman bir mesajı yalnızca hedeflenen tarafın okuyabileceği şekilde kodlamak veya şifrelemek olmuştur. Günümüz modern şifreleme algoritmaları için de şu yazımızı okuyabilirsiniz: Modern Şifreleme Yöntemleri

Bugün, bir HTTPS bağlantısının güvenliğini sağlamaya yardımcı olan SSL/TLS cipher suiteleri tartışacağız. Ardından çeşitli bölümlerinin üzerinden geçip TLS 1.2 ile TLS 1.3 arasında nelerin değiştiğine bakarak bitireceğiz.

5.3.1. Modern Ciphers & Cipher Suites

HTTPS bağlantısı aslında oldukça karmaşık bir süreçtir. Güvenli bir haberleşme için istemci ve sunucu karşılıklı olarak desteklenen bir cipher suite üzerinde anlaşır ve ardından güvenli bir bağlantı üzerinden seçilen cipher suite ile mesajlaşmaya başlarlar. Seçilen şifrelerin tümü, kimlik doğrulama, anahtar üretimi ve değişimi ile bütünlüğü sağlamak için çeşitli noktalarda birlikte çalışır.

Hangi algoritmaların kullanılacağını belirlemek için, istemci ve sunucu, kullanılacak bir cipher suite üzerinde karar kılarlar. Cipher suites, el sıkışma ve şifreleme gerçekleştirmek için birlikte çalışabilen bu algoritmaların koleksiyonlarıdır.

TLS 1.2 de 37 adet ve TLS 1.3 te 5 adet ciphers vardır. Bu ciphersları anlamak, HTTPS bağlantılarını ve SSL/TLS’nin kendisini anlamanın anahtarıdır. Bu nedenle protokolün daha yaygın sürümü olan TLS 1.2’ye genel bir bakışla başlayalım ve ardından TLS 1.3’te nelerin iyileştirildiğinden bahsedelim.

TLS 1.2 Cipher Suiteler için ana kategoriler şu şekildedir;

Key Exchange: (Anahtar değişimi) – Simetrik anahtarların değiştirilme şeklini belirler
Authentication: (Kimlik Doğrulama) – Sunucu kimlik doğrulamasının ve (gerekirse) istemci kimlik doğrulamasının nasıl yürütüleceğini belirtir.
Bulk Cipher: (Gizlilik) – Gerçek verileri şifrelemek için hangi simetrik anahtar algoritmasının kullanılacağını belirtir.
Message Authentication Code (MAC) – Hashing Algorithm: (Bütünlük) – Bağlantının veri bütünlüğü kontrollerini gerçekleştirmek için kullanacağı yöntemi belirler.

TLS 1.2’de desteklenen tüm cipher suites’lerden, geçici Diffie-Hellman algoritmasına sahip olanları kullanmamız önerilir. Bu nedenle, tavsiye edilen cipher suites şu şekildedir:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305

TLS 1.3 Cipher Suiteler için ana kategoriler şu şekildedir;

Bulk Cipher: (Gizlilik) – Gerçek verileri şifrelemek için hangi simetrik anahtar algoritmasının kullanılacağını belirtir.
HKDF (KMAC-based Extract-and-Expand Key Derivation Function) Hash: – (Bütünlük) – Bağlantının veri bütünlüğü kontrollerini gerçekleştirmek için kullanacağı yöntemi belirler.

TLS 1.3’te desteklenen cipher suites artık yalnızca beşe düştü ve şunlardır:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256

TLS 1.3’te kaldırılan algoritmalar ise şunlardır:

RC4
DSA
MD5
SHA-1
Weak Elliptic Curves
RSA Key Exchange
Static Diffie-Hellman (DH, ECDH)
Block ciphers (CBC)
Non-AEAD ciphers

Şimdi ise bir TLS 1.2 cipher suite örneği görelim:

Burada TLS protokoldür. ECDHE ile başlayarak, el sıkışma sırasında anahtarların geçici Elliptic Curve Diffie Hellman (ECDHE) algoritması aracılığıyla değiştirileceğini görebiliriz. ECDSA, kimlik doğrulama algoritmasıdır. AES_128_GCM, yığın şifreleme algoritmasıdır: 128-bit anahtar boyutuyla Galois Counter Mode (GCM) çalıştıran AES. Son olarak, SHA-256, hashing algoritmasıdır.

Son olarak ise TLS 1.3 cipher suite örneğine bakalım:

Burada ise TLS yine protokolümüzdür. AES 256 GCM, İlişkili Verilerle Kimliği Doğrulanmış Şifreleme (AEAD) algoritmasıdır. SHA384, Hashed-Key Derivation Function (HKFD) algoritmasıdır

Daha sonraki yazılarımızda cipher suiteslere daha detaylı girerek ana kategorilerdeki tüm algoritmaları tek tek inceleyeceğiz. Fakat şimdi yazının daha fazla uzamaması için cipher suites konusunu burada bitiriyoruz.

NOT: Resimlerdeki hikaye akışı https://howhttps.works/ adresinden alınmıştır.