WEB / WEB-05.01

TLS’in sağladığı güven ve cryptography

Kanalın neyi koruduğunu key rollerinden ve plaintext teslim sınırından ayır.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Hareket olmadan bütün senaryoları oku

Verified record

Korunan kanal koşulu
Path, hostname ve handshake key proof başarılı seçilir. Client identity application’da ayrı sorudur.
Client · TLS
usable selected channel; plaintext ready
Server · TLS
usable selected channel; no record
Local record preparation
NOTES AEAD ile korunacak seçilir; alias’lar gerçek ciphertext veya key değildir.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
usable selected channel; no record
Record server’a ulaştı
Wire arrival yalnız ciphertext/header/tag özetini taşır; plaintext henüz kabul edilmedi.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
record received; verification pending; app delivery=none
Local AEAD check
Seçilmiş verification sonucu başarılı; local delivery ayrı.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
AEAD valid; verified NOTES; app unread
Application teslim sınırı
Doğrulanmış byte’lar local application’a verildi; business commit yok.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
app read=NOTES; commit unmodeled

Integrity failure

Korunan kanal koşulu
Path, hostname ve handshake key proof başarılı seçilir. Client identity application’da ayrı sorudur.
Client · TLS
usable selected channel; plaintext ready
Server · TLS
usable selected channel; no record
Local record preparation
NOTES AEAD ile korunacak seçilir; alias’lar gerçek ciphertext veya key değildir.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
usable selected channel; no record
Record server’a ulaştı
Wire arrival yalnız ciphertext/header/tag özetini taşır; plaintext henüz kabul edilmedi.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
record received; verification pending; app delivery=none
Local AEAD check
Seçilmiş verification başarısız; hiçbir plaintext application’a verilmez.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
AEAD invalid; plaintext withheld; app delivery=none
Application teslim sınırı
Failure sonrası application side effect seçilmez; gerçek hata nedeni ölçülmez.
Client · TLS
c-app-0; seq=0 alias; record prepared
Server · TLS
channel unusable; app delivery=none; cause unmodeled

Identity failure

Bağımsız reference identity
URL’den beklenen DNS-ID belirlenir; server sertifikası bunu yeniden tanımlamaz.
Client · TLS
reference=api.example.org; checks pending
Server · TLS
selected certificate context; no application data
Path koşulu
Path başarılı koşulu seçilir; hostname kararı henüz yok.
Client · TLS
path=true; hostname pending; app data unsent
Server · TLS
selected certificate context; no application data
Hostname uyuşmazlığı
Başka SAN adı reference identity ile eşleşmez; key proof bunu düzeltmez.
Client · TLS
path=true; hostname=false; app data unsent
Server · TLS
selected certificate context; no application data
Gönderim gate’i kapalı
Protected application record gönderimi seçilmez; encryption authority yerine geçmez.
Client · TLS
peer identity rejected; recordSent=false
Server · TLS
selected certificate context; no application data

ROLLER · STATE · VERİ AKIŞI

HTTP semantics tek başına kanal güveni değildir

HTTP method, status ve header kuralları, kiminle konuştuğunu veya byte’ların yolda gizli kaldığını kendiliğinden kanıtlamaz. https URI, seçilen origin’e güvenli iletişim ve certificate doğrulaması ister; URL’deki harfi değiştirmek bu mekanizmayı tek başına kurmaz. Burada TLS 1.3 ile certificate-authenticated HTTPS kanalını inceliyoruz.

HTTP application semantics ile transport/cryptographic koruma ayrı sorumluluklardır. QUIC tabanlı HTTP/3 de güvenli aktarım sağlar, fakat TLS record’larını TCP’deki gibi taşımaz. Buradaki record örneği TLS-over-TCP’ye aittir; bir HTTP response, application authorization veya kalıcı kayıt sonucu üretmez.

Üç garanti farklı sorulara cevap verir

Confidentiality, korunan application byte’larının kanaldaki gözlemciye açıklanmamasını; integrity, değişikliklerin kabul edilmeden fark edilmesini; authentication, negotiated anahtarların doğrulanan peer’e bağlanmasını anlatır. Bu üçünü tek “encrypted” etiketiyle geçmek, public key’i bulunan herhangi bir peer’i beklediğin server sanmana neden olabilir.

