Mengaktifkan HTTPS di server Anda

Chris Palmer
Chris Palmer

Langkah-langkah yang dibahas dalam artikel ini

  1. Buat pasangan kunci publik/pribadi RSA 2048-bit.
  2. Buat permintaan penandatanganan sertifikat (CSR) yang menyematkan kunci publik Anda.
  3. Bagikan CSR Anda kepada Certificate Authority (CA) untuk menerima sertifikat final atau rantai sertifikat.
  4. Instal sertifikat final Anda di tempat yang dapat diakses selain web seperti /etc/ssl (Linux dan Unix) atau di mana pun yang diperlukan oleh IIS (Windows).

Membuat kunci dan permintaan penandatanganan sertifikat

Bagian ini menggunakan program command line openssl, yang biasanya disertakan di sebagian besar sistem Linux, BSD, dan Mac OS X, untuk membuat kunci pribadi/publik dan CSR.

Membuat pasangan kunci publik/pribadi

Mari kita mulai dengan membuat pasangan kunci RSA 2048-bit. Kunci yang lebih kecil, seperti 1.024 bit, tidak cukup tahan terhadap serangan tebakan brute force. Kunci yang lebih besar, misalnya 4.096 bit, terlalu berlebihan. Seiring waktu, ukuran kunci meningkat karena pemrosesan komputer semakin murah. 2.048 saat ini sudah tepat.

Perintah untuk membuat pasangan kunci RSA adalah:

openssl genrsa -out www.example.com.key 2048

Tindakan ini akan menghasilkan output berikut:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Membuat permintaan penandatanganan sertifikat

Pada langkah ini, Anda menyematkan kunci publik dan informasi tentang organisasi dan situs Anda ke dalam permintaan penandatanganan sertifikat atau CSR. Perintah openssl secara interaktif akan meminta metadata yang diperlukan kepada Anda.

Menjalankan perintah berikut:

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

Menghasilkan hal berikut:

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Untuk memastikan validitas CSR, jalankan perintah ini:

openssl req -text -in www.example.com.csr -noout

Dan responsnya akan terlihat seperti ini:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

Kirimkan CSR Anda ke certificate authority

Otoritas sertifikat (CA) yang berbeda memerlukan metode yang berbeda untuk mengirimkan CSR Anda. Metode dapat mencakup penggunaan formulir di situs mereka, pengiriman CSR melalui email, atau metode lainnya. Beberapa CA (atau reseller-nya) bahkan dapat mengotomatiskan sebagian atau semua prosesnya (termasuk, dalam beberapa kasus, pasangan kunci dan pembuatan CSR).

Kirim CSR ke CA Anda, dan ikuti petunjuknya untuk menerima sertifikat final atau rantai sertifikat Anda.

CA yang berbeda mengenakan biaya yang berbeda pula untuk layanan penjaminan kunci publik Anda.

Ada juga opsi untuk memetakan kunci Anda ke lebih dari satu nama DNS, termasuk beberapa nama yang berbeda (misalnya semua example.com, www.example.com, example.net, dan www.example.net) atau nama "karakter pengganti" seperti *.example.com.

Misalnya, satu CA saat ini menawarkan harga berikut:

  • Standar: $16/tahun, berlaku untuk example.com dan www.example.com.
  • Karakter pengganti: $150/tahun, valid untuk example.com dan *.example.com.

Dengan harga ini, sertifikat karakter pengganti akan ekonomis jika Anda memiliki lebih dari 9 subdomain; jika tidak, Anda hanya dapat membeli satu atau beberapa sertifikat nama tunggal. (Jika memiliki lebih dari lima subdomain, misalnya, Anda mungkin merasa sertifikat karakter pengganti lebih praktis jika Anda mengaktifkan HTTPS di server.)

Salin sertifikat ke semua server front-end Anda di tempat yang dapat diakses selain web seperti /etc/ssl (Linux dan Unix) atau di mana pun yang diperlukan oleh IIS (Windows).

Mengaktifkan HTTPS di server

