Wawancara Jaringan: Bagaimana Cara Kerja Handshake TLS 1.3, dan Kapan 0-RTT Aman Digunakan?

Pertanyaan dan Cakupan

Sebuah API global menggunakan TLS 1.3. Uraikan alur full handshake dan resumed handshake. Jelaskan apa saja yang dienkripsi pada setiap tahap, bagaimana sertifikat mengautentikasi server, bagaimana kunci-kunci dibuat, dan apakah GET /rates serta POST /transfers sebaiknya menggunakan 0-RTT.

Gunakan baseline yang eksplisit: klien terhubung ke layanan HTTPS melalui TCP; server mengautentikasi dengan sertifikat X.509; full handshake menggunakan ECDHE efemeral; koneksi yang dipulihkan (resumed connection) menggunakan session ticket yang diterbitkan pada koneksi sebelumnya; dan titik masuk API dapat berupa load balancer atau CDN. HTTP/3 mengintegrasikan TLS 1.3 ke dalam pembentukan koneksi QUIC, tetapi baseline ini menggunakan TLS records melalui TCP agar urutan pesan dan properti keamanannya konkret.

Pertanyaan ini cocok untuk wawancara backend, klien, infrastruktur, SRE, keamanan, dan rekayasa perangkat lunak umum. Pewawancara tidak sekadar menginginkan hafalan dari ClientHello hingga Finished. Kandidat harus menjelaskan bagaimana identitas terikat pada handshake ini, kunci mana yang melindungi tahap mana, dan mengapa menghilangkan satu network round trip menimbulkan masalah replay yang harus ditangani oleh aplikasi.

Apa yang Diuji oleh Pewawancara

Pertama, dapatkah kandidat memisahkan pertukaran kunci (key exchange), autentikasi, dan bulk encryption? Kunci publik dalam sertifikat biasanya memverifikasi tanda tangan CertificateVerify atas handshake transcript. Kunci tersebut tidak mengenkripsi seluruh lalu lintas bisnis berikutnya. Kunci lalu lintas simetris berasal dari ECDHE, sebuah PSK, dan key schedule berbasis HKDF.

Kedua, dapatkah kandidat menentukan batasan enkripsi dengan akurat? Pesan awal ClientHello dan ServerHello mengekspos informasi yang dibutuhkan untuk negosiasi. Setelah memproses ServerHello, kedua peer dapat menurunkan handshake traffic keys. Kunci-kunci tersebut melindungi EncryptedExtensions, Certificate, CertificateVerify, dan Finished. Kunci lalu lintas aplikasi terpisah kemudian melindungi data aplikasi.

Ketiga, dapatkah kandidat membedakan resumption dari 0-RTT? Session resumption dapat mempersingkat autentikasi sambil tetap menyelesaikan handshake 1-RTT. Dengan 0-RTT, klien mengirimkan early data dalam penerbangan pertamanya (first flight). Keduanya dapat melibatkan PSK, tetapi hanya early data yang tidak memiliki kesegaran (freshness) yang diturunkan dari ServerHello saat ini.

Keempat, dapatkah kandidat menerjemahkan risiko protokol ke dalam semantik bisnis? TLS 1.3 memberikan properti yang lebih lemah pada early data: data tersebut tidak memiliki forward secrecy dan tidak ada jaminan non-replay lintas koneksi. Pengaktifannya tidak dapat diputuskan hanya dari metode HTTP. Menagih uang, membuat sesi, menambah penghitung (counter), menerbitkan reward, atau mengonsumsi token sekali pakai akan mengubah jawabannya.

Kelima, dapatkah kandidat mengusulkan rencana peluncuran (rollout) dan debugging yang dapat diobservasi? Jawaban yang kuat membedakan full handshake, 1-RTT resumption, dan 0-RTT; memeriksa ticket, ALPN, HelloRetryRequest, penerimaan atau penolakan early-data, dan HTTP 425 Too Early; serta memverifikasi saluran keamanan terpisah dari terminator TLS di edge ke origin.

Pertanyaan untuk Diklarifikasi Terlebih Dahulu

