Arahkan https ke https lain


28

Saya telah mencari di Google untuk pertanyaan ini, dan ironisnya, saya tidak dapat menemukan jawaban konkret. Saya telah menjawab pertanyaan ini sendiri di masa lalu, dan sekarang saya tidak bisa mengingat penjelasan saya sendiri.

Beberapa kali setahun, seseorang akan meminta saya untuk melakukan ini. Saya ingin mengarahkan mereka ke semacam artikel terhormat yang menjelaskan hal ini.

Saya ingin mengambil URL di https://www.example.com/ dan mengarahkan lalu lintas ke https://www.example2.com/ .

Saya percaya ini harus memungkinkan secara teknis, tetapi tidak diinginkan. Apa yang salah dengan metode ini? Akankah browser mendapatkan popup keamanan karena saya mengarahkan mereka ke situs lain? Adakah yang bisa memberikan tautan ke beberapa dokumentasi terhormat yang menjelaskan hal ini?


4
Situasi Anda mungkin menjengkelkan, tetapi tidak ironis;)
Gareth

Jawaban:


17

Anda dapat melakukan ini, kedua situs harus memiliki sertifikat SSL yang valid. Dengan cara ini browser tidak akan memberikan pop-up keamanan. Namun jika kedua situs ada di server yang sama, kedua domain harus di-host dari alamat IP yang berbeda.

Server web melihat header "Host" di permintaan HTTP untuk melihat situs mana yang perlu dilayaninya. Negosiasi SSL terjadi sebelum permintaan HTTP dikirim, jadi pada saat itu server web tidak dapat memberi tahu situs web mana yang akan ditampilkan. Itu akan selalu mengirim sertifikat yang sama ke browser.

Ada dua cara untuk mengatasi ini:

  • Memiliki sertifikat wildcard untuk * .example.com, sehingga semua subdomain dapat berbagi sertifikat yang sama.
  • Jalankan setiap situs SSL di alamat IP yang berbeda. Dengan cara ini, server web mengetahui sertifikat SSL yang dapat dikirimkannya ke browser, dengan memeriksa alamat IP yang menerima koneksi yang masuk.

Perhatikan bahwa sangat mungkin untuk melampirkan beberapa alamat IP ke adaptor jaringan yang sama, hanya saja Anda memerlukan alamat IP kedua yang tersedia di ruang alamat IP Anda.

Pembaruan: Saat ini, Anda dapat menjalankan beberapa situs SSL dengan satu IP. Untuk mengaktifkan ini, konfigurasikan dukungan SNI di server web Anda. Sebagian besar browser modern (kecuali windows XP, dan Android 2) mendukung hal ini.


1
Anda juga dapat meng-host beberapa situs SSL pada IP yang sama di bawah Unified Communication Certificate (UCC), lihat help.godaddy.com/article/3908
ManiacZX

Satu solusi lain untuk masalah multi-hostname / satu sertifikat IP adalah dengan menggunakan nomor port alternatif. Ini tidak ideal, karena beberapa firewall / titik akses publik memblokir lalu lintas non 80/443.
Bryan Agee

5

Saya belum pernah mencoba ini jadi saya tidak berbicara dari pengalaman nyata, tetapi harus berhasil. Anda harus memiliki sertifikat SSL yang valid untuk https://www.example.com karena nama host dienkripsi di dalam header HTTP sehingga server Anda tidak akan tahu untuk mengarahkan ulang hingga didekripsi. Setelah itu harus diarahkan seperti permintaan HTTP normal.


2

Mengapa ini tidak diinginkan?

Sebagai contoh, Big Bank dan Little Bank menjalankan situs di https untuk memberi pelanggan perasaan aman yang bahagia. Big Bank membeli Little Bank. Pada titik tertentu orang-orang TI akan mengatur pengalihan untuk https://www.littlebank.com ke https://www.bigbank.com . Ini adalah alasan yang sah untuk mengalihkan dari https ke https.

Ini seharusnya bekerja dengan baik.


Skenario yang Anda jelaskan akan baik-baik saja, namun jika Anda menavigasi ke www.littlebank.com dan dialihkan ke www.bigbank.com sambil menyembunyikan alamat yang sebenarnya sehingga peramban masih menampilkan www.littlebank.com, itu tidak bagus benda. Ini cukup umum dengan situs-situs yang tidak aman di mana itu tidak relevan, tetapi tentunya Anda dapat melihat bahaya yang melekat dalam menampilkan diri Anda sebagai situs web aman yang sebenarnya tidak Anda miliki.
Charles

1

Satu putuskan yang saya pikir ada dalam tanggapan saat ini yang mungkin muncul untuk Anda adalah bahwa dalam keadaan apa pun, pengalihan yang benar (yaitu: peramban akan dicadangkan ke www.example2.com) akan baik-baik saja tetapi jika Anda menutupi ini sedemikian rupa sehingga peramban masih berpikir itu diarahkan ke www.example.com ketika pada kenyataannya Anda telah mengirimnya ke www.example2.com, ini adalah tempat Anda akan melihat peringatan keamanan justru karena Anda bisa mencoba menipu pengguna.

Versi singkatnya adalah redirect normal harus baik-baik saja, penyamaran alamat mungkin akan meninggalkan Anda dengan banyak penjelasan yang harus dilakukan.


Makasih Charles. Itu pasti situasi "yang tidak diinginkan" yang saya pikirkan.
Stefan Lasiewski

0

Seperti yang terlihat, masalah ini dapat diselesaikan pada lapisan transport. Katakanlah Anda memiliki catatan DNS A untuk example.com yang menunjuk ke 192.168.0.1. Ketika Anda mengetik https://example.com di browser, PC Anda membuat koneksi TCP ke server dengan IP 192.168.0.1, di mana beberapa proses mendengarkan pada port 443. Bagaimana jika pada saat yang sama server (yang tidak mencoba untuk masuk ke detail data yang dikirim melalui sesi TCP ini seperti memulai negosiasi SSL) membangun koneksi TCP ke 192.168.0.2 (server lain dengan DNS A example2.com menunjuk ke sana. HA proxy linux utulity diinstal pada server pertama mungkin menyelesaikan ini dengan konfigurasi seperti itu:

defaults
        log    global
        mode    tcp
        retries 2
        option redispatch
        option tcplog
        option tcpka
        option clitcpka
        option srvtcpka
        timeout connect 5s      
        timeout client  24h     #timeout client->haproxy(frontend)
        timeout server  60m

listen front443 192.168.0.1:443
    server back443 192.168.0.2:443

Tetapi ini akan menyebabkan kesalahan sertifikat SSL kecuali server web example2.com Anda akan menampilkan sertifikat SSL dengan CN = example2.com dan SAN = example.com, misalnya.

Atau Anda mungkin mengatur cakrawala DNS slpit ketika dari pengguna, misalnya, example.com dan example2.com memutuskan untuk 192.168.0.1.

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.