My Blog

Yazar: wafadmin

  • API Kavramı ve API Güvenliği: OWASP Top 10 ile Derinlemesine İnceleme

    Dijital Dünyada API’lerin Rolü

    Günümüzde kullandığımız hemen her dijital hizmetin arka planında, farklı sistemlerin birbiriyle haberleşmesini sağlayan temel bir yapı taşı bulunur: API (Application Programming Interface), yani Uygulama Programlama Arayüzü. API’ler, yazılım uygulamaları arasında köprü görevi görerek, sistemler arası veri alışverişini kolaylaştıran ve düzenleyen bir yapı sunar.

    Bir mobil uygulama üzerinden hava durumu sorguladığımızda, bir banka uygulamasında bakiye kontrolü yaptığımızda veya sosyal medya hesabımıza başka bir uygulamayla giriş yaptığımızda aslında bir API çağrısı gerçekleşir. Bu çağrı, arka planda verinin doğru adrese güvenli ve hızlı bir şekilde taşınmasını sağlar.

    Kısacası, API’ler dijital dünyanın görünmeyen kahramanlarıdır. Kullanıcıların farkında bile olmadan etkileşime girdiği bu arayüzler, yazılımların birlikte çalışabilirliğini sağlayarak hem kullanıcı deneyimini hem de yazılım geliştirme süreçlerini büyük ölçüde kolaylaştırır.

    API Nedir?

    API’nin Teknik Tanımı

    API (Application Programming Interface), yani Türkçesiyle Uygulama Programlama Arayüzü, bir yazılımın başka bir yazılımla iletişim kurmasını sağlayan arabirimdir. Bu arabirim, farklı uygulamalar arasında veri paylaşımını ve işlev çağrılarını standart bir şekilde gerçekleştirmeyi mümkün kılar.

    Kısaca özetlemek gerekirse: API, iki yazılım bileşeni arasında “nasıl konuşacaklarını” belirleyen bir sözleşmedir. Geliştiriciler, bir sistemin iç işleyişine dair detayları bilmeden, sadece API aracılığıyla gerekli işlemleri gerçekleştirebilir. Bu sayede hem güvenlik sağlanır hem de geliştirici deneyimi iyileştirilir.

    API Türleri: REST, SOAP ve GraphQL

    API’ler farklı protokol ve veri formatlarına göre sınıflandırılabilir. En yaygın kullanılan üç tür şunlardır:

    1. REST (Representational State Transfer)

    • Günümüzde en yaygın kullanılan API mimarisidir.
    • HTTP protokolü üzerinde çalışır (GET, POST, PUT, DELETE vb.).
    • JSON ya da XML veri formatını kullanabilir ama çoğunlukla JSON tercih edilir.
    • Kaynak odaklıdır. Her şey bir “kaynak” olarak tanımlanır ve URL’ler üzerinden erişilir.
    • Avantajı: Basit, hafif ve anlaşılır yapısı sayesinde mobil ve web uygulamalarında tercih edilir.

    Örnek:
    GET https://api.example.com/users/123
    Kullanıcı ID’si 123 olan kişinin bilgilerini getirir.

    2. SOAP (Simple Object Access Protocol)

    • Daha eski ve katı kurallara sahip bir protokoldür.
    • XML tabanlıdır ve mesaj yapısı daha ağırdır.
    • Güvenlik, kimlik doğrulama ve hata yönetimi gibi konularda daha detaylıdır.
    • Avantajı: Finans, sağlık gibi regülasyon gerektiren alanlarda güçlü güvenlik özellikleriyle kullanılır.

    3. GraphQL

    • Facebook tarafından geliştirilmiştir.
    • Tek bir endpoint ile birçok veri talebini özelleştirilmiş şekilde yapmanıza olanak tanır.
    • Kullanıcı yalnızca ihtiyaç duyduğu alanları sorgular, bu da veri israfını azaltır.
    • Avantajı: Özellikle karmaşık veri ilişkileri olan uygulamalarda esneklik sağlar.

    API’ler Nasıl Çalışır?

    API mimarisi genel olarak istemci ve sunucu arasındaki bir iletişim modeline dayanır. Burada istemci, API’ye talepte bulunan, sunucu ise bu talebi işleyip yanıt dönen taraftır.

    Endpoint Nedir?

    Bir API’deki her fonksiyon ya da kaynak, endpoint adı verilen bir URL ile tanımlanır. Örneğin, bir kullanıcı listesini almak için:

    GET https://api.uygulama.com/kullanicilar

    Bu URL bir endpoint’tir ve bu adrese yapılan HTTP GET isteği, sistemden kullanıcı verilerinin çekilmesini sağlar.

    Request –Response Döngüsü

    • istemci, belirli bir endpoint’e HTTP protokolü ile istek gönderir.
    • API, bu isteği işler, gerekirse bir veritabanına sorgu gönderir.
    • İlgili veriyi veya işlemi tamamladıktan sonra, HTTP yanıtı ile birlikte sonucu döner.
    • Yanıt genellikle JSON formatında olur.

    Örnek Request:

    GET /products/42 HTTP/1.1

    Host: api.mağaza.com

    Örnek Response:

    {

    “id”: 42,

    “isim”: “Kablosuz Mouse”,

    “fiyat”: 249.90

    }

    Neden Bu Kadar Önemlidir?

    API’ler, mikroservis mimarilerinden mobil uygulamalara, IoT cihazlarından 3. parti hizmetlere kadar pek çok alanda sistemlerin birlikte çalışabilmesini sağlar. Bu kadar geniş kullanım alanı nedeniyle, API’lerin doğru tasarlanması kadar güvenli olması da kritik öneme sahiptir.

    API Güvenliği Nedir?

    API güvenliği, API’ların yetkisiz erişimden, kötüye kullanımdan ve siber tehditlerden koruma sürecidir. Bu, API’ler aracılığıyla iletilen verilerin gizliliğini, bütünlüğünü ve erişilebilirliğini sağlamayı amaçlar. API güvenliği, sadece teknik önlemlerden ibaret olmayıp, aynı zamanda güvenli tasarım prensiplerini, geliştirme süreçlerini ve sürekli izleme mekanizmalarını da kapsar.

    Neden API Güvenliği Bu Kadar Önemli?

    API’ler, hassas verilere erişim sağlayan ve kritik iş süreçlerini yürüten kapılar gibidir. Bir API’deki güvenlik açığı, tüm sistemin tehlikeye girmesine, veri sızıntılarına, finansal kayıplara ve itibar zedelenmelerine yol açabilir. Özellikle modern uygulamaların mikroservis mimarisine geçişiyle birlikte, her bir mikroservisin kendi API’si olması, saldırı yüzeyini genişletmekte ve API güvenliğini daha da karmaşık hale getirmektedir.

    OWASP API Security Top 10 (2023): Başlıca Tehditler

    OWASP, web uygulamaları ve API’ler için güvenlik risklerini belirleyen ve önceliklendiren, kar amacı gütmeyen bir kuruluştur. OWASP API Security Top 10 listesi, API’lerde en sık karşılaşılan ve en kritik güvenlik açıklarını özetler. 2023 listesi aşağıdaki gibidir:

    API1:2023 — Broken Object Level Authorization (BOLA)

    Açıklama: API’ler genellikle nesne tanımlayıcılarını (ID’ler) işleyen uç noktaları açığa çıkarır. Bu durum, nesne düzeyinde erişim kontrolü sorunları için geniş bir saldırı yüzeyi oluşturur. Saldırganlar, geçerli bir ID’yi değiştirerek yetkisiz verilere erişebilir veya manipüle edebilir.

    Önlem: Her API çağrısında, kullanıcının talep ettiği kaynağa erişim yetkisinin olup olmadığını doğrulamak için kapsamlı nesne düzeyinde yetkilendirme kontrolleri yapılmalıdır.

    API2:2023 — Broken Authentication

    Açıklama: Kimlik doğrulama mekanizmaları genellikle yanlış uygulanır, bu da saldırganların kimlik doğrulama belirteçlerini ele geçirmesine veya uygulama hatalarını kullanarak başka bir kullanıcının kimliğine geçmesine olanak tanır. Zayıf şifre politikaları, oturum yönetimi sorunları ve yetersiz çok faktörlü kimlik doğrulama (MFA) uygulamaları bu kategoriye girer.

    Önlem: Güçlü kimlik doğrulama mekanizmaları (OAuth, OpenID Connect), güvenli oturum yönetimi, MFA kullanımı ve şifreleme standartlarına uygunluk sağlanmalıdır.

    API3:2023 — Broken Object Property Level Authorization

    Açıklama: Bu kategori, nesne özellik düzeyinde yetkilendirme doğrulamasının eksikliği veya yanlış uygulanmasına odaklanır. Bu durum, yetkisiz taraflarca bilgi ifşasına veya manipülasyonuna yol açar. Örneğin, bir kullanıcının sadece kendi profil bilgilerini güncellemesi gerekirken, başka bir kullanıcının bilgilerini de güncelleyebilmesi bu tür bir açıktır.

    Önlem: API’lerin, gelen verilerdeki nesne özelliklerini doğru bir şekilde filtrelemesi ve yalnızca yetkili özelliklerin işlenmesine izin vermesi gerekir. whitelist yaklaşımı kullanılmalıdır.

    API4:2023 — Unrestricted Resource Consumption

    Açıklama: API isteklerini karşılamak için ağ bant genişliği, CPU, bellek ve depolama gibi kaynaklar gereklidir. Saldırganlar, API’yi aşırı yükleyerek DoS saldırılarına neden olabilir veya operasyonel maliyetleri artırabilir. Örneğin, çok büyük veri yükleri göndermek veya çok sayıda eşzamanlı istek yapmak bu tür bir saldırı yoludur.

    Önlem: API Rate Limiting, kota yönetimi ve istek boyut sınırlamaları gibi mekanizmalar uygulanmalıdır. API Gateway’ler bu konuda yardımcı olabilir.

    API5:2023 — Broken Function Level Authorization

    Açıklama: Farklı hiyerarşiler, gruplar ve rollerle karmaşık erişim kontrol politikaları ve idari ile normal işlevler arasındaki belirsiz ayrım, yetkilendirme hatalarına yol açma eğilimindedir. Saldırganlar bu sorunları kullanarak diğer kullanıcıların kaynaklarına ve/veya idari işlevlere erişim sağlayabilir.

    Önlem: Fonksiyonel yetkilendirme, her API uç noktası için açıkça tanımlanmalı ve uygulanmalıdır. Rol tabanlı erişim kontrolü (RBAC) veya nitelik tabanlı erişim kontrolü (ABAC) modelleri kullanılabilir.

    API6:2023 — Unrestricted Access to Sensitive Business Flows

    Açıklama: Bu riske karşı savunmasız API’ler, bir iş akışını (örneğin, bilet satın alma veya yorum gönderme) açığa çıkarır, ancak işlevselliğin otomatik bir şekilde aşırı kullanılması durumunda işe nasıl zarar verebileceğini telafi etmez. Bu, genellikle uygulama hatalarından kaynaklanmaz, daha çok iş mantığı zayıflıklarından kaynaklanır.

    Önlem: İş akışlarının kötüye kullanımını önlemek için bot koruması, CAPTCHA, anomali tespiti ve davranış analizi gibi önlemler alınmalıdır.

    API7:2023 — Server Side Request Forgery (SSRF)

    Açıklama: SSRF güvenlik açıkları, bir API uzaktan bir kaynak getirirken kullanıcı tarafından sağlanan URI’yi doğrulamadığında ortaya çıkabilir. Bu, bir saldırganın uygulamayı, bir güvenlik duvarı veya VPN tarafından korunsa bile, beklenmedik bir hedefe özel olarak hazırlanmış bir istek göndermeye zorlamasına olanak tanır.

    Önlem: Kullanıcı tarafından sağlanan tüm URL’ler ve kaynaklar sıkı bir şekilde doğrulanmalı ve whitelist yaklaşımı kullanılmalıdır. Dahili ağlara erişim kısıtlanmalıdır.

    API8:2023 — Security Misconfiguration

    Açıklama: API’ler ve onları destekleyen sistemler genellikle API’leri daha özelleştirilebilir hale getirmek için karmaşık yapılandırmalar içerir. Yazılım ve DevOps mühendisleri bu yapılandırmaları gözden kaçırabilir veya yapılandırma konusunda güvenlik en iyi uygulamalarını takip etmeyebilir, bu da farklı saldırı türlerine kapı açar.

    Önlem: Güvenli varsayılan yapılandırmalar kullanılmalı, gereksiz özellikler ve servisler devre dışı bırakılmalı, güvenlik yamaları düzenli olarak uygulanmalı ve güvenlik yapılandırmaları otomatik araçlarla denetlenmelidir.

    API9:2023 — Improper Inventory Management

    Açıklama: API’ler, geleneksel web uygulamalarından daha fazla uç nokta açığa çıkarma eğilimindedir, bu da doğru ve güncel dokümantasyonu son derece önemli hale getirir. Ana bilgisayarların ve dağıtılan API sürümlerinin doğru bir envanteri, eski API sürümleri ve açıkta kalan hata ayıklama uç noktaları gibi sorunları azaltmak için de önemlidir.

    Önlem: Tüm API’lerin (dahili, harici, üçüncü taraf) kapsamlı bir envanteri tutulmalı, güncel dokümantasyon sağlanmalı ve eski veya kullanılmayan API’ler devre dışı bırakılmalıdır.

    API10:2023 — Unsafe Consumption of APIs

    Açıklama: Geliştiriciler, üçüncü taraf API’lerden alınan verilere kullanıcı girdisinden daha fazla güvenme eğilimindedir ve bu nedenle daha zayıf güvenlik standartları benimserler. API’leri tehlikeye atmak için saldırganlar, doğrudan hedef API’yi tehlikeye atmaya çalışmak yerine entegre üçüncü taraf hizmetleri hedef alır.

    Önlem: Üçüncü taraf API’lerden alınan veriler de dahil olmak üzere tüm harici veriler doğrulanmalı ve temizlenmelidir. Üçüncü taraf entegrasyonları için güvenli yapılandırmalar ve yetkilendirme mekanizmaları kullanılmalıdır.

    API Güvenliği İçin En İyi Uygulamalar ve Önlemler

    Yukarıda belirtilen OWASP Top 10 tehditlerine ek olarak, API güvenliğini sağlamak için genel olarak aşağıdaki en iyi uygulamalar ve önlemler benimsenmelidir:

    1. Güçlü Kimlik Doğrulama ve Yetkilendirme: OAuth 2.0, OpenID Connect, JWT gibi standartları kullanarak güçlü kimlik doğrulama ve yetkilendirme mekanizmaları uygulayın. Her isteğin kimlik doğrulamasını ve yetkilendirmesini doğrulayın.

    2. Veri Şifreleme: API üzerinden iletilen tüm hassas verileri hem aktarım sırasında (SSL/TLS) hem de depolama sırasında (at-rest encryption) şifreleyin.

    3. Giriş Doğrulama ve Çıkış Kodlama: Tüm API girişlerini sıkı bir şekilde doğrulayın ve potansiyel kötü amaçlı verileri filtreleyin. Çıkış verilerini uygun şekilde kodlayarak XSS gibi saldırıları önleyin.

    4. Rate Limiting ve Dos Koruması: API’lerin aşırı kullanımını önlemek ve DoS saldırılarına karşı koruma sağlamak için rate limiting ve kota yönetimi uygulayın.

    5. API Gateway Kullanımı: API Gateway’ler, kimlik doğrulama, yetkilendirme, rate limiting, trafik yönetimi ve izleme gibi güvenlik işlevlerini merkezi bir noktadan yönetmenizi sağlar.

    6. Güvenlik Testleri: Düzenli olarak penetrasyon testleri, güvenlik açığı taramaları ve statik/dinamik uygulama güvenlik testleri (SAST/DAST) yaparak API’lerinizdeki zayıflıkları tespit edin.

    7. Loglama ve İzleme: API trafiğini, hataları ve güvenlik olaylarını kapsamlı bir şekilde loglayın. Anormal davranışları tespit etmek için sürekli izleme ve uyarı sistemleri kurun.

    8. Güvenli Kodlama Pratikleri: Geliştiricilerin güvenli kodlama prensiplerini benimsemesini sağlayın. Güvenlik eğitimleri düzenleyin ve güvenlik açıklarını önlemeye yönelik araçlar kullanın.

    9. Hata Yönetimi: API’lerin hata mesajlarının hassas bilgiler içermediğinden emin olun. Detaylı hata mesajları yerine genel hata kodları kullanın.

    10. API Envanteri ve Yaşam Döngüsü Yönetimi: Tüm API’lerinizin güncel bir envanterini tutun. Eski veya kullanılmayan API’leri düzenli olarak denetleyin ve devre dışı bırakın.

    11. Zero Trust (Sıfır Güven) Modeli: Her erişim noktasını potansiyel bir tehdit olarak değerlendiren ve her çağrıyı ayrı ayrı doğrulayan bir güvenlik paradigması olan Zero Trust modelini benimseyin.

    Sonuç olarak, API güvenliği, modern yazılım geliştirme ve dağıtım süreçlerinin ayrılmaz bir parçasıdır. API’lerinizi OWASP Top 10 gibi bilinen tehditlere karşı korumak ve yukarıda belirtilen en iyi uygulamaları benimsemek, dijital varlıklarınızı ve müşteri verilerinizi güvende tutmanın anahtarıdır. Unutmayın, güvenlik sürekli bir süreçtir ve API’lerinizin güvenliğini sağlamak için proaktif ve sürekli çaba gereklidir.

  • SSL/TLS nedir?

    SSL(Secure Socket Layer), network üzerindeki bilgi transferi sırasında bilginin bütünlüğü ve gizliliği için sunucu ile istemci arasındaki iletişimin şifrelenmiş şekilde yapılabilmesine imkan veren bir sertifikadır. Türkçesi güvenli giriş katmanı anlamıan gelmektedir.

    SSL protokolü bütün yaygın web sunucularında ve tarayıcılar tarafından desteklenmektedir. SSLin çalışabilmesi için sunucu tarafında bir anahtar(private key) istemci tarafında ise çalışacak bir sertifikaya(Public key) ihtiyaç duyulmaktadır.

    Kısaca Şekil 1’de de görüldüğü üzere SSL internet bağlantılarının güvenli olmasını sağlamaktadır. Kötü niyetli kişilerin iki uç sistem arasında aktarılan verileri açık bir şekilde okumasını engellemektedir. Tarayıcı üzerinde adres çubuğunun sol kısmında bir kilit simgesi bulunuyorsa bu sitenin SSL sertifikasının bulunduğu anlamına gelir.

    Netscape tarafından geliştirilen SSL ilk 1994 yılında kullanılmaya başlanmıştır. Protokolün bu 30 yıllık sürede birçok sürümü olmuştur ve bu sürümlerde oldukça önemli zafiyetler ortaya çıkmıştır. SSL; 1.0, 2.0 ve 3.0 sürümlerinden sonra yenilenerek TLS (Taşıma Katmanı Güvenliği) ismi verilmiştir. Günümüzde TLS 1.0, 1.1, 1.2 ve 1.3 olmak üzere kullanılmaktadır fakat kullanıcılar yine eski ismiyle kullanıyor.

    HTTPS açılımı Hyper Text Transfer Protokol Secure Türkçesi ise Güvenli Hiper Metin Aktarım Protokolü anlamına gelmektedir. Tarayıcı ile Web sunucusu gibi iki uç sistem arasındaki iletişimin güvenliğini sağlamak için kullanılan bir protokoldür.

    Şekil 2’de görüldüğü üzere HTTP ve HTTPS arasındaki fark şema üzerinde belirtilmiştir. HTTP ile yapılan iletişimlerde giden ve gelen veriler açık şekilde iletilmektedir. Fakat HTTPS iletişiminde ise giden ve gelen veriler şifreli şekilde iletilmektedir. HTTP iletişiminde araya giren kötü niyetli biri iletişimi okuyup değiştirirken HTTPS iletişiminde veriler güvenli olduğundan okunamaz ve manipüle edilemez. Kötü niyetli kişiler iletişimi engellese bile verileri okuyamamaktadır. HTTPS verileri SSL sayesinde şifrelemektedir.

    SSL, temelde asimetrik ve simetrik kriptografi algoritmalarıyla çalışır.

    Simetrik Kriptografi: Şekil 3’te de görüldüğü üzere simetrik şifrelemede tek anahtar bulunur. Bu anahtar veriyi hem şifreler hem de şifreyi çözer. Örnek olarak kapı anahtarı verilebilir hem kapıyı kilitler hem de kilitli kapıyı açar. En yaygın kullanılan simetrik algoritmalar AES-128, AES-192 ve AES-256’dır.

    Asimetrik Kriptografi: Asimetrik Şifreleme veya Açık Anahtar Şifreleme olarak da bilinir. Şekil 4’te de görüldüğü üzere bu yöntem, verileri şifrelemek ve şifresini çözmek için matematiksel olarak ilişkili bir anahtar çifti kullanır. Anahtar çiftinin biri, herkesle paylaşılabilen public key (açık anahtar) olarak adlandırılır. Diğer anahtar ise gizli tutulur ve private key (özel anahtar) olarak bilinir.

    Asimetrik kriptografide, anahtarlar matematiksel değerlerdir ve verileri şifreleyen veya şifresini çözen özel algoritmalar kullanılarak oluşturulur. Bu yöntemde, veriler yalnızca belirli bir özel anahtar ile imzalanabilir ve yalnızca onunla ilişkili genel anahtar kullanılarak şifresi çözülebilir.

    Asimetrik şifreleme, özellikle SSL (Güvenli Yuva Katmanı) protokolü gibi güvenli iletişim sistemlerinde kullanılır. SSL anlaşması, iletişimi başlatmak için asimetrik şifreleme yönteminden faydalanır.En yaygın kullanılan asimetrik anahtar şifreleme algoritmaları arasında ElGamal, RSA, DSA ve PKCS bulunur.

    SSL’in Çalışma mantığı nasıldır?

    SSL ile gerçekleştirilen bir iletişim her zaman SSL anlaşması ile başlar. Bu anlaşmanın temeli, tarayıcının web sunucusunu doğrulamasına, public key almasına ve asıl veri aktarımı başlamadan önce şifreli yani güvenli bir bağlantı oluşmasına dayanır. Bu süreçte, asimetrik şifreleme kullanılarak güvenli bir iletişim kanalı oluşturulur.

    Şekil 5’te verilen SSL anlaşma şemasının açıklamasını adım adım ele alalım;

    1.Adım: İstemci, iletişimi başlatmak için “Client Hello” mesajı gönderir. Bu mesaj, istemcinin SSL sürüm numarasını, şifreleme algoritmalarını, oturuma özgü verileri ve sunucunun SSL kullanarak istemciyle güvenli bir bağlantı kurması için gerekli diğer bilgileri içerir.

    2.Adım: Sunucu, “Server Hello” mesajıyla yanıt verir. Bu mesaj, sunucunun SSL sürüm numarasını, şifreleme algoritmalarını, oturuma özgü verileri ve genel anahtarlı bir SSL sertifikasını içerir. Ayrıca, istemcinin sunucuyla güvenli bir şekilde iletişim kurması için gereken diğer bilgileri de sağlar.

    3.Adım: İstemci, sunucunun SSL sertifikasını Sertifika Yetkilisi (CA) üzerinden doğrular ve sunucunun kimliğini kontrol eder. Eğer kimlik doğrulama başarısız olursa, istemci SSL bağlantısını reddeder ve bir hata oluşturur. Başarılı olması durumunda ise bir sonraki adıma geçilir.

    4.Adım: İstemci, bir oturum anahtarı oluşturur, bunu sunucunun genel anahtarıyla şifreleyerek sunucuya gönderir. Eğer sunucu, istemcinin kimlik doğrulamasını talep ettiyse (genellikle sunucudan sunucuya iletişimde), istemci ayrıca kendi sertifikasını da sunucuya iletir.

    5.Adım: Sunucu, gelen oturum anahtarının şifresini kendi özel anahtarıyla çözer ve bağlantının doğrulandığını göstermek için oturum anahtarıyla şifrelenmiş bir onay mesajını istemciye gönderir.

    Bu nedenle, SSL anlaşmasının sonunda, hem istemci hem de sunucu, gerçek verileri şifrelemek ve şifresini çözmek için kullanacakları ortak bir oturum anahtarına sahip olur. Bu aşamadan sonra, açık anahtar ve özel anahtar bir daha kullanılmaz; iletişim, simetrik şifreleme ile devam eder.

    Tarayıcı Sertifanın Doğruluğunu nasıl tespit eder

    Şekil 7’de görüldüğü üzer bir SSL sertifikası bulunmaktadır. Bu sertifikanın doğrulanma sürecini ele alalım;

    1. Adım Sertifikayı Alma: Tarayıcı, bir web sitesine HTTPS üzerinden bağlanmak istediğinde, ilk olarak sunucuya bir istekte bulunur. Sunucu, kendisini doğrulamak ve güvenli bir bağlantı sağlamak amacıyla içinde public key (genel anahtar) bulunan SSL/TLS sertifikasını tarayıcıya iletir. Bu sertifika, web sitesinin kimliğini doğrulamak için kullanılan dijital bir belgedir.

    2. Adım Sertifika Zincirini Kontrol Etme: Sertifikayı alan tarayıcı, öncelikle sertifikanın zincirini kontrol eder. Sertifikayı hangi yetkili otoritenin (Issuer) verdiğini belirler ve bu otoritenin güvenilir olup olmadığını anlamaya çalışır. Eğer sertifika, tanınan bir Certificate Authority (CA) tarafından verilmişse, tarayıcı bu otoritenin köken (root) sertifikasını bulur. Köken sertifikaları genellikle tarayıcının içinde önceden yüklü olarak bulunur ve güvenilir kabul edilir.

    3.Adım Dijital İmzayı Doğrulama: Daha sonra tarayıcı, sertifikanın dijital imzasını doğrular. Bu işlem, sertifikanın içinde bulunan public key kullanılarak gerçekleştirilir. Eğer imza geçerliyse, sertifikanın gerçekten CA tarafından verildiği ve üzerinde herhangi bir değişiklik yapılmadığı anlaşılır. Bu, sertifikanın güvenilir olup olmadığını belirlemede kritik bir adımdır.

    4. Adım Sertifika Geçerliliğini Kontrol Etme: Sertifikanın geçerliliği de kontrol edilmelidir. Bu aşamada tarayıcı, sertifikanın süresinin dolup dolmadığını, bağlanılmak istenen alan adı (CN — Common Name) ile eşleşip eşleşmediğini denetler. Örneğin, sertifika yalnızca “test.com” için verilmişse, tarayıcının bağlandığı adres de “https://test.com” olmalıdır. Ayrıca, sertifikada kullanılan şifreleme algoritmalarının güçlü olup olmadığı ve sertifikanın daha önce iptal edilip edilmediği gibi güvenlik kriterleri de incelenir.

    5. Adım Sertifika İptal Listelerini (CRL/OCSP) Kontrol Etme: Sertifika iptal durumunu doğrulamak için tarayıcı, CA tarafından yayınlanan Sertifika İptal Listesi (CRL — Certificate Revocation List) veya Online Sertifika Durum Protokolü (OCSP — Online Certificate Status Protocol) sunucularına bir istek gönderir. Eğer sertifika iptal edilmişse, tarayıcı siteyi güvenli kabul etmez ve kullanıcıyı uyarır. Bu, çalıntı veya tehlikeye girmiş sertifikaların kullanımını engellemek için kritik bir adımdır.

    6. Adım Güvenli Bağlantıyı Kurma: Son olarak, tüm kontrolleri başarıyla geçen sertifikaya sahip bir siteyle güvenli bağlantı kurulabilir. Tarayıcı ve sunucu, TLS handshake sürecini tamamlayarak ortak bir şifreleme anahtarı belirler ve güvenli iletişim başlar.

    Bu sürecin tamamı Public Key Infrastructure (PKI) içinde gerçekleşir. Eğer herhangi bir adımda hata olursa, tarayıcı “Güvenli değil” uyarısı verir.

    Geçmişten Günümüze SSL/TLS Gelişimi

    SSL 1.0: Ciddi güvenlik eksikleri nedeniyle yayınlanmamıştır

    SSL 2.0: İnternet üzerindeki ilk güvenli iletişim protokollerinden biri olmuştur. Fakat mesaj bütünlüğü kontrol mekanizmasının zayıflığı ve MITM (ortadaki adam saldırısı) saldırılarına karşı savunmasız kalmıştır. Bu sebeplerden dolayı 2011 yılında kullanımdan kaldırılmıştır.

    SSL 3.0: Daha önceki sürümlerin açıklarını kapatmak ve diğer sürümlere nazaran daha güvenli şifreleme algoritması sunmak için geliştirilmiştir. POODLE (Padding Oracle On Downgraded Legacy Encryption) saldırılarına karşı savunmasızdı ve MD5 ile SHA-1 gibi zayıf algoritmalar kullanıldığından dolayı 2015 yılında kullanımdan kaldırılmıştır.

    TLS 1.0: SSL 3.0’ın yerine geçmesi için geliştirilen TLS 1.0, daha güvenli bir protokol yapısına sahiptir. Buna rağmen yine de BEAST (Browser Exploit Against SSL/TLS) saldırısına karşı savunmasız olmuştur. Bu nedenden dolayı zamanla güvenlik riski oluşturmuş ve 2020 itibariyle kullanımdan kaldırılmıştır.

    TLS 1.1: BEAST saldırısına karşı daha dayanıklı hale getirilerek geliştirilmiştir ve blok şifreleme modlarını güçlendirmiştir. Ancak, modern siber tehditlere karşı yeterli olmaması nedeniyle 2020 yılında kullanımdan kaldırılmıştır.

    TLS 1.2: SHA-256 gibi daha güçlü hash algoritmalarını destekleyen, AEAD (Authenticated Encryption with Associated Data) kullanımına izin veren ve forward secrecy desteği sunan bir protokol olmuştur. AEAD, hem veri gizliliği hem de bütünlüğü sağlayarak güvenliği artırırken, forward secrecy ise uzun vadeli şifreleme anahtarlarının ele geçirilmesi durumunda geçmiş oturumların korunmasını garanti eder. Ancak, gereksiz el sıkışma mesajları nedeniyle performans açısından geliştirilmeye açıktır.

    TLS 1.3: Güvenlik ve performans iyileştirilmeleriyle en güncel ve güvenli sürümdür. Daha hızlı el sıkışma protokolü sayesinde çok daha verimli çalışır ve eski, güvensiz şifreleme algoritmalarını tamamen kaldırarak forward secrecy’yi zorunlu hale getirmiştir. AEAD algoritmalarının standart hale getirilmesiyle veri güvenliği daha da artırılmıştır. Ancak, eski sistemlerle uyumluluk sorunları yaratabileceği için bazı kurumsal ortamlarda güncellemeler gerektirmektedir.

    SSL ve TLS arasındaki farklar nelerdir?

    SSL ve TLS aynı amaca hizmet etseler de geçen bu sürede önemli değişikliklere tanık olmuştur. Bu değişikliklerin özeti tablo 1’de verilmiştir.

  • Hello world!

    Welcome to WordPress. This is your first post. Edit or delete it, then start writing!