Örnekte client api.example.org için bağımsız reference identity kurar; certificate path, hostname ve handshake proof başarılı seçilir. Böylece server authentication varsayımı sağlanır. Client certificate istenmez: server TLS kanalı kurunca kullanıcının Duru olduğu veya bir raporu okuyabileceği sonucu çıkmaz. Bu identity ve authorization application katmanına aittir.

Symmetric key her yönün traffic’ini korur

TLS 1.3 record protection için AEAD kullanır. Seçilmiş c-app-0 alias’ı client’ın write key’ini, server’ın aynı yön için read key’ini temsil eder; s-app-0 karşı yöndür. Bunlar farklı direction/phase scope’larıdır. Certificate public key’iyle her HTTP byte’ını encrypt etmek bu model değildir.

AEAD girdileri key, nonce, plaintext ve authenticated additional data’dır. TLS’de record header AAD’ye katılır; nonce, ilgili yönün write IV’si ve record sequence bilgisinden türetilir. Örnek gerçek key veya nonce byte’larını göstermez. Aynı key altında nonce uniqueness ve key usage limit’leri önemlidir; aynı nonce alias’ını her record’da kullanmak geçerli bir tasarım değildir.

Asymmetric roller: agreement ve signature

Seçilmiş yeni connection’da X25519 ephemeral key shares shared secret hesaplamasına girer; private share karşıya gönderilmez. HKDF, shared input ve handshake context’inden ayrı traffic secrets/keys türetir. Long-term certificate key’i ise CertificateVerify signature’ı ile handshake context’ine possession proof bağlar. CA certificate signature’ı farklı signer ve farklı içerik üzerindedir.

“Private key ile encrypt, public key ile decrypt” signature için doğru genel tanım değildir. Signature doğrulamak mesajın plaintext’ini açmak değildir; key agreement da signing değildir. Bu X25519 dalı bütün TLS profillerini kapsamaz: PSK ve birleşik modlar vardır; güncel TLS metni KEM extensions’ını da ayırır. Forward secrecy seçilen ephemeral agreement ve secret yönetimi varsayımlarına bağlıdır; endpoint’teki plaintext’i koruma sözü değildir.

Record geldi, fakat henüz teslim edilmedi

Scene korunan bir record’ın server’a arrival’ını, server’ın local AEAD doğrulamasını ve application’a local teslimini ayrı adımlar yapar. Record header/ciphertext/tag byte’larının görülmesi, plaintext’in kabul edildiği anlamına gelmez. Integrity-failure dalında seçilmiş AEAD check başarısızdır; plaintext application’a verilmez ve kanal kullanılabilir kabul edilmez.

Bazı cryptographic API’ler deprotection sırasında provisional plaintext verebilir; bu byte’lar authentication tamamlanmadan güvenilir kabul edilmez. Final verification başarısızsa application side effect başlamış olmamalıdır. Bu ayrım ciphertext’i okumak, doğrulanmış plaintext elde etmek ve uygulamanın onu tüketmesi arasında üç farklı sınır kurar; gerçek hata nedenini tek bir verification failure sonucundan çıkarmayız.

HTTPS’in sınırı endpoint ve uygulamadır

TLS terminator application byte’larını okuyabilir. Reverse proxy’de termination seçilirse browser→proxy ve proxy→upstream ayrı kanal/policy sorularıdır; ilk kanal ikinci hop’un korunduğunu kanıtlamaz. TLS ayrıca destination IP, trafik zamanı ve boyutları bütünüyle gizlemez; padding bazı gözlemleri azaltabilir ama anonymity garantisi değildir.

Path/hostname/key proof geçerli bir server’a bağlandığını gösterir; içerik doğruluğunu, kötü davranışın yokluğunu veya resource permission’ını sertifika mühürlemez. Güncel kaynak RFC9846’dır: RFC8446’nın yerini alır, sürüm yine TLS 1.3’tür. Öğretim alias’ları gerçek TLS stack, public trust store veya certificate capture değildir.

Hareket olmadan bütün senaryoları oku

Identity gate

