Verifikasi Hostname TLS Mengikat Sertifikat Valid ke Nama yang Diminta

Sertifikat TLS dapat valid secara kriptografis tetapi tetap salah untuk server yang hendak dihubungi client. Validasi chain memeriksa apakah sertifikat dapat dihubungkan ke trust anchor yang dikonfigurasi berdasarkan aturan PKI yang berlaku. Verifikasi identitas service memeriksa hal yang berbeda: apakah sertifikat tersebut mewakili hostname yang diminta client.

Kedua pemeriksaan diperlukan untuk autentikasi HTTPS biasa. Menerima sertifikat tepercaya tanpa memeriksa nama yang diminta mengubah kredensial dengan cakupan sempit menjadi kredensial untuk tujuan lain yang tidak terkait.

Validasi chain dan pencocokan nama menangani masalah berbeda

Saat certificate path validation berlangsung, client mengevaluasi chain dari end-entity certificate yang diberikan menuju trust anchor. Verifikasi signature, masa berlaku, certificate constraints, dan aturan PKI lain menentukan apakah jalur tersebut dapat diterima.

Proses itu sendiri tidak mengikat sertifikat ke api.example.com.

Certification authority publik maupun privat dapat menerbitkan sertifikat untuk banyak nama secara sah. Sertifikat untuk files.example.net dapat memiliki chain ke trusted root yang sama dengan sertifikat untuk api.example.com. Root yang sama membentuk relasi trust dengan hierarki issuer; kondisi itu tidak membuat kedua identitas service dapat saling menggantikan.

Verifikasi hostname menyediakan pengikatan yang belum ada. Client memulai dengan reference identity yang berasal dari service yang memang hendak dihubungi, lalu membandingkan identitas tersebut dengan identifier yang dinyatakan oleh sertifikat server.

Untuk HTTPS, reference identity yang umum adalah DNS hostname dari URI target:

https://api.example.com/v1/orders
        ^^^^^^^^^^^^^^^
        reference hostname

Jika sertifikat tepercaya tetapi tidak mengidentifikasi api.example.com, autentikasi harus gagal.

Subject Alternative Name membawa identifier service

Pemeriksaan identitas service TLS modern menggunakan identifier di extension Subject Alternative Name pada sertifikat. Untuk service DNS, identifier tersebut berupa entri dNSName.

Sebuah sertifikat dapat memuat:

X509v3 Subject Alternative Name:
    DNS:api.example.com, DNS:status.example.com

Client yang terhubung ke api.example.com dapat membandingkan reference hostname dengan identifier dNSName. Client yang terhubung ke admin.example.com tidak dapat menganggap sertifikat ini cocok hanya karena ketiga nama memakai suffix example.com.

Common Name pada subject sertifikat memiliki sejarah panjang dalam PKI yang sudah digunakan, tetapi aturan identitas service saat ini menempatkan pencocokan DNS pada Subject Alternative Name. Implementasi baru sebaiknya tidak membangun verifikasi identitas dengan fallback ke Common Name.

Pemisahan ini juga membuat maksud sertifikat lebih eksplisit. Issuer menandatangani kumpulan identifier service yang terstruktur, bukan bergantung pada subject field yang lebih berorientasi pada tampilan.

Wildcard memiliki cakupan yang sengaja dibatasi

DNS identifier dapat memuat wildcard pada deployment dan profil yang mengizinkannya. Sertifikat yang berisi:

DNS:*.example.com

dapat mewakili satu label pada posisi wildcard, misalnya:

api.example.com

Wildcard tersebut tidak membentuk kredensial suffix tanpa batas. Secara khusus, identifier itu tidak cocok dengan nama yang lebih dalam seperti:

v2.api.example.com

Memperlakukan wildcard sebagai pencocokan string bebas akan memperluas otoritas sertifikat melewati cakupan identitas yang dikodekan. Karena itu, verifikasi hostname memerlukan aturan pencocokan yang ditetapkan protokol, bukan glob generik atau regular expression buatan kode aplikasi.

Wildcard certificate juga memperluas blast radius operasional dibanding sertifikat untuk host individual. Setiap service yang bergantung pada wildcard ikut bergantung pada perlindungan private key terkait dan proses penerbitan untuk namespace yang lebih luas tersebut.

Nama referensi harus berasal dari intent koneksi tepercaya

Pencocokan yang benar tetap gagal sebagai kontrol keamanan jika aplikasi memilih reference name dari data yang dikendalikan penyerang.

Pertimbangkan service yang dikonfigurasi untuk memanggil:

https://payments.internal.example

Reference hostname harus berasal dari tujuan yang memang dimaksud. Nilai itu tidak boleh diganti dengan nama yang disalin dari sertifikat peer, karena cara tersebut meminta sertifikat menentukan klaim sekaligus nilai pembanding untuk klaim itu sendiri.

Prinsip yang sama berlaku pada redirect, proxy, service resolution, dan custom connection stack. Sebuah komponen dapat secara sah mengubah tujuan jaringan, tetapi identitas yang harus diautentikasi perlu tetap terikat pada routing dan trust model aplikasi.

