Temuduga Rangkaian: Bagaimana Jabat Tangan TLS 1.3 Berfungsi, dan Bilakah 0-RTT Selamat?

Soalan dan Skop

Satu API global menggunakan TLS 1.3. Terangkan langkah demi langkah jabat tangan penuh dan jabat tangan yang disambung semula. Jelaskan perkara yang disulitkan pada setiap peringkat, cara sijil mengesahkan pelayan, cara kunci dihasilkan, dan sama ada GET /rates dan POST /transfers patut menggunakan 0-RTT.

Gunakan garis dasar yang eksplisit: klien bersambung ke perkhidmatan HTTPS melalui TCP; pelayan mengesahkan identiti dengan sijil X.509; jabat tangan penuh menggunakan ECDHE efemerol; sambungan yang disambung semula menggunakan tiket sesi yang dikeluarkan pada sambungan terdahulu; dan titik masuk API mungkin merupakan pengimbang beban atau CDN. HTTP/3 menyepadukan TLS 1.3 ke dalam pembentukan sambungan QUIC, tetapi garis dasar ini menggunakan rekod TLS melalui TCP untuk menjadikan susunan mesej dan sifat keselamatan lebih konkrit.

Soalan ini sesuai untuk temuduga backend, klien, infrastruktur, SRE, keselamatan, dan kejuruteraan perisian am. Penemuduga bukan sekadar mahukan bacaan hafalan daripada ClientHello ke Finished. Calon mesti menerangkan bagaimana identiti diikat pada jabat tangan ini, kunci mana yang melindungi peringkat mana, dan mengapa menghapuskan satu pusingan perjalanan rangkaian (round trip) mewujudkan masalah main semula (replay) yang mesti dikendalikan oleh aplikasi.

Perkara yang Diuji oleh Penemuduga

Pertama, bolehkah calon memisahkan pertukaran kunci, pengesahsahihan, dan penyulitan pukal? Kunci awam dalam sijil biasanya mengesahkan tandatangan CertificateVerify ke atas transkrip jabat tangan. Ia tidak menyulitkan semua trafik perniagaan yang seterusnya. Kunci trafik simetri datang daripada ECDHE, PSK, dan jadual kunci berasaskan HKDF.

Kedua, bolehkah calon meletakkan sempadan penyulitan dengan tepat? ClientHello dan ServerHello awal mendedahkan maklumat yang diperlukan untuk perundingan. Selepas memproses ServerHello, kedua-dua pihak (peer) boleh menerbitkan kunci trafik jabat tangan. Kunci tersebut melindungi EncryptedExtensions, Certificate, CertificateVerify, dan Finished. Kunci trafik aplikasi yang berasingan kemudiannya melindungi data aplikasi.

Ketiga, bolehkah calon membezakan penyambungan semula (resumption) daripada 0-RTT? Penyambungan semula sesi boleh memendekkan pengesahsahihan sambil tetap melengkapkan jabat tangan 1-RTT. Dengan 0-RTT, klien menghantar data awal (early data) dalam penerbangan pertamanya (first flight). Kedua-duanya boleh melibatkan PSK, tetapi hanya data awal yang kekurangan kesegaran (freshness) yang diterbitkan daripada ServerHello semasa.

Keempat, bolehkah calon menterjemahkan risiko protokol kepada semantik perniagaan? TLS 1.3 memberikan sifat yang lebih lemah kepada data awal: ia tidak mempunyai kerahsiaan ke hadapan (forward secrecy) dan tiada jaminan ketiadaan main semula merentasi sambungan. Mengaktifkannya tidak boleh diputuskan semata-mata daripada kaedah HTTP. Mengenakan bayaran wang, mencipta sesi, menambah pembilang, mengeluarkan ganjaran, atau menggunakan token sekali guna akan mengubah jawapannya.

