MS Lesson4: HTTP vs HTTPS
Https ile spring boot configuration. Keystore yaratmaq:
terminalda:
keytool -genkeypair \
-alias demoapp \
-keyalg RSA \
-keysize 2048 \
-storetype PKCS12 \
-keystore src/main/resources/keystore.p12 \
-validity 3650
Bunun ucun Proxyman - da sorgu atiriq, sadece sorgu bu shekilde olacaq: https://localhost.proxyman.io:9595/param?id=1&name=Parvin&surname=Etibarli
Keystore silmek:
rm src/main/resources/keystore.p12
Case1 — Happy case (saxtakarlıq yoxdur)
- A a_kilid-i B-yə göndərir.
- B b_kilid-i A-ya göndərir.
- C istəsə bu kilidləri kopyalaya bilər, amma bu normaldır (public-dir).
- A məktubu qutuya qoyur.
- Qutunu b_kilid ilə bağlayır.
- C qutunu B-yə aparır.
- B qutunu b_acar ilə açır və oxuyur.
- B cavab məktubunu qutuya qoyur.
- Qutunu a_kilid ilə bağlayır.
- C qutunu A-ya aparır.
- A qutunu a_acar ilə açır və oxuyur.
Case2 — Oğurluq/MITM (C kilidləri əvəzləyir)
- A a_kilid-i B-yə göndərir.
- C yolda onu saxlayır, B-yə c_kilid verir (sanki A-nındır).
- B b_kilid-i A-ya göndərir.
- C yolda onu saxlayır, A-ya c_kilid verir (sanki B-nindir).
- A mesajı c_kilid ilə bağlayır (B-ninki sanır).
- C qutunu c_acar ilə açır, oxuyur.
- Sonra mesajı b_kilid ilə yenidən bağlayıb B-yə göndərir.
- B b_acar ilə açır, heç nə hiss etmir.
- B mesajı yenə c_kilid ilə bağlayır (A-nınkı sanır).
- C c_acar ilə açır, oxuyur.
- Sonra a_kilid ilə yenidən bağlayıb A-ya göndərir.
- A a_acar ilə açır, yenə heç nə hiss etmir.
Hell qaydasi:
Personajlar və obyektlər
- A: göndərən
- B: alıcı
- C: aradakı saxtakar/kuryer
- CA (notarius): hamının güvəndiyi təsdiqləyici qurum
- b_kilid = B-nin public key-i (hamıya açıla bilər)
- b_acar = B-nin private key-i (yalnız B-də qalır)
CA olmadan problem nə idi?
- mesajı c_kilid ilə bağlayır,
- C c_acar ilə açır, oxuyur,
- sonra B-yə yenidən b_kilid ilə bağlayıb göndərir.
CA (notarius) bu problemi necə həll edir?
Addım 1 — B notariusa gedir
- “Mən B-yəm”
- “Bu da mənim b_kilid-im”
Addım 2 — CA sənəd verir (sertifikat)
- “Sahib: B”
- “Kilid: b_kilid”
- “Vaxt: bu tarixə qədər keçərlidir”
- “İmza: CA-nın rəqəmsal imzası”
Addım 3 — A-da CA-ya etibar əvvəlcədən var
- “CA-nın imzasını yoxlaya bilirəm.”
Addım 4 — A, B-dən kilid alanda artıq tək kilid almır
- b_kilid
- sertifikat (CA imzalı)
Addım 5 — A sertifikatı yoxlayır
- CA imzası düzdürmü?
- Sertifikat vaxtı bitməyib?
- Sertifikatdakı ad doğrudan qoşulduğum adla eynidirmi? (b.com vs b.com)
- “Bu kilid həqiqətən B-yə aiddir.”
Addım 6 — A mesajı şifrələyir
C niyə artıq alınmır?
- Saxta sertifikat düzəltsin → A imzanı yoxlayanda tutacaq (CA imzası uyğun gəlmir).
- Öz adına düzgün sertifikat versin → ad uyuşmazlığı çıxacaq (c.com vs b.com).
1) CA sertifikatı necə yaradır? (B üçün)
- B açar cütü yaradır
- b_kilid (public)
- b_acar (private, serverdən çıxmır)
- B bir “ərizə” yaradır (CSR)
- Buna Certificate Signing Request deyirlər
- İçində əsasən bunlar olur:
- domain adı (example.com)
- B-nin public key-i (b_kilid)
- təşkilat məlumatı (OV/EV hallarda)
- Bu ərizə B tərəfindən private key ilə əlaqəli şəkildə hazırlanır (yəni key pair-ə bağlıdır)
- B CSR-i CA-ya göndərir
- CA yoxlama aparır
- Minimumda (DV): “Bu domain həqiqətən B-nindir?”
- Daha ciddi hallarda (OV/EV): şirkət hüquqi məlumatları da yoxlanır
- CA sertifikat yaradır və imzalayır
- Sertifikat içində:
- Subject (kimə verilib)
- Public key (b_kilid)
- SAN (hansı domain-lər üçün keçərlidir)
- NotBefore / NotAfter (vaxt aralığı)
- Issuer (hansı CA verib)
- Sonra CA öz private key-i ilə bunun üstünə rəqəmsal imza vurur
2) A niyə CA-ya güvənir?
- OS/browser daxilində bir siyahı olur: “etibarlı kök CA-lar”
- Bu siyahıda hər kök CA-nın root public key-i olur
- A serverdən sertifikat alanda bu public key-lərlə imzanı yoxlayır
3) A serverə qoşulanda texniki nə yoxlayır?
- İmza doğrudurmu?
- Chain qurulurmu?
- Domain uyğun gəlirmi?
- Müddət keçməyib?
- Revoked deyil?
4) C niyə saxtalaşdıra bilmir?
- Öz key-i ilə B adına saxta sertifikat düzəltmək
- İmza CA-dan olmadığı üçün A bunu rədd edir
- Öz adına real sertifikat göstərmək (c.com)
- Domain mismatch çıxır (example.com gözlənilirdi)
- CA-nın private key-i yoxdur
- Ona görə “B adına etibarlı imza” yarada bilmir
5) Root CA, Intermediate CA niyə var?
- Root CA çox qorunan yerdə qalır
- Root, intermediate CA-ları imzalayır
- Intermediate-lər son istifadəçi sertifikatlarını verir
6) Sənin notarius analoqunda tam uyğunluq
- CA Root = dövlət səviyyəli baş notarius
- Intermediate CA = rayon notariusları
- Server cert = “bu açar bu domenə məxsusdur” sənədi
- Trust Store = A-nın “hansı notariuslara inanıram” siyahısı
Certificate Authority (CA) nedir?
Certificate Authority (CA) – rəqəmsal dünyanın "Pasport İdarəsi" və ya **"Notariusu"**dur. Onun əsas vəzifəsi internetdəki tərəflərin (saytların, şirkətlərin və ya şəxslərin) həqiqətən kim olduqlarını təsdiq etməkdir.
Pasport Bənzətməsi
Təsəvvür et ki, sən xarici ölkəyə gedirsən. Oradakı polis sənin kim olduğunu haradan bilir? Sənin sözünə inanmır, amma sənin pasportuna inanır. Çünki o pasportu hər kəsin etibar etdiyi rəsmi bir dövlət qurumu (CA) verib.
| Real Dünya | Rəqəmsal Dünya |
| Sən | Veb-sayt (məsələn, https://www.google.com/search?q=google.com) |
| Pasport | SSL/TLS Sertifikatı |
| Pasport İdarəsi (ASAN Xidmət) | Certificate Authority (CA) |
| Polis/Gömrük | Sənin brauzerin (Chrome, Safari və s.) |
CA necə işləyir? (Sadə addımlarla)
Müraciət: Bir veb-sayt sahibi (məsələn, sən) öz saytı üçün təhlükəsizlik sertifikatı almaq istəyir. O, CA-ya müraciət edir.
Yoxlama: CA dərhal sertifikat vermir. Öncə yoxlayır ki, bu domen (məsələn,
seninsaytin.com) həqiqətən sənindirmi və sən real şəxssənmi.İmzalama: Yoxlama bitdikdən sonra CA həmin sayt üçün rəqəmsal bir sertifikat hazırlayır və onu öz "möhürü" (rəqəmsal imza) ilə təsdiqləyir.
Etibar: Sən o sayta daxil olanda brauzerin baxır: "Bu sertifikatı kim verib? Aha, filan CA verib. Mən bu CA-ya inanıram, deməli bu sayt saxta deyil."
CA olmasa nə olar?
Əgər CA-lar olmasaydı, hər hansı bir fırıldaqçı asanlıqla saxta bir "facebook.com" və ya "https://www.google.com/search?q=bank-sayti.com" qura bilərdi. Sən o sayta daxil olanda brauzerin onun həqiqi və ya saxta olduğunu anlaya bilməzdi, çünki onu təsdiq edən ortaq bir etibarlı tərəf olmazdı.
Tanınmış CA-lar:
İnternetdə ən çox qarşılaşdığın CA-lar bunlardır: Let's Encrypt (pulsuz olduğu üçün çox məşhurdur), DigiCert, Sectigo və GlobalSign.
Public Key Infrastructure (PKI)
Public Key Infrastructure (PKI) — rəqəmsal dünyada şəxsiyyətləri təsdiq edən və məlumatların təhlükəsiz ötürülməsini təmin edən sistemlər, qaydalar və simmetrik olmayan şifrələmə (asymmetric encryption) toplusudur.
HTTPS kontekstində PKI-ın əsas vəzifəsi "Mən həqiqətən daxil olduğum saytla (məsələn, https://www.google.com/search?q=google.com) danışırammı?" sualına cavab verməkdir.
PKI-ın Əsas Komponentləri
PKI-ı bir dövlətin pasport sistemi kimi təsəvvür edə bilərsiniz:
Digital Certificate (Rəqəmsal Sertifikat): Bu, veb-saytın "pasportu"dur (SSL/TLS sertifikatı). İçində saytın adı və onun Public Key-i olur.
Certificate Authority (CA - Sertifikat Mərkəzi): Pasportu verən "ASAN Xidmət" və ya "Daxili İşlər Nazirliyi" kimidir. Məsələn: DigiCert, Let's Encrypt. Onlar saytın sahibini yoxlayır və sertifikatı rəqəmsal imza ilə təsdiqləyirlər.
Public & Private Key (Açıq və Gizli Açarlar): PKI-ın riyazi əsasıdır.
Public Key: Hər kəsə açıqdır, məlumatı şifrələmək üçün istifadə olunur.
Private Key: Sırf serverdə saxlanılır, şifrəni açmaq üçün istifadə olunur.
Registration Authority (RA): CA-ya kömək edən, müraciətləri yoxlayan qurumdur.
PKI necə işləyir? (HTTPS Prosesi)
Siz brauzerdə bir sayta daxil olduqda bu zəncirvari proses baş verir:
Addım 1: Server brauzerinizə öz rəqəmsal sertifikatını göndərir.
Addım 2: Brauzeriniz sertifikatın altındakı imzaya baxır: "Bunu etibarlı bir CA (məsələn, Let's Encrypt) imzalayıb?"
Addım 3: Brauzerinizdə öncədən yüklənmiş "Etibarlı CA-lar siyahısı" var. Əgər imza doğrudursa, brauzer sayta inanır.
Addım 4: Brauzer sertifikatdakı Public Key-i götürür, onunla müvəqqəti bir "ünsiyyət açarı" (session key) şifrələyir və serverə göndərir.
Addım 5: Server özündəki Private Key ilə bu şifrəni açır. İndi hər iki tərəfdə eyni açar var və HTTPS bağlantısı (yaşıl qıfıl) aktivləşir.
Niyə PKI lazımdır?
Əgər PKI olmasaydı, araya girən bir haker (Man-in-the-Middle) sizə öz Public Key-ini göndərib özünü "bank saytı" kimi təqdim edə bilərdi. PKI-dakı CA (Sertifikat Mərkəzi) faktoru bunun qarşısını alır, çünki haker saxta sertifikatı etibarlı bir quruma imzalada bilməz.
Siz proqramçı olduğunuz üçün bir nümunə çəkim: Məsələn, curl ilə HTTPS sayta müraciət edəndə bəzən "SSL certificate problem" xətası alırıq. Bu, əslində PKI zəncirinin qırılması deməkdir (ya sertifikat köhnəlib, ya da imzalayan qurum tanınmır).
kod numunesi:
package com.compiler.encrypt;
import javax.crypto.Cipher;
import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.util.Base64;
public class Main {
public static void main(String[] args) {
try {
String message = "Salam, bu gizli mesajdır!";
// 1. RSA açar cütünü (Public və Private) yaradırıq
KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA");
keyPairGen.initialize(2048);
KeyPair pair = keyPairGen.generateKeyPair();
PublicKey publicKey = pair.getPublic();
PrivateKey privateKey = pair.getPrivate();
String string = publicKey.toString();
System.out.println(string);
// 2. Şifrələmə (Encryption)
String encryptedMessage = encrypt(message, publicKey);
System.out.println("Şifrələnmiş mesaj: " + encryptedMessage);
// 3. Deşifrə etmə (Decryption)
String decryptedMessage = decrypt(encryptedMessage, privateKey);
System.out.println("Deşifrə olunmuş mesaj: " + decryptedMessage);
} catch (Exception e) {
e.printStackTrace();
}
}
public static String encrypt(String message, PublicKey publicKey) throws Exception {
Cipher cipher = Cipher.getInstance("RSA");
cipher.init(Cipher.ENCRYPT_MODE, publicKey);
byte[] encryptedBytes = cipher.doFinal(message.getBytes());
return Base64.getEncoder().encodeToString(encryptedBytes);
}
public static String decrypt(String encryptedMessage, PrivateKey privateKey) throws Exception {
Cipher cipher = Cipher.getInstance("RSA");
cipher.init(Cipher.DECRYPT_MODE, privateKey);
byte[] decryptedBytes = cipher.doFinal(Base64.getDecoder().decode(encryptedMessage));
return new String(decryptedBytes);
}
}
TLS handshake ile application yaratmaq:
Step1:
keytool -genkeypair \
-alias demoapp \
-keyalg RSA \
-keysize 2048 \
-storetype PKCS12 \
-keystore src/main/resources/server-keystore.p12 \
-validity 3650 \
-dname "CN=localhost, OU=Demo, O=Demo, L=Baku, ST=Baku, C=AZ"
Step2:
application.properties - de set etmek:
server.port=8443
server.ssl.enabled=true
server.ssl.key-store=classpath:server-keystore.p12
server.ssl.key-store-type=PKCS12
server.ssl.key-store-password=changeit123
server.ssl.key-alias=demoapp
Step3: diger application key export edirik
keytool -exportcert \
-alias demoapp \
-keystore src/main/resources/server-keystore.p12 \
-storetype PKCS12 \
-rfc \
-file server-cert.cer
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
Комментарии
Отправить комментарий