Apa tujuan dari argumen -nodes di openssl?

103

Apa tujuan dari -nodesargumen di openssl?

openssl

— pengguna624409
sumber

Stack Overflow adalah situs untuk pertanyaan pemrograman dan pengembangan. Pertanyaan ini tampaknya di luar topik karena ini bukan tentang pemrograman atau pengembangan. Lihat Topik apa yang dapat saya tanyakan di sini di Pusat Bantuan. Mungkin Super User atau Unix & Linux Stack Exchange akan menjadi tempat yang lebih baik untuk bertanya.

— jww

@jww Saya tidak setuju, openssl adalah perangkat tingkat rendah dan pengembang harus menghadapinya setiap saat. Garisnya cukup kabur, dan akan sangat merugikan jika tidak mengizinkan pertanyaan openssl di sini hanya karena ini merupakan CLI dan bukan C lib.

— gtd

@gtd - itulah yang sering menjadi keluhan ketika saya menandai ini. Lihat juga Di mana saya memposting pertanyaan tentang Dev Ops? . (Tapi saya pikir saya melakukan kesalahan dalam hal ini - pertanyaannya dari tahun 2011, dan saya yakin itu sesuai topik saat itu. Saya tidak suka menghukum untuk perubahan kebijakan).

— jww

@gtd - re: "openssl adalah perangkat tingkat rendah dan pengembang harus menanganinya sepanjang waktu." - untuk itulah Super User atau Unix & Linux Stack Exchange . "... akan sangat merugikan jika tidak mengizinkan pertanyaan openssl ..." - pertanyaan pemrograman openssl C selalu diterima di sini. Hilangnya pertanyaan non-pemrograman tidak akan terlewatkan karena Stack Overflow adalah situs pemrograman dan pengembangan. Ada situs lain untuk dikunjungi jika Anda tidak tahu cara menggunakan perintah.

— jww

Terima kasih untuk tautannya, saya akan mengirimkan tanggapan saya di sana karena menurut saya ini adalah masalah yang sangat penting.

— gtd

Jawaban:

123

Opsinya -nodesbukanlah kata dalam bahasa Inggris "node", melainkan "no DES". Ketika diberikan sebagai argumen, itu berarti OpenSSL tidak akan mengenkripsi kunci privat dalam file PKCS # 12 .

Untuk mengenkripsi kunci privat, Anda dapat menghilangkan -nodesdan kunci Anda akan dienkripsi dengan 3DES-CBC. Untuk mengenkripsi kunci, OpenSSL meminta Anda untuk memasukkan kata sandi dan menggunakan kata sandi tersebut untuk menghasilkan kunci enkripsi menggunakan fungsi turunan kunci EVP_BytesToKey .

Bergantung pada versi OpenSSL Anda dan opsi yang dikompilasi, Anda mungkin dapat memberikan opsi ini sebagai pengganti -nodes:

-des          encrypt private keys with DES
-des3         encrypt private keys with triple DES (default)
-idea         encrypt private keys with idea
-seed         encrypt private keys with seed
-aes128, -aes192, -aes256
              encrypt PEM output with cbc aes
-camellia128, -camellia192, -camellia256
              encrypt PEM output with cbc camellia

Pada akhirnya di tingkat perpustakaan OpenSSL memanggil fungsi PEM_write_bio_PrivateKey dengan algoritma enkripsi (atau ketiadaan) yang Anda pilih.

— individu
sumber

Dengan mengenkripsi, maksud Anda dengan kata sandi?

— Flimm

@Flimm: Dilindungi dengan kata sandi, ya. Kata sandi menghasilkan kunci enkripsi menggunakan algoritma derivasi kunci, dan enkripsi dilakukan dengan kunci tersebut, bukan dengan kata sandi. Satu-satunya cara untuk menggunakan kunci terenkripsi adalah dengan mendekripsinya terlebih dahulu, yang mana Anda perlu mengetahui kata sandi yang dienkripsi untuk menghasilkan kunci yang sama.

— indiv

mengapa saya harus mengenkripsi file kunci pribadi saya? yang tidak dipublikasikan kepada siapa pun, maka namanya. Atau apakah saya salah?

— phil294

@Blauhirn: Anda akan mengenkripsi file kunci pribadi Anda untuk alasan yang sama seperti Anda mengenkripsi file apa pun: Anda tidak ingin seseorang yang memperoleh salinannya dapat membaca atau menggunakannya. Apakah Anda harus mengenkripsi kunci privat tergantung pada pentingnya kunci dan model ancaman Anda.

— indiv

edit: nginx v1.7.3 telah menambahkan direktif ssl_password_file yang membaca frasa sandi dari file tertentu mencoba setiap frasa sandi pada encrypted-private.key konteks

indiv benar bahwa -nodesargumen tersebut berarti OpenSSL akan membuat private.key yang tidak terenkripsi ; jika tidak, akan ada prompt frasa sandi untuk membuat encrypted-private.key . lihat req , pkcs12 , CA.pl

Namun, saya merasa tujuan (untuk programmer) adalah karena:

Server HTTP (misalnya Apache , Nginx ) tidak dapat membaca encrypted-private.key tanpa kata sandi →
- Opsi A - setiap kali server HTTP dimulai, harus memberikan frasa sandi untuk encrypted-private.key
- Opsi B - tentukan ssl_password_file file.keys;dalam http { }atau server { }konteks. [ ref ]
- Opsi C - gunakan -nodesuntuk membuat private.key tanpa enkripsi

berguna: kunci private.key

{tambahkan server HTTP ke grup ssl-cert }
sudo chown root:ssl-cert private.key- ch ange sendiri er dari private.key ke akar pengguna, ssl-cert kelompok
sudo chmod 640 private.key- ubah izin akses private.key menjadi pemilik R / W, grup R.
sekarang, server HTTP seharusnya dapat memulai dan membaca private.key yang tidak terenkripsi

Opsi A

keamanan yang lebih kuat, namun saat server dimulai ulang, harus mengetikkan frasa sandi secara manual untuk encrypted-private.key

Opsi B

keamanan sedang, dan mungkin keseimbangan yang baik antara A / C

Opsi C

keamanan yang lebih lemah, namun TIDAK diminta untuk frasa sandi private.key yang tidak terenkripsi

— Jake Berger
sumber

penjelasan yang sangat baik

— rizidoro

Nginx dapat membaca kunci pribadi terenkripsi sejak versi 1.7.3, lihat: nginx.org/en/docs/http/…

— 5lava

Apa tujuan membawa nginx dan versinya ke dalam diskusi? Juga, (B) dan (C) menawarkan keamanan yang setara (yaitu, sistem file ACL). Masalah yang Anda gambarkan adalah Masalah Penyimpanan Kunci Tanpa Pengawasan , dan ini masalah tanpa solusi. Lihat buku Keamanan Rekayasa Gutmann .

— jww

@jww pertanyaannya menanyakan "apa tujuannya ...". Saya mempertimbangkan konteks pertanyaan (QnA untuk pemrogram), yang saya coba tunjukkan melalui "namun, saya merasa tujuan (untuk pemrogram) adalah karena:". khusus mengenai keamanan .. mungkin bisa menjadi pembahasan untuk security.stackexchange.com

— Jake Berger