Kelima, bolehkah calon mencadangkan pelan pelaksanaan dan penyahpepijatan yang boleh diperhatikan (observable)? Jawapan yang kukuh membezakan jabat tangan penuh, penyambungan semula 1-RTT, dan 0-RTT; menyemak tiket, ALPN, HelloRetryRequest, penerimaan atau penolakan data awal, dan 425 Too Early HTTP; serta mengesahkan saluran keselamatan berasingan daripada penamat TLS pinggir ke asal (origin).

Soalan untuk Dijelaskan Terlebih Dahulu

• Pengangkutan (transport) mana yang digunakan? HTTPS melalui TCP dan QUIC/HTTP/3 kedua-duanya menggunakan kriptografi TLS 1.3, tetapi membawa mesej dan membina sambungan secara berbeza. Garis dasar ini menggunakan TCP.
• Adakah ini sambungan pertama atau yang disambung semula? Sambungan pertama tidak mempunyai PSK yang boleh digunakan dan memerlukan pengesahsahihan sijil. Sambungan yang disambung semula boleh menawarkan tiket terdahulu, tetapi tidak semestinya menghantar 0-RTT.
• Adakah pelayan meminta sijil klien? Kebanyakan API web hanya mengesahkan pelayan. mTLS menambah Certificate dan CertificateVerify klien.
• Di manakah TLS ditamatkan? Jika ia ditamatkan pada CDN atau pengimbang beban, klien mengesahkan titik akhir pinggir tersebut. Trafik pinggir ke asal adalah sambungan berasingan dengan keputusan penyulitan dan identitinya yang tersendiri.
• Apakah semantik main semula bagi operasi tersebut? Adakah GET /rates benar-benar baca sahaja? Adakah ia menggunakan token sekali guna, menambah pembilang yang boleh dibilkan, atau mencetuskan kerja yang mahal? Kunci keidempotenan pada POST /transfers tidak secara automatik menghapuskan setiap risiko data awal.
• Adakah kedua-dua pihak melaksanakan data awal HTTP dengan betul? Klien mesti mencuba semula dengan selamat pada sambungan yang telah dibina jika lapisan TLS menolak data awal atau pelayan mengembalikan 425.

Rangka Jawapan 30 Saat

“Dalam jabat tangan penuh TLS 1.3, klien menghantar ClientHello dengan versi, suite sifer, dan bahagian kunci ECDHE. Pelayan memilih parameter dalam ServerHello dan mengembalikan bahagian kuncinya. Kedua-dua pihak memasukkan hasil ECDHE dan transkrip ke dalam HKDF untuk menerbitkan kunci jabat tangan, jadi sambungan (extensions), sijil, tandatangan, dan Finished selepas ServerHello adalah disulitkan. Klien mengesahkan rantai, nama hos, CertificateVerify, dan Finished, kemudian menghantar Finished miliknya sendiri. Kunci trafik aplikasi yang berasingan melindungi data seterusnya.

Penyambungan semula menggunakan PSK yang dikaitkan dengan tiket terdahulu dan boleh mengelakkan pengesahsahihan sijil penuh. Jika 0-RTT juga didayakan, klien menghantar data awal bersama ClientHello. Data itu hanya bergantung pada PSK, tidak mempunyai kerahsiaan ke hadapan, dan boleh dimainkan semula merentasi sambungan. Saya hanya akan membenarkan bacaan yang selamat untuk dicuba semula secara eksplisit dan bebas daripada kesan sampingan. Pemindahan mesti menunggu penyelesaian jabat tangan, dengan dasar get laluan yang konsisten, 425 Too Early, dan sokongan percubaan semula yang normal.”

Penerangan Mendalam Langkah demi Langkah

Langkah 1: ClientHello membekalkan bahan perundingan

