Drupal hosting dengan ssl

HTTPS adalah protokol yang menyulitkan permintaan HTTP dan jawapan mereka. Ini memastikan bahawa jika seseorang mampu untuk berkompromi rangkaian antara komputer anda dan pelayan yang anda minta daripada, mereka tidak akan dapat mendengar atau mengganggu komunikasi.

Apabila anda melawat laman web melalui HTTPS, URL kelihatan seperti ini: https://drupal.org/user/login. Apabila anda melawat laman web melalui biasa (tanpa enkrip) HTTP, ia kelihatan seperti ini: drupal.org/user/login.

Mengapa ia penting kepada anda (dan apabila)

HTTPS biasanya digunakan dalam situasi di mana pengguna akan menghantar maklumat sensitif kepada laman web dan pemintasan maklumat yang akan menjadi masalah. Biasanya, maklumat ini termasuk:

• Kad kredit
• cookies sensitif seperti PHP sesi cookies
• Kata Laluan dan Nama pengguna
• maklumat pengenalan (nombor Keselamatan Sosial, nombor ID Negeri, dan lain-lain)
• kandungan sulit

Terutamanya dalam situasi di mana anda, sebagai pentadbir, menghantar kata laluan Drupal atau kata laluan FTP untuk pelayan anda, anda perlu menggunakan HTTPS seboleh mungkin untuk mengurangkan risiko menjejaskan laman web anda.

HTTPS juga boleh menghalang eavesdroppers daripada mendapatkan kunci sesi disahkan anda, yang merupakan cookie dihantar dari pelayar anda dengan setiap permintaan untuk laman web ini, dan menggunakannya untuk menyamar sebagai anda. Sebagai contoh, penyerang boleh mendapat akses pentadbiran ke laman web ini jika anda seorang pentadbir laman mengakses laman web ini melalui HTTP dan bukannya HTTPS. Ini dikenali sebagai sesi rampasan dan boleh dicapai dengan alat seperti Firesheep.

Keselamatan adalah keseimbangan. Berkhidmat HTTPS kos lalu lintas lebih dalam sumber daripada permintaan HTTP (kedua-dua pelayan dan web pelayar) dan kerana ini, anda mungkin ingin menggunakan campuran HTTP / HTTPS mana pemilik laman web boleh membuat keputusan yang halaman atau pengguna perlu menggunakan HTTPS.

Bagaimana untuk membolehkan sokongan HTTPS dalam Drupal

1. Mendapat sijil. Banyak pembekal hosting menetapkan ini untuk anda - sama ada secara automatik atau dengan dikenakan bayaran. Anda juga boleh menggunakan Mari Encrypt yang bebas, automatik, dan membuka Sijil Kuasa. Jika anda ingin mendapatkan tapak ujian, maka anda boleh menjana sijil ditandatangani sendiri.
2. Mengkonfigurasi pelayan web anda. Beberapa pautan yang berguna:
3. arahan Apache.
4. arahan Nginx
5. Arahan Ubuntu

Kemungkinan, hosting anda boleh melakukan ini untuk anda jika anda menggunakan kongsi atau diuruskan hosting.

Nota: URL Clean Jika anda menggunakan Apache HTTP dan HTTPS:

Anda mungkin akan mempunyai dua baldi Virtual berbeza.

1. A baldi untuk port: 80 http
2. A baldi untuk port: 443 https

Setiap bekas Virtual atau baldi memerlukan arahan Apache tertentu ditambah dalam diri mereka jika anda menggunakan URL Bersih. Ini kerana Drupal menggunakan banyak .htaccess dan mod_rewrite untuk menyediakan URL friendly.

Pastikan anda mempunyai yang berikut dalam arahan itu, yang merupakan anak berusia bawah bekas Virtual itu: Lihat Apache Dokumentasi untuk AllowOverride

Ini bermakna bahawa .htaccess anda keutamaan dan konfigurasi Apache akan membolehkan ia berjalan seperti yang anda inginkan untuk Drupal.

Penyelesaian masalah:
Jika anda telah mendayakan HTTPS dan ia hanya berfungsi pada laman utama dan pautan sub anda yang dipecahkan, ia adalah kerana Virtual: baldi 443 memerlukan AllowOverride Semua dibolehkan supaya URL boleh ditulis semula semasa dalam mod HTTPS.

