Sahipleri : Necdet Yücel
HTTPS kullandığımızda internet trafiğimizin şifrelendiğini biliyoruz. Gizlilik, mahremiyet gibi bizim için çok önemli olan konularda güvendiğimiz bu protokolün nasıl çalıştığını kısaca açıklamak istiyorum
Aslında HTTPS standart HTTP protokolünün
TLS şifrelemesi ile kaplanması anlamına geliyor. Gönderip aldığınız veriyi araya giren birinin anlam çıkaramayacağı şekilde şifrelediği için değiştirilmesinin de önüne geçer. Bu sayede HTTPS kullanarak gönderdiğimiz kullanıcı adı ve parolamız, kredi kartı bilgilerimiz ve hatta ulaştığımız sayfanın adresi (
https://en.wikipedia.org/wiki/HTTPS gibi) trafiğimizi dinleyenlerce görülemez. HTTPS ile temelde iki ana hedef gerçekleştirilir:
- Ulaştığımız adresin gerçekte ulaşmaya çalıştığımız adres olduğundan emin olunması,
- Sunucu ve istemci arasındaki trafiğin sadece bu iki taraf tarafından çözümlenebilecek şekilde şifrelenmesi.
Bu hedeflere ulaşabilmek için ilk yapılacak şey TLS bağlantısının kurulmasıdır. HTTP için kullandığımız istemci (çoğu durumda tarayıcımız) TLS bağlantısının kurulması için de aracılık eder. Taraflar aralarında aşağıdaki gibi anlaşırlar:
İstemci sunucuya bir "client hello" mesajı gönderir. Bu mesajda istemcinin desteklediği protokolün sürümü ve tercih ettiği kriptografik algoritmaların listesi bulunur.
İlk mesajı alan sunucu istemciye bir "server hello" mesajı gönderir. Bu mesajda ise istemciden aldığı listeden seçilen kriptografik algoritma ve oturum ID'si bulunur. Sunucu ayrıca sayısal sertifikasını da gönderir. Sunucunun istemciyi doğrulaması gereken durumlarda bir de "client certificate request" mesajı gönderilir ama biz bunun gerekmediğini varsayacağız.
Bu aşamadan sonrasına devam edilebilmesi için istemcinin sunucu sertifikasını onaylaması gerekir. Bir sunucu sertifikası aşağıdaki bilgileri içerir:
- Sertifikanın sahibi,
- Sertifikanın geçerli olduğu alan veya makine adı,
- Sunucunun açık anahtarı,
- Sertifikanın geçerli olduğu tarih aralığı,
- Sertifikanın sayısal imzası.
Bu sertifika eğer istemcinin güvendiği bir
Sertifika Otoritesi (CA) tarafından üretilmişse veya bu aşamada istemci sertifikayı güvenli bulursa sertifikanın onaylanması adımı geçilmiş olur. Aksi durumda iletişime devam edilmez. Tarayıcılarımızın bizi "bağlantı güvenli değil" diyerek uyardığı sayfaları gördüğümüz nokta burası oluyor.
Henüz sunucu ve istemci arasında yapılmasını planladığımız trafiğin başlamadığını unutmadan devam edelim. Bulunduğumuz durumda istemci sunucudan aldığı sertifikaya güvenebileceğini doğruladı ama sunucunun bu sertifikanın gerçek sahibi olduğunu henüz doğrulamış değil. Sunucu bu sertifikayı kendisiyle iletişime geçen herkese gönderdiği için bu sertifikayı ele geçişmiş herhangi bir taraf bizi yanıltıyor olabileceğinden bunu da doğrulaması gerekiyor. Bunun doğrulaması da sertifika içinde bulunan sunucunun açık anahtarıyla gerçekleştiriliyor. İstemci bu açık anahtarı kullanarak sunucuya bir veri gönderdiğinde ancak sunucu o açık anahtarla ilişkili gizli anahtara sahipse veriyi deşifreleyebilecektir.
Artık istemci ve sunucu bu açık anahtarı ve bir anahtar değişim algoritmasını kullanarak oturum boyunca verileri şifreli gönderip almak için bir ortak anahtar oluşturabilirler (bunun nasıl yapıldığı kendi başına açıklanabilecek kadar güzel bir konu).
Simetrik şifrelemede kullanılacak anahtar oluşturulduktan sonra istemci sunucuya bir "finished" mesajını bu anahtarla şifreleyerek gönderir. Bu noktadan sonra taraflar aralarında simetrik şifreleme algoritmalarından birini kullanırlar.
Mesajı alan sunucu da aynı anahtarla şifreleyerek "finished" mesajını istemciye iletir. Böylece her iki taraf da şifrelemede kullanacakları bir ortak anahtar üzerinde anlaşmış ve birbirlerini doğrulamış olurlar.
Bu kadar uğraşının sonunda hala istemci sunucuya bir
http get isteği bile göndermiş değil. Sadece istemci ve sunucu arasında güvenli bir tünel oluşturuldu. Bu aşamadan sonra taraflar arasındaki iletişim standart HTTP'de olduğu gibi yapılacaktır ama arada gidip gelen bütün veri şifrelendiği için HTTP'de olduğu gibi üçüncü taraflara değil verinin görünmesi, ulaştığımız adresin bile görünmesi mümkün olmayacaktır.
Alıntı Kaynağına Gitmek İçin Tıklayınız
Sahipleri : Necdet Yücel
SHA1 için 2005 yılından bu yana saldırılar yapılabildiği bilinse de http://shattered.it/ adresinde anlatılan tipte güçlü bir saldırı imkanı olmadığı düşünülerek hala çok yaygın olarak kullanılıyor
İnternette güvenlik, gizlilik, bütünlük gibi konular çoğunlukla bizim üzerinde pek düşünmediğimiz ve kullandığımız yazılımlar tarafından halledilen konular arasında yer alıyor. Örneğin internette bankacılık işlemi yaparken bağlandığımız sunucu gerçekten bağlanmak istediğimiz sunucu mu, gönderip aldığımız verileri araya giren birileri ele geçirip ondan bir anlam çıkartabiliyor mu diye düşünmüyoruz. Bu işlemleri tarayıcımız bizim yerimize yapıyor. O da verilerin şifrelenmesi ve sunucuların doğrulanması gibi işlemleri kriptografik protokolleri kullanarak gerçekleştiriyor. Benzer şekilde kullandığınız programlar güncellemeleri indirdikten sonra onların bozulmadan indiğini kontrol etmek için benzer kriptografik araçları arka planda çalıştırıyorlar.
Kriptografinin diğer kullanım alanlarının yanı sıra veri bütünlüğünün kontrol edilmesi de hepimiz için büyük önem taşıyor. Bu işlem için dosya içeriklerini kontrol etmek yerine onların tek yönlü fonksiyonlar kullanılarak özetleri çıkartılıyor ve bu özetler karşılaştırılarak dosyalar bozulmaya uğramış mı veya araya giren biri tarafından değiştirilmiş mi anlaşılabiliyor. Tek yönlü fonksiyonlar derken de her x için f(x)'in benzersiz bir şekilde ve kolayca hesaplanabildiği ama f(x) değeri verildiğinde ona karşılık gelen x değerinin hesaplanamadığı (ya da hesaplanması çok uzun süren) fonksiyonları kastediyoruz. Elbette her dosya için benzersiz bir özet üretme işinin de sınırları var. Ne kadar uzun özet üretilirse özetlerin benzersiz olması o kadar mümkün hale geliyor ama bu da (diğer konuları işin içine katmadan söylemek gerekirse) özet alma ve onu doğrulama işleminin süresini uzatıyor.
Farklı uzunluklarda özetler üreten md5, sha1, sha256 ve sha512 gibi algoritmalar mevcut. Bunların bir dosya için ürettikleri özetlere şöyle örnekler vermek mümkün. Bu
adresteki pdf dosyasını indirip siz de aynı sonuçları üretebilirsiniz.
MD5SUM: ee4aa52b139d925f8d8884402b0a750c
SHA1SUM: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a
SHA256SUM: 2bb787a73e37352f92383abe7e2902936d1059ad9f1ba6daaa9c1e58ee6970d0
SHA512SUM: 3c19b2cbcf72f7f5b252ea31677b8f2323d6119e49bcc0fb55931d00132385f1e749bb24cbd68c04ac826ae8421802825d3587fe185abf709669bb9693f6b416
Özetlerin boyutlarındaki farklılık dikkatinizi çekmiş olmalı. Bu özetlerle yapılmaya çalışılan şeyin farklı dosyalar için farklı (benzersiz) özetler üretmek olduğunu yukarıda söylemiştim. MD5 bu yazıda bahsi geçen algoritmalar arasında en kısa özeti üreten algoritma olduğundan farklı iki dosyanın özetlerinin çakışması olasılığı en yüksek olan algoritma da aynı zamanda. İlk akla gelen şey madem en uzun özet sha512 ile üretilebiliyor her yerde o kullanılsın şeklinde olsa da bir dosyanın md5 özetini almakla sha512 özetini almak arasında süre olarak gerçekten çok büyük farklar var. Küçük dosyalarda özet çıkartma süresi farkedilemeyecek kadar yakın olsa da dosya boyutu büyüdükçe (hatta disk kalıplarının özetlerinin alındığı düşünüldüğünde) aradaki fark çok büyük oluyor.
SHA1 için 2005 yılından bu yana saldırılar yapılabildiği bilinse de
shattered.it adresinde anlatılan tipte güçlü bir saldırı imkanı olmadığı düşünülerek hala çok yaygın olarak kullanılıyordu. Sayfaya girdiğinizde görebileceğiniz gibi sha1 özetleri aynı olacak şekilde birbirinden farklı iki pdf dosyası üretilmiş ve bunun başka dosyalar için de nasıl gerçeklenebileceği konusunda ayrıntılı bilgiler verilmiş durumda. Burada ilgi çekebilecek noktalardan biri de aynı sha1 özetine sahip iki dosyanın md5 özetlerinin hala farklı olması. Hem md5, hem de sha1 özeti aynı olacak şekilde farklı dosyalar üretmek elbette bambaşka bir konu.
SHA1 dosya bütünlüğünün kontrolü yanı sıra yazılım depolarının ve güncellemelerinin kontrolünden tutun da kredi kartı bilgilerinin transferine kadar pek çok konuda çok yaygın olarak kullanıldığından yazılım geliştiricileri ve sistem yöneticilerini ilgilendiren çok önemli gelişme bu. Yukarıda da gördüğümüz gibi sha1'i kullanmayacak olsak da alternatifsiz değiliz; kullanabileceğimiz başka algoritmalar var. Olmasaydı bile yenilerini yazmak imkanı her zaman mevcut.
Son kullanıcıların ise kullandıkları yazılımları güncel tutmaktan başka yapabilecekleri bir şey yok.
Düzenleme: Yazıda yaptığım ifade hatalarını düzeltmeme yardımcı olan Kadir Altan'a teşekkür ederim
Alıntı Kaynağına Gitmek İçin Tıklayınız