Klien bermula dengan ClientHello. Ia biasanya mengandungi nonce, versi TLS yang disokong, suite sifer TLS 1.3, algoritma tandatangan, kumpulan pertukaran kunci yang disokong, satu atau lebih nilai key_share, dan sambungan seperti SNI dan ALPN. Suite sifer TLS 1.3 terutamanya memilih algoritma AEAD dan cincangan (hash) yang digunakan oleh HKDF. Sambungan lain merundingkan algoritma tandatangan sijil dan kumpulan pertukaran kunci.

Mesej ini belum lagi dilindungi oleh kunci trafik jabat tangan dalam TLS 1.3 biasa. SNI juga biasanya kelihatan melainkan pihak terlibat berjaya menggunakan ECH. Mengatakan bahawa TLS menyulitkan setiap medan dari bait pertama mengabaikan fakta bahawa pihak terlibat belum lagi menerbitkan kunci trafik kongsi untuk sambungan ini.

Bahagian kunci klien ialah nilai awam ECDHE efemerol. Nilai peribadi yang sepadan kekal secara tempatan. Nilai awam itu sendiri bukanlah rahsia kongsi. Setiap pihak menggabungkan nilai peribadinya dengan nilai awam pihak yang satu lagi untuk mengira rahsia ECDHE yang sama.

Langkah 2: ServerHello memilih parameter dan melengkapkan pertukaran kunci yang segar

Pelayan memilih versi TLS, suite sifer, dan bahagian kunci yang boleh diterima, kemudian menghantar ServerHello. Dengan ECDHE, ia juga membekalkan nilai awam efemerolnya. ClientHello ditambah ServerHello menentukan parameter kriptografi, dan kedua-dua pihak kini boleh memasukkan rahsia ECDHE ke dalam jadual kunci HKDF TLS 1.3.

Jika klien tidak menawarkan bahagian kunci dalam kumpulan yang diterima oleh pelayan, pelayan boleh menghantar HelloRetryRequest dan memerlukan satu lagi ClientHello dengan kumpulan yang dipilih. Itu memerlukan kos satu lagi pusingan perjalanan, dan percubaan data awal asal tidak boleh diteruskan begitu sahaja sebagai laluan berjaya yang normal. RTT tambahan yang berselang-seli dalam pengeluaran sepatutnya mendorong semakan HRR dan bukannya anggapan automatik terhadap ketidakstabilan rangkaian (network jitter).

Selepas ServerHello, kedua-dua pihak boleh menerbitkan rahsia trafik jabat tangan klien dan pelayan. Protokol melindungi mesej jabat tangan seterusnya dengan kunci tersebut. Pemerhati pasif tidak boleh membaca sijil atau kebanyakan sambungan terkemudian, walaupun saiz rekod, pemasaan, dan maklumat awal yang tidak disembunyikan oleh ECH kekal boleh diperhatikan.

Langkah 3: Parameter pelayan, sijil, dan tandatangan transkrip menetapkan identiti

Pelayan seterusnya menghantar EncryptedExtensions yang disulitkan, yang mengandungi pilihan untuk sambungan seperti ALPN. Ia menghantar CertificateRequest jika ia mahukan pengesahsahihan klien. Jabat tangan HTTPS satu hala yang tipikal kemudian menghantar Certificate, CertificateVerify, dan Finished pelayan.

Mesej-mesej tersebut mempunyai tugas yang berbeza:

Klien mengesahkan rantai, sela masa sah, nama hos, dan algoritma tandatangan yang dibenarkan mengikut dasar PKI miliknya, kemudian mengesahkan tandatangan CertificateVerify ke atas transkrip. Ini mengikat kawalan kunci peribadi sijil kepada ClientHello, ServerHello, dan set parameter yang dirundingkan ini. Penyerang tidak boleh memindahkan tandatangan daripada jabat tangan yang tidak berkaitan.

Langkah 4: Finished melengkapkan jabat tangan dan mengasingkan kunci aplikasi