Mengaktifkan HTTPS di server Anda merupakan langkah penting dalam memberikan keamanan bagi halaman web Anda.

  • Gunakan alat Server Configuration dari Mozilla untuk menyiapkan server bagi dukungan HTTPS.
  • Uji situs Anda secara rutin dengan SSL Server Test yang praktis dari Qualys dan pastikan Anda mendapatkan setidaknya A atau A+.

Pada tahap ini, Anda harus membuat keputusan operasi yang sangat penting. Pilih salah satu opsi berikut:

  • Khususkan alamat IP berbeda ke setiap nama host yang digunakan server web Anda.
  • Menggunakan hosting virtual berbasis nama.

Jika telah menggunakan alamat IP berbeda untuk setiap nama host, Anda dapat mendukung HTTP dan HTTPS dengan mudah untuk semua klien.

Namun, sebagian besar operator situs menggunakan hosting virtual berbasis nama untuk menghemat alamat IP dan karena lebih praktis secara umum. Masalah pada IE di Windows XP dan Android sebelum versi 2.3 adalah tidak adanya pemahaman tentang Server Name Indication (SNI), yang sangat penting untuk hosting virtual berbasis nama HTTPS.

Suatu hari — mudah-mudahan segera — klien yang tidak mendukung SNI akan diganti dengan software modern. Pantau string agen pengguna di log permintaan untuk mengetahui kapan populasi pengguna Anda telah cukup banyak yang bermigrasi ke software modern. (Anda dapat menentukan nilai minimum; mungkin kurang dari 5%, atau kurang dari 1%.)

Jika belum memiliki layanan HTTPS yang tersedia di server Anda, aktifkan layanan tersebut sekarang (tanpa mengalihkan HTTP ke HTTPS; lihat di bawah). Konfigurasikan server web Anda untuk menggunakan sertifikat yang telah Anda beli dan instal. Anda mungkin merasa bahwa pembuat konfigurasi praktis di Mozilla bisa berguna.

Jika Anda memiliki banyak nama host atau subdomain, masing-masing harus menggunakan sertifikat yang tepat.

Sekarang, dan sepanjang masa pakai situs, periksa konfigurasi HTTPS dengan SSL Server Test praktis dari Qualys. Situs Anda harus mendapatkan skor A atau A+; perlakukan apa pun yang menyebabkan nilai lebih rendah sebagai bug. (Hari ini A adalah B besok, karena serangan terhadap algoritma dan protokol selalu berkembang)

Menjadikan URL intrasitus relatif

Karena sekarang Anda menayangkan situs di HTTP dan HTTPS, semuanya harus berfungsi selancar mungkin, apa pun protokolnya. Faktor penting adalah menggunakan URL relatif untuk link intrasitus.

Pastikan URL intrasitus dan URL eksternal tidak bergantung pada protokol; yaitu, pastikan Anda menggunakan jalur relatif atau jangan sertakan protokol seperti //example.com/something.js.

Masalah akan muncul saat Anda menayangkan halaman melalui HTTPS yang menyertakan resource HTTP, yang dikenal sebagai konten campuran. Browser memperingatkan pengguna bahwa kekuatan penuh HTTPS telah hilang. Bahkan, untuk konten campuran aktif (skrip, plugin, CSS, iframe), browser sering kali tidak mau memuat atau mengeksekusi konten sama sekali, sehingga mengakibatkan halaman rusak. Dan ingat, tidak masalah untuk menyertakan resource HTTPS di halaman HTTP.

Selain itu, jika Anda membuat link ke halaman lain di situs Anda, pengguna dapat mengalami downgrade dari HTTPS ke HTTP.

Masalah ini terjadi saat halaman Anda menyertakan URL intrasitus yang sepenuhnya memenuhi syarat yang menggunakan skema http://.

Larangan
<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
Hindari penggunaan URL intrasitus yang sepenuhnya memenuhi syarat.

