İçerikler :

Access Token - Erişim Belirteci Coarse-Grained Access Control - CGAC Fail2Ban Fine-Grained Access Control - FGAC Hack - Hack Etmek - Heklemek HTTPS Nasıl Çalışıyor? Message Authentication Code - MAC - Mesaj Doğ.. net::ERR_CERT_COMMON_NAME_INVALID Hatası Refresh Token - Yenileme Belirteci SHA1'in Kırılması Ne Anlama Geliyor?

Bu Sayfayı Paylaş:

Kavram

Fail2Ban

Tanım: Bir sunucuya yapılan saldırıları (belirli sayıdan çok fazla işlem yapılması, sürekli giriş denemesi yapma vb..) belirleyip saldırı yapan IP'leri otomatik olarak yasaklayan uygulama

Kavram

Hack - Hack Etmek - Heklemek

Tanım: Bir bilgisara ve bilgisyardaki verilere yetkisiz ve izinsiz olarak erişmek

Kavram

Fine-Grained Access Control - FGAC

Tanım: Erişimin kontrol özelliklerinin detaylı olduğu güvenlik kontrol yapısı. Coarse-Grained Access Control yaklaşımının tersidir.

Kavram

Coarse-Grained Access Control - CGAC

Tanım: Erişimin kontrol özelliklerinin detaylı olmadığı daha genel olduğu güvenlik kontrol yapısı. Fine-Grained Access Control yaklaşımının tersidir.

Alıntı

HTTPS Nasıl Çalışıyor?

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
Sahipleri : Necdet Yücel
Bu yazı izinle alıntılanmıştır : https://www.nyucel.com/2017/05/https-nasl-calsyor.html
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ı

SHA1'in Kırılması Ne Anlama Geliyor?

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
Sahipleri : Necdet Yücel
İ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

Veri

net::ERR_CERT_COMMON_NAME_INVALID Hatası

Chrome bazı sitelerde net::ERR_CERT_COMMON_NAME_INVALID hatası vermektedir. Bu hata gerçerli sertifikası olmayan bir siteye HTTPS ile istek yapıldığında oluşur. Örneğin HTTPS olmayan bir siteye veya setifikası geçerli olmayan bir siteye bağlanırsak aşağıdaki gibi hata gösterilir:
Your connection is not private
Attackers might be trying to steal your information from 
www.deneme12.com (for example, passwords, messages, or credit cards). Learn more
Bir sayfa içindende geçerli sertifikası olmayan başka bir siteye HTTPS ile istek yapıldığında da bu hata alınır ve bu developer console'unda gözükebilir:
Failed to load resource: net::ERR_CERT_COMMON_NAME_INVALID
Bu kullanıcılar tarafından çözülebilecek bir konu değildir. Eğer site destekliyorsa HTTP ile istek yapılabilir yada sitenin sertifikasını geçerli hale getirmesi gerekir.

Kavram

Message Authentication Code - MAC - Mesaj Doğrulama Kodu - MDK - Tag

Tanım: Bir mesajın doğrulunu kanıtlamak için mesaj içinde kullanılan mesaj içindeki küçük bilgiler. Bu şekilde bir mesajın değiştirilip değiştirilmediği, bütünlüğünün bozulup bozulmadığı anlaşılabilmektedir.

Kavram

Access Token - Erişim Belirteci

Tanım: Bir kaynağa erişmek isteyen istemciye verilen, genellikle şifrelenmiş ve belirli bir süresi olan token.

Kavram

Refresh Token - Yenileme Belirteci

Tanım: Bir kaynağın kullandığı access token'ın geçersiz olduğu durumlarda access token'ın yenilenmesi için kullanılan token



Bu Sayfayı Paylaş:

İletişim Bilgileri

Takip Et

Her Hakkı Saklıdır. Bu sitede yayınlanan tüm bilgi ve fikirlerin kullanımından fibiler.com sorumlu değildir. Bu sitede üretilmiş , derlenmiş içerikleri, fibiler.com'u kaynak göstermek koşuluyla kendi sitenizde kullanılabilirsiniz. Ancak telif hakkı olan içeriklerin hakları sahiplerine aittir