Pages

Sabtu, 20 Agustus 2011

Post Pic Mengkonfigurasi HTTPS Server di Nginx

Tulisan ini adalah terjemahan dari dokumentasi Nginx. Sebelumnya saya pernah membuat artikel Konfigurasi HTTPS di Nginx, tapi disana hanya dibahas secara singkat saja.
Dan tulisan yg saya akan terjemahkan ini, membahas lebih lengkap tentang konfigurasi HTTPS di Nginx, ditulis oleh pengembang Nginx, Igor Sysoev.
Tulisan ini adalah terjemahan bebas dari “Configuring HTTPS servers“. Dokumentasi tentang HTTPS server yang ditulis oleh Igor Sysoev, developer nginx.
Untuk mengkonfigurasi HTTPS server, Anda harus mengaktifkan protokol SSL di blok server, dan menuliskan lokasi dari berkas server certificate dan private key:
server {
    listen               443;
    server_name          www.nginx.com;
    ssl                  on;
    ssl_certificate      www.nginx.com.crt;
    ssl_certificate_key  www.nginx.com.key;
    ssl_protocols        SSLv3 TLSv1;
    ssl_ciphers          HIGH:!ADH:!MD5;
    ...
}
Server certificate adalah entitas publik. Ini akan dikirim ke setiap klien yang terhubung ke server. Sedangkan private key adalah entitas keamanan dan harus disimpan dalam berkas dengan akses terbatas, tapi walau terbatas harus bisa dibaca oleh master proses nginx. Private key bisa juga disimpan dalam berkas sama sebagai certificate:
ssl_certificate      www.nginx.com.cert;
    ssl_certificate_key  www.nginx.com.cert;
yang dalam kasus ini akses ke berkas juga harus dibatasi. Meskipun sertifikat dan kuncinya disimpan dalam satu berkas, hanya bagian certificate yang akan dikirim ke klien.
Direktif “ssl_protocols” dan “ssl_chipers” mungkin bisa digunakan untuk membatasi koneksi ke versi aman/kuat (strong) protokol SSL dan chipers. Sejak versi 0.8.20, nginx menggunakan “ssl_protocols SSLv3 TLSv1” dan “ssl_chipers HIGH:!ADH:!MD5” pada konfigurasi default, jadi semua itu hanya harus diset jika menggunakan versi nginx sebelumnya.

Optimasi HTTPS server

Operasi SSL mengkonsumsi sumberdaya CPU lebih banyak. Pada sistem multi prosesor Anda sebaiknya menjalankan beberapa worker processes: tidak lebih sedikit dari jumlah CPU core yang tersedia. Operasi yang paling banyak memakai sumberdaya CPU adalah pada saat SSL handshake.
Ada dua cara untuk meminimalkan jumlah operasi ini per klien: yang pertama adalah mengaktifkan keepalive connections untuk mengirimkan beberapa request melalui satu koneksi dan yang kedua adalah untuk menggunakan ulang sesi SSL untuk menghindari SSL handshake untuk koneksi parallel dan subsequent connections. Sesi-sesi ini disimpan dalam SSL session cache yang di share antara worker dan dikonfigurasi oleh direktif “ssl_session_cache“. Satu megabyte dari cache bisa menyimpan sekitar 4000 sesi. Nilai default untuk cache timeout adalah 5 menit. Dan bias dinaikkan menggunakan direktif “ssl_session_timeout“.
Berikut ini adalah contoh konfigurasi yang sudah dioptimasi untuk sistem quad core dengan 10M shared session cache:
worker_processes  4;
 
