أسرار HTTPS و TLS خلف علامة القفل: المصافحة غير المتناظرة، التشفير المتناظر، و PKI

🔒 HTTPS: What Really Happens Behind the Lock?

HTTPS مش مجرد HTTP وعليه 🔒 😂

هو بروتوكول HTTP يعمل فوق اتصال محمي بـTLS، مع certificate validation وcryptographic key establishment.

📚 Table of Contents

• الفكرة في دقيقة
• HTTP بدون HTTPS
• HTTPS يعني إيه؟
• TLS ولا SSL؟
• TLS Handshake
• ClientHello
• ServerHello
• Certificate
• Certificate Authority
• Certificate Validation
• Asymmetric vs Symmetric Cryptography
• هل الـPublic Key يشفر الـSession Key؟
• TLS 1.3 وKey Exchange
• Session Keys
• Confidentiality
• Integrity
• Authentication
• هل HTTPS يخفي كل حاجة؟
• HTTPS لا يعني Application Security
• HTTP vs HTTPS
• MITM Attack
• TLS Termination
• Common Misconceptions
• Production Checklist
• الخلاصة
• Further Reading

⚡ الفكرة في دقيقة

ناس كتير فاهمة HTTPS بالشكل ده:

HTTP
+
🔒
=
HTTPS

😂

لكن الحقيقة أعمق.

لما تفتح:

https://example.com

الـBrowser والـServer بيعملوا cryptographic handshake قبل ما الـHTTP application data الحساسة تتنقل.

الصورة المبسطة:

Browser
   │
   │ TLS Handshake
   ▼
Server
   │
   ├── Certificate
   ├── Identity verification
   ├── Key exchange
   └── Session keys
   │
   ▼
Encrypted HTTP traffic

🌐 HTTP بدون HTTPS

في HTTP العادي:

Browser
   │
   │ HTTP
   │
   ▼
Server

لو البيانات نفسها غير مشفرة على مستوى التطبيق/النقل، network observer قادر على رؤية محتوى HTTP.

مثلاً:

POST /login
Content-Type: application/x-www-form-urlencoded

email=amr@example.com&password=123456

أي جهة قادرة على مراقبة هذا traffic على المسار يمكنها رؤية المحتوى غير المشفر.

ممكن يشمل:

• Passwords
• Cookies
• Tokens
• Request body
• Response body
• URLs والمسارات
• Headers

وده سبب أساسي في أهمية TLS.

🔒 HTTPS يعني إيه؟

HTTPS هو:

HTTP over TLS

يعني:

HTTP
  ↓
TLS
  ↓
TCP / QUIC
  ↓
IP

حسب إصدار HTTP المستخدم، ممكن يكون:

HTTP/1.1 → TLS → TCP
HTTP/2   → TLS → TCP
HTTP/3   → TLS integrated with QUIC → UDP

لذلك HTTPS ليس protocol منفصلًا عن HTTP بمعنى أنه يستبدل HTTP semantics.

الـHTTP ما زال عنده:

GET
POST
PUT
DELETE
Headers
Status Codes
Body

لكن الـtransport يكون محميًا بـTLS أو TLS integrated into QUIC في HTTP/3.

⚠️ TLS ولا SSL؟

هنا تصحيح مهم جدًا.

ناس كتير تقول:

"HTTPS = HTTP + SSL"

لكن SSL بروتوكول قديم deprecated.

اللي نستخدمه اليوم هو:

TLS — Transport Layer Security

مثل:

TLS 1.2
TLS 1.3

فالأدق:

HTTPS = HTTP over TLS

وليس:

HTTPS = HTTP + SSL

🤝 TLS Handshake

قبل ما يتم إرسال HTTP application data المحمية، الـclient والـserver يتفاوضوا على secure connection.

بشكل مبسط:

Browser
   │
   │ ClientHello
   ▼
Server
   │
   │ ServerHello
   │ Certificate
   │ Key Exchange Messages
   ▼
Browser
   │
   │ Finished
   ▼
Secure connection

لكن TLS 1.3 handshake الحقيقي أكثر اختصارًا وتفصيلاته تختلف عن TLS 1.2.

👋 ClientHello

الـBrowser يبدأ برسالة:

ClientHello

وتحتوي على معلومات مثل:

• Supported TLS versions
• Supported cipher suites
• Random / nonce
• Extensions
• Server Name Indication (SNI)
• Supported groups / key exchange capabilities

بشكل مبسط:

Client
  ↓
"I support these TLS capabilities."

الـClient لا يقول فقط:

"أنا عايز encryption."

هو يعلن مجموعة من capabilities التي تساعد الطرفين في الاتفاق على handshake.

👋 ServerHello

السيرفر يرد:

ServerHello

ويختار parameters مشتركة، مثل:

TLS version
Cipher suite
Key exchange parameters

بشكل مبسط:

Client capabilities
        +
Server capabilities
        ↓
Compatible secure parameters

📜 Certificate

هنا جزء مهم جدًا:

السيرفر يقدم:

Digital Certificate

الشهادة ليست مجرد:

"Google.com is safe"

😂

هي structured data موقعة من جهة موثوقة، وتحتوي على information مثل:

• Subject / identity
• Subject Alternative Names
• Public key
• Issuer
• Validity period
• Signature
• Certificate extensions

وفي شهادات TLS الحديثة، اسم الـdomain عادةً يتم التحقق منه من Subject Alternative Name.

🏛️ Certificate Authority

مين قال للـBrowser إن الشهادة دي موثوقة؟

Certificate Authority — CA

مثلاً:

Browser
   │
   │ trusts
   ▼
Root CA
   │
   ▼
Intermediate CA
   │
   ▼
Server Certificate

نظام الثقة في المتصفح مبني على trust store يحتوي root certificates موثوقة.

🔍 Certificate Validation

الـBrowser لا يقول:

"الشهادة موجودة يبقى تمام."

بل يتحقق من مجموعة أشياء، مثل:

Certificate
    │
    ├── Valid time?
    ├── Correct hostname?
    ├── Trusted chain?
    ├── Signature valid?
    ├── Key usage / constraints?
    └── Policy checks?

لو فشل التحقق، ممكن تشوف:

⚠️ Your connection is not private

🔑 Asymmetric vs Symmetric Cryptography

دي من أهم أجزاء الفهم.

ناس كتير تتخيل:

HTTPS
↓
Public Key encrypts everything

وده غلط.

HTTPS/TLS يستخدم cryptographic primitives مختلفة لأغراض مختلفة.

🔐 Asymmetric Cryptography

عندك key pair:

Public Key
Private Key

الـPublic Key يمكن مشاركته.

الـPrivate Key:

SECRET

ويظل مع صاحب الهوية/السيرفر.

الـpublic/private key cryptography تستخدم في TLS لأغراض مثل:

• Authentication
• Digital signatures
• Key agreement mechanisms

⚡ Symmetric Cryptography

بعد إنشاء session keys، البيانات الفعلية يتم حمايتها باستخدام symmetric cryptography.

يعني:

Client
   │
   │ encrypt with session key
   ▼
Server
   │
   │ decrypt with session key

Symmetric cryptography أسرع بكثير للبيانات الكبيرة.

أمثلة:

AES-GCM
ChaCha20-Poly1305

🧠 هل الـPublic Key يشفر الـSession Key؟

دي نقطة مهمة جدًا في النصوص التعليمية القديمة.

التفسير المبسط:

Public Key
   ↓
Encrypt secret
   ↓
Server Private Key
   ↓
Decrypt

كان مفيدًا لفهم بعض أنظمة key transport القديمة.

لكن:

TLS 1.3 عادةً يعتمد على ephemeral Diffie-Hellman key agreement، وليس على تشفير session key بالـserver public key بالطريقة القديمة.

بشكل مبسط:

Client ephemeral key
        +
Server ephemeral key
        ↓
Shared Secret
        ↓
Key Derivation
        ↓
Session Traffic Keys

وهذا يعطي TLS 1.3 خصائص أمنية مهمة مثل forward secrecy عند استخدام ephemeral key exchange.

🔐 TLS 1.3 وKey Exchange

بشكل مبسط:

Client
  │
  │ ClientHello
  │ key share
  ▼
Server
  │
  │ ServerHello
  │ key share
  ▼
Both derive:
Shared Secret
      ↓
Key Schedule
      ↓
Traffic Keys

الـprivate key في certificate يثبت هوية السيرفر من خلال signature mechanisms، بينما الـephemeral key exchange يستخدم لإنشاء shared secret.

يعني:

Identity
   ↓
Certificate / Signature

Encryption Keys
   ↓
Ephemeral Key Exchange

ودي نقطة مهمة جدًا لفهم TLS 1.3.

🔑 Session Keys

بعد الـhandshake:

Client
   ↕
Traffic Keys
   ↕
Server

البيانات الفعلية يتم تشفيرها باستخدام symmetric authenticated encryption.

مثلاً:

HTTP Request
     ↓
AEAD Encryption
     ↓
Ciphertext + Authentication Data

ثم السيرفر يفكها ويتحقق من سلامتها.

🛡️ Confidentiality

أول هدف:

Confidentiality

يعني network observer لا يستطيع قراءة application data المحمية بواسطة TLS.

بدل:

password=123456

المراقب يرى encrypted ciphertext.

🧬 Integrity

ثاني هدف:

Integrity

لو attacker حاول يغير البيانات:

100 EGP

إلى:

10000 EGP

فـTLS authenticated encryption يوفر integrity checks، والـmodified ciphertext يفشل في التحقق.

👤 Authentication

ثالث هدف:

Authentication

الـBrowser يريد التأكد من هوية السيرفر، ضمن حدود نظام الشهادات وtrust chain.

بشكل مبسط:

I am talking to:
example.com

وليس:

some-random-attacker.com

وده السبب إن Certificate validation مهمة جدًا.

🧱 HTTPS Security Model

              HTTPS
                 │
        ┌────────┼────────┐
        ▼        ▼        ▼
 Confidentiality Integrity Authentication
        │        │        │
        ▼        ▼        ▼
     Encrypt   Detect    Verify
               tamper    identity

لكن الثلاثة دول لا يعنيوا:

Application = Secure

👀 هل HTTPS يخفي كل حاجة؟

لا.

TLS يحمي application data داخل الاتصال، لكنه لا يجعل كل network metadata سرية.

حسب البيئة والبروتوكول، observers قد يعرفوا أشياء مثل:

• Destination IP
• بعض connection metadata
• Timing
• Packet sizes
• Traffic volume

وكمان اسم الموقع قد يكون له آثار في طبقات مثل DNS، رغم وجود تقنيات مثل DoH/DoT لتشفير DNS traffic.

في TLS الحديث، SNI نفسه يمكن أن تكون له حماية إضافية عبر ECH في البيئات الداعمة، لكن ده موضوع منفصل.

🕵️ MITM Attack

MITM:

Man-in-the-Middle

المهاجم يحاول يقف بين:

Browser
   ↕
Attacker
   ↕
Server

بدون TLS validation:

Browser
   ↓
Attacker
   ↓
Server

ممكن يحاول يقرأ أو يغير traffic.

لكن TLS certificate validation وauthenticated key establishment مصممان لمنع المهاجم من انتحال هوية السيرفر في الظروف الطبيعية.

لو المستخدم تجاهل تحذير certificate:

⚠️ Certificate Error
      ↓
"I don't care"
      ↓
Continue

فأنت قد تكون أضعفت أهم جزء من server authentication.

🌐 HTTP vs HTTPS

🏢 TLS Termination

في Production مش لازم الـTLS ينتهي عند الـapplication server نفسه.

ممكن:

Browser
   ↓ HTTPS
Cloudflare / Load Balancer / NGINX
   ↓ HTTP or HTTPS
Application

مثال:

                 TLS
Browser ─────────────────► Reverse Proxy
                              │
                              │ internal traffic
                              ▼
                           Backend

الـTLS termination layer قد تكون:

• CDN
• Load Balancer
• Reverse Proxy
• API Gateway

وده مهم جدًا لأن:

HTTPS بين Browser وProxy لا يعني تلقائيًا أن traffic بين Proxy وBackend مشفر.

في production، encryption الداخلي قد يكون مطلوبًا حسب threat model والبيئة.

🔄 HTTPS + Cookies

HTTPS مهم جدًا مع authentication cookies.

مثلاً:

Set-Cookie: session=...
  ; Secure
  ; HttpOnly

Secure يعني أن cookie يتم إرسالها عبر secure transport.

لكن:

HTTPS
≠
CSRF protection

وممكن تحتاج:

SameSite
+
CSRF tokens
+
Origin checks

حسب الـarchitecture.

🔥 HTTPS لا يعني Application Security

دي أهم نقطة في المقال كله.

HTTPS يحمي:

Data in transit

لكن لا يحل:

SQL Injection
XSS
Broken Authorization
IDOR
Bad Password Storage
Business Logic Bugs
Insecure APIs
Server Vulnerabilities

مثلاً:

HTTPS
   ↓
POST /api/transfer
   ↓
Application
   ↓
Broken Authorization
   ↓
Attacker transfers another user's money

الاتصال encrypted.

لكن الـapplication نفسها broken.

🔐 HTTPS + Passwords

حتى مع HTTPS:

لا تخزن passwords plaintext.

الصح:

Password
   ↓
Strong Password Hash
   ↓
Database

باستخدام password hashing algorithms مناسبة مثل:

Argon2id
bcrypt
scrypt

HTTPS يحمي password أثناء النقل.

Password hashing يحميها في حالة compromise للـdatabase.

الاتنين مختلفين.

🧠 HTTPS لا يلغي الحاجة إلى Authentication

HTTPS يقول:

Secure channel
+
Server identity

لكن التطبيق يحتاج:

Authentication
Authorization
Session management

يعني:

HTTPS
   +
Authentication
   +
Authorization
   +
Secure coding

هو اللي يعمل security architecture أفضل.

🧪 Common Misconceptions