Şifreli kanalın koşulları ayrıldı
Identity-failure case’inde path ve key proof koşulları başarılıdır, fakat hostname eşleşmez. Bu nedenle beklenen api.example.org service identity’si kabul edilmez. Bir gate’in başarısı diğerinin failure’ını telafi etmez.
Channel predicates
Path passes / hostname fails
Acceptance gate
Acceptance gate yok
Application boundary
Application delivery yok
Acceptance gate conjunction’dır
path, hostname, keyProof peer authentication koşullarıdır; usable channel ve successful AEAD verification plaintext delivery için ayrıca gerekir. Bir hücrenin true olması diğerinin failure’ını kapatmaz.
Channel predicates
Path passes / hostname fails
Acceptance gate
Independent predicates retained
Application boundary
Application delivery yok
Erken trusted plaintext durduruldu
Hostname failure recordSent=false ve applicationDelivered=null verir. Protected application gönderimi beklenen identity kabul edilmeden seçilmez.
Channel predicates
Path passes / hostname fails
Acceptance gate
Independent predicates retained
Application boundary
applicationDelivered=null
Key rolleri birbirine karışmadı
leaf-sign-public signature doğrulama, c-eph-public key agreement share, c-app-0 client-write/server-read rolündedir. Public share, private signing veya directional traffic key yerine geçmez.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Independent predicates retained
Application boundary
applicationDelivered=null
TLS user yetkisi değildir
Bu fixture TLS user authentication, resource authorization veya business outcome kanıtlamaz. Geçerli channel, application’ın role ve tenant kontrollerini tamamlamaz; business commit ayrıca kendi sonucunu gerektirir.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Transport guarantees / app gates separate
Application boundary
applicationDelivered=null
Failure boundary doğru yerde kaldı
Identity gate gönderimden önce durur. Endpoint plaintext okuyabilir ve metadata’nın tamamı gizlenmez; encryption varlığından bütün güvenlik özellikleri türetilmez.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Transport guarantees / app gates separate
Application boundary
Identity rejected / record withheld

Integrity gate

Şifreli kanalın koşulları ayrıldı
Integrity-failure case’inde path, hostname ve key proof başarılı verilmiştir. Record’un AEAD doğrulaması ise başarısızdır. Kabul edilmiş peer identity ile doğrulanmış record content’i iki ayrı sonuçtur.
Channel predicates
Identity passes / AEAD fails
Acceptance gate
Acceptance gate yok
Application boundary
Application delivery yok
Acceptance gate conjunction’dır
path, hostname, keyProof peer authentication koşullarıdır; usable channel ve successful AEAD verification plaintext delivery için ayrıca gerekir. Bir hücrenin true olması diğerinin failure’ını kapatmaz.
Channel predicates
Identity passes / AEAD fails
Acceptance gate
Independent predicates retained
Application boundary
Application delivery yok
Erken trusted plaintext durduruldu
aeadValid=false olduğundan applicationDelivered=null kalır. Provisional decrypt çıktısı verification final olmadan application side effect’ine dönüştürülmez.
Channel predicates
Identity passes / AEAD fails
Acceptance gate
Independent predicates retained
Application boundary
applicationDelivered=null
Key rolleri birbirine karışmadı
leaf-sign-public signature doğrulama, c-eph-public key agreement share, c-app-0 client-write/server-read rolündedir. Public share, private signing veya directional traffic key yerine geçmez.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Independent predicates retained
Application boundary
applicationDelivered=null
TLS user yetkisi değildir
Bu fixture TLS user authentication, resource authorization veya business outcome kanıtlamaz. Geçerli channel, application’ın role ve tenant kontrollerini tamamlamaz; business commit ayrıca kendi sonucunu gerektirir.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Transport guarantees / app gates separate
Application boundary
applicationDelivered=null
Failure boundary doğru yerde kaldı
Record receipt olabilir fakat verified plaintext teslimi yoktur. Failure nedeni bu verilen Boolean condition’dan öte teşhis edilmez; gerçek AEAD veya encoded record üretilmez.
Channel predicates
Signing / agreement / traffic roles
Acceptance gate
Transport guarantees / app gates separate
Application boundary
Record rejected / application withheld

VARSAYIM · SINIR · KONTROL

Kırılan varsayım: encrypted yeterli authority’dir

Encryption olsa da intended hostname/path doğrulanmamışsa aranan service identity sonucu kurulamaz. Gerekli hata, kanalı bir public key’e bağlayıp o key’in beklenen service ile ilişkisini atlamaktır.

Kontrol chain, independently selected reference identity ve handshake possession proof’u ayrı gereksinim olarak tutmaktır. TLS server identity’yi application role/tenant yetkisi gibi kullanmamak gerekir.