http {
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  10m;
 
    server {
        listen               443;
        server_name          www.nginx.com;
        keepalive_timeout    70;
 
        ssl                  on;
        ssl_certificate      www.nginx.com.crt;
        ssl_certificate_key  www.nginx.com.key;
        ssl_protocols        SSLv3 TLSv1;
        ssl_ciphers          HIGH:!ADH:!MD5;
        ...

SSL certifcate chains

Beberapa peramban mungkin komplen tentang sertifikat yang ditandatangani oleh well-kown certificate authority, sementara peramban lainnya mungkin menerima sertifikat tanpa masalah. Hal ini terjadi karena yang mengeluarkan otoritas telah menandatangi sertifikat server menggunakan sertifikat perantara (intermediate certificate) yang tidak tersedia di basis sertifikat dari well-known trusted certificate authorities, tapi dilain sisi sertifikat ini mungkin didistribusikan di sebagian peramban lainnya. Dalam kasus ini si otoritas biasanya menyediakan satu bundle chained certificates yang harus di gabungkan (concatenated) ke sertifikat yang telah ditandatangani. Sertifikat harus muncul sebelum chained certificates pada berkas yang sudah digabung:
$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt
Berkas yang dihasilkan digunakan dalam direktif “ssl_certificate“:
server {
    listen               443;
    server_name          www.nginx.com;
    ssl                  on;
    ssl_certificate      www.nginx.com.chained.crt;
    ssl_certificate_key  www.nginx.com.key;
    ...
}
Jika sertifikate server dan bunel sudah digabungkan dalam urutan yang salah, nginx akan gagal dijalankan dan akan menampilkan pesan error:
SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed
   (SSL: error:0B080074:x509 certificate routines:
    X509_check_private_key:key values mismatch)
karena nginx mencoba menggunakan private key dengan certifikat pertama dari bundle dan bukan ke sertifikat server yang seharusnya.
Peramban biasanya menyimpan sertifikat perantara yang mereka terima dan yang ditandatangani oleh otoritas terpercaya, jadi peramban yang sudah digunakan secara aktif mungkin sudah memiliki sertifikat perantara yang dibutuhkan dan tidak akan komplen tentang sertifikat yang dikirim tanpa bundle. Untuk meyakinkan server mengirimkan certificate chain yang lengkap, Anda bisa menggunakan perintah “openssl“, misalnya:
$ openssl s_client -connect www.godaddy.com:443
...
Certificate chain
 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
     /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
     /OU=MIS Department/CN=www.GoDaddy.com
     /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc.
     /OU=ValiCert Class 2 Policy Validation Authority
     /CN=http://www.valicert.com//emailAddress=info@valicert.com
...
Di contoh ini subject (“s”) dari sertifikat server www.GoDaddy.com #0 ditandatangani oleh issuer (“i”) yang merupakan subject dari sertifikat #1, yang juga ditandatangani oleh issuer yang merupakan subject dari certificate #2, yang ditandatangani oleh well-known issuer ValiCert, Inc. Semua sertifikat itu disimpan di built-in certificate base dari peramban.
Jika Anda tidak menambahkan certificate bundle, Anda hanya akan melihat sertifikate server #0.

A single HTTP/HTTPS server

Merupakan langkah yang baik untuk mengkonfigurasi server secara terpisah untuk protokol HTTP dan HTTPS dari sejak awal. Meskipun mungkin fungsionalitas mereka terlihat mirip, tapi ini bisa saja berubah secara signifikan di masa yang akan datang dan menggunakan server yang digabung mungkin akan menjadi masalah. Walau demikian, jika server HTTP dan HTTPS adalah sama, dan Anda tidak ingin berfikir tentang masa yang akan datang, Anda bisa mengkonfigurasi satu server tunggal yang menangani request HTTP dan HTTPS dengan menghapus direktif “ssl on” dan menambahkan parameter “ssl” untuk port *:443
server {
    listen               80;
    listen               443  ssl;
    server_name          www.nginx.com;
    ssl_certificate      www.nginx.com.crt;
    ssl_certificate_key  www.nginx.com.key;
    ...
}
Semenjak versi 0.8.21, nginx hanya membolehkan parameter “ssl” di set pada socket yang di listen dengan parameter “default”:
listen  443  default  ssl;

Name-based HTTPS servers

Biasanya muncul masalah umum ketika mengkonfigurasi dua atau lebih server HTTPS yang listening pada satu alamat IP:
server {
    listen           443;
    server_name      www.nginx.com;
    ssl              on;
    ssl_certificate  www.nginx.com.crt;
    ...
}
 
server {
    listen           443;
    server_name      www.nginx.org;
    ssl              on;
    ssl_certificate  www.nginx.org.crt;
    ...
}
Dengan konfigurasi ini, peramban menerima sertifikat dari default server, misalnya, www.nginx.com tanpa terpengaruh dengan server name yang direquest. Ini disebabkan karena sifat dari protokol SSL. Koneksi SSL terjadi sebelum browser mengirim request HTTP dan nginx tidak akan pernah tahu nama dari server yang direquest. Oleh karena itu, dia hanya akan menawarkan satu sertifikat dari default server.
Cara lama dan yang paling tokcer untuk mengatasi masalah ini adalah dengan membuat alamat IP terpisah untuk setiap HTTPS server:
server {
    listen           192.168.1.1:443;
    server_name      www.nginx.com;
    ssl              on;
    ssl_certificate  www.nginx.com.crt;
    ...
}
 
server {
    listen           192.168.1.2:443;
    server_name      www.nginx.org;
    ssl              on;
    ssl_certificate  www.nginx.org.crt;
    ...
}

Sertifikat SSL dengan beberapa nama

Ada cara lain untuk berbagi alamat IP antara beberapa HTTPS server, meskipun demikian, semuanya memiliki kelemahan. Salah satu cara adalah menggunakan sertifikat dengan beberapa nama pada bagian SubjectAltName di sertifikat. Sebagai contoh misalnya, www.nginx.com dan www.nginx.org. Tapi, bagian SubjectAltName memiliki panjang yang terbatas.
Cara lain adalah menggunakan sertifikat dengan wildcard name, misalnya, *.nginx.org. Sertifikat ini akan cocok dengan www.nginx.org, tapi tidak akan cocok dengan nginx.org dan www.sub.nginx.org. Dua metode tadi, bisa juga dikombinasikan. Sertifikat bisa saja berisikan exact dan wildcard name pada bagian SubjectAltName, misalnya, nginx.org dan *.nginx.org.
Akan lebih baik untuk menyimpan berkas sertifikat dengan beberapa nama dan berkas kunci privatenya pada level http dari berkas konfigurasi, agar di inherit ke semua server dari satu salinan memori.
ssl_certificate      common.crt;
ssl_certificate_key  common.key;
 
server {
    listen           443;
    server_name      www.nginx.com;
    ssl              on;
    ...
}
 
server {
    listen           443;
    server_name      www.nginx.org;
    ssl              on;
    ...
}

Server Name Indication

Solusi yang lebih mendasar untuk menjalankan beberapa server HTTPS pada satu alamat IP tunggal adalah menggunakan TLSv1.1 Server Name Indication extension (SNI, RFC3546), dimana dia membolehkan peramban melanjutkan request server name pada saat SSL handshake, dan selanjutnya, server akan tahu sertifikat yang mana yang harus digunakan untuk koneksi tersebut. Tapi SNI memiliki dukungan peramban yang terbatas. Saat ini dukungan fitur mulai ada di beberapa versi peramban berikut:
Opera 8.0;
MSIE 7.0 (hanya untuk Windows Vista atau versi lebih tinggi);
Firefox 2.0 dan peramban lain yang menggunakan platform Mozilla Platform rv:1.8.1;
Safari 3.2.1 (Versi Windows mendukung SNI pada Vista atau versi lebih baru);
dan Chrome (Versi Windows mendukung SNI pada Vista atau versi lebih baru).
Untuk menggunakan SNI di nginx, ini harus didukung oleh pustaka OpenSSL yang mana saat nginx dibangun juga oleh pustakan yang sedang ditautkan secara dinamik saat dijalankan. OpenSSL sudah mendukung SNI sejak versi 0.9.8f jika dia dibangun dengan opsi konfigurasi “--enable-tlsext“. Sejak OpenSSL 0.8.9j opsi ini diaktifkan secara default. Jika nginx sudah dibangun dengan dukungan SNI, maka nginx akan menampilkan ini ketika dijalankan dengan pilihan “-V”:
$ nginx -V
...
TLS SNI support enabled
...
Akan tetapi, jika nginx yang sudah diaktifkan SNI nya, tapi ditautkan secara dinamik ke pustaka OpenSSl yang tidak memiliki dukungan SNI, ngixn akan menampilkan peringatan:
nginx was built with SNI support, however, now it is linked
dynamically to an OpenSSL library which has no tlsext support,
therefore SNI is not available

Diposting oleh di 15.20

0 komentar:

Posting Komentar

Langganan: Posting Komentar (Atom)