Autentikasi dasar melalui HTTPS versus IPsec: apa yang dilindungi masing-masing

Buka alat pengembang, muat aplikasi internal, dan amati satu permintaan melewati empat titik pemeriksaan sebelum halaman dirender. Pertama nama diuraikan, lalu koneksi TCP terbuka, lalu jabat tangan TLS menetapkan siapa servernya, dan baru setelah itu aplikasi menanyakan siapa Anda. Perlakukan ini sebagai peristiwa terpisah, karena masing-masing gagal dengan bukti berbeda dan masing-masing dimiliki tim berbeda. Sebagian besar kebingungan dalam insiden berasal dari membaca 401 sebagai masalah terowongan, atau masalah terowongan sebagai kata sandi yang salah.

Titik pemeriksaan satu: apakah ini server yang ingin Anda ajak bicara

Jabat tangan TLS menjawab pertanyaan itu sebelum kredensial apa pun dikirim. Klien Anda memvalidasi rantai sertifikat terhadap penyimpanan kepercayaan dan memeriksa bahwa nama dalam sertifikat cocok dengan hos yang Anda ketik. Jika itu gagal, peramban menampilkan kesalahan sertifikat dan sama sekali tidak mengirim header Authorization. Jadi permintaan kata sandi bukan bukti bahwa servernya asli; itu bukti bahwa aplikasi menjawab.

Di sini batas pertama muncul. TLS melindungi koneksi hingga titik penghentiannya. Jika penyeimbang beban mengakhiri TLS dan meneruskan HTTP biasa ke aplikasi, segmen terenkripsi berakhir di penyeimbang, dan kredensial hanya terlindungi pada lompatan pertama itu.

Titik pemeriksaan dua: apa yang sebenarnya berpindah dalam pertukaran 401

Autentikasi dasar HTTP mengirim pengenal pengguna dan kata sandi dalam header, dikodekan dengan Base64 seperti dijelaskan dalam RFC 7617. Authorization: Basic dXNlcjpwYXNz adalah bentuknya; pengodean dapat dibalik oleh siapa pun yang dapat membaca permintaan, jadi seluruh kerahasiaan berasal dari transportasi di bawahnya. curl -v menampilkan tantangan WWW-Authenticate: Basic dan header yang Anda kirim kembali.

Header itu memberi tahu aplikasi siapa yang bertanya. Header itu tidak memberi tahu jaringan siapa yang boleh terhubung, dan tidak mengenkripsi apa pun dengan sendirinya. Aplikasi tetap harus memeriksa kredensial terhadap penyimpanan dan memutuskan apa yang boleh dilakukan akun itu, yang merupakan otorisasi dan terjadi setelah autentikasi.

Di mana terowongan IPsec berada di jalur itu

Sekarang berjalanlah keluar dari peramban. Terowongan IPsec gerbang-ke-gerbang melindungi lalu lintas terpilih antara dua gerbang keamanan, bukan antara laptop Anda dan proses aplikasi. ESP dalam mode terowongan membungkus paket asli, gerbang mengenkripsi dan mengautentikasinya, dan alamat dalam bertahan sehingga sisi jauh dapat merutekan permintaan ke aplikasi.

Pemilihan adalah bagian yang membuat orang tersandung. Terowongan berbasis kebijakan menggunakan pemilih lalu lintas, sering dinyatakan sebagai daftar kontrol akses, untuk menentukan paket mana yang masuk ke terowongan. Terowongan berbasis rute menggunakan antarmuka virtual dan tabel perutean sebagai gantinya. Di Linux ip xfrm policy menampilkan pemilih dan ip xfrm state menampilkan asosiasi keamanan yang terbentuk; pada perangkat tembok api padanannya adalah tabel SA terowongan ditambah pelacak paket.

Konsekuensinya layak dinyatakan dengan jelas. Sebuah paket dapat duduk di dalam terowongan yang sepenuhnya sehat dan tetap membawa permintaan HTTPS yang ditolak aplikasi, dan kredensial yang sah dapat tiba melalui jalur tanpa terowongan sama sekali jika perutean mengizinkannya.

Baca kegagalan pada lapisan yang melaporkannya

401 berarti aplikasi tidak menerima kredensial itu. 403 berarti aplikasi menerima identitasnya dan menolak operasinya. Kesalahan TLS berarti klien tidak menerima servernya. Tidak ada rute atau ketidakcocokan kebijakan berarti paket tidak pernah mencapai gerbang jauh. Empat kegagalan berbeda, empat pemilik berbeda, dan tidak satu pun didiagnosis dengan menatap formulir masuk.

Gunakan bukti yang dihasilkan setiap lapisan: panel jaringan peramban untuk status dan header, openssl s_client -connect host:443 untuk rantai sertifikat, penghitung SA dan log gerbang untuk lalu lintas terowongan, serta log aplikasi untuk keputusan akun. Ketika dua lapisan melaporkan kesalahan sekaligus, perbaiki yang lebih rendah lebih dulu, karena terowongan mati dapat dengan mudah menutupi kegagalan autentikasi dan sebaliknya.

Petakan satu layanan dari ujung ke ujung

Tulis lima baris untuk layanan yang Anda telusuri: pasangan mana yang dihubungkan terowongan, subjaring dan porta mana yang diizinkan pemilih, di mana TLS berakhir dan identitas mana yang dinyatakan sertifikat, akun dan peran aplikasi mana yang dipakai, dan di mana setiap lapisan mencatat log. Simpan pada satu halaman, karena inti peta adalah menunjukkan di mana tanggung jawab satu lapisan berakhir dan lapisan berikutnya dimulai.

Lalu uji satu kasus negatif per lapisan. Gunakan kata sandi salah dan pastikan Anda mendapat 401, bukan waktu tunggu. Hubungkan dari subjaring di luar pemilih dan pastikan paket tidak melewati terowongan. Tampilkan sertifikat untuk nama yang salah dan pastikan klien menolak sebelum mengirim kredensial. Ketiga hasil itu memberi tahu Anda lebih banyak tentang desain daripada diagram kotak mana pun.

Terakhir, putuskan dengan sengaja perlindungan apa yang dibutuhkan setiap hubungan. Autentikasi dasar di atas TLS adalah pilihan wajar untuk alat internal kecil di belakang gerbang; itu bukan pengganti otorisasi per pengguna atau perlindungan lalu lintas di luar titik akhir TLS. Terowongan melindungi jalur, sertifikat melindungi lompatan, dan 401 melindungi akun, dan hanya yang terakhir tahu siapa Anda.