Kırılan varsayım: decrypt çıktısı kabul edilmiş veridir

Provisional plaintext’i verification final olmadan işlemek, integrity failure sonrası oluşmuş application side effect’i geri alamayabilir. Gerekli koşul incomplete authentication çıktısının trusted input gibi tüketilmesidir.

Kontrol doğrulanmış plaintext’in teslim sınırıdır. Failure dalı hiçbir byte’ı application’a vermez; error’ın gerçek kaynağı yalnız bu sentetik sonuçtan teşhis edilmez.

Kırılan varsayım: TLS iş kuralını garanti eder

Geçerli kanal, permission kontrolü eksik uygulamayı düzeltmez. Endpoint plaintext ve termination politikası da TLS wire protection’ın dışında ayrı güven sınırlarıdır.

Kontrol operation scope, user authentication, authorization ve upstream channel gereksinimlerini açık tutmaktır. Bir HTTPS bağlantısı commit veya once-only execution kanıtı değildir.

Hareket olmadan bütün senaryoları oku

Directional keys

Alias’ların anlamı seçildi
leaf-sign-private server CertificateVerify signing, c-eph-private X25519 agreement, c-app-0 traffic rolüdür. Alias secret bytes içermez; secret=true classification paylaşılabilir credential demek değildir.
Key-role evidence
Inert signing/agreement/traffic aliases
Verification review
Receipt scope yok
Guarantee review
Guarantee review yok
Direction iki uçta eşleştirildi
c-app-0 client write/server read, s-app-0 server write/client read’dır. Aynı alias’ı her iki gönderim yönüne koymak key-role ledger’ın sözleşmesini bozar.
Key-role evidence
Inert signing/agreement/traffic aliases
Verification review
c-app-0 ↔ client→server
Guarantee review
Guarantee review yok
Record evidence encoding değildir
NOTES ASCII plaintext, opaque-teaching-alias ciphertext/tag ve c-seq-0-with-write-iv nonce alias’ı sunulur. realTlsRecordProduced=false; bu değerlerden key schedule veya nonce bytes çıkarılmaz.
Key-role evidence
Semantic record aliases / no encoding
Verification review
c-app-0 ↔ client→server
Guarantee review
Guarantee review yok
Verification sonucu delivery’den ayrı
Normal modelde record gönderilir ve AEAD doğrulaması başarılı kabul edilir. NOTES ancak bu check sonrasında application’a teslim edilir. Bunlar verilmiş teaching koşullarıdır; gerçek cryptographic verification veya network capture değildir.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Supplied verified delivery: NOTES
Guarantee review
Guarantee review yok
Guarantee tablosunda boşluk korundu
Peer auth path/hostname/keyProof ister. User authentication, resource authorization ve commit ayrı UNKNOWN kalır; endpointCanReadPlaintext=true, allMetadataHidden=false doğrudan tablonun scope’udur.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Supplied verified delivery: NOTES
Guarantee review
TLS scope ≠ user/resource/business proof
Normal ve failure baseline ayrı bitti
c-app-0’ın client write/server read rolü ile doğrulamadan sonra NOTES teslimi ayrı alanlarla gösterilmiştir. Gerçek incelemede receiver TLS doğrulama sonucu ve aynı connection’a bağlı application teslim kaydı gerekir. Wire’da ciphertext görmek bu iki sonucu tek başına göstermez; secret key byte’larını toplamak gerekmez.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Supplied verified delivery: NOTES
Guarantee review
Key directions consistent / app proof absent

Integrity evidence