Pada Drupal 7, jika anda mahu menyokong bercampur-mod HTTPS dan sesi HTTP, membuka tapak / default / settings.php dan menambah $ conf [ 'https'] = TRUE ;. Ini membolehkan anda menggunakan sesi yang sama atas kedua-dua HTTP dan HTTPS - tetapi dengan dua cookies mana cookie HTTPS yang dihantar melalui HTTPS sahaja. Anda akan perlu menggunakan modul menyumbang seperti securepages berbuat apa-apa yang berguna dengan mod ini, seperti mengemukakan borang melalui HTTPS. Manakala HTTP anda cookie masih terdedah kepada semua serangan biasa. Kuki sesi tidak selamat dirampas hanya boleh digunakan untuk mendapatkan akses disahkan kepada tapak HTTP, dan ia tidak akan sah di laman web HTTPS. Sama ada ini adalah masalah atau tidak bergantung kepada keperluan laman web anda dan pelbagai konfigurasi modul. Sebagai contoh, jika semua bentuk ditetapkan melalui HTTPS dan pengunjung anda boleh melihat maklumat yang sama seperti log masuk pengguna, ini tidak menjadi masalah.

Perhatikan bahawa dalam Drupal 8, sokongan bercampur-mod telah dikeluarkan # 2.342.593: Buang sokongan SSL campuran dari teras.

Untuk keselamatan yang lebih baik, menghantar semua trafik disahkan melalui HTTPS dan menggunakan HTTP untuk sesi tanpa nama. Pada Drupal 8, memasang Secure modul Login yang membuat ketetapan amaran bercampur kandungan. Pada Drupal 7, meninggalkan $ conf [ 'https'] pada nilai lalai (FALSE) dan memasang Secure Login. Drupal 7 dan 8 secara automatik membolehkan konfigurasi session.cookie_secure PHP pada tapak HTTPS, yang menyebabkan SSL sahaja cookies sesi selamat untuk dikeluarkan kepada pelayar. Pada Drupal 6, lihat modul menyumbang 443 Sesyen dan Secure Login.

Untuk keselamatan terbaik, menubuhkan laman web anda untuk hanya menggunakan HTTPS, dan bertindak balas kepada semua permintaan HTTP dengan redirect ke laman web HTTPS anda. Drupal 7 ini $ conf [ 'https'] boleh dibiarkan pada nilai lalai (FALSE) di laman web yang tulen HTTPS. Walaupun begitu, HTTPS terdedah kepada serangan man-in-the-middle jika sambungan bermula sebagai sambungan HTTP sebelum diarahkan ke HTTPS. Menggunakan modul HSTS atau Security modul Kit. atau menetapkan header-Transport-Security ketat dalam pelayan web anda, dan menambah domain anda kepada pelayar HSTS senarai spring itu. untuk membantu menghalang pengguna daripada mengakses laman web ini tanpa HTTPS.

Anda mungkin mahu mengubah hala semua lalu lintas dari example.com dan www.example.com untuk https://example.com. Anda boleh melakukan ini dengan menambah kod di bawah pada fail konfigurasi pelayan anda, iaitu takrif Virtual:

Penggunaan RewriteRule akan sesuai jika anda tidak mempunyai akses ke fail konfigurasi pelayan utama, dan wajib untuk melaksanakan tugas ini dalam fail .htaccess sebaliknya:

Terdapat komen yang sedia ada dalam .htaccess yang menerangkan bagaimana untuk mengarahkan example.com untuk www.example.com (dan sebaliknya), tetapi kod ini di sini pelencongan kedua-dua mereka untuk https://example.com.

bjdeliduka mengulas 27 Februari 2015 pada 21:25

Sebagai mata pelajaran itu berkata. yang Joys.