• Transport apa yang digunakan? HTTPS melalui TCP dan QUIC/HTTP/3 keduanya menggunakan kriptografi TLS 1.3, tetapi membawa pesan dan membentuk koneksi secara berbeda. Baseline ini menggunakan TCP.
• Apakah ini koneksi pertama atau koneksi yang dipulihkan (resumed)? Koneksi pertama tidak memiliki PSK yang dapat digunakan dan memerlukan autentikasi sertifikat. Koneksi yang dipulihkan dapat menawarkan ticket sebelumnya, tetapi tidak serta-merta mengirimkan 0-RTT.
• Apakah server meminta sertifikat klien? Sebagian besar API web hanya mengautentikasi server. mTLS menambahkan Certificate dan CertificateVerify milik klien.
• Di mana TLS diterminasi? Jika diterminasi di CDN atau load balancer, klien mengautentikasi endpoint edge tersebut. Lalu lintas edge-to-origin adalah koneksi terpisah dengan keputusan enkripsi dan identitasnya sendiri.
• Apa semantik replay dari operasi tersebut? Apakah GET /rates benar-benar read-only? Apakah operasi tersebut mengonsumsi token sekali pakai, menambah penghitung yang dapat ditagih, atau memicu komputasi yang mahal? Idempotency key pada POST /transfers tidak secara otomatis menghilangkan setiap risiko early-data.
• Apakah kedua sisi mengimplementasikan HTTP early data dengan benar? Klien harus mencoba ulang (retry) dengan aman pada koneksi yang sudah terbentuk jika lapisan TLS menolak early data atau server mengembalikan 425.

Kerangka Jawaban 30 Detik

"Dalam full TLS 1.3 handshake, klien mengirimkan ClientHello berisi versi, cipher suite, dan key share ECDHE. Server memilih parameter di ServerHello dan mengembalikan key share miliknya. Kedua peer memasukkan hasil ECDHE dan transcript ke dalam HKDF untuk menurunkan handshake keys, sehingga ekstensi, sertifikat, tanda tangan, dan Finished setelah ServerHello terenkripsi. Klien memvalidasi rantai (chain), hostname, CertificateVerify, dan Finished, lalu mengirimkan Finished miliknya sendiri. Kunci lalu lintas aplikasi terpisah melindungi data berikutnya.

Resumption menggunakan PSK yang terkait dengan ticket sebelumnya dan dapat menghindari autentikasi sertifikat penuh. Jika 0-RTT juga diaktifkan, klien mengirimkan early data bersama ClientHello. Data tersebut hanya bergantung pada PSK, tidak memiliki forward secrecy, dan dapat di-replay lintas koneksi. Saya hanya akan mengizinkan operasi baca yang secara eksplisit aman untuk diulang (retry-safe) dan bebas efek samping. Permintaan transfer harus menunggu penyelesaian handshake, dengan kebijakan gateway yang konsisten, 425 Too Early, dan dukungan retry normal."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: ClientHello menyediakan materi negosiasi

Klien memulai dengan ClientHello. Pesan ini umumnya berisi nonce, versi TLS yang didukung, cipher suite TLS 1.3, algoritma tanda tangan, grup pertukaran kunci yang didukung, satu atau beberapa nilai key_share, serta ekstensi seperti SNI dan ALPN. Cipher suite TLS 1.3 terutama memilih algoritma AEAD dan fungsi hash yang digunakan oleh HKDF. Ekstensi lain menegosiasikan algoritma tanda tangan sertifikat dan grup pertukaran kunci.

Pesan ini belum dilindungi oleh handshake traffic keys pada TLS 1.3 standar. SNI biasanya juga terlihat kecuali jika kedua peer berhasil menggunakan ECH. Mengatakan bahwa TLS mengenkripsi setiap field sejak byte pertama mengabaikan fakta bahwa kedua peer belum menurunkan shared traffic keys untuk koneksi ini.

Key share milik klien adalah nilai publik ECDHE efemeral. Nilai privat pasangannya tetap berada di lokal. Nilai publik itu sendiri bukanlah shared secret. Setiap peer menggabungkan nilai privatnya dengan nilai publik peer lainnya untuk menghitung shared secret ECDHE yang sama.

Langkah 2: ServerHello memilih parameter dan menyelesaikan pertukaran kunci baru