Koneksi ke IP address ketika aplikasi mengharapkan identitas service DNS juga memerlukan penanganan yang disengaja. Keterjangkauan transport dan identitas service yang diautentikasi merupakan properti terpisah. Socket yang mencapai address yang diharapkan tidak membuktikan bahwa peer memiliki otorisasi untuk DNS name yang dimaksud.

SNI dan verifikasi hostname berkaitan tetapi tidak saling menggantikan

TLS Server Name Indication, atau SNI, memungkinkan client mengirim server name selama handshake agar server yang menampung beberapa identitas TLS dapat memilih konfigurasi dan sertifikat yang sesuai.

Hal itu membuat SNI berkaitan secara operasional dengan identitas sertifikat, tetapi pengiriman SNI bukan langkah verifikasi.

Flow yang disederhanakan:

target client: api.example.com
        |
        +-- SNI: api.example.com --------> server memilih sertifikat
        |
        <--------- sertifikat untuk api.example.com
        |
        +-- validasi chain
        +-- cocokkan identitas sertifikat dengan api.example.com

Jika client mengirim nilai SNI yang diharapkan lalu melewati verifikasi hostname, sertifikat server tetap belum diperiksa terhadap identitas yang dimaksud client. SNI memengaruhi pemilihan di sisi server; verifikasi mengautentikasi hasilnya.

Perbedaan ini sangat penting pada custom TLS code, ketika low-level API dapat menyediakan validasi sertifikat dan pemeriksaan hostname sebagai pilihan konfigurasi yang terpisah.

Menonaktifkan verifikasi mengubah enkripsi menjadi transport tanpa autentikasi

Environment development kadang mengumpulkan opsi bernama seperti insecure, skip verify, atau trust all. Semantik tepatnya berbeda pada setiap library, tetapi mode yang menonaktifkan autentikasi sertifikat menghapus properti inti yang diharapkan dari TLS.

Traffic dapat tetap terenkripsi di jaringan, tetapi client tidak lagi memiliki bukti yang andal bahwa koneksi terenkripsi tersebut menuju peer yang dimaksud. Intermediary aktif yang dapat menempatkan dirinya pada jalur koneksi kemudian dapat mengisi celah autentikasi itu.

Setup pengujian yang lebih aman mempertahankan verifikasi dan mengubah trust input secara sengaja. Sebagai contoh, certification authority privat untuk pengujian dapat ditambahkan ke test trust store, sementara test certificate memuat nama service yang benar-benar dipakai di environment tersebut.

Struktur autentikasi tetap sama dengan production: jalur issuer tepercaya ditambah pencocokan identitas service.

Proxy membuat hop yang diautentikasi menjadi eksplisit

Forward proxy, reverse proxy, service mesh sidecar, atau load balancer yang melakukan terminasi TLS dapat mengubah titik awal dan akhir TLS. Verifikasi hostname berlaku pada setiap koneksi TLS secara independen.

Jika aplikasi membuka TLS ke proxy, sertifikat pada hop tersebut mengautentikasi identitas yang diharapkan untuk koneksi menuju proxy. Jika proxy membuka koneksi TLS kedua ke origin, proxy menjadi client pada hop itu dan harus mengautentikasi origin berdasarkan reference identity serta trust policy yang dikonfigurasi untuknya.

Kedua pemeriksaan tidak dapat dilebur menjadi pernyataan umum bahwa request sudah “dilindungi TLS”. Setiap hop memiliki peer, reference identity, trust configuration, dan keputusan autentikasi sendiri.

Model ini berguna saat menelusuri certificate error pada infrastruktur berlapis. Hal yang relevan bukan hanya sertifikat mana yang tersedia, tetapi komponen mana yang menerimanya dan service name apa yang diharapkan komponen tersebut.

Certificate error sering merupakan error identitas, bukan kegagalan kriptografis

Pesan seperti “certificate is valid for X, not Y” menunjukkan bahwa banyak bagian TLS mungkin sudah berfungsi. Server memberikan sertifikat, client dapat memprosesnya, dan chain bahkan mungkin dapat diterima. Kegagalan terjadi karena identitas yang diautentikasi tidak cocok dengan intent koneksi.

Mengganti error tersebut dengan bypass verifikasi global hanya menghapus pemeriksaan identitas. Perbaikan yang tepat biasanya lebih sempit: terbitkan sertifikat yang memuat identifier tujuan, koreksi hostname yang dipakai client, perbaiki konfigurasi routing atau SNI, atau perbaiki trust configuration ketika kegagalan memang berada pada chain.

Pemisahan kelas kegagalan tersebut membuat konfigurasi TLS lebih mudah dianalisis. Trust anchor menentukan issuer mana yang dapat menjamin identitas. Identifier sertifikat menyatakan identitas mana yang dijamin. Verifikasi hostname menghubungkan pernyataan bertanda tangan itu dengan service yang memang hendak dihubungi client.

Referensi: RFC 9525 — Service Identity in TLS