Finished pelayan ialah nilai pengesahan yang diterbitkan daripada transkrip dan rahsia jabat tangan. Semakan yang berjaya memberitahu klien bahawa perundingan yang diperhatikan tidak diubah suai dan pihak yang satu lagi memiliki bahan kunci jabat tangan yang sepadan. Menerima data tanpa pengesahsahihan sijil atau pengesahan Finished akan membuang jaminan identiti dan integriti TLS.

Klien kemudian menghantar Finished miliknya sendiri. Jika pelayan meminta mTLS, klien menghantar sijil dan CertificateVerify miliknya terlebih dahulu. Pihak terlibat melindungi data aplikasi dengan rahsia trafik aplikasi dan bukannya terus menggunakan semula kunci jabat tangan. TLS 1.3 kemudiannya boleh menggunakan KeyUpdate untuk beralih kepada kunci trafik aplikasi yang baharu.

Kerahsiaan ke hadapan datang daripada (EC)DHE efemerol. Jika pihak terlibat memadamkan nilai peribadi efemerol dan rahsia trafik yang sudah lapuk, kebocoran kunci peribadi sijil jangka panjang pelayan pada masa hadapan tidak sepatutnya menyahsulit trafik aplikasi yang ditangkap daripada jabat tangan penuh yang telah selesai tersebut. Kunci sijil mengesahkan identiti; ia bukan satu-satunya punca kerahsiaan ke hadapan.

Langkah 5: Tiket sesi mengubah sambungan kemudian kepada penyambungan semula PSK

Selepas jabat tangan penuh, pelayan boleh menghantar NewSessionTicket. Klien menyimpan tiket dan rahsia penyambungan semula yang berkaitan. Pada sambungan yang terkemudian, ia menawarkan identiti tiket dalam pre_shared_key dan menggunakan pengikat (binder) untuk membuktikan pemilikan PSK yang sepadan. Jika pelayan menerimanya, PSK mengesahkan sambungan yang disambung semula, biasanya menghapuskan keperluan untuk menghantar rantai sijil dan CertificateVerify sekali lagi.

Penyambungan semula tidak memerlukan pelepasan ECDHE yang segar. TLS 1.3 menyokong PSK sahaja dan PSK yang digabungkan dengan ECDHE. Reka bentuk pengeluaran biasanya mementingkan PSK+DHE kerana ia mengekalkan faedah pengesahsahihan dan pengiraan penyambungan semula sambil menggabungkan bahan Diffie-Hellman yang segar ke dalam trafik aplikasi 1-RTT biasa. PSK sahaja mempunyai sifat yang berbeza, jadi jawapan harus menamakan mod yang dipilih.

Tiket bukanlah kelayakan log masuk yang kekal. Ia mempunyai jangka hayat, parameter kriptografi yang terikat, penggiliran kunci pelayan, dan dasar perkongsian kelompok (cluster). Jika perkhidmatan berbilang rantau tidak dapat menyahsulit atau mengesahkan tiket secara konsisten, pengunduran (fallback) ke jabat tangan penuh atau penolakan penyambungan semula adalah cabang keserasian yang sah. Mengejar kadar penyambungan semula yang lebih tinggi tidak mewajarkan jangka hayat kunci tiket tanpa had.

Langkah 6: 0-RTT meletakkan data awal dalam penerbangan pertama

Jika tiket membenarkan data awal, klien boleh menghantar ClientHello dan data aplikasi dalam penerbangan pertama bagi sambungan yang disambung semula. Data awal disulitkan dengan rahsia trafik awal klien yang diterbitkan daripada PSK. Pada masa penghantaran, klien belum menerima ServerHello bagi sambungan ini.

Itu mengurangkan kependaman tetapi mewujudkan dua kelemahan kritikal:

1. Data awal diterbitkan daripada PSK tanpa pertukaran ECDHE sambungan ini, jadi ia tidak mempunyai kerahsiaan ke hadapan.
2. Ia tidak bergantung pada nonce pelayan dan ServerHello ini, jadi protokol tidak dapat menjamin bahawa teks sifer yang sama tidak akan dimainkan semula pada sambungan lain.

