Memilih domain mana yang akan diamankan

Kami memiliki situs web yang dilayani keduanya www.example.comdan hanya example.com- kami belum pernah melakukan pemaksaan memaksa pengguna dari satu domain ke domain lainnya, jadi jika mereka mendarat example.commaka di situlah mereka tinggal, dan saya menduga bahwa yang mem-bookmark halaman kita akan sekitar 50/50 split (ada masalah sebelumnya di mana beberapa materi kita menghilangkan WWW dan bertahun-tahun kemudian kita masih melihat split lalu lintas).

Kami sekarang menambahkan SSL. Kami tidak memaksa SSL sampai pengguna membuka halaman login atau register. Di domain mana kita harus menjalankan SSL?

www.example.com
example.com
secure.example.com
Sesuatu yang lain

Saya telah melakukan banyak situs SSL sebelumnya, tetapi mereka selalu dirancang dengan mempertimbangkan SSL, dan kami selalu memaksa subdomain www.

Apakah ada pro dan kontra melakukannya dengan cara-cara itu? Perhatian utama saya adalah tentang pengenalan cookie, tetapi karena kami memaksa SSL saat masuk, cookie sesi akan tetap ditulis di domain SSL'd. Perhatian utama saya adalah untuk orang-orang yang mungkin mengunjungi https://example.comketika kami menjalankan situs https://www.example.com, dll.

_{Pertanyaan lain adalah, "Haruskah saya menulis ulang mereka yang mendarat di situs non-www ke situs WWW?}

— Mark Henderson
sumber

Bergantung pada siapa Anda membeli sertifikat Anda, mereka mungkin memberi Anda domain telanjang sebagai nama pengganti subjek secara gratis. Jadi, jika Anda membeli, www.example.comAnda mungkin mendapatkan sertifikat yang mencakup keduanya www.example.comdan example.com.

— Michael Hampton

Jawaban:

Saya biasanya ikut secure.domain.comkarena memberi saya lebih banyak fleksibilitas sejauh administrasi. Sebagai contoh, saya bisa meletakkan subdomain itu di server lain, di belakang beberapa gigi IDS / IPS yang lebih baik dan mungkin melampirkannya ke jaringan pribadi yang saya tidak ingin server web menyentuh.

Ini adalah tempat yang baik untuk memarkir berbagai keperluan, seperti:

secure.domain.com/checkout/
secure.domain.com/portal/
secure.domain.com/support/

... dll.

— Pos Tim
sumber

Apakah Anda pernah memiliki masalah dengan cookie? Misalnya jika cookie dibuat di www.example.com, apakah Anda dapat membacanya dari secure.example.com?

— Mark Henderson

@Farseeker: Anda dapat mengatur cookie untuk .example.com(atau example.com, yang sama), dan itu akan berfungsi untuk www.example.com dan secure.example.com (dengan kekurangannya, cookie akan selalu dikirim ke kedua subdomain) . Inilah halaman favorit saya tentang topik ini: code.google.com/p/browsersec/wiki/…

— Chris Lercher

@Farseeker - Ya, cookie menyebar ke subdomain, namun jika Anda sedikit pintar, itu bukan masalah. Sebagai contoh, cookie-> login_in / connection-> ssl, dll. Ini tidak seperti CDN di mana ketidakhadiran mereka menguntungkan, mereka hanya harus direncanakan dan dikelola.

— Tim Post

@ Chris, saya tidak tahu Anda dapat mengatur cookie example.comdari www.example.com- saya harus melihat ke dalam ini. Terima kasih.

— Mark Henderson

Dengan solusi ini, Anda juga dapat menolak secure.example.com di robots.txt Anda. Jadi +1. :-)

— fwaechter

Secara pribadi saya hanya menggunakan sertifikat SSL Plus DigiCert dengan melakukan dengan example.com dan www.example.com. Seperti dalam pertanyaan Anda yang lain, saya masih akan mengirim semua orang ke www.example.com karena itu membuat hidup lebih mudah di kemudian hari. Melakukan ini sekarang, juga akan memberi Anda kesempatan untuk menggunakan sesuatu seperti secure.example.com nanti.

Saya biasanya menambahkan kode untuk mendeteksi apakah pengguna menjalankan HTTP saat mereka seharusnya menjalankan HTTPS dan mengarahkan mereka. Saya menemukan ini biasanya hanya terjadi selama login, tetapi tergantung pada situs, itu bisa terjadi di lain waktu juga.

— Darryl Hein
sumber