OpenVPN EC vs ED: mengapa nama-nama ini bukan tangga kekuatan

Letakkan ec, ed, ecdh, ecdsa, auth dan senarai sifer TLS bersebelahan dalam satu profil, dan fail itu mula kelihatan seperti dail kekuatan dengan enam kedudukan. Tetapi ia bukan. Setiap nama menjawab soalan yang berbeza, dan dua profil yang berbeza pada salah satunya tidak semestinya lebih kuat atau lebih lemah antara satu sama lain. Menyusun nama mengikut kerja yang dilakukannya mengambil masa kira-kira lima minit dan menghalang kebanyakan suntingan buruk yang dilakukan orang pada konfigurasi yang berfungsi.

Susunan di bawah bermula daripada kekeliruan itu sendiri, kemudian bergerak ke luar ke bahagian profil yang benar-benar menentukan apa yang melindungi trafik anda. Setiap bahagian mengambil satu salah baca secara bergilir dan menunjukkan apa yang sebenarnya terikat pada nama itu.

Dua huruf, dua soalan berbeza

Pasangan yang paling banyak menimbulkan perdebatan ialah EC dan ED, dan perdebatan itu biasanya menganggap kedua-duanya jawapan bersaing kepada satu soalan. Kedua-duanya bukan pun pada paksi yang sama. EC menerangkan satu keluarga matematik: kriptografi lengkung eliptik, tempat keselamatan datang daripada kesukaran logaritma diskret pada lengkung dan bukan dalam medan terhingga yang besar.

ED menerangkan bentuk lengkung di dalam keluarga itu. Lengkung Twisted Edwards ialah perwakilan yang dipilih kerana kelajuan dan kerana ketahanan terhadap beberapa kesilapan pelaksanaan, dan Ed25519 ialah nama yang biasanya dimaksudkan orang. Lengkung itu bukan pesaing kriptografi lengkung eliptik; ia salah satu cara menulis lengkung eliptik. Membaca ED sebagai "EC yang lebih baharu dan lebih kuat" ialah selekoh salah yang pertama, dan segala-galanya selepas itu cenderung salah ke arah yang sama.

Menandatangani dan menukar ialah kerja berasingan

Sebaik sahaja soalan keluarga diselesaikan, nama-nama yang tinggal terbahagi kepada dua lajur yang tidak pernah menggantikan satu sama lain. Satu lajur menandatangani, yang lain bersetuju tentang rahsia bersama.

EdDSA dan ECDSA kedua-duanya menandatangani, tetapi ia skema berbeza dengan format kunci yang berbeza, jadi sijil yang dikeluarkan untuk satu tidak boleh digunakan sebagai yang lain. EdDSA ditakrifkan untuk set lengkung yang kecil; P-256 bukan salah satunya, sebab itulah sijil P-256 disahkan dengan ECDSA dan tidak pernah dengan Ed25519.

Lajur pertukaran tiada persamaan bernama EdDH. Persetujuan efemeral pada kunci Curve25519 ialah X25519, dan itu ECDH dengan lengkung tertentu, sama seperti dengan P-256. Ed25519 secara ketat bermaksud skema tandatangan, walaupun nama itu digunakan secara longgar untuk pertukaran kerana kedua-dua lengkung berkaitan: bentuk Edwards yang digunakan untuk menandatangani dan bentuk Montgomery yang digunakan untuk X25519 menerangkan kumpulan asas yang sama.

Mengapa profil EC tiada fail dh

Fail dh mengandungi parameter yang dijana terlebih dahulu untuk Diffie-Hellman medan terhingga, dan parameter itu wujud kerana nombor perdana besar dan penjana mesti datang dari suatu tempat. Pertukaran lengkung eliptik tidak memerlukannya: lengkung yang dinamakan ialah set parameter, dan kedua-dua pihak sudah mengetahuinya. Itulah seluruh sebab profil EC boleh meninggalkan direktif itu.

Dua keadaan masih menghasilkan baris dh dalam profil yang sebaliknya kelihatan moden. Yang pertama ialah pendengar kedua atau rakan lama yang benar-benar merundingkan kumpulan medan terhingga. Yang kedua ialah teks sisa yang disalin daripada templat era RSA dan tidak pernah dibuang. Profil yang menamakan lengkung untuk pertukaran dan masih memuatkan fail dh 2048-bit tidak lebih selamat kerana berbuat demikian; ia membawa artifak yang tidak digunakan.