Pelayan boleh menerima atau menolak kelompok data awal TLS. Jika ia menolaknya, klien mesti menghantar semula permintaan yang masih memerlukan pelaksanaan selepas jabat tangan normal selesai. Aplikasi sudah pun menghadapi ketidakpastian apabila pelayan mungkin telah memproses permintaan tetapi klien tidak menerima hasilnya. 0-RTT secara tambahan membolehkan penyerang sengaja mencipta pendua merentasi sambungan.

Langkah 7: Tentukan kelayakan daripada kesan sampingan perniagaan

Tanpa maklumat tambahan, RFC 8470 membenarkan klien menggunakan kaedah HTTP yang selamat dalam data awal dan melarang kaedah yang tidak selamat atau tidak diketahui. Kaedah hanyalah penapis pertama. Tingkah laku sumber menentukan risiko sebenar.

Kunci keidempotenan tidak dengan sendirinya mewajarkan mendayakan 0-RTT untuk pemindahan. Rekod keidempotenan mestilah konsisten merentasi setiap nod pemprosesan, dikomit secara atomik pada sempadan transaksi yang betul, dan merangkumi kesan sampingan audit, pemberitahuan, had, dan penipuan. Memainkan semula permintaan yang dicuri juga boleh menetapkan atau menghabiskan kunci. Dasar yang lebih selamat masih lagi menunggu penyelesaian jabat tangan untuk penulisan berisiko tinggi.

Langkah 8: Jadikan dasar get laluan, asal, dan klien konsisten

HTTP mentakrifkan Early-Data: 1 dan 425 Too Early. Apabila get laluan memajukan permintaan yang mungkin telah tiba dalam data awal pada lompatan (hop) terdahulu, ia mengekalkan isyarat risiko tersebut. Asal yang tidak dapat memproses permintaan dengan selamat akan mengembalikan 425. Klien mencuba semula pada sambungan selepas jabat tangan selesai, dan percubaan semula itu tidak boleh menggunakan data awal lagi.

Setiap tika (instance) pinggir mesti mengendalikan kelas permintaan yang sama secara konsisten. Jika satu tika melaksanakannya serta-merta manakala tika lain menunggu jabat tangan selesai atau menolak, penyerang boleh mengeksploitasi perbezaan berbilang tika untuk menduplikasi kesan. Kawalan termasuk:

• Nyahdayakan 0-RTT secara lalai dan hanya benarkan sumber baca sahaja yang didaftarkan secara eksplisit.
• Hadkan jangka hayat tiket, saiz data awal, dan tetingkap penerimaan.
• Gunakan keadaan anti-main semula yang dikongsi atau dipisahkan secara konsisten sambil menyedari bahawa ia mengurangkan risiko dan bukannya menggantikan semantik aplikasi.
• Tolak data awal secara keseluruhan di bawah beban supaya main semula tidak dapat menguatkan kerja yang mahal.
• Pastikan CDN, proksi terbalik, dan asal semuanya memahami Early-Data dan 425.

Contoh Jawapan yang Kukuh

“Saya akan menggunakan jabat tangan ECDHE penuh melalui TCP dengan pengesahsahihan sijil pelayan sebagai garis dasar.

Klien menghantar ClientHello dengan versi yang disokong, suite sifer TLS 1.3, algoritma tandatangan, kumpulan pertukaran kunci, dan bahagian kunci efemerol, ditambah kemungkinan sambungan SNI dan ALPN. Pelayan memilih parameter dalam ServerHello dan mengembalikan bahagian kuncinya. Kedua-dua pihak memasukkan hasil ECDHE dan transkrip ke dalam HKDF untuk menerbitkan kunci trafik jabat tangan. Selepas fasa pertukaran kunci, EncryptedExtensions, sijil pelayan, CertificateVerify, dan Finished adalah disulitkan.

