HTTPS şifreleme ilkesini göstermek için 5 dakika, SSL / TLS kontrolünüz altında!
İnternet çağında, her zaman İnternet dalgasının içindeyiz. Ödeme / finans / giriş / çevrimiçi alışveriş gibi hassas işletmeleri ziyaret ettiğinizde, bu web sitelerinin https: // URL'sine yönlendirileceğini fark ettiniz mi bilmiyorum, örneğin:
- Adres yeşildir, bu da güvenli ve güvenilir olan şifreli aktarımın kullanıldığı anlamına gelir;
- Adres kırmızıdır, bu, şifreleme açık olmasına rağmen web sitesinin kimliğinin doğrulanmadığı ve kurcalanmayacağına dair hiçbir garanti olmadığı anlamına gelir.
Adres çubuğundaki https: // web sitesine vurduğumuz andan, önümüzde görüntülenen içeriğe kadar, hangi süreçten geçti? Tarayıcı neye dayanarak karar veriyor, mevcut web sitesi URL'si güvenli mi yoksa doğrulanmamış mı? Hemen takip edin İnternet diplomatik güvenlik stratejisinin SSL / TLS protokolünün çalışma mekanizmasını inceleyelim.
SSL / TLS protokolünün kaynağı
Menşei
İlk iletişim, SSL / TLS olmadan HTTP iletişimidir, yani şifrelemesiz iletişimdir. İnsanların bilgi aktarımı sürecinde pek çok sorun vardır: üçüncü bir şahıs tarafından gizlice dinleme, iletişim içeriğinin üçüncü bir şahıs tarafından değiştirilmesi ve başka bir şahıs gibi davranan üçüncü bir şahsın iletişime katılımı. Çeşitli bilgi güvenliği sorunları herkesin dikkatini çekti. Herkes, bilgi güvenliğini sağlayabilecek şifreli bir bilgi aktarımı olabileceğini umuyor. SSL / TLS protokolü doğdu.
Tarih gelişimi
İnternet şifreli iletişim protokolünün geçmişi, neredeyse İnternet:
1994 yılında, NetScape şirketi SSL versiyon 1.0'ı tasarladı, ancak henüz piyasaya sürülmedi;
1995'te NetScape, çok geçmeden ciddi güvenlik açıklarını keşfeden SSL 2.0 sürümünü yayınladı;
1996 yılında SSL 3.0 sürümü çıktı ve büyük ölçekli uygulamaya kavuştu;
1999'da İnternet Mühendisliği Görev Gücü (IETF), SSL'nin yükseltilmiş bir sürümü olan TLS adlı yeni bir protokolü standartlaştırdı;
2006 ve 2008'de, TLS iki kez yükseltilerek sırasıyla TLS 1.1 ve TLS 1.2'ye yükseltildi. TLS 1.2'nin gözden geçirilmiş bir sürümü 2011'de yayınlandı;
TLS 1.3'ün son sürümü Ağustos 2018'de piyasaya sürüldü ve birçok güvenlik ve performans iyileştirmesi içeriyor.
Görülebileceği gibi, SSL ve TLS aynı protokolün farklı sürümleri olarak anlaşılabilir, bu nedenle her zaman çiftler halinde görünürler.
SSL / TLS'nin TCP / IP referans modelindeki konumu
SSL / TLS aslında tek bir protokolden ziyade dört bölümden oluşan bir protokol paketidir: SSL / TLS el sıkışma protokolü, değiştirilmiş şifreleme metin protokolü, alarm protokolü ve kayıt protokolü.
SSL / TLS protokolünün kendisi iki katmana ayrılabilir: ana olanlar SSL kayıt protokolü ve SSL el sıkışma protokolüdür.
SSL kayıt protokolü, TCP gibi güvenilir bir aktarım protokolü üzerine inşa edilmiştir ve yüksek seviyeli protokoller için veri kapsülleme, sıkıştırma ve şifreleme gibi temel işlevleri sağlar.
SSL el sıkışma protokolü, SSL kayıt protokolünün üzerine inşa edilmiştir ve gerçek veri aktarımı başlamadan önce iletişim kuran taraflar arasında kimlik doğrulama, görüşme ve anahtar değişimi vb. İçin kullanılır.
SSL / TLS güvenliğe nasıl ulaşır?
SSL / TLS protokolünü kullanmak, İnternet üzerindeki iletişimimizi "anlaşılmaz, değiştirilemez veya taklit edilemez" hale getirebilir. Bu güvenlik protokolleri seti gerçekten karmaşıktır! Bilgi güvenliğinin gizliliğini, bütünlüğünü ve gerçekliğini sırasıyla onayladı.
Gizlilik: İletişim kuran taraflar, konuşmalarının içeriğini kimsenin anlayamayacağına ikna olduklarında, iletişim gizli kabul edilir. Simetrik şifrelemenin kullanılması, iletişimin gizliliğini sağlayabilir.
Tamlık: SSL / TLS'nin bir doğrulama mekanizması vardır ve MAC el sıkışma protokolünde tanımlanır.Bilgi ile oynandığında, her iki taraf da hemen öğrenecek ve önlem alacaktır.
Doğrulanabilir: Kötü niyetli saldırganların meşru bir web sitesini taklit etmesini önlemek için, web sitesinin kimliğini sertifika ve genel anahtar şifreleme yoluyla web tarayıcısına kanıtlaması gerekir.Bu süreçte tarayıcının sertifikaya güvenmesi için iki şeye ihtiyacı vardır: diğer tarafın sertifikanın sahibi olduğunu kanıtlama Ve sertifikanın gerçek olduğunu kanıtlayın.
İnternet iletişiminde, gizlilik ve doğrulanabilirlik, paylaşılan bir anahtarın oluşturulması ve bir sertifikanın sahipliğinin kanıtlanması süreciyle sağlanır. SSL / TLS protokolü bu iki noktayı bir "el sıkışma" süreciyle elde eder Bütünlük, el sıkışma protokolü tarafından tanımlanan MAC ile sağlanır. Peki, bu kadar önemli bir "tokalaşma" sürecine ne dersiniz?
"El sıkışma" sürecini ayrıntılı olarak açıklayın
"El sıkışma aşaması" dört iletişimi içerir, hadi onlara tek tek bakalım. "El sıkışma aşamasındaki" tüm iletişimlerin düz metin şeklinde olduğuna dikkat edilmelidir.
İstemci, aşağıdaki bilgilerle sunucuya bir istek gönderir:
Sunucu, istemcinin isteğine yanıt verir. Oturum Kimliği önceki adımda getirilirse, oturum doğrudan devam ettirilir, aksi takdirde aşağıdaki bilgiler istemciye getirilir:
İstemci, sertifikanın geçerlilik süresini ve sertifikadaki etki alanı adının geçerli oturum etki alanı adıyla eşleşip eşleşmediğini ve en üst düzey sertifika verenin işletim sistemi tarafından güvenilen bir CA kuruluşu olup olmadığına dair güven zincirini araştırmak dahil olmak üzere burada sunucu sertifikasının meşruiyetini doğrular.
Müşteri yanıtıİstemci, sunucu sertifikasının geçerliliğini doğrular, bir ön yönetici sırrı oluşturur ve aşağıdaki bilgileri sunucuya gönderir:
Bu, el sıkışma sürecinin son adımıdır, sunucu aşağıdaki bilgileri istemciye gönderecektir:
Bu sırada, istemci ve sunucu aynı anda üç rastgele sayıya sahiptir ve bu üç rasgele sayı kullanılarak üretilen anahtar, sonraki iletişimlerin simetrik şifrelemesi için kullanılacaktır.
Arasöz
1. Genel anahtarın ziyaret edilen yasal web sitesine ait olduğundan nasıl emin olunur?
Genel anahtarı dijital sertifikaya koyun Sertifikayı veren CA güvenilir olduğundan genel anahtar güvenilirdir.
2. Oturum anahtarını oluşturmak neden bu kadar karmaşık, neden kararlaştırılan anahtarı doğrudan daha uygun bir şekilde iletmiyorsunuz?
Saldırı yöntemlerinin sürekli geliştirilmesiyle herhangi bir aktarım sürecine güvenilemez, oturum anahtarı şifrelenip iletilse bile çalınma tehlikesi vardır. Bu nedenle, Diffle-Hellman anahtar anlaşması algoritmasını kullanarak, oturum anahtarının kendisi iletim sırasında hiçbir zaman görünemez ve oturum anahtarı yalnızca el sıkışmasının sonunda istemcide ve sunucuda yerel olarak oluşturulur.
3. Simetrik bir oturum anahtarı oluşturmak çok karmaşık olduğundan, anahtar sızıntısını önleyebilecek açık anahtar şifrelemesini neden kullanmayalım?
Açık anahtar şifrelemesi simetrik şifrelemeden daha yavaş olduğu için, iletişim sırasında büyük miktarlarda veri şifreleme için uygun değildir.
4. El sıkışma sırasında sunucunun özel anahtarın sahibi olduğu nasıl doğrulanır?
İstemci, sunucunun özel anahtarını göremiyorsa, sunucunun özel anahtarı kullanabileceğini kanıtlamasına izin verin. Sunucu, istemcinin bildiği bilgileri dijital olarak imzalamak için özel anahtarı kullanır. İstemci, sunucunun genel anahtarıyla dijital imzayı doğrulayabilirse , Karşı tarafın ilgili özel anahtarı elinde tuttuğunu onaylayabilirsiniz.
Bugün dünden daha bilgili!
