Tag Archives

5 Articles
Membuat Sertifikat Let’s Encrypt Menggunakan certbot Di Debian Wheezy
By The people from the Tango! project, derived RRZEicons (The Tango! Desktop Project) [Public domain], via Wikimedia Commons, color modified by JP

Membuat Sertifikat Let’s Encrypt Menggunakan certbot Di Debian Wheezy

Maaf, ya, saya suka khilaf lupa menulis tulisan lanjutan. Ha… ha… ha….

Berikut ini adalah cara memasang sertifikat SSL yang ditandatangani oleh Let’s Encrypt dengan menggunakan certbot pada Debian Wheezy. Silakan lihat cara pasang di Wheezy untuk keterangan lebih lanjut.

Aktifkan Repo Debian Wheezy Backports

Anda bisa langsung mengaktifkan repo Debian Wheezy Backports:

echo "deb http://kambing.ui.ac.id/debian-backports/ jessie-backports main" | sudo tee /etc/apt/sources.list.d/debian-backports.list
sudo apt update

Atau nanti tunggu ditanyakan pada saat menjalankan certbot.

Pasang certbot

Unduh dengan pengunduh favorit Anda.

sudo wget https://dl.eff.org/certbot-auto -O /usr/local/bin/certbot-auto
sudo chmod +x /usr/local/bin/certbot-auto

Sebelum Memasang Let’s Encrypt

Siapa tahu Anda malas tidak punya waktu untuk membaca artikel sebelumnya, perhatikanlah:

  1. Pastikan semua domain yang didaftarkan sudah terdaftar di DNS publik.
  2. Pastikan bahwa direktori yang memuat URL untuk sertifikasi dapat diakses.

Penulisan DNS di luar cakupan tulisan ini. Berikut contoh direktori .well-known

server {
        listen   80;
        listen  [::]:80 ipv6only=on;
        server_name  example.com www.example.com;
        server_name_in_redirect on;
        port_in_redirect on;
 
        access_log  /var/log/nginx/access.log;
        error_log  /var/log/nginx/error.log;
 
        # For ACME Let's Encrypt challenge
        location /.well-known {
                alias /var/www/html/.well-known; # have this as the webroot
        }
 
        location / {
                return 301 https://$server_name$request_uri;
        }
 
}

Mari memasang certbot.

Sertifikasi

Seperti biasa:

sudo certbot-auto certonly --webroot -w /var/www/html -d example.com -d www.example.com

Seandainya tadi Anda melewati bagian pemasangan repositori Debian Backports, maka Anda akan ditanyakan:

To use the Apache Certbot plugin, augeas needs to be installed from wheezy-backports.
Would you like to enable the wheezy-backports repository [Y/n]? y

Lalu beberapa pesan pemasangan paket Python virtualenv. Kemudian, ditanyakan alamat info:

Installing Python packages...
Installation succeeded.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel):admin@example.com

Lalu, ditanyakan apakah menyetujui syarat dan ketentuan yang diberikan, jawab A untuk setuju.

-------------------------------------------------------------------------------
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree
in order to register with the ACME server at

No Title

No Description

------------------------------------------------------------------------------- (A)gree/(C)ancel: A

Setelah itu, tunggu beberapa saat.

Obtaining a new certificate
Performing the following challenges:
http-01 challenge for example.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/example.com/fullchain.pem. Your
   cert will expire on 2017-04-19. To obtain a new or tweaked version
   of this certificate in the future, simply run certbot-auto again.
   To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you lose your account credentials, you can recover through
   e-mails sent to admin@example.com.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Kalau sudah sampai sini, Anda sudah selesai mendapatkan sertifikasi dari Let’s Encrypt.

Konfigurasi NGINX

Kalau mau penjelasan, lihat artikel terdahulu.

Berikut blok SSL:

ssl  on;
 
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
        
ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers         "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
ssl_prefer_server_ciphers on;
ssl_session_cache   shared:SSL:20m;
ssl_session_timeout 60m;
 
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
 
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 8.8.8.8;
 
add_header Strict-Transport-Security "max-age=31536000" always;

Nah, untuk Debian Wheezy, ada tambahan yang harus dilakukan.

Penambahan Penjadwalan CRON

Pada paket Debian Jessie, jadwal CRON untuk certbot sudah dipasang pada /etc/cron.d/certbot. Mari tambahkan secara manual untuk Debian Wheezy.

Pertama-tama, coba jalankan apakah sukses.

sudo certbot-auto renew --dry-run

Kalau sudah berhasil, maka pasang pada CRON.

sudo crontab -e

Masukkan entri:

0 */12 * * * /usr/local/bin/certbot-auto renew --quiet --no-self-upgrade

