Kesalahan Sertifikat SSL di Captive Portal

10

Situasi: Tamu hotel yang mencoba akses internet melalui portal captive kami. Masalah: Google, Yahoo dan sekarang semakin banyak situs mengarahkan semua halaman beranda ke HTTPS sehingga tamu mendapat kesalahan Sertifikat ketika kami mengarahkan mereka ke halaman login kami. Menghargai tujuan SSL adalah untuk melakukan hal ini tetapi bertanya-tanya apakah ada cara lain untuk mengelola log tamu pada proses konfirmasi untuk mengkonfirmasi identitas mereka, sebelum mengaktifkan akses melalui firewall. Ini membuat para tamu ketakutan yang tidak mengerti. Pada dasarnya memerlukan arsitektur yang berbeda untuk proses captive portal / otentikasi dan bertanya-tanya apa pikiran seseorang. Terima kasih.

ssl redirect

Solusi yang mungkin: WPA2-Enterprise dengan server otentikasi Radius.

— Ajedi32

Ini bukan solusi, tetapi untuk server saat ini sebagai solusi. Bolehkan pengguna untuk mengakses https secara bebas, dan pada klik http pertama, mereka akan dialihkan karena Industri semakin banyak bergerak ke https, ini akan menjadi usang.

— cusco

6

Seluruh definisi "captive portal" berputar di sekitar "mengarahkan ulang pengguna tanpa sepengetahuannya", yang merupakan salah satu hal yang harus dihindari SSL.

Jika URL pertama yang coba dibuka oleh browser adalah HTTPS, tidak ada cara untuk mengarahkan lalu lintas tanpa membuat kesalahan sertifikat.

— Massimo
sumber

4

Ya, saya pikir OP mengerti itu. Pertanyaannya adalah: apa alternatifnya? (Misalnya. Jika setiap situs yang ada menggunakan HTTPS, bagaimana Anda bisa "mengelola log tamu pada proses konfirmasi" tanpa portal captive?)

— Ajedi32

5

Proyek Chromium memiliki halaman bagus yang menjelaskan cara kerja logikanya untuk mendeteksi portal captive:

Coba sambungkan (HTTP biasa) ke host terkenal + URI
Mengharapkan HTTP 204 No Content
Jika respons berbeda diterima, anggap itu adalah captive portal.

Ada detail lain di tautan yang disediakan mengenai bagaimana mereka menangani kegagalan DNS ketika mencoba menyelesaikan host yang terkenal, dll. Ini hanya satu contoh, tetapi (dalam pengalaman pribadi saya) desain OS modern menggunakan proses yang mirip dengan ini untuk mendeteksi dan meminta pengguna bahkan, dalam beberapa kasus, sebelum pengguna membuka browser. (Pertimbangkan: seseorang yang hanya ingin menggunakan klien IMAP atau layanan non-HTTP lainnya.) Dalam hal itu, deteksi terjadi bukan melalui SSL / TLS sehingga kekhawatiran Anda dihindari.

RFC 6585 Bagian 6 mengusulkan kode status HTTP baru 511 Network Authentication Requiredyang tidak membantu kasus SSL / TLS Anda, tetapi merupakan standar lain yang dapat Anda pertimbangkan jika Anda belum menggunakannya.

— William Price
sumber

Android juga memiliki dukungan untuk mendeteksi portal captive. Ketika mendeteksi portal tawanan itu menampilkan pesan di bilah status. Kata-katanya seperti "Masuk ke jaringan nirkabel". Itu terjadi bahkan jika belum ada aplikasi yang mencoba menggunakan koneksi. Pada titik tertentu saya juga melihat portal captive mengirimkan redirect 30x dengan header HTTP tambahan, menunjukkan bahwa ini adalah captive portal, dan badan berisi beberapa data XML. Saya tidak tahu apakah itu merupakan perilaku standar.

— kasperd

0

Bagaimanapun, jika pengguna menerima kesalahan sertifikat adalah karena Sertifikat tidak cocok dengan nama host Situs .

Dalam kasus Anda, ini berarti Anda mengarahkan pengguna ke portal Anda tanpa mengubah URL. Pengguna melihat " http://www.google.com " di bilah alamat mereka tetapi portal Anda ada di layar. Ini tidak cocok, jelas, dan sertifikat tidak.

Anda perlu mengarahkan mereka di HTTP (sebelum HTTPS melompat) ke alamat portal Anda (atau nama server), minta mereka masuk di sana, dan kemudian arahkan kembali ke tujuan yang dituju, yang akan cocok dengan benar.

Lihat https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx untuk cara melakukannya dengan kode HTTP 3xx, khususnya 303.

— Envite
sumber

Sebagian besar pengguna mungkin tidak mengetik https:// , tetapi bookmark yang disimpan atau mekanisme pinning lainnya dapat mengakibatkan permintaan pertama pergi ke layanan berbasis HTTPS dan karenanya gagal karena handshaking TLS gagal sebelum mencapai lapisan protokol HTTP untuk pengalihan. Selain bookmark, contoh "menyematkan" seperti itu termasuk bilah pencarian browser yang memiliki pengetahuan sebelumnya bahwa penyedia pencarian lebih suka pertanyaan melalui HTTPS; atau aplikasi seluler yang terhubung ke layanan jaringan aman.

— William Harga

-1

solusi sementara adalah memandu pengguna untuk memulai URL yang dimulai dengan "http" hanya setelah sinyal wifi tersambung.

tetapi sayangnya, pengguna tidak menyukainya. mereka mengatakan "betapa rumitnya layanan wifi yang Anda miliki"

— versi satu
sumber