Alias’ların anlamı seçildi
leaf-sign-private server CertificateVerify signing, c-eph-private X25519 agreement, c-app-0 traffic rolüdür. Alias secret bytes içermez; secret=true classification paylaşılabilir credential demek değildir.
Key-role evidence
Inert signing/agreement/traffic aliases
Verification review
Receipt scope yok
Guarantee review
Guarantee review yok
Direction iki uçta eşleştirildi
c-app-0 client write/server read, s-app-0 server write/client read’dır. Aynı alias’ı her iki gönderim yönüne koymak key-role ledger’ın sözleşmesini bozar.
Key-role evidence
Inert signing/agreement/traffic aliases
Verification review
c-app-0 ↔ client→server
Guarantee review
Guarantee review yok
Record evidence encoding değildir
NOTES ASCII plaintext, opaque-teaching-alias ciphertext/tag ve c-seq-0-with-write-iv nonce alias’ı sunulur. realTlsRecordProduced=false; bu değerlerden key schedule veya nonce bytes çıkarılmaz.
Key-role evidence
Semantic record aliases / no encoding
Verification review
c-app-0 ↔ client→server
Guarantee review
Guarantee review yok
Verification sonucu delivery’den ayrı
Integrity-failure modelinde record gönderilmiştir, fakat AEAD check başarısızdır. Application’a hiçbir plaintext verilmez. Record receipt ile verified delivery’nin farklı observation noktaları olması bu sınırı gösterir.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Receipt yes / delivery no
Guarantee review
Guarantee review yok
Guarantee tablosunda boşluk korundu
Peer auth path/hostname/keyProof ister. User authentication, resource authorization ve commit ayrı UNKNOWN kalır; endpointCanReadPlaintext=true, allMetadataHidden=false doğrudan tablonun scope’udur.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Receipt yes / delivery no
Guarantee review
TLS scope ≠ user/resource/business proof
Normal ve failure baseline ayrı bitti
Bu dalda record varmış fakat receiver doğrulaması başarısızdır; application’a NOTES teslimi atlanır. Identity-failure dalı ise record göndermeden durur. Gerçek ayrım için ilgili connection’ın identity-check, record-verification ve application-delivery sonuçları ayrı gözlenmelidir; eksik kayıt başarıya çevrilmez.
Key-role evidence
Semantic record aliases / no encoding
Verification review
Receipt yes / delivery no
Guarantee review
Integrity fail / identity fail distinct

UYGULAMA · GÜVENLİK KONTROLÜ · DOĞRULAMA

Key-role ledger’ını oku

Certificate signing key, ephemeral agreement key ve directional traffic key alias’larını eşleştir. c-app-0’ın server’da read key olmasını, aynı alias’ın karşı yön için seçilmemesini açıkla.

Public key paylaşılabilir; secret alias gerçek secret içermez. Signature verification mesaj secrecy’si veya certificate trust kararı değildir.

Receipt, verification ve delivery’yi ayır

Normal dalda NOTES byte’ları ancak local check başarıyla bitince application’a teslim edilir. Failure dalında arrival vardır ama verified plaintext ve application read yoktur.

Identity-failure dalı handshake yerine declarative local koşulları gösterir: path başarılı olsa bile hostname eşleşmesi eksikse protected application gönderimi seçilmez.

AEAD kullanan consumer, decryption sırasında üretilen geçici plaintext’i verification tamamlanmadan parser’a veya application state’ine vermemelidir. Node.js crypto örneğinde decipher.update çıktısı bu aşamada doğrulanmış sayılmaz; authentication sonucu decipher.final ile tamamlanır. Hata halinde geçici sonucu bırakıp normal NOTES teslimini atla. Hem geçerli sonuçta teslimi hem integrity-failure dalında application’a hiçbir plaintext verilmemesini kontrol etmek, bu kararın uygulamada korunup korunmadığını gösterir.

Garanti tablosunu product kararına bağla

Confidentiality, integrity ve server authentication için gereken koşulları yaz; kullanıcı identity, authorization ve business outcome hücrelerini ayrı tut. Bu ayrım “TLS var, her şey tamam” yorumunu sınırlar.

HTTP/3’te packet protection rolü QUIC’e geçer. TLS-over-TCP record ledger’ını QUIC packet encoding’i gibi kullanma; iki model aynı channel amaçlarına farklı taşıma mekanizmalarıyla ulaşır.

ŞİMDİ VAKAYA UYGULA

Identity, record integrity ve business authority neden ayrı gate’lerdir?

api.example.org için TLS peer acceptance; path, hostname ve key proof koşullarını birlikte ister. AEAD doğrulaması başarısızsa NOTES application’a verilmez. Geçerli TLS kanalı, kullanıcıya veya resource’a erişim yetkisi sağlamaz.

Vakadaki güvenli bağlantının peer’i kimdir? TLS peer trust, browser origin ve kullanıcıya verilen object permission kararlarını ayrı anlat.

Bağlı vaka dosyasını aç ↗

ÖRNEĞİ BİRLİKTE OKUYALIM

Atlas · tls-key-guarantee-ledger