Server memilih versi TLS, cipher suite, dan key share yang dapat diterima, lalu mengirimkan ServerHello. Dengan ECDHE, server juga menyediakan nilai publik efemeral miliknya. ClientHello ditambah ServerHello menentukan parameter kriptografi, dan kedua peer kini dapat memasukkan secret ECDHE ke dalam key schedule HKDF TLS 1.3.

Jika klien tidak menawarkan share dalam grup yang diterima server, server dapat mengirimkan HelloRetryRequest dan meminta ClientHello lain dengan grup yang dipilih. Hal tersebut membutuhkan satu round trip tambahan, dan upaya early-data awal tidak dapat dilanjutkan begitu saja sebagai jalur sukses normal. RTT ekstra yang terjadi sesekali di lingkungan produksi harus mendorong pemeriksaan HRR alih-alih langsung mengasumsikannya sebagai network jitter.

Setelah ServerHello, kedua peer dapat menurunkan client dan server handshake traffic secrets. Protokol melindungi pesan handshake berikutnya dengan kunci-kunci tersebut. Pengamat pasif tidak dapat membaca sertifikat atau sebagian besar ekstensi lanjutan, meskipun ukuran record, waktu (timing), dan informasi awal yang tidak disembunyikan oleh ECH tetap dapat diamati.

Langkah 3: Parameter server, sertifikat, dan tanda tangan transcript menetapkan identitas

Server selanjutnya mengirimkan EncryptedExtensions yang terenkripsi, berisi pilihan untuk ekstensi seperti ALPN. Server mengirimkan CertificateRequest jika menginginkan autentikasi klien. Handshake HTTPS satu arah yang umum kemudian mengirimkan Certificate, CertificateVerify, dan Finished milik server.

Pesan-pesan tersebut memiliki tugas yang berbeda:

Klien memvalidasi rantai (chain), masa berlaku, hostname, dan algoritma tanda tangan yang diizinkan sesuai dengan kebijakan PKI miliknya, lalu memverifikasi tanda tangan CertificateVerify atas transcript. Ini mengikat kendali atas kunci privat sertifikat ke ClientHello, ServerHello, dan kumpulan parameter yang dinegosiasikan saat ini. Penyerang tidak dapat memindahkan tanda tangan dari handshake lain yang tidak terkait.

Langkah 4: Finished menyelesaikan handshake dan memisahkan kunci aplikasi

Finished milik server adalah nilai verifikasi yang diturunkan dari transcript dan handshake secret. Pemeriksaan yang berhasil memberi tahu klien bahwa negosiasi yang diamati tidak dimodifikasi dan bahwa peer memiliki materi kunci handshake yang sesuai. Menerima data tanpa autentikasi sertifikat atau verifikasi Finished akan membatalkan jaminan identitas dan integritas TLS.

Klien kemudian mengirimkan Finished miliknya sendiri. Jika server meminta mTLS, klien mengirimkan sertifikatnya dan CertificateVerify terlebih dahulu. Kedua peer melindungi data aplikasi dengan application traffic secrets alih-alih terus menggunakan kembali handshake keys. TLS 1.3 nantinya dapat menggunakan KeyUpdate untuk beralih ke application traffic keys yang baru.

Forward secrecy berasal dari (EC)DHE efemeral. Jika kedua peer menghapus nilai privat efemeral dan traffic secrets yang sudah usang, kebocoran kunci privat sertifikat jangka panjang server di masa mendatang tidak akan dapat mendekripsi lalu lintas aplikasi yang ditangkap dari full handshake yang telah selesai tersebut. Kunci sertifikat berfungsi untuk mengautentikasi; kunci tersebut bukan satu-satunya sumber forward secrecy.

Langkah 5: Session tickets mengubah koneksi berikutnya menjadi PSK resumption

Setelah full handshake, server dapat mengirimkan NewSessionTicket. Klien menyimpan ticket dan resumption secret terkait. Pada koneksi berikutnya, klien menawarkan identitas ticket di pre_shared_key dan menggunakan binder untuk membuktikan kepemilikan PSK yang sesuai. Jika server menerimanya, PSK mengautentikasi koneksi yang dipulihkan tersebut, yang biasanya meniadakan kebutuhan untuk mengirimkan rantai sertifikat dan CertificateVerify lagi.