TLS 1.3 membuang pertukaran kunci daripada nama

Bandingkan TLS_AES_256_GCM_SHA384 dengan TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 dan nama yang lebih pendek kelihatan seperti penurunan. Ini penamaan semula, dan alasannya bersifat struktur: TLS 1.3 membuang RSA statik dan pertukaran kunci Diffie-Hellman medan terhingga, jadi pertukaran lengkung eliptik efemeral ialah satu-satunya pilihan bukan PSK yang tinggal. Menamakannya dalam setiap suit akan mengulang fakta yang sama sedozen kali.

Jenis sijil hilang daripada nama atas sebab yang berkaitan. Dalam 1.3 sijil mengesahkan tandatangan jabat tangan, bukan persetujuan kunci, jadi ia tidak lagi memilih suit. Itulah juga sebabnya ada senarai sifer berasingan untuk 1.3 dalam konfigurasi: suit telah dinamakan semula dan disusun semula, bukan dilemahkan.

Satu akibat wajar dinyatakan dengan terus terang. ECDHE ialah algoritma pertukaran kunci dan tidak pernah sifer. Suit yang digambarkan sebagai "eliptik" memberitahu sesuatu tentang bagaimana kedua-dua rakan mencapai kunci bersama, dan tidak sama sekali tentang apa yang kemudian menyulitkan muatan.

auth mengesahkan paket, bukan muatan

Direktif auth memilih penghadaman HMAC yang mengesahkan paket, dan nilai lalainya dari segi sejarah ialah SHA1. Dengan sifer data bukan AEAD, OpenVPN mengira penghadaman atas teks sifer dan menambahkannya, susunan sulit-kemudian-MAC yang menjadikan manipulasi pelapik tidak praktikal.

Mitos di sini ialah menaikkan auth kepada SHA512 mengeraskan terowong. Ia tidak menaikkan kekuatan penyulitan, dan jika sifer data yang dirundingkan ialah mod AEAD seperti AES-256-GCM, penghadaman itu tidak dikenakan langsung pada paket data. Tag GCM sudah mengesahkannya, dan nilai auth ditinggalkan untuk HMAC saluran kawalan dan untuk mana-mana sifer bukan AEAD yang masih digunakan.

Jadi direktif itu penting, tetapi ia penting di tempat yang lebih sempit daripada yang dicadangkan oleh kedudukannya dalam fail. Menyemak sifer mana yang benar-benar dirundingkan memberitahu anda sama ada ia terpakai sama sekali.

Baca profil mengikut lajur, bukan mengikut pangkat

Tiga soalan memisahkan lapisan dengan bersih, dan setiap satu dijawab oleh bahagian sesi yang dirundingkan yang berbeza. Sifer mana yang melindungi muatan? Tag atau penghadaman mana yang menjamin setiap paket, dan adakah sifer yang digunakan memerlukannya langsung? Sijil siapa yang menutup jabat tangan, dan adakah saluran kawalan juga dilindungi oleh tls-auth atau tls-crypt?

Tiada apa-apa pada label EC atau ED yang menyelesaikan mana-mana satu daripada ketiga-tiganya, dan nama suit sahaja juga tidak menyelesaikan mana-mana satu daripadanya. Hasil yang dirundingkan ialah satu-satunya bukti, jadi bacalah ia daripada menyimpulkan kekuatan daripada kosa kata:

openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.log

Perintah pertama memberitahu anda skema tandatangan mana yang sebenarnya digunakan oleh sijil anda, dan itulah satu-satunya cara yang boleh dipercayai untuk mengetahui sama ada anda menjalankan ECDSA atau Ed25519. Yang kedua menunjukkan baris saluran kawalan yang direkodkan oleh klien untuk sesi itu, termasuk versi TLS dan suit yang diselesaikannya. Jika sesuatu suntingan profil tidak dapat dijustifikasikan oleh salah satu daripada dua output itu, ia mungkin perubahan nama dan bukan perubahan sifat.