Sijil membekalkan rantai kepercayaan untuk identiti pelayan. CertificateVerify menandatangani transkrip jabat tangan ini dengan kunci peribadi sijil, mengikat identiti kepada perundingan ini. Finished mengesahkan integriti transkrip dan mengesahkan pemilikan kunci jabat tangan. Selepas klien mengesahkan rantai, nama hos, tandatangan, dan Finished, ia menghantar Finished miliknya sendiri, dan pihak terlibat beralih kepada kunci trafik aplikasi yang berasingan. Kunci awam sijil mengesahkan identiti; ia tidak menyulitkan semua data perniagaan. Kerahsiaan ke hadapan terutamanya datang daripada ECDHE efemerol dan pemadaman rahsia.

Sambungan yang terkemudian boleh disambung semula dengan PSK yang dikaitkan dengan NewSessionTicket. Ia boleh menggunakan jabat tangan PSK+DHE 1-RTT biasa atau secara pilihan menggunakan 0-RTT. Dengan 0-RTT, klien menghantar data awal di samping ClientHello, tetapi bait tersebut hanya dilindungi oleh kunci yang diterbitkan daripada PSK, tidak mempunyai kerahsiaan ke hadapan, dan boleh dimainkan semula merentasi sambungan.

Oleh itu, saya tidak akan sekali-kali menghantar POST /transfers dalam 0-RTT. Walaupun dengan kunci keidempotenan, kesan pemindahan, audit, had, dan pemberitahuan semuanya mesti dibuktikan selamat daripada pendua. GET /rates hanya dimasukkan ke dalam senarai dibenarkan (allowlist) jika ia adalah bacaan tulen, boleh dicuba semula dengan selamat, dan tidak mempunyai token sekali guna atau kesan sampingan yang tidak boleh diterima. Get laluan dan asal menyebarkan Early-Data: 1, mengembalikan 425 Too Early apabila tidak selamat, dan klien mencuba semula selepas jabat tangan selesai. Semasa pelaksanaan, saya mengukur jabat tangan penuh, penyambungan semula 1-RTT, dan 0-RTT secara berasingan, kemudian mengesahkan penerimaan tiket, HRR, laluan penolakan, dan dasar merentasi nod.”

Kesilapan Biasa

• Mengatakan kunci awam sijil menyulitkan semua trafik terkemudian → Trafik perniagaan TLS 1.3 menggunakan kunci trafik simetri → pisahkan pengesahan tandatangan sijil daripada ECDHE/PSK dan HKDF.
• Mengatakan semuanya disulitkan dari ClientHello dan seterusnya → perundingan awal mendahului penerbitan kunci jabat tangan → letakkan sempadan selepas ServerHello untuk mesej jabat tangan yang seterusnya.
• Hanya mengesahkan rantai dan mengabaikan transkrip → identiti mesti diikat pada perundingan ini → terangkan peranan berasingan bagi CertificateVerify dan Finished.
• Menyamakan penyambungan semula dengan 0-RTT → sambungan yang disambung semula boleh menunggu jabat tangan 1-RTT → huraikan penyambungan semula PSK terlebih dahulu dan data awal sebagai pilihan.
• Menganggap 0-RTT sebagai pengurangan RTT percuma → data awal tidak mempunyai kerahsiaan ke hadapan dan boleh dimainkan semula → petakan risiko kepada kesan aplikasi.
• Membenarkan setiap GET secara automatik → GET boleh menggunakan token, membilkan penggunaan, atau mencetuskan kerja yang mahal → senaraikan dalam senarai dibenarkan mengikut semantik sumber sebenar.
• Menganggap kunci keidempotenan menyelesaikan main semula pemindahan → konsistensi kelompok dan kesan di sekelilingnya masih boleh menduplikasi → tunggu penyelesaian jabat tangan untuk penulisan berisiko tinggi.
• Hanya mengkonfigurasi CDN dan mengabaikan asal → penamatan TLS dan pemajuan HTTP merentasi dua sempadan keselamatan → selaraskan tingkah laku pinggir, get laluan, asal, klien, dan 425.