Resumption tidak mengharuskan pelepasan ECDHE baru. TLS 1.3 mendukung PSK-only dan PSK yang digabungkan dengan ECDHE. Desain produksi umumnya mengutamakan PSK+DHE karena mempertahankan manfaat autentikasi dan komputasi dari resumption sambil tetap memasukkan materi Diffie-Hellman baru ke dalam lalu lintas aplikasi 1-RTT biasa. PSK-only memiliki properti yang berbeda, sehingga jawaban harus menyebutkan mode yang dipilih.

Ticket bukanlah kredensial login permanen. Ticket memiliki masa berlaku, parameter kriptografi yang terikat, rotasi kunci server, dan kebijakan pembagian kluster. Jika layanan multi-wilayah tidak dapat mendekripsi atau memvalidasi ticket secara konsisten, fallback ke full handshake atau menolak resumption adalah percabangan kompatibilitas yang valid. Mengejar rasio resumption yang lebih tinggi tidak membenarkan masa berlaku kunci ticket tanpa batas.

Langkah 6: 0-RTT menempatkan early data pada penerbangan pertama

Jika ticket mengizinkan early data, klien dapat mengirimkan ClientHello dan data aplikasi pada penerbangan pertama koneksi yang dipulihkan. Early data dienkripsi dengan client early traffic secret yang diturunkan dari PSK. Pada saat pengiriman, klien belum menerima ServerHello dari koneksi ini.

Hal ini mengurangi latensi tetapi menciptakan dua kelemahan kritis:

1. Early data diturunkan dari PSK tanpa pertukaran ECDHE pada koneksi ini, sehingga tidak memiliki forward secrecy.
2. Data tersebut tidak bergantung pada server nonce dan ServerHello koneksi ini, sehingga protokol tidak dapat menjamin bahwa ciphertext yang sama tidak akan di-replay pada koneksi lain.

Server dapat menerima atau menolak batch early-data TLS tersebut. Jika menolaknya, klien harus mengirim ulang permintaan yang masih perlu dieksekusi setelah handshake normal selesai. Aplikasi sudah menghadapi ketidakpastian ketika server mungkin telah memproses permintaan tetapi klien tidak menerima hasilnya. 0-RTT selain itu memungkinkan penyerang secara sengaja membuat duplikat lintas koneksi.

Langkah 7: Tentukan kelayakan berdasarkan efek samping bisnis

Tanpa informasi tambahan, RFC 8470 mengizinkan klien menggunakan metode HTTP yang aman (safe methods) dalam early data dan melarang metode yang tidak aman atau tidak dikenal. Metode HTTP hanyalah filter pertama. Perilaku sumber daya menentukan risiko sebenarnya.

Idempotency key saja tidak serta-merta membenarkan pengaktifan 0-RTT untuk transfer dana. Catatan idempotensi harus konsisten di setiap node pemrosesan, di-commit secara atomik pada batas transaksi yang tepat, dan mencakup efek samping audit, notifikasi, limit, serta fraud. Me-replay permintaan yang dicuri juga dapat mengunci atau mengonsumsi kunci tersebut. Kebijakan yang lebih aman adalah tetap menunggu penyelesaian handshake untuk operasi tulis (write) berisiko tinggi.

Langkah 8: Buat kebijakan gateway, origin, dan klien menjadi konsisten

HTTP mendefinisikan Early-Data: 1 dan 425 Too Early. Ketika sebuah gateway meneruskan permintaan yang mungkin tiba sebagai early data pada hop sebelumnya, gateway tersebut mempertahankan sinyal risiko. Origin yang tidak dapat memproses permintaan tersebut secara aman akan mengembalikan 425. Klien mencoba ulang pada koneksi tersebut setelah handshake selesai, dan percobaan ulang tersebut tidak boleh menggunakan early data lagi.

Setiap instance di edge harus menangani kelas permintaan yang sama secara konsisten. Jika satu instance langsung mengeksekusi sementara instance lain menunggu penyelesaian handshake atau menolak, penyerang dapat mengeksploitasi perbedaan multi-instance untuk menduplikasi efek. Langkah-langkah pengendalian meliputi:

• Nonaktifkan 0-RTT secara default dan hanya izinkan sumber daya read-only yang terdaftar secara eksplisit.
• Batasi masa berlaku ticket, ukuran early-data, dan jendela penerimaan.
• Gunakan state anti-replay bersama atau yang dipartisi secara konsisten sambil menyadari bahwa langkah ini mengurangi risiko alih-alih menggantikan semantik aplikasi.
• Tolak early data secara keseluruhan saat beban tinggi agar replay tidak memperparah beban komputasi yang mahal.
• Pastikan CDN, reverse proxy, dan origin semuanya memahami Early-Data dan 425.

Contoh Jawaban yang Kuat

"Saya akan menggunakan baseline full ECDHE handshake melalui TCP dengan autentikasi sertifikat server.

Klien mengirimkan ClientHello berisi versi yang didukung, cipher suite TLS 1.3, algoritma tanda tangan, grup pertukaran kunci, dan key share efemeral, ditambah kemungkinan ekstensi SNI dan ALPN. Server memilih parameter di ServerHello dan mengembalikan key share miliknya. Kedua peer memasukkan hasil ECDHE dan transcript ke dalam HKDF untuk menurunkan handshake traffic keys. Setelah fase pertukaran kunci, EncryptedExtensions, sertifikat server, CertificateVerify, dan Finished dienkripsi.

Sertifikat menyediakan rantai kepercayaan (trust chain) untuk identitas server. CertificateVerify menandatangani handshake transcript ini dengan kunci privat sertifikat, mengikat identitas ke negosiasi ini. Finished mengautentikasi integritas transcript dan mengonfirmasi kepemilikan kunci handshake. Setelah klien memvalidasi rantai, hostname, tanda tangan, dan Finished, klien mengirimkan Finished miliknya, dan kedua peer beralih ke kunci lalu lintas aplikasi terpisah. Kunci publik sertifikat memverifikasi identitas; kunci tersebut tidak mengenkripsi semua data bisnis. Forward secrecy terutama berasal dari ECDHE efemeral dan penghapusan secret.

Koneksi berikutnya dapat dipulihkan (resume) menggunakan PSK yang terkait dengan NewSessionTicket. Koneksi ini dapat menggunakan handshake 1-RTT PSK+DHE normal atau secara opsional menggunakan 0-RTT. Dengan 0-RTT, klien mengirimkan early data bersama ClientHello, tetapi byte tersebut hanya dilindungi oleh kunci turunan PSK, tidak memiliki forward secrecy, dan dapat di-replay lintas koneksi.

Oleh karena itu, saya tidak akan pernah mengirimkan POST /transfers dalam 0-RTT. Bahkan dengan idempotency key, efek transfer, audit, limit, dan notifikasi semuanya harus terbukti aman dari duplikasi. GET /rates hanya dimasukkan ke dalam allowlist jika merupakan operasi baca murni, aman dicoba ulang, dan tidak memiliki token sekali pakai atau efek samping yang tidak dapat diterima. Gateway dan origin meneruskan Early-Data: 1, mengembalikan 425 Too Early jika tidak aman, dan klien mencoba ulang setelah handshake selesai. Selama peluncuran, saya mengukur full handshake, 1-RTT resumption, dan 0-RTT secara terpisah, lalu memverifikasi penerimaan ticket, HRR, jalur penolakan, serta kebijakan lintas-node."

Kesalahan Umum

• Mengatakan bahwa kunci publik sertifikat mengenkripsi semua lalu lintas berikutnya → Lalu lintas bisnis TLS 1.3 menggunakan kunci lalu lintas simetris → pisahkan verifikasi tanda tangan sertifikat dari ECDHE/PSK dan HKDF.
• Mengatakan bahwa semuanya dienkripsi sejak ClientHello dan seterusnya → Negosiasi awal mendahului penurunan handshake-key → tempatkan batas enkripsi setelah ServerHello untuk pesan handshake berikutnya.
• Hanya memvalidasi rantai sertifikat dan mengabaikan transcript → Identitas harus terikat pada negosiasi ini → jelaskan peran terpisah dari CertificateVerify dan Finished.
• Menyamakan resumption dengan 0-RTT → Koneksi yang dipulihkan dapat menunggu handshake 1-RTT → jelaskan PSK resumption terlebih dahulu dan sebutkan bahwa early data bersifat opsional.
• Menganggap 0-RTT sebagai pengurangan RTT tanpa konsekuensi → Early data tidak memiliki forward secrecy dan dapat di-replay → petakan risikonya terhadap efek pada aplikasi.
• Mengizinkan setiap GET secara otomatis → Sebuah GET dapat mengonsumsi token, menagih penggunaan, atau memicu pekerjaan berat → buat allowlist berdasarkan semantik sumber daya yang sebenarnya.
• Mengasumsikan idempotency key menyelesaikan replay transfer → Konsistensi kluster dan efek samping di sekitarnya masih dapat terduplikasi → tunggu penyelesaian handshake untuk operasi tulis berisiko tinggi.
• Hanya mengonfigurasi CDN dan mengabaikan origin → Terminasi TLS dan penerusan HTTP melintasi dua batas keamanan → selaraskan perilaku edge, gateway, origin, klien, dan 425.

