Panduan untuk TLS Standar Kepatuhan

Transport Layer Security (TLS) Protokol adalah alat utama untuk melindungi komunikasi jaringan melalui Internet. Artikel ini adalah panduan singkat untuk membantu Anda mengkonfigurasi server aman agar sesuai dengan saat ini TLS standar.

Pengantar

Grafik Keamanan Lapisan Transportasi (TLS) protokol adalah alat utama untuk melindungi komunikasi jaringan melalui Internet. Itu (dan pendahulunya, Secure Sockets Layer atau SSL) telah digunakan selama beberapa dekade di banyak aplikasi, tetapi terutama di browser saat mereka berkunjung HTTPS website. TLS biasanya berfungsi dengan tenang di latar belakang, tetapi bertentangan dengan apa yang mungkin dipikirkan, TLS bukan kotak hitam yang hanya berfungsi. Sebaliknya, keamanan TLS menyediakan muncul dari kerjasama berbagai algoritma kriptografi. Bahkan, TLS, seperti SSL sebelumnya, terus berkembang dengan industri keamanan — persyaratan bisnis dan teknologi baru harus dipenuhi, sementara ancaman keamanan terbaru harus dikurangi. Algoritme dapat menjadi usang seiring waktu, atau praktik dapat ditinggalkan, dengan setiap perubahan yang memengaruhi keamanan a TLS contoh (seperti yang melindungi koneksi Anda sekarang).

Volatilitas ini telah memotivasi berbagai organisasi standar untuk menerbitkan dokumen pedoman, sehingga baseline minimum untuk TLS keamanan dapat dibangun di pasar, sektor atau layanan tertentu. Sayangnya, ada banyak standar seperti itu, dengan sektor yang berbeda membutuhkan kepatuhan dengan dokumen yang berbeda dan berlaku, sedangkan standar itu sendiri juga berkembang dari waktu ke waktu, mengakomodasi perubahan dalam sektor yang dirancang untuk dilindungi.

Maklum, menavigasi melalui lautan standar ini untuk mendirikan modern TLS Misalnya bisa sangat memusingkan bagi administrator. Artikel ini adalah panduan singkat untuk membantu Anda mengkonfigurasi server aman agar sesuai dengan yang diharapkan TLS standar pada tahun 2021. (Untuk bantuan lebih lanjut, kami juga telah memberikan contoh konfigurasi dari solusi server web paling populer di lampiran.)

Standar

Ada beberapa entitas yang mempertahankan pedoman untuk TLS terkait dengan keamanan jaringan, seperti Departemen Kesehatan dan Layanan Kemanusiaan (HHS) Amerika Serikat atau Institut Standar dan Teknologi Nasional (NIST). Agar singkatnya, artikel ini hanya akan mempelajari tiga dokumen yang paling banyak diadopsi:

1. Grafik Portabilitas Asuransi Kesehatan dan Akuntabilitas Act (HIPAA)
2. NIST Pedoman SP 800-52r2
3. Grafik Standar Keamanan Data Industri Kartu Pembayaran (PCI-DSS)

HIPAA

HIPAA adalah peraturan yang diberlakukan oleh pemerintah AS pada tahun 1996, tentang penanganan yang aman atas Informasi Kesehatan yang Dilindungi (PHI). PHI mengacu pada informasi pasien digital, seperti hasil tes atau diagnosis. A HIPAA dokumen pedoman diterbitkan tahun 2013 menyatakan sebagai berikut:

Proses enkripsi yang valid untuk data yang bergerak adalah yang sesuai dengan NIST Special Publications 800-52, Pedoman Pemilihan dan Penggunaan Transport Layer Security (TLS) Implementasi; 800-77, Panduan ke IPsec VPN; atau 800-113, Panduan ke SSL VPN, atau lainnya yang divalidasi Standar Pemrosesan Informasi Federal (FIPS) 140-2.

Standar NIST

Pada tahun 2005, NIST menerbitkan Publikasi Khusus (SP) 800-52, menjelaskan prosedur operasional yang benar untuk mengkonfigurasi a TLS misalnya untuk server pemerintah. SP 800-52 telah digantikan oleh versi SP 800-52r1 (2014) dan SP 80052r2 (2019). Artikel ini mengikuti pedoman SP 800-52r2, yang saat ini stabil.

PCI DSS

PCI-DSS adalah standar kepatuhan yang dikelola oleh Dewan Keamanan Standar Industri Kartu (PCI) Standar Keamanan (SSC) yang menetapkan bagaimana pembayaran dan informasi kartu ditangani oleh situs web e-commerce. Mengenai konfigurasi yang tepat dari TLS contoh, PCI-DSS menyatakan:

"Lihat standar industri dan praktik terbaik untuk informasi tentang kriptografi yang kuat dan protokol aman (misalnya NIST SP 800-52 dan SP 800-57, OWASP, dll.)"

TLS standar: menyatukan semua ini

Perlu dicatat sekarang bahwa setiap standar mempengaruhi sistem yang berbeda, berdasarkan fungsinya dan data yang mereka tangani. Misalnya, server email rumah sakit dapat termasuk dalam pedoman HIPAA karena pesan yang dipertukarkan mungkin berisi informasi pasien, sedangkan sistem CRM rumah sakit mungkin termasuk dalam PCI-DSS karena dapat berisi kartu kredit dan data pelanggan lainnya. Memenuhi ketiga standar akan membutuhkan penggunaan umum TLS parameter ada di semua dokumen.

Untungnya, terlihat jelas bahwa semua standar mengikuti pedoman NIST untuk pemilihan TLS parameter. Ini berarti bahwa, pada saat penulisan ini, menjadi patuh dengan SP 800-52r2 harus membuat server patuh dengan HIPAA dan PCI-DSS juga. (Oke, ini bukan persis benar, tetapi semuanya akan menjadi lebih jelas di bagian selanjutnya.)

dikonfigurasi TLS parameter

Tingkat keamanannya TLS menyediakan paling terpengaruh oleh versi protokol (mis. 1.0, 1.1, dll.) dan diizinkan suite sandi. Cipher adalah algoritma yang melakukan enkripsi dan dekripsi. Namun demikian, a suite sandi adalah seperangkat algoritma, termasuk cipher, algoritma pertukaran kunci dan algoritma hashing, yang digunakan bersama untuk membangun keamanan TLS koneksi. Paling TLS klien dan server mendukung banyak alternatif, sehingga mereka harus bernegosiasi ketika membuat koneksi yang aman untuk memilih yang umum TLS versi dan paket sandi.

TLS versi protokol

Mengenai TLS dukungan versi, NIST SP 800-52r2 menyatakan sebagai berikut:

Server yang mendukung aplikasi khusus pemerintah akan dikonfigurasi untuk digunakan TLS 1.2 dan harus dikonfigurasi untuk digunakan TLS 1.3 juga. Server ini jangan dikonfigurasi untuk digunakan TLS 1.1 dan seharusnya tidak menggunakan TLS 1.0, SSL 3.0, atau SSL 2.0.

...

Server yang mendukung aplikasi warga negara atau bisnis (yaitu, klien mungkin bukan bagian dari sistem TI pemerintah) akan dikonfigurasi untuk bernegosiasi TLS 1.2 dan harus dikonfigurasi untuk bernegosiasi TLS 1.3. Penggunaan TLS versi 1.1 dan 1.0 umumnya tidak disarankan, tetapi versi ini dapat dikonfigurasi bila diperlukan untuk mengaktifkan interaksi dengan warga dan bisnis… Server ini seharusnya tidak izinkan penggunaan SSL 2.0 atau SSL 3.0.

agen akan mendukung TLS 1.3 pada 1 Januari 2024. Setelah tanggal ini, server akan mendukung TLS 1.3 untuk aplikasi khusus pemerintah dan warga negara atau bisnis. Secara umum, server yang mendukung TLS 1.3 harus dikonfigurasi untuk digunakan TLS 1.2 juga. Namun, TLS 1.2 mungkin dinonaktifkan di server yang mendukung TLS 1.3 jika sudah ditentukan itu TLS 1.2 tidak diperlukan untuk interoperabilitas.

Sementara TLS 1.0 dilarang dan TLS 1.1 tidak digunakan lagi untuk situs pemerintah, pedoman NIST menyatakan bahwa untuk kompatibilitas dengan layanan pihak ketiga, server yang dikendalikan pemerintah mungkin melaksanakan TLS 1.0 dan 1.1 bila perlu. Di bawah PCI-DSS 3.2.1 (versi saat ini), server yang sesuai harus meninggalkan dukungan untuk TLS 1.0 dan "bermigrasi ke minimum TLS 1.1, Lebih disukai TLS 1.2. " HIPAA secara teknis mengizinkan penggunaan semua versi TLS. Jadi minimum umumnya didukung TLS versi 1.1; Namun, PCI-DSS dan NIST sangat menyarankan penggunaan yang lebih aman TLS 1.2 (dan, seperti yang terlihat di atas, NIST merekomendasikan adopsi TLS 1.3 dan berencana membutuhkan dukungan pada tahun 2024).