Seorang pelanggan saya mempunyai banyak pelanggan dengan Drupal 7 sites. Kami bergerak semua dari mereka CloudFlare (www.cloudflare.com) kita mereka menawarkan CERT PERCUMA SSL, caching web, dan ddos ​​perlindungan / pengurangan. Kami kemudian firewall pelayan untuk hanya menerima sambungan dari CF Cache dan memastikan bahawa HTTP Server sebenar tidak disenaraikan di DNS (pelanggan / pelayar harus menyambung kepada Pelayan CF yang kemudiannya akan mengambil halaman daripada pelayan sebenar). Drupal Server (apache 2.4 pada CentOS) juga menggunakan SSL untuk menyulitkan sambungan antara CF dan pelayan (mungkin juga menjaga segala-galanya daripada teks biasa)

Walaupun kelihatan di atas dan berasa seperti satu penyelesaian yang bagus untuk menginsuranskan semua sambungan disulitkan kami menghadapi masalah dengan beberapa halaman yang mempunyai IFRAMES yang memuatkan kandungan disulitkan. (Pelayar web membuang ralat apabila ini berlaku dan sering menolak untuk memuatkan kandungan tanpa campur tangan pengguna).

Pilihan yang termasuk 1) menubuhkan proksi dan menyulitkan kandungan yang tidak selamat. Dari segi teknikal mungkin ia memberi pengguna gambaran sesi adalah selamat manakala sebahagian daripada kandungan adalah dalam teks biasa (walaupun tidak ke / dari pelanggan). 2) melepaskan kandungan sehingga ia boleh didapati melalui sambungan selamat (klien / pelanggan tidak suka pilihan ini) 3) muka surat kuasa yang mengandungi kandungan ini menjadi tak disulitkan (http) sambungan manakala yang lain daripada tapak tersebut disulitkan.

Kami memilih pilihan 3.

Laman web yang telah sebelum ini dikonfigurasikan untuk mengalihkan sambungan ke https menggunakan peraturan tulis semula dalam fail .htaccess (mungkin akan bergerak ini ke dalam fail config vhost atas sebab-sebab prestasi tetapi hanya jika kita boleh bersetuju mengenai melumpuhkan fail .htaccess) Oleh itu setiap http sambungan menjadi sambungan https.

Biasanya rewriterule yang boleh diwujudkan dalam bentuk:

untuk menangkap sambungan ke halaman dengan iframe yang tidak selamat. (Menulis semula hampir sama http dan bukan yang hampir sama untuk https)

cuba ini dengan bersih ini url yang aktif dan anda tidak mendapatkan halaman yang tak disulitkan kerana setiap permintaan halaman dikemukakan kepada drupal tidak lulus akhir melalui enjin tulis semula pada /index.php.

Saya tidak pasti sebab sebenar tetapi secure_pages tidak dianggap sebagai pilihan yang berdaya maju.

Penyelesaian Hasilnya adalah satu siri 13 rewriterule garis / rewritecond yang berkesan boleh menggantikan modul secure_pages untuk memaksa semua tetapi (1 atau lebih) muka untuk sambungan https segelintir.

/ Streaming-Page dan halaman akar laman web ini adalah HTTP sepanjang laman web ini adalah HTTPS. halaman tambahan boleh dikecualikan daripada HTTPS dengan menambah orang seperti tambahan di bawah line / Streaming-Page berikut ia format.

Satu-satunya sampingan yang diketahui menjejaskan kod ini ialah penyuntingan halaman yang disulitkan adalah lebih rumit kerana admin_menu jatuh pada halaman tanpa enkrip. Versi 1.1 akan termasuk kaedah melumpuhkan sebelah http dari pelayar pelanggan (menyebabkan kesilapan pelayar bahawa pemaju akan menangani seperti yang diperlukan semasa mengedit halaman) Saya juga akan melihat satu arahan yang lebih terperinci mengenai meletakkan ini ke dalam fail .htaccess dan menghapuskan yang tidak diingini / kod yang tidak diperlukan untuk perkara seperti www. pelucutan (atau pra-pending) dan lain-lain

selinav mengulas 25 April 2017 pada 09:51

Bairnsfather mengulas 26 April 2017 pada 17:29

Saya telah sangat gembira dengan https://www.drupal.org/project/securepages untuk masa yang lama. Hanya memuatkan halaman konfigurasi dan meletakkan asterisk dalam bidang yang mana halaman yang anda mahu selamat, iaitu semua. Saya rasa amaran di bahagian atas laman projek ini adalah basi; Saya telah menggunakan modul tanpa patch atau mengubah suai .htaccess saya untuk keluaran 7.x kebelakangan. Semak settings.php anda dan pastikan ubah base_url mengandungi https, tidak http.