Soalan Susulan

Susulan 1: Mengapakah TLS 1.3 lebih pantas daripada TLS 1.2?

Jabat tangan penuh TLS 1.3 yang tipikal boleh merundingkan parameter dan mengesahkan pelayan dalam satu pusingan perjalanan rangkaian, sambil mengalih keluar algoritma lapuk dan beberapa mesej yang tidak diperlukan daripada reka bentuk terdahulu. Jadual kunci dan mekanisme penyambungan semula yang lebih bersepadu juga membantu. Jumlah kependaman permintaan masih merangkumi DNS, TCP, pemprosesan pelayan, dan data aplikasi. “TLS 1.3 ialah 1-RTT” tidak bermakna keseluruhan permintaan sentiasa hanya memerlukan satu RTT.

Susulan 2: Apakah yang berlaku kepada trafik sejarah jika kunci peribadi sijil bocor?

Jika jabat tangan penuh tersebut menggunakan ECDHE efemerol dan pelaksanaan telah memadamkan nilai peribadi efemerol serta rahsia trafik yang lapuk, kebocoran hanya pada kunci sijil jangka panjang tidak sepatutnya menyahsulit trafik aplikasi yang ditangkap sebelum ini. Itulah nilai kerahsiaan ke hadapan. Kunci penyulitan tiket, PSK, rahsia sesi, atau rahsia trafik titik akhir yang bocor mempunyai impak yang berbeza dan mesti dinilai berdasarkan jangka hayat tiket, log, dan penggiliran.

Susulan 3: Mengapakah stor anti-main semula tidak menjadikan setiap permintaan selamat untuk 0-RTT?

Sistem berbilang rantau global tidak boleh dengan mudah menjadikan setiap tiket dan penerimaan data awal konsisten secara kukuh dan kegunaan sekali sahaja tanpa menambah kependaman. Pemisahan rangkaian (network partitions), keadaan nod, penggiliran tiket, dan main semula penyerang yang serentak mewujudkan sempadan. Kawalan protokol boleh mengehadkan tetingkap atau bilangan main semula yang berjaya, tetapi aplikasi masih mesti menganggap permintaan pendua boleh berlaku dan mengehadkan data awal kepada operasi yang sesuai.

Susulan 4: Bagaimanakah anda mengesahkan sama ada pengeluaran menggunakan jabat tangan penuh, penyambungan semula, atau 0-RTT?

Dalam persekitaran ujian yang dibenarkan, gunakan openssl s_client -connect api.example:443 -servername api.example -tls1_3 -alpn h2 untuk memeriksa versi, sijil, dan ALPN. Simpan dan gunakan semula sesi, kemudian perhatikan sama ada ia menyambung semula dan sama ada data awal diterima. Telemetri pelayan harus merekodkan mod jabat tangan dan sebab penolakan tanpa kandungan sensitif. Nyahsulit tangkapan paket hanya dalam persekitaran terkawal dengan kunci sesi yang dieksport oleh klien, kemudian bersihkan ia.

Susulan 5: Adakah 425 Too Early merupakan gangguan perkhidmatan (outage)?

Tidak semestinya. Ia bermakna pelayan menolak risiko main semula dan ia merupakan laluan kawalan data awal yang normal. Klien harus mencuba semula selepas jabat tangan selesai, dan percubaan semula itu tidak boleh menggunakan data awal. Jika pengguna melihat kegagalan berulang, sahkan pelaksanaan percubaan semula klien, penyebaran Early-Data, konsistensi merentasi tika pelayan, dan sama ada titik akhir yang tidak sesuai telah tersilap ditambah ke dalam senarai dibenarkan 0-RTT.