❌ "HTTPS = HTTP + SSL"

الأدق:

HTTPS = HTTP over TLS

SSL قديم.

❌ "Public Key يشفر كل البيانات"

لا.

الـbulk application data يتم حمايته عادةً باستخدام symmetric traffic keys بعد key establishment.

❌ "Public Key يشفر Session Key دائمًا"

ده تبسيط قديم.

TLS 1.3 يستخدم عادةً ephemeral Diffie-Hellman key agreement.

❌ "Certificate يشفر الـwebsite"

لا.

الـcertificate يربط identity بـpublic key ويحتوي على metadata/signature.

❌ "HTTPS يخفي الـIP"

لا.

الـdestination IP عادةً يظل ظاهرًا في network layer.

❌ "HTTPS يمنع XSS"

لا.

XSS vulnerability في التطبيق نفسه.

❌ "HTTPS يمنع SQL Injection"

لا.

SQL Injection مشكلة application/database layer.

❌ "HTTPS يعني الموقع secure"

لا.

HTTPS جزء مهم من security، لكنه ليس security architecture كاملة.

🏗️ Production Checklist

TLS

• استخدم HTTPS everywhere
• استخدم TLS 1.2+ مع تفضيل TLS 1.3
• استخدم certificates صحيحة
• راقب expiration
• تحقق من hostname
• استخدم trusted certificate chain
• لا تتجاهل certificate errors

Browser / Cookies

• استخدم Secure
• استخدم HttpOnly للـsensitive cookies عندما يناسب الـarchitecture
• حدد SameSite
• استخدم HTTPS لكل authentication traffic
• طبق CSRF defenses عندما تعتمد على cookies

Application

• Authentication
• Authorization
• Password hashing
• Input validation
• SQL injection prevention
• XSS prevention
• Rate limiting
• Secure session management

Infrastructure

• TLS termination واضح
• افهم traffic بين proxy وbackend
• استخدم mTLS/internal TLS عند الحاجة
• راقب certificate expiration
• راقب TLS errors
• لا تعتمد على WAF كبديل عن secure code

🗺️ HTTPS Flow

sequenceDiagram
    participant B as Browser
    participant S as Server

    B->>S: TCP / QUIC connection
    B->>S: ClientHello
    S->>B: ServerHello
    S->>B: Certificate + key exchange data
    B->>S: Key exchange / Finished
    S->>B: Finished

    Note over B,S: Secure traffic keys established

    B->>S: Encrypted HTTP Request
    S-->>B: Encrypted HTTP Response

🔐 Cryptography Flow

                 TLS Handshake
                       │
          ┌────────────┴────────────┐
          ▼                         ▼
   Server Identity             Key Agreement
          │                         │
 Certificate +                 Ephemeral DH
 Signatures                    Key Exchange
          │                         │
          └────────────┬────────────┘
                       ▼
                Shared Secrets
                       │
                       ▼
                 Key Derivation
                       │
                       ▼
                Traffic Keys
                       │
                       ▼
             Symmetric Encryption
                       │
                       ▼
                 HTTP Data

🎯 الخلاصة

لما تفتح:

https://example.com

الموضوع مش:

HTTP + 🔒

بل رحلة cryptographic كاملة:

Client
   ↓
ClientHello
   ↓
ServerHello
   ↓
Certificate
   ↓
Certificate Validation
   ↓
Key Exchange
   ↓
Shared Secrets
   ↓
Traffic Keys
   ↓
Encrypted HTTP

والـHTTPS يحقق أساسًا:

Confidentiality
+
Integrity
+
Server Authentication

لكن أهم تصحيح لازم يفضل في دماغك:

HTTPS يحمي الاتصال، مش التطبيق نفسه.

يعني ممكن يكون عندك:

🔒 HTTPS
+
❌ SQL Injection
+
❌ Broken Authorization
+
❌ XSS
+
❌ Bad Password Storage

وعشان كده الـSecurity Engineer أو الـBackend Engineer الشاطر مش بس يعرف:

"إزاي أركب HTTPS؟"

لكن يفهم:

TLS
+
Certificates
+
Key Exchange
+
Cookies
+
Authentication
+
Authorization
+
Secure Coding
+
Infrastructure

وساعتها الـ🔒 يبقى أكتر من مجرد icon جنب الـURL.

📚 Further Reading

TLS / HTTPS

• RFC 8446 — TLS 1.3
• RFC 5246 — TLS 1.2
• MDN — Transport Layer Security
• MDN — HTTPS

Certificates

• CA/Browser Forum — Baseline Requirements
• Let's Encrypt

Web Security

• OWASP — Transport Layer Security Cheat Sheet
• OWASP — Password Storage Cheat Sheet

🔒 HTTPS secures the channel.

Your application still has to secure itself.