Dengan kata lain, buat URL intrasitus serelatif mungkin: baik berupa protokol-relatif (tidak memiliki protokol, dimulai dengan //example.com) atau host-relatif (dimulai dengan jalur saja, seperti /jquery.js).

Anjuran
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24/">new post on cats!</a></p>
Gunakan URL intrasitus relatif.
Anjuran
<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
Atau, gunakan URL intrasitus protokol-relatif.
Anjuran
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24/">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
Gunakan URL HTTPS untuk URL antarsitus (jika memungkinkan).

Lakukan hal ini dengan skrip, bukan dengan cara manual. Jika konten situs Anda ada dalam database, uji skrip Anda pada salinan pengembangan database Anda. Jika konten situs Anda terdiri dari beberapa file sederhana, uji skrip Anda pada salinan pengembangan file. Kirim perubahan ke produksi hanya setelah perubahan tersebut lulus QA, seperti biasa. Anda dapat menggunakan skrip Bram van Damme atau yang serupa untuk mendeteksi konten campuran di situs.

Saat menautkan ke situs lain (bukan menyertakan sumber daya dari sana), jangan ubah protokol karena Anda tidak memiliki kontrol atas cara beroperasi situs tersebut.

Agar migrasi berjalan lebih lancar bagi situs besar, sebaiknya gunakan URL protokol-relatif. Jika Anda belum yakin apakah dapat men-deploy HTTPS sepenuhnya, memaksa situs Anda menggunakan HTTPS untuk semua sub-resource dapat merugikan. Mungkin ada masanya Anda baru menggunakan HTTPS, dan situs HTTP akan tetap berfungsi sebaik mungkin. Seiring waktu, Anda akan menyelesaikan migrasi dan mengunci HTTPS (lihat dua bagian berikutnya).

Jika situs Anda bergantung pada skrip, gambar, atau resource lain yang disalurkan dari pihak ketiga, seperti CDN atau jquery.com, Anda memiliki dua opsi:

  • Gunakan URL protokol-relatif untuk resource ini. Jika pihak ketiga tidak menayangkan HTTPS, minta mereka melakukannya. Sebagian besar sudah melakukannya, termasuk jquery.com.
  • Sajikan resource dari server yang Anda kontrol, dan yang menawarkan HTTP dan HTTPS. Ini sering kali merupakan ide yang bagus, karena selanjutnya Anda memiliki kontrol yang lebih baik atas tampilan, performa, dan keamanan situs Anda. Selain itu, Anda tidak perlu mempercayai pihak ketiga, walaupun biasanya hal itu bagus.

Mengalihkan HTTP ke HTTPS

Anda perlu menempatkan link kanonis di bagian atas halaman untuk memberi tahu mesin telusur bahwa HTTPS adalah cara terbaik untuk membuka situs Anda.

Tetapkan tag <link rel="canonical" href="https://…"/> di halaman Anda. Hal ini membantu mesin telusur menentukan cara terbaik menuju situs Anda.

Aktifkan Strict Transport Security dan cookie aman

Pada tahap ini, Anda siap untuk "mengunci" penggunaan HTTPS.

  • Gunakan HTTP Strict Transport Security (HSTS) untuk menghindari biaya pengalihan 301.
  • Selalu setel flag Aman pada cookie.

Pertama, gunakan Strict Transport Security untuk memberi tahu klien bahwa mereka harus selalu terhubung ke server Anda melalui HTTPS, bahkan saat mengikuti referensi http://. Tindakan ini akan mengalahkan serangan seperti SSL Stripping, dan juga menghindari biaya bolak-balik 301 redirect yang kita aktifkan di Mengalihkan HTTP ke HTTPS.

Aktifkan HTTP Strict Transport Security (HSTS) dengan menyetel header Strict-Transport-Security. Halaman HSTS milik OWASP memiliki link ke petunjuk untuk berbagai software server.

Sebagian besar server web menawarkan kemampuan yang serupa untuk menambahkan header kustom.

Penting juga untuk memastikan bahwa klien tidak pernah mengirim cookie (misalnya untuk autentikasi atau preferensi situs) melalui HTTP. Misalnya, jika cookie autentikasi pengguna diekspos dalam bentuk teks biasa, jaminan keamanan seluruh sesinya akan dihapus, meskipun Anda telah melakukan hal lainnya dengan benar.

Oleh karena itu, ubah aplikasi web Anda agar selalu menetapkan flag Secure pada cookie yang ditetapkannya. Halaman OWASP ini menjelaskan cara menetapkan flag Secure di beberapa framework aplikasi. Setiap framework aplikasi memiliki cara untuk menyetel flag.

Sebagian besar server web menawarkan fitur pengalihan sederhana. Gunakan 301 (Moved Permanently) untuk menunjukkan kepada mesin telusur dan browser bahwa versi HTTPS adalah kanonis, dan mengalihkan pengguna Anda ke versi HTTPS situs dari HTTP.

Menelusuri peringkat

Google menggunakan HTTPS sebagai indikator kualitas penelusuran positif. Google juga memublikasikan panduan untuk cara mentransfer, memindahkan, atau memigrasikan situs dengan tetap mempertahankan peringkat penelusurannya. Bing juga memublikasikan panduan untuk webmasters.

Performa

Jika lapisan konten dan aplikasi telah disesuaikan dengan baik (lihat buku Steve Souders untuk mendapatkan saran bermanfaat), masalah performa TLS yang tersisa biasanya kecil, relatif terhadap biaya aplikasi secara keseluruhan. Selain itu, Anda dapat mengurangi dan mengamortisasi biaya tersebut. (Untuk mendapatkan saran bagus tentang pengoptimalan TLS dan secara umum, lihat Jaringan Browser Berperforma Tinggi oleh Ilya Grigorik.) Lihat juga OpenSSL Cookbook dan Bulletproof SSL And TLS dari Ivan Ristic.

Dalam beberapa kasus, TLS dapat meningkatkan performa, sebagian besar akibat dari mengizinkan HTTP/2. Chris Palmer memberikan pembahasan tentang performa HTTPS dan HTTP/2 di Chrome Dev Summit 2014.

Header perujuk

Saat pengguna mengikuti link dari situs HTTPS ke situs HTTP lain, agen pengguna tidak akan mengirim header Perujuk. Jika ini masalahnya, ada beberapa cara untuk menyelesaikannya:

  • Situs lainnya harus bermigrasi ke HTTPS. Jika situs penerima rujukan dapat menyelesaikan bagian Mengaktifkan HTTPS di server Anda dalam panduan ini, Anda dapat mengubah link di situs Anda ke situs rujukan dari http:// ke https://, atau Anda dapat menggunakan link protokol-relatif.
  • Untuk mengatasi berbagai masalah pada header Perujuk, gunakan standar Kebijakan Perujuk baru.

Karena mesin telusur bermigrasi ke HTTPS, di masa mendatang, Anda mungkin melihat header Perujuk lainnya saat bermigrasi ke HTTPS.

Pendapatan iklan

Operator situs yang memonetisasi situs mereka dengan menampilkan iklan ingin memastikan bahwa bermigrasi ke HTTPS tidak akan mengurangi tayangan iklan. Namun, karena masalah keamanan konten campuran, <iframe> HTTP tidak berfungsi di halaman HTTPS. Terdapat masalah tindakan kolektif yang rumit di sini: sebelum pengiklan memublikasikan melalui HTTPS, operator situs tidak dapat bermigrasi ke HTTPS tanpa kehilangan pendapatan iklan; tetapi hingga operator situs bermigrasi ke HTTPS, pengiklan memiliki sedikit motivasi untuk memublikasikan HTTPS.

Pengiklan setidaknya harus menawarkan layanan iklan melalui HTTPS (seperti dengan menyelesaikan bagian "Mengaktifkan HTTPS di server Anda" pada halaman ini). Banyak yang sudah melakukannya. Anda harus meminta pengiklan yang sama sekali tidak menayangkan HTTPS untuk setidaknya memulai. Anda dapat menunda penyelesaian Membuat URL IntraSite relatif hingga cukup banyak pengiklan yang melakukan interoperabilitas dengan benar.