Let’s Encrypt memandatkan untuk pengecekan sehari dua kali.

Terakhir

Selesai.

 

Bacaan Lebih Lanjut

Membuat Sertifikat Let’s Encrypt Menggunakan certbot Di Debian Jessie
By The people from the Tango! project, derived RRZEicons (The Tango! Desktop Project) [Public domain], via Wikimedia Commons, color modified by JP

Membuat Sertifikat Let’s Encrypt Menggunakan certbot Di Debian Jessie

Untuk mendukung web yang aman dan dalam rangka HTTP/2 yang sudah menggunakan SSL sebagai dasar koneksi, diperlukan sertifikat digital yang ditandatangani oleh pihak yang terpercaya. Situs yang memiliki sertifikat digital yang ditandatangani sendiri bahkan sudah ditandai oleh beberapa peramban sebagai situs tak aman. Tak ayal lagi, diperlukan tanda tangan digital yang terpercaya.

Kali ini kita menggunakan sebuah sertifikat gratis yang bernama Let’s Encrypt. Penyedia sertifikat ini (CA) didukung oleh EFF (Electronic Frontier Foundation), sebuah organisasi nirlaba yang bergerak dalam aktivitas digital. Bahkan, organisasi nirlaba ini menyediakan perkakas untuk sertifikasi tanda tangan digital, certbot.

Mungkin Anda bertanya, bagaimana dengan Sivion? Sivion adalah salah satu usaha dari Indonesia untuk itu. CA (penyedia sertifikat) dari Indonesia ini saat ini menyediakan tanda tangan gratis bagi kita. Namun, sayangnya mereka belum menyediakan perkakas sertifikasi seperti Let’s Encrypt.

Artikel kali ini membahas bagaimana memasang sertifikat Let’s Encrypt dengan certbot. Artikel ditulis untuk Debian Jessie.

Aktifkan Repo Debian Jessie Backports

Tambahkan ke daftar repo dan perbaharui daftar paket.

echo "deb http://ftp.debian.org/debian jessie-backports main" | sudo tee /etc/apt/sources.list.d/debian-backports.list
sudo apt update

Saya tidak arahkan ke Kambing karena saya sedang malas membetulkan Kambing. Mungkin nanti setelah betul, saya arahkan ke Kambing. ;-P

Pasang certbot

Perkakas certbot ada di repo Jessie Backports.

sudo apt-get install certbot -t jessie-backports

Sebelum Memasang Let’s Encrypt

Ada dua hal yang menjadi kewajiban kita:

  1. Pastikan semua domain yang didaftarkan sudah terdaftar di DNS publik.
  2. Pastikan bahwa direktori yang memuat URL untuk sertifikasi dapat diakses.

Untuk pembuatan entri DNS di luar cakupan tulisan ini.