Pertanyaan Lanjutan

Pertanyaan Lanjutan 1: Mengapa TLS 1.3 lebih cepat daripada TLS 1.2?

Full handshake TLS 1.3 standar dapat menegosiasikan parameter dan mengautentikasi server dalam satu network round trip, sekaligus menghapus algoritma usang dan beberapa pesan yang tidak perlu dari desain lama. Key schedule yang lebih terpadu dan mekanisme resumption-nya juga membantu. Total latensi permintaan tetap mencakup DNS, TCP, pemrosesan server, dan data aplikasi. "TLS 1.3 adalah 1-RTT" tidak berarti seluruh permintaan selalu hanya membutuhkan satu RTT.

Pertanyaan Lanjutan 2: Apa yang terjadi pada lalu lintas historis jika kunci privat sertifikat bocor?

Jika full handshake tersebut menggunakan ECDHE efemeral dan implementasinya menghapus nilai privat efemeral serta traffic secret yang sudah usang, kebocoran kunci sertifikat jangka panjang saja tidak akan dapat mendekripsi lalu lintas aplikasi yang telah ditangkap sebelumnya. Itulah nilai dari forward secrecy. Kebocoran kunci enkripsi ticket, PSK, session secret, atau endpoint traffic secret memiliki dampak yang berbeda dan harus dievaluasi terhadap masa berlaku ticket, log, dan rotasi kunci.

Pertanyaan Lanjutan 3: Mengapa penyimpanan anti-replay tidak membuat setiap permintaan aman untuk 0-RTT?

Sistem multi-wilayah global tidak dapat dengan mudah membuat setiap penerimaan ticket dan early-data berkonsistensi kuat (strongly consistent) dan sekali pakai tanpa menambah latensi. Partisi jaringan, state node, rotasi ticket, dan replay penyerang yang konkuren menciptakan keterbatasan. Kontrol protokol dapat membatasi jendela waktu atau jumlah replay yang berhasil, tetapi aplikasi tetap harus berasumsi bahwa permintaan duplikat dapat terjadi dan membatasi early data hanya untuk operasi yang sesuai.

Pertanyaan Lanjutan 4: Bagaimana cara memverifikasi apakah lingkungan produksi menggunakan full handshake, resumption, atau 0-RTT?

Di lingkungan pengujian yang diotorisasi, gunakan openssl s_client -connect api.example:443 -servername api.example -tls1_3 -alpn h2 untuk memeriksa versi, sertifikat, dan ALPN. Simpan dan gunakan kembali sebuah sesi, lalu amati apakah sesi tersebut dipulihkan dan apakah early data diterima. Telemetri server harus mencatat mode handshake dan alasan penolakan tanpa menyertakan konten sensitif. Dekripsi packet captures hanya di lingkungan terkontrol dengan session keys yang diekspor klien, lalu bersihkan setelahnya.

Pertanyaan Lanjutan 5: Apakah 425 Too Early merupakan sebuah gangguan (outage)?

Belum tentu. Respons tersebut berarti server menolak risiko replay dan merupakan jalur kontrol early-data yang normal. Klien harus mencoba ulang setelah handshake selesai, dan percobaan ulang tersebut tidak boleh menggunakan early data. Jika pengguna melihat kegagalan berulang, verifikasi implementasi retry klien, penerusan Early-Data, konsistensi di seluruh instance server, dan apakah ada endpoint yang tidak sesuai yang secara tidak sengaja dimasukkan ke dalam allowlist 0-RTT.