Suites sandi

TLS 1.2 dan Sebelumnya

SP 800-52r2 menentukan berbagai cipher suite yang dapat diterima untuk TLS 1.2 dan sebelumnya. Standar tersebut tidak memerlukan dukungan untuk cipher suite tertentu, tetapi menawarkan panduan untuk memilih yang lebih kuat:

1. Lebih memilih kunci efemeral daripada kunci statis (yaitu, lebih memilih DHE daripada DH, dan lebih memilih ECDHE daripada ECDH). Kunci singkat memberikan kerahasiaan ke depan yang sempurna.
2. Lebih suka mode GCM atau CCM daripada mode CBC. Penggunaan mode enkripsi terotentikasi mencegah beberapa serangan (lihat Bagian 3.3.2 [dari SP 800-52r2] untuk informasi lebih lanjut). Perhatikan bahwa ini tidak tersedia dalam versi sebelumnya TLS 1.2.
3. Lebih suka CCM daripada CCM_8. Yang terakhir berisi tag otentikasi yang lebih pendek, yang memberikan kekuatan otentikasi yang lebih rendah.

Selanjutnya, meskipun ini adalah diijinkan suite sandi, jika Anda TLS Server tidak berurusan dengan berbagai macam platform dan klien yang berbeda, disarankan bahwa hanya sebagian kecil dari algoritma ini yang digunakan. Mengizinkan lebih banyak cipher suites hanya dapat memperluas permukaan serangan ke server Anda jika (atau kapan) kerentanan protokol baru ditemukan.

TLS 1.3

TLS 1.3 memiliki daftar cipher suite yang jauh lebih pendek:

• TLS_AES_128_GCM_SHA256 (0x13, 0x01)
• TLS_AES_256_GCM_SHA384 (0x13, 0x02)
• TLS_AES_128_CCM_SHA256 (0x13, 0x04)
• TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)

Kesimpulan

Kami harap panduan singkat ini akan membantu Anda lebih memahami TLS, dan membantu Anda saat mengonfigurasi TLS di server Anda sendiri. Sehubungan dengan standar dan rekomendasi yang telah kita diskusikan, bagian berikut berisi contoh konfigurasi yang seharusnya dapat Anda terapkan pada solusi server web paling populer. Jika Anda memiliki pertanyaan tentang bagaimana menjaga kepatuhan online Anda, jangan ragu untuk menghubungi kami melalui email Support@SSL.com atau mengklik tombol live chat di bagian bawah layar ini.

Lampiran: Contoh TLS konfigurasi

Mengumpulkan aturan yang dinyatakan dalam tiga dokumen spesifikasi, server aman modern harus diimplementasikan TLS 1.2 dan / atau TLS 1.3, dengan daftar cipher suite pilihan yang singkat tapi beragam. Sebagai referensi cepat, contoh konfigurasi untuk server web paling populer di pasar ditunjukkan di bawah ini. Ini adalah konfigurasi "menengah" (tujuan umum) yang dibuat dengan Mozilla Generator Konfigurasi SSL:

... SSLProtokol semua -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHAHA384: ECDHE-ECDSA POLY20: ECDHE-RSA-CHACHA1305-POLY20: DHE-RSA-AES1305-GCM-SHA128: DHE-RSA-AES256-GCM-SHA256 SSLHonorCipherOrder nonaktif SSLSessionTickets mati

... ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

... ssl.openssl.ssl-conf-cmd = ("Protocol" => "ALL, -SSLv2, -SSLv3, -TLSv1, -TLSv1.1 ") ssl.cipher-list =" ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM- SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384 "ssl.honor-cipher-order =" nonaktifkan "

...

ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 tidak-tlsv11 tidak-tls-tickets

ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-server-options no-sslv3 no-tlsv10 tidak-tlsv11 tidak-tls-tiket

... Kebijakan: - PolicyName: Mozilla-intermediate-v5-0 PolicyType: SSLNegotiationPolicyType Attributes: - Name: Protocol-TLSv1.2 Nilai: true - Nama: Server-Defined-Cipher-Order Nilai: false - Nama: ECDHE-ECDSA-AES128-GCM-SHA256 Nilai: true - Nama: ECDHE-RSA-AES128-GCM-SHA256 Nilai: true - Nama: ECDHE-ECDSA-AES256-GCM-SHA384 Nilai: true - Nama: ECDHE-RSA-AES256-GCM-SHA384 Nilai: true - Nama: DHE-RSA-AES128-GCM-SHA256 Nilai: true - Nama: DHE-RSA -AES256-GCM-SHA384 Nilai: true