Halaman HTTP (tanpa SSL) untuk lokasi .well-known/ (http://example.com/.well-known/) harus dapat diakses. Bila Anda seperti saya yang mematikan non-SSL, harus ditambahkan dahulu pengecualian tersebut di peladen. Omong-omong saya menggunakan peladen NGINX. Contoh pengecualian:

server {
        listen   80;
        listen  [::]:80 ipv6only=on;
        server_name  example.com www.example.com;
        server_name_in_redirect on;
        port_in_redirect on;

        access_log  /var/log/nginx/access.log;
        error_log  /var/log/nginx/error.log;

        # For ACME Let's Encrypt challenge
        location /.well-known {
                alias /var/www/html/.well-known; # have this as the webroot
        }

        location / {
                return 301 https://$server_name$request_uri;
        }

}

Berikutnya, pasang.

Sertifikasi

Jalankan sertifikasi

sudo certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com

Ikuti prosesnya, biasanya pertama-tama ditanyakan alamat surel yang bisa dihubungi bila ada apa-apa.

Enter our email address

Enter our email address

Setelah itu, biasanya ditanyakan kesediaan mengikuti syarat dan ketentuan yang ditetapkan oleh Let’s Encrypt. Pencet tombol [ENTER] saja.

Saya lupa menyuplikkan saat sudah berhasil. Ya, coba saja cek direktori /etc/letsencrypt/live yang seharusnya berisi satu direktori bernama domain pertama yang kita daftarkan.

Konfigurasi NGINX

Sebelum saya kasih konfigurasi penuh, saya coba berikan potongan.

SSL Baku

Untuk konfigurasi SSL baku gunakan sertifikat-sertifikat ini:

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

OCSP Stapling

Untuk memanfaatkan OCSP Stapling gunakan sertifikat ini:

ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

Contoh Penuh

Ini contoh penuh blok SSL saya.

ssl  on;

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
        
ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers         "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
ssl_prefer_server_ciphers on;
ssl_session_cache   shared:SSL:20m;
ssl_session_timeout 60m;

ssl_dhparam /etc/nginx/ssl/dhparam.pem;

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 8.8.8.8;

add_header Strict-Transport-Security "max-age=31536000" always;

Terakhir

Untungnya menggunakan paket Debian Jessie adalah pembaharuan SSL berlangsung otomatis. Setelah ini saya akan buat tulisan untuk Debian Wheezy. Sayangnya, pemasangan Debian Wheezy lebih rumit dari Debian Jessie.

Selamat mencoba dan tinggalkan komentar bila ingin bertanya.

Bacaan Lebih Lanjut

NGINX dan Situs Siap HTTP/2

NGINX dan Situs Siap HTTP/2

Semenjak versi 1.9.5, NGINX sudah menggantikan modul SPDY dengan HTTP/2. Protokol tersebut telah resmi dan banyak peramban modern memanfaatkannya pada versi anyar. Salah satu yang paling gencar adalah Chromium dan turunannya (Google Chrome).

Ajaibnya, mengaktifkan HTTP/2 dapat menyebabkan galat berikut pada Chromium:

ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

Berikut penyebab mengapa demikian:

  • Menggunakan enkripsi lawas yang dilarang oleh HTTP/2, misalnya masih SHA-1, RC4, atau lebih rendah.
  • Menggunakan sertifikat SSL yang tidak ditandatangani oleh CA yang terpercaya/diakui oleh peramban.
  • Masih ada penggunaan protokol tak terenkripsi sehingga isi situs tercampur antara yang terenkripsi atau tidak.

Lalu apa yang harus kita lakukan untuk dapat sesuai dengan HTTP/2?

  • Untuk situs yang melayani HTTP dan HTTPS, sebaiknya penulisan URI tidak mencantumkan skema. Misalnya, daripada menulis “http://alamat.sesuatu/res/1.jpg” atau “https://alamat.sesuatu/res/1.jpg”, lebih baik ditulis dengan “/res/1.jpg”.
  • Solusi yang paling betul, tulis semua dengan menggunakan protokol HTTPS.
  • Solusi lain, tulis semua dengan menggunakan HTTP non-enkripsi dan lupakan HTTP/2.

Pada zaman dahulu, penggunaan protokol HTTPS berat dan cenderung dilewati. Namun, protokol HTTP/2 memiliki mekanisme saluran aman sehingga dapat mengirim sumber daya dengan lebih cepat dan efisien. Apalagi, prosesor zaman sekarang sudah dilengkapi oleh ekstensi AES-NI yang melakukan enkripsi secara perangkat keras. Dengan kedua alasan itu, menyalakan HTTP/2 justru mempercepat situs.

Sayangnya, dunia tak seindah itu. Harga tanda tangan sertifikat per domain itu mahal! Kalau Anda memiliki situs dengan banyak domain, Anda tentunya harus berstrategi. Salah satunya Anda bisa saja membeli sertifikat wildcard (*) sehingga bisa dipakai oleh sub domain.

Tetap saja, untuk UI yang memiliki lembaga tingkat 2 (misalnya lembaga di bawah fakultas), sertifikat wildcard tidak bisa dipakai. UI harus membeli sertifikat wildcard per fakultas juga. Atau, UI bisa saja membeli sertifikat untuk menjadi CA sekunder.

Keduanya adalah solusi yang mahal. Apalagi, setiap sertifikat hanya berlaku setahun atau dua tahun saja dan harus diperpanjang. Kalau sudah sampai seperti itu, kita harus berstrategi.

Dalam kasus UI, situs-situs yang membutuhkan keamanan tinggi harus menggunakan HTTP/2 dan sertifikat SHA2. Sedangkan untuk situs-situs kurang penting seperti Blog Staff ini, penggunaan sertifikat sekenanya saja. Misalnya, masih ditandatangani sendiri (self-signed) atau sertifikat SHA1 sisa-sisa dana tahun lalu.

Untuk peladen yang menggunakan WordPress Multisite dan Drupal multisite sayangnya harus secara manual menulis konfigurasi HTTP/2 pada NGINX. Bisa, sih, ditulis skripnya. Tetapi, saya terlalu malas untuk saat ini. Terlalu banyak kasus anomali (edge cases) yang harus dipertimbangkan.

Bagaimana dengan Anda, sudah siapkah situs Anda?

Memperketat Keamanan Situs

Memperketat Keamanan Situs

Pendahuluan

Halo, jumpa lagi di hari Jumat!

Karena isu keamanan akhir-akhir ini semakin ketat, saya merasakan perlunya pembelajaran kepada masyarakat Indonesia mengenai penggunaan enkripsi yang tepat. Entahlah, mungkin ini juga karena saya meneliti Owncloud terlalu jauh. Atau mungkin ini sekedar tulisan menambah kuota tulisan saya di blog. Ilmu memang untuk dibagi.

Orang pasti sudah tahu tentang BEAST, CRIME, dan HEARTBLEED. BEAST adalah proof-of-concept serangan terhadap enkripsi TLSv1.0 yang menyebabkan sebuah domain dapat dibajak dari implementasi TLS v1.0 yang buruk di sistem operasi. Lalu, ada CRIME yang menyerang implementasi kompresi HTTP pada TLS dan SPDY. Yang menghebohkan berikutnya adalah HEARTBLEED yang menyerang implementasi cacat OpenSSL pada implementasi ekstensi TLS heartbeat.

Yang terakhir dan teranyar adalah POODLE, eksploit terhadap SSLv3 yang menyebabkan sekarang ini orang dipaksa untuk mematikan SSLv3. Ya, kecuali Anda menggunakan IE6/7 pada Windows XP yang belum diperbaharui, sebenarnya SSLv3 sudah lama tidak diperlukan. Bahkan, sebaiknya Anda memaksa peramban Anda langsung menggunakan TLS v1.2.

Ekstensi AES-NI

Tapi… tapi… bukankah menggunakan enkripsi membuat peladen kurang responsif?

Itu dulu! Sekarang, ‘kan, sudah ada ekstensi AES-NI pada prosesor x86. Jadi, enkripsi dilakukan secara langsung oleh CPU. Saya melakukan eksperimen kecil untuk memperlihatkan perbedaan operasi biasa dan menggunakan AES-NI.

Operasi biasa menggunakan instruksi CPU normal.

$ OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 34349970 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 8984170 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 2337382 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 589989 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 74022 aes-128-cbc's in 3.00s
OpenSSL 1.0.1i 6 Aug 2014
built on: Fri Aug  8 06:23:32 WIB 2014
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: x86_64-pc-linux-gnu-gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -O2 -pipe -march=native -mtune=native -fomit-frame-pointer -flto=8 -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize -fno-strict-aliasing -Wa,--noexecstack
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     183199.84k   191662.29k   199456.60k   201382.91k   202129.41k

Sedangkan berikut operasi menggunakan instruksi AES-NI.

$ openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 99416661 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 27157194 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 7746016 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 2005119 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 253147 aes-128-cbc's in 3.00s
OpenSSL 1.0.1i 6 Aug 2014
built on: Fri Aug  8 06:23:32 WIB 2014
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: x86_64-pc-linux-gnu-gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -O2 -pipe -march=native -mtune=native -fomit-frame-pointer -flto=8 -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize -fno-strict-aliasing -Wa,--noexecstack
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     530222.19k   579353.47k   660993.37k   684413.95k   691260.07k

Berikut tabel hasilnya:

Instruksi CPU Tipe 16-bit 64-bit 256-bit 1024-bit 8192-bit
AES-NI aes-128-cbc 530222,19 579353,47 660993,37 684413,95 691260,07
Normal 183199,84 191662,29 199456,6 201382,91 202129,41
Performa 2,8942284557 3,0227827811 3,313970909 3,3985701667 3,4198886248
Total Performa AES-NI 3,2098881874

Tampak bahwa dalam kasus ini, penggunakan AES-NI pada OpenSSL meningkatkan performa 3 kali lipat.

Dukungan AES-NI

Untuk mengetahui apakah prosesor peladen Anda mendukung AES-NI, silakan lihat dengan:

$ cat /proc/cpuinfo  | grep aes
flags           : ... aes ...

Kalau didukung, akan ada tulisan ‘aes’. Biasanya, sih, untuk prosesor AMD dan Intel yang baru [baca: keluaran tahun-tahun ini] sudah mendukung instruksi AES-NI. Kalau pun belum, bisa langsung saja mengompilasi OpenSSL dengan menggunakan instruksi SSE4 atau AVX. Ya, tapi itu di luar cakupan tulisan ini agar tidak terlalu rumit.

Untuk Debian Wheezy, OpenSSL 1.0.1e yang digunakan akan secara otomatis mendeteksi AES-NI. Tidak perlu mengompilasi sendiri untuk versi Debian tersebut. Untuk sistem operasi yang lain, silakan konsultasi kepada Mbah Gugel.

Bila Anda menggunakan KVM atau Proxmox, pastikan Anda menggunakan tipe CPU Host. Cara lain adalah pastikan instruksi AES-NI diperbolehkan untuk KVM.

Konfigurasi NGINX

Karena OpenSSL transparan, maka tidak ada yang perlu dipusingkan oleh NGINX untuk menggunakan AES-NI. NGINX hanya perlu memberitahukan protokol enkripsi yang dipakai untuk HTTPS.  Untuk itu, perhatikan contoh konfigurasi NGINX:

server {
        listen   80;
        listen  [::]:80 ipv6only=on;
        server_name  www.contoh.aja;
        server_name_in_redirect on;
        port_in_redirect on;

        access_log  /var/log/nginx/normal.access.log;
        error_log  /var/log/nginx/normal.error.log;

        ## redirect http to https ##
        rewrite        ^ https://$server_name$request_uri? permanent;
}

server {
        listen   443 ssl spdy;
        listen [::]:443 ipv6only=on ssl spdy;

        server_name  www.contoh.aja;
        server_name_in_redirect on;
        port_in_redirect on;

        ssl  on;
        ssl_certificate /etc/nginx/ssl.cert;
        ssl_certificate_key /etc/nginx/ssl.key;
        
        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers         "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
        ssl_prefer_server_ciphers on;
        ssl_session_cache   shared:SSL:10m;
        ssl_session_timeout 10m;

        access_log  /var/log/nginx/ssl.access.log;
        error_log  /var/log/nginx/ssl.error.log;

        ## HERE PHP ENGINE AND OTHER REWRITE RULES ##
}

Saya akan mencoba menjelaskan beberapa bagian yang penting. Saya mengasumsikan Anda sudah tahu mengonfigurasi NGINX secara dasar sehingga saya tak perlu menjelaskan semuanya. Atau, setidaknya Anda bisa mencari langsung di Internet.

Saya sengaja tidak menyertakan aturan FastCGI PHP dan aturan-aturan rewrite untuk mengurangi kompleksitas kode. Ada banyak tutorial dasar untuk menyertakan aturan FastCGI. Lagipula, untuk aturan-aturan rewrite tergantung kepada aplikasi yang kita gunakan (Drupal, WordPress, dsb.).

Yak, langsung saja.

Mendengar di IPv4 dan IPv6

Berikut sintaksis agar NGINX mendengar semua antarmuka jaringan (IPv4 dan IPv6).

listen   80;
listen  [::]:80 ipv6only=on;

Ada alasan mengapa mengaktifkan dual stack. Universitas Indonesia (UI) sudah sejak lama memiliki satu blok (/16) IPv4 kelas B. Karena termasuk historical member dari IANA, UI juga beruntung mendapatkan satu blok /48 IPv6. Itu sebabnya, hampir semua peladen UI sudah memiliki IPv6 sendiri berikut IPv4 publik.

Mengarahkan Semua ke HTTPS

Berikut sintaksis untuk mengarahkan koneksi HTTP ke HTTPS.

rewrite        ^ https://$server_name$request_uri? permanent;

Ada tutorial lama yang menyampur koneksi HTTPS dan HTTP. Hal ini tidak sesuai dengan prinsip keamanan. Bila memang situs ingin aman sepenuhnya, maka harus semuanya harus menggunakan HTTPS. Konten campuran (berisi HTTP dan HTTPS) tidak disarankan dan beberapa peramban akan cerewet tentang itu.

Mengaktifkan SPDY

Berikut sintaksis agar NGINX menggunakan SSL (HTTPS) dengan SPDY.

listen   443 ssl spdy;
listen [::]:443 ipv6only=on ssl spdy;

Untuk akselerasi HTTPS, Google mengembangkan teknik SPDY. Hampir semua peramban modern mendukung protokol SPDY. Saya pernah membahas ini.

Mengaktifkan SSL

Baris-baris inilah yang mengaktifkan enkripsi HTTPS (SSL).

ssl  on;
ssl_certificate /etc/nginx/ssl.cert;
ssl_certificate_key /etc/nginx/ssl.key;

Baris ssl_certificate mengarahkan ke berkas sertifikat peladen. Ada tiga jenis skenario untuk berkas sertifikat peladen:

  1. Untuk menambah legitimasi, biasanya sertifikat ditandatangani oleh Certificate Authority (CA) yang sudah diakui. StartSSL menyediakan layanan ini dengan gratis. Kalau mau yang murah ada RapidSSL atau Komodo. Kalau mau lebih bonafide, gunakan VeriSign. Mereka ini biasanya sertifikat utamanya (root certificate) sudah dipasang di sistem operasi/peramban. Root certificate adalah sertifikat CA yang dipakai untuk melegitimasi sertifikat sebuah server.
  2. Ada juga organisasi yang membuat root certificate sendiri. Biasanya, mereka memasang sendiri root certificate ke sistem operasi/peramban pengguna. Ada banyak tutorial tentang itu, terutama Windows Server dan UNIX.
  3. Yang paling jamak digunakan di tutorial-tutorial biasanya menggunakan sertifikat yang ditandatangani sendiri (self-signed).

Silakan pilih skenario yang terbaik. Untuk situs bisnis biasanya menggunakan CA pihak ketiga (poin 1). Namun, untuk Intranet biasanya menggunakan poin 2.

Baris berikutnya ssl_certificate_key mengarahkan berkas kunci privat peladen. Pastikan berkas ini hanya bisa diakses baca-saja oleh root (0400).

Parameter Tambahan

Berikut parameter tambahan yang opsional. Parameter-parameter ini yang memperkuat enkripsi situs.

Hanya Gunakan TLS

Protokol SSLv3 sudah tamat semenjak POODLE beberapa hari yang lalu. Banyak yang menyarankan untuk mematikan protokol ini. Ya, berhubung protokol ini sudah sangat lama, wajar saja. Lagipula, hanya IE6/7 yang menggunakan Windows XP SP3 yang belum ditambal saja yang terpengaruh. Sisanya, dunia sudah mengenal TLS sejak lama.

Ya sudah, cukup aktifkan semua versi protokol TLS saja.

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;

Protokol TLS pun sebenarnya tidak begitu aman. Kalau mau paranoid, hanya aktifkan TLSv1.2 saja. Tentu saja, ini mengurangi jumlah pengunjung dan peramban yang bisa mengakses situs kita.

Gunakan SHA256 AES-GCM dengan Forward Secrecy dan RC4 Sebagai Cadangan

Semenjak tahun 2011, SHA1 dianggap sudah tidak aman lagi. Lebih parah lagi, Google akan mempenalti situs-situs yang masih menggunakan SHA1 pada 1 Januari 2017. Artinya, semua situs yang masih memakai sertifikat dengan tanda tangan SHA1 akan dianggap tidak aman oleh produk-produk Google.

Bila Anda masih baru mau memasang sertifikat, gunakan sertifikat dengan tanda tangan SHA256. Atau kalau lebih bagus lagi, gunakan SHA387. Tetapi, untuk SHA387 masih jarang dan lagi mahal.

Ada banyak protokol pertukaran kunci dan saya tidak mau terlalu detail. Saat ini protokol yang aman dari gangguan adalah AES-GCM dan RC4. Protokol RC4 sudah lama dan relatif aman. Sedangkan GCM masih relatif baru, sehingga beberapa peramban lama tidak mendukung.

[Lama itu hitungannya 10 s.d. 20 tahun yang lalu, ya, kawan-kawan.]

Saat ini RC4 disarankan untuk ditinggalkan. Bukan berarti dia tidak aman. Sudah ada metodenya, tetapi untuk bisa membobol RC4 saat ini memerlukan sumber daya yang sangat besar. Jadi, RC4 relatif cukup aman.

Penggunaan AES-GCM disarankan oleh karena adanya instruksi AES-NI yang mempercepat percepat perhitungan.  Teknik ini peningkatan implementasi dari AES-CBC dengan menggunakan instruksi perangkat keras. Itu sebabnya, AES-CBC disarankan ditinggalkan.

Berikut instruksinya.

ssl_ciphers         "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

Oh, iya, satu lagi. Dalam konfigurasi ini diaktifkan mode Forward Secrecy yang ada di TLSv1.2.

Mengaktifkan Urutan Enkripsi Di Sisi Server

Instruksinya:

ssl_prefer_server_ciphers on;

Instruksi ini mengakibat peladen akan menyuruh klien untuk menggunakan metode enkripsi yang diinginkan sesuai dengan urutan. Ini mengurangi kemungkinan klien yang sudah mendukung TLSv1.2 malah menggunakan versi terdahulu karena konfigurasi perambannya. Hal ini bisa memitigasi terhadap serangan BEAST.

Menyimpan Sesi SSL

Instruksinya:

ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 10m;

Untuk keperluan optimasi, NGINX dapat menyimpan sesi SSL pada tembolok. Ada dua jenis yang didukung. Yang pertama, tembolok tersebut disimpan oleh NGINX sehingga bisa diakses oleh sesama proses-proses pekerja NGINX. Yang kedua, per pekerja menggunakan tembolok yang disediakan oleh OpenSSL. Disarankan untuk menggunakan tembolok NGINX saja.

Menurut NGINX, 1 MB mampu menampung 4000 sesi. Konfigurasi ini menggunakan 10MB sehingga kira-kira ada 40000 sesi yang didukung. Setiap sesi ini disimpan selama 10 menit saja. Silakan dikonfigurasikan sesuai kemampuan peladen Anda.

Terakhir

Setelah semua selesai, silakan menyalakan ulang NGINX. Mari saya rekap untuk Anda:

  1. Gunakan SPDY untuk mempercepat koneksi HTTPS.
  2. Gunakan kunci dengan algoritma SHA256 atau lebih yang sudah divalidasi oleh CA.
  3. Gunakan protokol TLS teranyar dengan AES-GCM dengan RC4 sebagai cadangan.
  4. Gunakan tembolok untuk mengoptimasi penggunaan TLS.

Anda pun sudah memiliki peladen yang cukup handal. Anda bisa mempelajari teknik-teknik tambahan lain mengenai SSL, misalnya menggunakan OCSP.

Terakhir, Anda perlu mengedukasi pengguna Anda agar tidak memberikan sandi kepada siapa pun dan mengganti sandi secara periodik, misalnya 6 bulan sekali. Percuma punya infrastruktur yang handal tanpa pengguna yang paham.

Nota Bene

Gunakan pihak ketiga untuk menguji SSL. Saya menggunakan perkakas dari Qualys SSL Lab. Contoh hasil pengujian konfigurasi SSL pada Blog Staff UI.

SSL Labs test on Blog Staff UI. Yeah, we need to upgrade into SHA256. The certificate is issued not long ago.

SSL Labs test on Blog Staff UI. Yeah, we need to upgrade into SHA256. The certificate is issued not long ago.

Bacaan Lebih Lanjut

Kabar dari Dunia Keamanan
Let's draw something cool and call it cyber war.

Kabar dari Dunia Keamanan

Tulisan ini mungkin bukan untuk Anda. Tapi, Snowden memperlihatkan bahwa spionase negara-negara maju telah sampai kepada tingkat memprihatinkan. Penyadapan negara terhadap warga negaranya sendiri mempertanyakan sebuah masalah serius: dapatkah demokrasi tetap ada?

Kendati banyak yang berpendapat bahwa saat ini hanyalah pseudo-demokrasi, namun tetaplah demokrasi masih ada dan dipraktikkan. Penyadapan dan interfensi informasi, sayangya, dapat mengancam demokrasi yang secuil itu. Hak-hak manusia untuk memilih jalan hidupnya semakin dipertanyakan. Semua ditentukan oleh penguasa (pemerintah dan korporasi).

Jangan-jangan, akan timbul generasi yang tidak mengenal lagi arti kebebasan karena segala sesuatunya telah ditentukan oleh pemerintah dan korporasi. Ini bisa jadi awal mula titik kepunahan manusia. Pemikiran yang seragam membuat jalan keluar sebuah masalah pun seragam.

Pluralitas manusia menjamin akan ada selalu jawaban alternatif yang siap untuk menjawab. Jawaban-jawaban ini saling menajamkan satu sama lain sehingga menghasilkan jawaban yang semakin sempurna. Itu sebabnya, alternatif akan selalu diperlukan untuk melihat sebuah masalah dari sisi lain.

Mungkin berita ini lebih banyak mengenai Amerika Serikat. Namun, negara-negara lain pun melakukan hal yang sama. Hanya saja, operasi-operasi ini lebih banyak terbuka di Amerika Serikat, terutama semenjak Snowden.

Berikut catatan keamanan yang berhasil saya kompilasi.

Pintu Belakang IPSEC OpenBSD

Berita paling tua tentang keberadaan campur tangan pemerintahan untuk sengaja melemahkan sebuah sistem operasi berada pada tahun 2010 sebelum Snowden. Kala itu sebuah audit kode yang dilakukan menemukan adanya kelemahan dalam kernel IPSEC pada OpenBSD. OpenBSD adalah sebuah varian BSD yang bertujuan untuk keamanan.

Dari hasil penelusuran, diduga kode diinjeksi oleh sebuah perusahaan. Perusahaan ini terletak di Washington DC. Dari hasil investigasi, diduga kode tersebut diinjeksi oleh FBI.

Update on the OpenBSD IPSEC backdoor allegationwithout a ‘hint’ (true or fake), Well, the allegations came without any facts pointing at specific code. At the moment my beliefs are somewhat along these lines: (a) NETSEC, as a company, was in that peculiar near-DC business of accepting contracts to do security and anti-security work from parts of the government.
via Lwn

RSA Sengaja Melemahkan Kriptografinya

Siapa RSA? RSA adalah pemegang paten dari kriptografi RSA, sebuah formula kunci publik-kunci pribadi. Algoritmanya banyak dipakai perusahaan-perusahaan untuk membuat kriptografi keamanan yang diperlukan untuk melindungi data-datanya. Algoritma/formula tersebut juga digunakan pada produk-produk pihak ketiga.

NSA Paid a Huge Security Firm $10 Million to Keep Encryption WeakReuters reports that the NSA paid massive computer security firm RSA $10 million to promote a flawed encryption system so that the surveillance organization could wiggle its way around security. In other words, the NSA bribed the firm to leave the back door to computers all over the world open.

Yahoo!, Google, Microsoft, dan Facebook beritahu Publik tentang data yang diberikan kepada NSA

Perusahaan-perusahaan yang beroperasi di Amerika Serikat terikat Undang-Undang Pengintaian Mata-mata Asing (Foreign Intelligence Surveillance Act). Intinya, UU ini memperbolehkan pemerintah AS untuk meminta data-data pribadi pada perusahaan-perusahaan tersebut. Hal ini dapat dilakukan dengan dalih nasionalisme perlindungan terhadap niat-niat jahat asing termasuk terorisme.

Microsoft, Facebook, Google and Yahoo release US surveillance requestsTens of thousands of accounts associated with customers of Microsoft, Google, Facebook and Yahoo have their data turned over to US government authorities every six months as the result of secret court orders, the tech giants disclosed for the first time on Monday.

Kriptografi lemah SSL pada Apple

Auditor menemukan kelemahan pada implementasi SSL Apple sehingga orang dapat melewati satu bagian dari enkripsinya. SSL dipakai untuk mengenkripsi sandi dan data-data penting sebelum dikirim melalui jaringan. Hal ini dapat mengakibatkan pihak tak berkepentingan dapat mengeksploitasi sistem untuk mencuri data.

Apple’s #gotofail weekendIn case you spent your weekend watching closing ceremonies and not reading tech news, there was a lot of buzz around a security problem in Apple products. On Friday, Apple released an emergency update for iOS7 that fixed a severe vulnerability in their SSL/TLS implementation on the iPhone.

Kode Verifikasi GnuTLS Rusak

Redhat menemukan pada GnuTLS versi apa pun bahwa fungsi validasi sertifikat telah terkompromi sehingga dapat membuat verifikasi sertifikat dilewati. Hal ini membuat sebuah aplikasi menjadi tak aman.

Critical crypto bug leaves Linux, hundreds of apps open to eavesdroppingHundreds of open source packages, including the Red Hat, Ubuntu, and Debian distributions of Linux, are susceptible to attacks that circumvent the most widely used technology to prevent eavesdropping on the Internet, thanks to an extremely critical vulnerability in a widely used cryptographic code library.

 

Kebobrokan GnuTLS sudah diduga sejak lama. Sayangnya, tidak banyak orang yang tahu. Karena kode sumber yang terbuka, akhirnya banyak orang yang melihat dan sudah mendengar.

Untungnya, audit terbuka Redhat menghasilkan sebuah keputusan yang luar biasa. Produk tersebut diperbaiki. Sambil malu, pengembang GnuTLS menyarankan untuk pengguna memperbaharui versi GnuTLS mereka ke versi 3.2.12 atau 3.1.22.

GnuTLSCVE-2014-0092 Certificate verification issue A vulnerability was discovered that affects the certificate verification functions of all gnutls versions. A specially crafted certificate could bypass certificate validation checks. The vulnerability was discovered during an audit of GnuTLS for Red Hat. Who is affected by this attack? Anyone using certificate authentication in any version of GnuTLS.
via Gnutls

Kata Terakhir

Menjual keamanan seperti menjual keledai mati. Semua orang membayar mahal untuk itu hanya demi rasa aman. Rasa aman yang semu ini sering kali menjadi justifikasi orang untuk lengah. Ya, kalau pun teknologi memang kuat, belum tentu social engineering tidak dapat dilakukan. Keamanan tetaplah sesuatu yang dapat dikompromikan bila dengan pihak ketiga.

Kebanyakan dari apa yang saya ceritakan ini sudah diperbaiki. Hal ini karena kode-kode sumber yang terbuka membuat banyak orang tahu. Keterbukaan ini membuat produk-produk tersebut diperbaiki. Entah bagaimana dengan perangkat lunak yang tidak menyertakan kode sumber.

Salah satu motivasi saya dalam menggunakan FOSS adalah audit kode. Banyak orang ditakut-takuti dengan bilang bahwa kode yang terbuka membuat orang banyak tahu. Namun, justru kode yang terbuka menjamin integritas implementasi. Alternatif yang berbeda menyebabkan setiap orang dapat menggunakan implementasi yang berbeda.