Bir alan seç; hangi sonucu desteklediğini ve nerede yetersiz kaldığını incele.

Ham kaydı ve alan açıklamalarını oku

{
  "profile": {
    "protocol": "TLS 1.3 over TCP",
    "currentSpecification": "RFC9846",
    "originalSpecification": "RFC8446 (obsoleted)",
    "handshake": "selected new certificate-authenticated X25519 branch",
    "referenceDnsId": "api.example.org",
    "clientCertificateRequested": false,
    "secretsExported": false
  },
  "keyRoles": [
    {
      "alias": "leaf-sign-public",
      "role": "CertificateVerify signature verification",
      "secret": false
    },
    {
      "alias": "leaf-sign-private",
      "role": "local server CertificateVerify signing",
      "secret": true
    },
    {
      "alias": "c-eph-private",
      "role": "local selected X25519 agreement",
      "secret": true
    },
    {
      "alias": "c-eph-public",
      "role": "ClientHello key share",
      "secret": false
    },
    {
      "alias": "s-eph-public",
      "role": "ServerHello key share",
      "secret": false
    },
    {
      "alias": "c-app-0",
      "role": "client write / server read, application phase",
      "secret": true
    },
    {
      "alias": "s-app-0",
      "role": "server write / client read, application phase",
      "secret": true
    }
  ],
  "record": {
    "plaintext": "NOTES",
    "encoding": "ASCII",
    "keyAlias": "c-app-0",
    "nonceAlias": "c-seq-0-with-write-iv",
    "aad": "TLS record header (semantic alias, no encoding)",
    "ciphertext": "opaque-teaching-alias",
    "tag": "opaque-teaching-alias",
    "realTlsRecordProduced": false
  },
  "cases": [
    {
      "case": "normal",
      "path": true,
      "hostname": true,
      "keyProof": true,
      "aeadValid": true,
      "recordSent": true,
      "applicationDelivered": "NOTES",
      "businessCommitProven": false
    },
    {
      "case": "integrity-failure",
      "path": true,
      "hostname": true,
      "keyProof": true,
      "aeadValid": false,
      "recordSent": true,
      "applicationDelivered": null,
      "businessCommitProven": false
    },
    {
      "case": "identity-failure",
      "path": true,
      "hostname": false,
      "keyProof": true,
      "aeadValid": null,
      "recordSent": false,
      "applicationDelivered": null,
      "businessCommitProven": false
    }
  ],
  "guaranteeScope": {
    "peerAuthenticationRequires": [
      "path",
      "hostname",
      "keyProof"
    ],
    "plaintextDeliveryRequires": "selected usable channel and successful AEAD verification",
    "tlsUserAuthenticationProven": false,
    "resourceAuthorizationProven": false,
    "businessOutcomeProven": false,
    "endpointCanReadPlaintext": true,
    "allMetadataHidden": false
  },
  "limits": "Aliases, conditions and outcomes only; no real certificate, TLS encoding, key schedule, nonce bytes, packet capture or network."
}

keyRoles: Secret byte içermeyen farklı key sorumlulukları.
record: Bir direction/phase için inert protected record özeti.
cases: Verification ve teslim için seçilmiş koşullar.
guaranteeScope: Channel garantisinin application kararına uzanmadığı sınır.

Key/certificate alias ve outcome koşullarıdır; gerçek TLS encoding, trust store veya certificate doğrulaması yürütülmez.

İki yanlış kanı

Public key ile verify edilen her mesaj gizlidir.

Signature verification authenticity/integrity ilişkisini kontrol eder; mesajı encrypt etmez.

HTTPS, kullanıcının resource yetkisini kanıtlar.

TLS channel ve server identity sağlar; user authentication ve authorization ayrıca değerlendirilir.

SIRA SENDE

Bu hikâyeyi sen çöz.

Sonucu tahmin et, kanıtın sınırını bul ve nedenini kendi cümlenle anlat.

Path ve hostname kontrolleri geçti, fakat record için aeadValid=false. Plaintext application’a teslim edilir mi?

Hayır. applicationDelivered=null kalır.
Evet. Güvenilen certificate, bozuk record’u kabul ettirir.

Gerekçeli cevabı oku

Hayır. applicationDelivered=null kalır. — Başarılı peer identity kontrolü, başarısız record authentication sonucunu geçerli yapmaz. Delivery durur.

