Dapatkah saya mendeteksi jika klien SSL tidak mendukung Indikasi Nama Server dan menyediakan situs web HTTP standar dalam kasus itu?


8

Saya perlu menggunakan SSL SNI, tapi sayangnya dari blogpost Cloudflare baru-baru ini hanya 90% dari jaringan mendukungnya. Bagaimana saya (misalnya, dengan nginx) dapat mendeteksi jika klien mendukung SNI dan menyediakan / mengalihkan ke versi HTTP situs web? Apakah ini mungkin? Bagaimana lagi saya tidak bisa kehilangan 10% dari lalu lintas menggunakan SNI? Apakah benar untuk berasumsi bahwa saya tidak akan dapat mengarahkan lalu lintas HTTPS ke HTTP tanpa sertifikat yang valid, dan dengan demikian permintaan ini tidak mungkin?

Terima kasih.


Pertanyaan yang berhubungan erat diajukan di sini: Redirect ke SSL hanya jika browser mendukung SNI
Simon East

Jawaban:


10

Jika Anda ingin menawarkan HTTPS dari awal, Anda harus memberikan sertifikat yang diterima oleh klien dari awal. Karena jika tidak, klien tidak akan menerima koneksi SSL dan Anda tidak akan dapat mengarahkan klien ke situs lain atau versi HTTP-only. Ini berarti untuk mendukung hal ini Anda

  • Anda harus memiliki satu sertifikat yang berisi semua domain Anda, sehingga Anda dapat memberikan sertifikat yang tepat kepada klien non-SNI. Tetapi dalam hal ini Anda tidak perlu SNI sama sekali.
  • atau Anda harus menginstal beberapa sertifikat default yang tidak cocok dengan sebagian besar nama Anda. Dalam hal ini Anda hanya dapat memberikan halaman berbeda kepada klien atau mengalihkannya jika klien menerima sertifikat buruk ini.

Jika Anda tidak perlu memiliki HTTPS dari awal, yaitu jika klien biasanya terhubung terlebih dahulu dengan HTTP biasa, maka Anda dapat mencoba mendeteksi dukungan SNI sehingga Anda dapat mengarahkan klien nanti. Ini dapat dilakukan dengan memasukkan gambar, beberapa JavaScript atau hal serupa dari situs HTTPS Anda dan jika pemuatan berhasil maka Anda tahu bahwa klien mendukung SNI atau mengabaikan kesalahan sertifikat.

Tentu saja ini membuat segalanya terbuka untuk serangan man-in-the-middle, karena yang harus dilakukan man-in-the-middle adalah melayani beberapa sertifikat berbeda atau membuat HTTPS tidak tersedia sama sekali, karena dalam hal ini Anda tidak akan pernah mencoba untuk memutakhirkan koneksi ke HTTPS. Selain itu ini dapat digunakan untuk membuatnya terlihat seperti klien mendukung SNI, jika man-in-the-middle yang melakukannya. Dan bukan hanya klien non-SNI yang terpengaruh oleh hal ini, tetapi klien berkemampuan SNI hanya dapat disadap. Jadi sementara ini mungkin dalam teori itu tidak dianjurkan karena Anda bisa mengatur semuanya dan dengan demikian membuat titik utama menggunakan HTTPS moot.


0

Seperti yang saya posting di StackOverflow , Anda hanya dapat menguji dukungan SNI sebelum memerlukannya. Artinya, Anda tidak dapat memaksa pengguna ke SNI HTTPS dan kemudian mundur jika mereka tidak mendukungnya, karena mereka akan menerima kesalahan seperti ini (dari Chrome di Windows XP) tanpa jalan untuk melanjutkan.

Jadi (sayangnya) pengguna harus benar-benar memulai koneksi HTTP yang tidak aman dan kemudian ditingkatkan hanya jika mereka mendukung SNI.

Anda dapat mendeteksi dukungan SNI melalui:

  1. Skrip jarak jauh
    Dari halaman HTTP biasa Anda, muat a <script>dari server HTTPS SNI tujuan Anda dan jika skrip dimuat dan berjalan dengan benar, Anda tahu browser mendukung SNI.

  2. Cross-Domain AJAX (CORS)
    Mirip dengan opsi 1, Anda dapat mencoba melakukan permintaan AJAX lintas-domain dari halaman HTTP ke HTTPS, tetapi perlu diketahui bahwa CORS hanya memiliki dukungan browser yang terbatas .

  3. Menghirup agen-pengguna
    Ini mungkin metode yang paling tidak dapat diandalkan, dan Anda harus memutuskan antara memiliki daftar hitam peramban (dan sistem operasi) yang diketahui tidak mendukungnya, atau daftar putih dari sistem yang dikenal yang melakukannya.

    Kita tahu bahwa semua versi IE, Chrome & Opera di Windows XP dan di bawahnya tidak mendukung SNI. Lihat CanIUse.com untuk daftar lengkap browser yang didukung .

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.