[Sunting] Tetapi jangan mengambil ini sebagai kata-kata terakhir kepada kaedah yang kini terbaik untuk mengalihkan semua lalu lintas ke https hari ini. Berdasarkan bacaan baru-baru ini, ia seolah-olah HSTS adalah di mana perkara-perkara yang diketuai.

Bairnsfather mengulas 9 Mei 2017 pada 17:30

Berikut adalah apa yang aku yang seolah-olah bekerja untuk D7 D8 (khususnya pada 7.54 8.3.1 pada Apache 2.4.5 dengan php 5.6.30) menggunakan fail saham .htaccess dengan hanya pengubahsuaian yang dinyatakan di bawah. Dalam bahasa yang mudah,-Transport-Security ketat baris tidak akan pada mulanya mengarahkan lalu lintas dari http kepada https. (Line Yang tidak dilihat pada permintaan http dan pelayar lama tidak memahaminya.) Oleh itu kepentingan dalam redirection dengan RewriteRule a; Walau bagaimanapun, yang meninggalkan membuka kemungkinan serangan MITM. Tetapi harapan adalah dengan DNSSEC dan pelayar moden yang memahami HSTS, dalam masa kurang daripada satu saat penyemak imbas anda akan ingat (untuk saat max-umur) hanya permintaan https sumber, walaupun tapak anda atau tapak lain mempunyai pautan http / sumber pada ia. Dalam erti kata lain apabila pelayar web moden anda memuatkan halaman melalui https daripada laman anda, pelayar belajar ia harus ketat dan hanya membuat https permintaan, walaupun ia menemui seorang http sumber atau link menyatakan.

Pertama, pastikan anda mempunyai pelayan anda tersedia melalui https dan sijil anda termasuk semua subdomain yang anda gunakan. Max-umur adalah dalam beberapa saat, menyesuaikan ia untuk keperluan anda, dan pastikan anda membaca (sekurang-kurangnya) https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security (link RFC di bawah.)

Di bawah garis:

Kemudian meletakkan # di hadapan tiga baris di bawah untuk komen mereka keluar; ia tidak lagi boleh digunakan kerana kita hanya memaksa semua lalu lintas ke https. Baris berikut sudah dalam fail .htaccess dan hanya di bawah apa yang anda ditampal dalam.

Perhatikan juga https://www.drupal.org/project/hsts HSTS modul mempunyai versi untuk D7 D8. Yang baik jika anda menjalankan multisite dan tidak semua domain mempunyai sijil.

Anda boleh menguji perkara dengan membuka aplikasi terminal anda dan curl -I domain anda dalam pelbagai cara untuk memeriksa pengepala.

Artikel berkaitan

2013-07-23 13:22 EST Terima kasih kerana soalan! Ya, anda boleh menggunakan sijil SSL dikongsi. Sijil SSL Shared adalah pratetap, jadi tidak ada konfigurasi dilakukan di sebelah pelayan. Sila ...

Dalam WordPress, anda boleh meletakkan kandungan pada laman web anda sama ada sebagai "post" atau "halaman". Apabila anda menulis entri blog biasa, anda menulis catatan. Jawatan, dalam persediaan lalai, muncul secara terbalik ...

Nota: terima kasih khas tambahan untuk Doug Vann untuk memberikan motivasi untuk akhirnya hantar post blog ini! Pada awal 2016, apabila API Carian dan modul Solr berkaitan untuk Drupal 8 adalah pada awal alpha ...

Pengenalan An pelaksanaan carian yang berkesan adalah salah satu tugas yang paling sukar dalam pembangunan, tetapi ia juga kunci kepada kejayaan banyak laman web dan aplikasi. Satu carian pantas dan ...

Saya sedang mewujudkan arkib laman web yang akan membolehkan pengguna untuk memuat naik pelbagai jenis kandungan media termasuk video, audio, imej, dokumen dan teks. Saya mahu menjadikan ia mudah bagi pengguna untuk ...