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 akhir Anda di tempat yang dapat diakses selain web seperti /etc/ssl (Linux dan Unix) atau di mana pun IIS memerlukannya (Windows).

Membuat kunci dan permintaan penandatanganan sertifikat

Bagian ini menggunakan program command line openssl, yang umumnya 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 2.048-bit. Kunci yang lebih kecil, seperti 1.024 bit, tidak cukup tahan terhadap serangan tebakan brute force. Kunci yang lebih besar, seperti 4.096 bit, terlalu banyak digunakan. 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

Ini 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 output 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

Certificate authority (CA) yang berbeda memerlukan metode yang berbeda untuk mengirimkan CSR Anda. Metode dapat mencakup penggunaan formulir di situs, pengiriman CSR melalui email, atau metode lainnya. Beberapa CA (atau reseller-nya) bahkan dapat mengotomatiskan sebagian atau semua proses ini (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 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 dapat membeli satu atau beberapa sertifikat nama tunggal. (Jika memiliki lebih dari lima subdomain, Anda mungkin merasa sertifikat karakter pengganti lebih praktis jika Anda akan mengaktifkan HTTPS di server.)

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

Mengaktifkan HTTPS di server

Mengaktifkan HTTPS di server 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 Qualys yang praktis dan pastikan Anda mendapatkan setidaknya nilai A atau A+.

Pada titik 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 untuk menayangkan konten.
  • Gunakan hosting virtual berbasis nama.

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

Namun, sebagian besar operator situs menggunakan hosting virtual berbasis nama untuk menghemat alamat IP dan karena lebih praktis secara umum. Masalah dengan IE di Windows XP dan Android yang lebih lama dari 2.3 adalah tidak memahami Server Name Indication (SNI), yang penting untuk hosting virtual berbasis nama HTTPS.

Suatu hari—semoga cepat—klien yang tidak mendukung SNI akan diganti dengan software modern. Pantau string agen pengguna di log permintaan untuk mengetahui kapan populasi pengguna Anda telah mencapai jumlah migrasi yang cukup ke software modern. (Anda dapat menentukan berapa nilai minimum pembayaran; 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 Anda beli dan instal. Menurut Anda, pembuat konfigurasi Microsoft yang praktis di Mozilla mungkin berguna.

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

Sekarang, dan selama masa aktif situs Anda, periksa konfigurasi HTTPS dengan SSL Server Test praktis dari Qualys. Situs Anda harus memberikan skor A atau A+; anggaplah apa pun yang menyebabkan nilai lebih rendah sebagai bug. (Hari ini A adalah B masa depan, karena serangan terhadap algoritma dan protokol selalu meningkat!)

Menjadikan URL intrasitus relatif

Karena sekarang Anda menayangkan situs di HTTP dan HTTPS, segala sesuatunya harus bekerja semulus mungkin, apa pun protokolnya. Salah satu 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 tidak menyertakan 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 yang aktif (skrip, plugin, CSS, iframe), sering kali browser tidak bisa 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 menyediakan link ke halaman lain di situs Anda, pengguna dapat mengalami downgrade dari HTTPS ke HTTP.

Masalah ini terjadi saat halaman Anda berisi URL intrasitus yang sepenuhnya memenuhi syarat dan 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 protokol-relatif (tidak memiliki protokol, dimulai dengan //example.com) maupun host-relatif (dimulai dengan jalur, 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 ini dengan skrip, bukan dengan cara manual. Jika konten situs Anda ada dalam database, uji skrip di salinan pengembangan database Anda. Jika konten situs Anda terdiri dari beberapa file sederhana, uji skrip Anda pada salinan pengembangan file. Terapkan perubahan ke produksi hanya setelah perubahan tersebut lulus UM (Uji Mutu) seperti biasa. Anda dapat menggunakan skrip Bram van Damme atau metode yang mirip untuk mendeteksi konten campuran di situs Anda.

Saat menautkan ke situs lain (bukan menyertakan resource dari situs tersebut), jangan mengubah protokol karena Anda tidak memiliki kontrol atas cara beroperasi situs tersebut.

Untuk membuat migrasi lebih lancar di situs besar, sebaiknya gunakan URL relatif protokol. Jika Anda belum yakin apakah Anda dapat sepenuhnya men-deploy HTTPS, memaksa situs Anda menggunakan HTTPS untuk semua sub-resource dapat berdampak negatif. Mungkin ada masa tertentu saat HTTPS masih baru dan aneh bagi Anda, dan situs HTTP harus tetap berfungsi sebagaimana mestinya. 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, mintalah mereka untuk melakukannya. Sebagian besar sudah melakukannya, termasuk jquery.com.
  • Tayangkan resource dari server yang Anda kontrol, dan yang menawarkan HTTP dan HTTPS. Hal ini sering dilakukan karena Anda memiliki kontrol yang lebih baik atas tampilan, performa, dan keamanan situs. Selain itu, Anda tidak perlu mempercayai pihak ketiga, dan itu bagus.

Mengalihkan HTTP ke HTTPS

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

Tetapkan tag <link rel="canonical" href="https://…"/> di halaman Anda. Hal ini membantu mesin telusur menentukan cara terbaik untuk 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 tetapkan 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://. Hal ini akan mengalahkan serangan seperti SSL Stripping, dan juga menghindari biaya bolak-balik 301 redirect yang telah diaktifkan di Mengalihkan HTTP ke HTTPS.

Aktifkan HTTP Strict Transport Security (HSTS) dengan menyetel header Strict-Transport-Security. Halaman HSTS 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 jika Anda telah melakukan hal lainnya dengan benar.

Oleh karena itu, ubah aplikasi web Anda untuk selalu menetapkan flag Secure pada cookie yang ditetapkannya. Halaman OWASP ini menjelaskan cara menyetel 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 bersifat kanonis, dan mengalihkan pengguna ke versi HTTPS situs Anda dari HTTP.

Menelusuri peringkat

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

Performa

Jika lapisan konten dan aplikasi telah disesuaikan dengan baik (lihat buku Steve Souders untuk mendapatkan saran bagus), masalah performa TLS yang tersisa umumnya kecil, relatif terhadap keseluruhan biaya aplikasi. Selain itu, Anda dapat mengurangi dan mengamortisasi biaya tersebut. (Untuk 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 karena memungkinkan 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 menjadi masalah, ada beberapa cara untuk mengatasinya:

  • Situs lainnya harus dimigrasikan 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 mereka dari http:// ke https://, atau Anda dapat menggunakan link protokol-relatif.
  • Untuk mengatasi berbagai masalah dengan header Perujuk, gunakan standar Kebijakan Perujuk baru.

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

Pendapatan iklan

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

Pengiklan harus menawarkan setidaknya 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 memulainya. Anda dapat menunda penyelesaian Membuat URL intrasitus relatif hingga cukup pengiklan yang melakukan interoperabilitas dengan benar.