Bu üç key alias neden birbirinin yerine kullanılamaz?

Dersten seçilen artifact alanları; öğretim örneği

keyRoles[0]: {"alias":"leaf-sign-public","role":"CertificateVerify signature verification","secret":false}
keyRoles[2]: {"alias":"c-eph-private","role":"local selected X25519 agreement","secret":true}
keyRoles[5]: {"alias":"c-app-0","role":"client write / server read, application phase","secret":true}

Biri signature, biri agreement, biri traffic protection için.
TLS’deki bütün key’ler aynı symmetric encryption key’idir.

Gerekçeli cevabı oku

Biri signature, biri agreement, biri traffic protection için. — Key’in kullanım amacı önemlidir. Public signing key, application record write key’i değildir.

Normal TLS örneğinde NOTES teslim edildi. Kullanıcı kimliği ve resource izni için neden ayrı kanıt gerekir?

Gerekçeli cevabı oku

TLS service identity ile channel confidentiality/integrity koşullarını korur. Bu profilde client certificate istenmez; kullanıcı authentication veya resource authorization sonucu verilmez. Endpoint plaintext’i okuyabilir. TLS bütün metadata’nın gizliliğini veya business commit’i garanti etmez.

□ Service identity ile kullanıcı kimliğini ayırdım.

□ TLS sonucuna resource izni eklemedim.

Uygulama konsolunu aç · request / response / browser

Request, URL, cookie ve DOM örneklerini ayrıca aç

Kaynaklar ve kapsam

TLS 1.3 — current specification (2026)1 Introduction · 1.2 Relationship to RFC8446 · 2 Protocol Overview · 4.2 Hello Messages · 4.3 Extensions · 4.4.1 Encrypted Extensions · 4.5 Authentication Messages · 4.5.1 Certificate · 4.5.2 Certificate Verify · 4.5.3 Finished · 5.2 Record Payload Protection · 5.3 Per-Record Nonce · 7.1 Key Schedule · 7.4.2 Elliptic Curve Diffie-Hellman
TLS 1.3 — original specification (2018; obsoleted by RFC9846)2 Protocol Overview · 4.4.2 Certificate · 4.4.3 Certificate Verify · 4.4.4 Finished · 5.2 Record Payload Protection
Service Identity in TLS6.1.1 Constructing Reference Identifiers — Rules · 6.2 Preparing to Seek a Match · 6.3 Matching the DNS Domain Name Portion · 6.4 Matching an IP Address Portion · 7.7 Certificate Trust · Appendix A Changes from RFC6125
HTTP Semantics4.2.1 http URI Scheme · 4.2.2 https URI Scheme · 4.3.4 https Certificate Verification
Node.js v24 crypto API — local primitive evidencedecipher.update / decipher.final / decipher.setAuthTag · crypto.generateKeyPairSync · crypto.sign / crypto.verify · crypto.diffieHellman · decipher.update authenticated plaintext uncertainty

KENDİ NOTUN / BU TARAYICIDA

TLS’in sağladığı güven ve cryptography

1. Core · Mekanizma

Verified record

Integrity failure

Identity failure

HTTP semantics tek başına kanal güveni değildir

Üç garanti farklı sorulara cevap verir

Symmetric key her yönün traffic’ini korur

Asymmetric roller: agreement ve signature

Record geldi, fakat henüz teslim edilmedi

HTTPS’in sınırı endpoint ve uygulamadır

2. Red · Güven ve etki

Identity gate

Integrity gate

Kırılan varsayım: encrypted yeterli authority’dir

Kırılan varsayım: decrypt çıktısı kabul edilmiş veridir

Kırılan varsayım: TLS iş kuralını garanti eder

3. Blue · Güvenli geliştirme ve savunma

Directional keys

Integrity evidence

Key-role ledger’ını oku

Receipt, verification ve delivery’yi ayır

Garanti tablosunu product kararına bağla

Identity, record integrity ve business authority neden ayrı gate’lerdir?

İki yanlış kanı

Path ve hostname kontrolleri geçti, fakat record için aeadValid=false. Plaintext application’a teslim edilir mi?

Bu üç key alias neden birbirinin yerine kullanılamaz?

Normal TLS örneğinde NOTES teslim edildi. Kullanıcı kimliği ve resource izni için neden ayrı kanıt gerekir?

Kaynaklar ve kapsam