WireGuard telah mendapatkan banyak perhatian akhir-akhir ini, sebenarnya ini adalah bintang baru di antara VPN. Tapi apakah dia sebaik kelihatannya? Saya ingin membahas beberapa pengamatan dan meninjau implementasi WireGuard untuk menjelaskan mengapa ini bukan solusi untuk mengganti IPsec atau OpenVPN.
Dalam artikel ini, saya ingin menyanggah beberapa mitos [seputar WireGuard]. Ya, akan memakan waktu lama untuk membacanya, jadi jika Anda belum membuat secangkir teh atau kopi untuk diri sendiri, maka inilah waktunya. Saya juga ingin mengucapkan terima kasih kepada Peter karena telah mengoreksi pikiran saya yang kacau.
Saya tidak menetapkan tujuan untuk mendiskreditkan pengembang WireGuard, merendahkan upaya atau ide mereka. Produk mereka berfungsi, tetapi secara pribadi menurut saya ini disajikan sangat berbeda dari yang sebenarnya - ini disajikan sebagai pengganti IPsec dan OpenVPN, yang sebenarnya tidak ada sekarang.
Sebagai catatan, saya ingin menambahkan bahwa tanggung jawab untuk memposisikan WireGuard seperti itu terletak pada media yang membicarakannya, dan bukan pada proyek itu sendiri atau pembuatnya.
Belum banyak kabar baik tentang kernel Linux akhir-akhir ini. Jadi, kami diberi tahu tentang kerentanan prosesor yang mengerikan, yang diratakan oleh perangkat lunak, dan Linus Torvalds membicarakannya terlalu kasar dan membosankan, dalam bahasa utilitarian pengembang. Penjadwal atau tumpukan jaringan tingkat nol juga bukan topik yang sangat jelas untuk majalah glossy. Dan inilah WireGuard.
Di atas kertas, semuanya terdengar hebat: sebuah teknologi baru yang menarik.
Tapi mari kita lihat sedikit lebih dekat.
kertas putih WireGuard
Artikel ini didasarkan pada ditulis oleh Jason Donenfeld. Di sana ia menjelaskan konsep, tujuan, dan penerapan teknis [WireGuard] di kernel Linux.
Kalimat pertama berbunyi:
WireGuard [β¦] bertujuan untuk mengganti IPsec di sebagian besar kasus penggunaan dan ruang pengguna populer lainnya dan/atau solusi berbasis TLS seperti OpenVPN sembari menjadi lebih aman, berkinerja, dan lebih mudah digunakan [alat].
Tentu saja, keunggulan utama dari semua teknologi baru adalah milik mereka kesederhanaan [dibandingkan dengan pendahulunya]. Tapi VPN juga harus efektif dan aman.
Jadi, apa selanjutnya?
Jika Anda mengatakan bahwa ini bukan yang Anda butuhkan [dari VPN], maka Anda dapat mengakhiri bacaan di sini. Namun, saya perhatikan bahwa tugas tersebut ditetapkan untuk teknologi tunneling lainnya.
Yang paling menarik dari kutipan di atas terletak pada kata-kata "dalam banyak kasus", yang tentu saja diabaikan oleh pers. Jadi, kita berada di tempat kita berakhir karena kekacauan yang diciptakan oleh kelalaian ini - dalam artikel ini.
Akankah WireGuard mengganti VPN situs-ke-situs [IPsec] saya?
TIDAK. Tidak ada kemungkinan vendor besar seperti Cisco, Juniper, dan lainnya akan membeli WireGuard untuk produk mereka. Mereka tidak "melompati kereta yang lewat" saat bergerak kecuali ada kebutuhan besar untuk melakukannya. Nanti, saya akan membahas beberapa alasan mengapa mereka mungkin tidak bisa mendapatkan produk WireGuard mereka meskipun mereka menginginkannya.
Akankah WireGuard membawa RoadWarrior saya dari laptop ke pusat data?
TIDAK. Saat ini, WireGuard tidak memiliki sejumlah besar fitur penting yang diterapkan agar dapat melakukan hal seperti ini. Misalnya, tidak dapat menggunakan alamat IP dinamis di sisi server terowongan, dan ini saja merusak seluruh skenario penggunaan produk tersebut.
IPFire sering digunakan untuk link internet murah, seperti koneksi DSL atau kabel. Ini masuk akal untuk usaha kecil atau menengah yang tidak membutuhkan serat cepat. [Catatan dari penerjemah: jangan lupa bahwa dalam hal komunikasi, Rusia dan beberapa negara CIS jauh di depan Eropa dan Amerika Serikat, karena kami mulai membangun jaringan jauh kemudian dan dengan munculnya jaringan Ethernet dan serat optik sebagai standar, lebih mudah bagi kami untuk membangun kembali. Di negara yang sama di UE atau AS, akses broadband xDSL dengan kecepatan 3-5 Mbps masih menjadi norma umum, dan koneksi serat optik menghabiskan biaya yang tidak realistis menurut standar kami. Oleh karena itu, penulis artikel berbicara tentang DSL atau koneksi kabel sebagai norma, dan bukan zaman kuno.] Namun, DSL, kabel, LTE (dan metode akses nirkabel lainnya) memiliki alamat IP dinamis. Tentu saja, terkadang mereka tidak sering berubah, tetapi mereka berubah.
Ada subproyek bernama , yang menambahkan daemon userspace untuk mengatasi kekurangan ini. Masalah besar dengan skenario pengguna yang dijelaskan di atas adalah kejengkelan pengalamatan IPv6 dinamis.
Dari sudut pandang distributor, semua ini juga tidak terlihat bagus. Salah satu tujuan desain adalah untuk menjaga agar protokol tetap sederhana dan bersih.
Sayangnya, semua ini sebenarnya menjadi terlalu sederhana dan primitif, sehingga kami harus menggunakan perangkat lunak tambahan agar keseluruhan desain ini dapat digunakan secara nyata.
Apakah WireGuard begitu mudah digunakan?
Belum. Saya tidak mengatakan bahwa WireGuard tidak akan pernah menjadi alternatif yang baik untuk melakukan tunneling antara dua titik, tetapi untuk saat ini ini hanyalah versi alfa dari produk yang seharusnya.
Tapi lalu apa yang sebenarnya dia lakukan? Apakah IPsec benar-benar lebih sulit dipertahankan?
Tentu saja tidak. Vendor IPsec telah memikirkan hal ini dan mengirimkan produk mereka bersama dengan antarmuka, seperti dengan IPFire.
Untuk mengatur terowongan VPN melalui IPsec, Anda memerlukan lima set data yang harus Anda masukkan ke dalam konfigurasi: alamat IP publik Anda sendiri, alamat IP publik pihak penerima, subnet yang ingin Anda publikasikan melalui koneksi VPN ini dan kunci yang dibagikan sebelumnya. Dengan demikian, VPN disiapkan dalam hitungan menit dan kompatibel dengan vendor mana pun.
Sayangnya, ada beberapa pengecualian untuk cerita ini. Siapa pun yang telah mencoba melakukan tunnel melalui IPsec ke mesin OpenBSD tahu apa yang saya bicarakan. Ada beberapa contoh yang lebih menyakitkan, tetapi pada kenyataannya, ada banyak lagi praktik yang baik untuk menggunakan IPsec.
Tentang kompleksitas protokol
Pengguna akhir tidak perlu khawatir tentang kerumitan protokol.
Jika kita hidup di dunia di mana ini benar-benar menjadi perhatian pengguna, maka kita sudah lama menyingkirkan SIP, H.323, FTP, dan protokol lain yang dibuat lebih dari sepuluh tahun lalu yang tidak berfungsi dengan baik dengan NAT.
Ada alasan mengapa IPsec lebih kompleks daripada WireGuard: IPsec melakukan lebih banyak hal. Misalnya, otentikasi pengguna menggunakan login / kata sandi atau kartu SIM dengan EAP. Ini memiliki kemampuan yang diperluas untuk menambahkan yang baru .
Dan WireGuard tidak memilikinya.
Dan ini berarti WireGuard akan rusak di beberapa titik, karena salah satu primitif kriptografi akan melemah atau dikompromikan sepenuhnya. Penulis dokumentasi teknis mengatakan ini:
Perlu dicatat bahwa WireGuard memiliki pendapat kriptografis. Itu sengaja tidak memiliki fleksibilitas sandi dan protokol. Jika lubang serius ditemukan di primitif yang mendasarinya, semua titik akhir perlu diperbarui. Seperti yang Anda lihat dari aliran kerentanan SLL/TLS yang sedang berlangsung, fleksibilitas enkripsi kini telah meningkat pesat.
Kalimat terakhir benar sekali.
Mencapai konsensus tentang enkripsi apa yang digunakan membuat protokol seperti IKE dan TLS lebih kompleks. Terlalu rumit? Ya, kerentanan cukup umum di TLS/SSL, dan tidak ada alternatif selain itu.
Tentang mengabaikan masalah nyata
Bayangkan Anda memiliki server VPN dengan 200 klien pertempuran di suatu tempat di seluruh dunia. Ini adalah kasus penggunaan yang cukup standar. Jika Anda harus mengubah enkripsi, Anda perlu mengirimkan pembaruan ke semua salinan WireGuard di laptop, ponsel cerdas, dan sebagainya ini. Serentak mengantarkan. Ini benar-benar tidak mungkin. Administrator yang mencoba melakukan ini akan membutuhkan waktu berbulan-bulan untuk menerapkan konfigurasi yang diperlukan, dan ini benar-benar akan memakan waktu bertahun-tahun bagi perusahaan menengah untuk melakukan peristiwa semacam itu.
IPsec dan OpenVPN menawarkan fitur negosiasi cipher. Oleh karena itu, untuk beberapa waktu setelah Anda mengaktifkan enkripsi baru, yang lama juga akan berfungsi. Ini akan memungkinkan pelanggan saat ini untuk meningkatkan ke versi baru. Setelah pembaruan diluncurkan, Anda cukup mematikan enkripsi yang rentan. Dan itu saja! Siap! kamu cantik! Klien bahkan tidak akan menyadarinya.
Ini sebenarnya adalah kasus yang sangat umum untuk penyebaran besar, dan bahkan OpenVPN mengalami kesulitan dengan ini. Kompatibilitas mundur itu penting, dan meskipun Anda menggunakan enkripsi yang lebih lemah, bagi banyak orang, ini bukan alasan untuk menutup bisnis. Karena akan melumpuhkan pekerjaan ratusan pelanggan karena tidak mampu melakukan pekerjaannya.
Tim WireGuard telah membuat protokol mereka lebih sederhana, tetapi sama sekali tidak dapat digunakan oleh orang-orang yang tidak memiliki kendali konstan atas kedua rekan di terowongan mereka. Dalam pengalaman saya, ini adalah skenario yang paling umum.
Kriptografi!
Tapi apa enkripsi baru yang menarik yang digunakan WireGuard ini?
WireGuard menggunakan Curve25519 untuk pertukaran kunci, ChaCha20 untuk enkripsi, dan Poly1305 untuk otentikasi data. Ini juga berfungsi dengan SipHash untuk kunci hash dan BLAKE2 untuk hashing.
ChaCha20-Poly1305 distandarisasi untuk IPsec dan OpenVPN (melalui TLS).
Jelas bahwa perkembangan Daniel Bernstein sangat sering digunakan. BLAKE2 adalah penerus BLAKE, finalis SHA-3 yang tidak menang karena kemiripannya dengan SHA-2. Jika SHA-2 akan dilanggar, ada kemungkinan besar BLAKE juga akan disusupi.
IPsec dan OpenVPN tidak memerlukan SipHash karena desainnya. Jadi satu-satunya hal yang saat ini tidak dapat digunakan dengan mereka adalah BLAKE2, dan itu hanya sampai standar. Ini bukan kelemahan besar, karena VPN menggunakan HMAC untuk menciptakan integritas, yang dianggap sebagai solusi yang kuat bahkan jika digabungkan dengan MD5.
Jadi saya sampai pada kesimpulan bahwa perangkat kriptografi yang hampir sama digunakan di semua VPN. Oleh karena itu, WireGuard tidak lebih atau kurang aman dibandingkan produk lain saat ini dalam hal enkripsi atau integritas data yang dikirimkan.
Tetapi bahkan ini bukanlah hal terpenting yang perlu diperhatikan menurut dokumentasi resmi proyek. Bagaimanapun, yang utama adalah kecepatan.
Apakah WireGuard lebih cepat daripada solusi VPN lainnya?
Singkatnya: tidak, tidak lebih cepat.
ChaCha20 adalah cipher aliran yang lebih mudah diimplementasikan dalam perangkat lunak. Ini mengenkripsi satu bit pada satu waktu. Protokol blok seperti AES mengenkripsi blok 128 bit sekaligus. Lebih banyak transistor diperlukan untuk mengimplementasikan dukungan perangkat keras, sehingga prosesor yang lebih besar hadir dengan AES-NI, ekstensi set instruksi yang melakukan beberapa tugas proses enkripsi untuk mempercepatnya.
Diharapkan AES-NI tidak akan pernah masuk ke smartphone [tapi ternyata β kira-kira. per.]. Untuk itu, ChaCha20 dikembangkan sebagai alternatif yang ringan dan hemat baterai. Oleh karena itu, mungkin menjadi berita bagi Anda bahwa setiap ponsel cerdas yang dapat Anda beli hari ini memiliki semacam akselerasi AES dan berjalan lebih cepat serta dengan konsumsi daya yang lebih rendah dengan enkripsi ini dibandingkan dengan ChaCha20.
Jelas, hampir setiap prosesor desktop/server yang dibeli dalam beberapa tahun terakhir memiliki AES-NI.
Oleh karena itu, saya berharap AES mengungguli ChaCha20 di setiap skenario. Dokumentasi resmi WireGuard menyebutkan bahwa dengan AVX512, ChaCha20-Poly1305 akan mengungguli AES-NI, tetapi ekstensi set instruksi ini hanya akan tersedia pada CPU yang lebih besar, yang sekali lagi tidak akan membantu dengan perangkat keras seluler yang lebih kecil dan lebih banyak, yang akan selalu lebih cepat dengan AES - N.I.
Saya tidak yakin apakah hal ini dapat diramalkan selama pengembangan WireGuard, tetapi saat ini fakta bahwa WireGuard terpaku pada enkripsi saja sudah merupakan kelemahan yang mungkin tidak memengaruhi operasinya dengan baik.
IPsec memungkinkan Anda untuk bebas memilih enkripsi mana yang terbaik untuk kasus Anda. Dan tentu saja, ini diperlukan jika, misalnya, Anda ingin mentransfer 10 atau lebih gigabyte data melalui koneksi VPN.
Masalah integrasi di Linux
Meskipun WireGuard telah memilih protokol enkripsi modern, ini sudah menyebabkan banyak masalah. Jadi, alih-alih menggunakan apa yang didukung oleh kernel out of the box, integrasi WireGuard telah tertunda selama bertahun-tahun karena kurangnya primitif ini di Linux.
Saya tidak sepenuhnya yakin bagaimana situasinya di sistem operasi lain, tetapi mungkin tidak jauh berbeda dengan di Linux.
Seperti apa realitas itu?
Sayangnya, setiap kali klien meminta saya menyiapkan koneksi VPN untuk mereka, saya mengalami masalah bahwa mereka menggunakan kredensial dan enkripsi yang sudah usang. 3DES bersama dengan MD5 masih merupakan praktik umum, begitu pula AES-256 dan SHA1. Dan meskipun yang terakhir sedikit lebih baik, ini bukanlah sesuatu yang harus digunakan di tahun 2020.
Untuk pertukaran kunci selalu RSA digunakan - alat yang lambat tapi cukup aman.
Klien saya terkait dengan otoritas pabean dan organisasi dan institusi pemerintah lainnya, serta dengan perusahaan besar yang namanya dikenal di seluruh dunia. Mereka semua menggunakan formulir permintaan yang dibuat beberapa dekade lalu, dan kemampuan untuk menggunakan SHA-512 tidak pernah ditambahkan. Saya tidak dapat mengatakan bahwa hal itu jelas memengaruhi kemajuan teknologi, tetapi jelas memperlambat proses perusahaan.
Sungguh menyakitkan saya melihat ini, karena IPsec telah mendukung kurva elips begitu saja sejak tahun 2005. Curve25519 juga lebih baru dan tersedia untuk digunakan. Ada juga alternatif untuk AES seperti Camellia dan ChaCha20, tetapi jelas tidak semuanya didukung oleh vendor besar seperti Cisco dan lainnya.
Dan orang-orang memanfaatkannya. Ada banyak kit Cisco, ada banyak kit yang dirancang untuk bekerja dengan Cisco. Mereka adalah pemimpin pasar di segmen ini dan tidak terlalu tertarik dengan inovasi apa pun.
Ya, situasinya [di segmen korporat] sangat buruk, tetapi kami tidak akan melihat perubahan apa pun karena WireGuard. Vendor mungkin tidak akan pernah melihat masalah kinerja apa pun dengan perkakas dan enkripsi yang sudah mereka gunakan, tidak akan melihat masalah apa pun dengan IKEv2, sehingga mereka tidak mencari alternatif.
Secara umum, apakah Anda pernah berpikir untuk meninggalkan Cisco?
Tolak ukur
Dan sekarang mari beralih ke tolok ukur dari dokumentasi WireGuard. Meskipun [dokumentasi] ini bukan artikel ilmiah, saya tetap mengharapkan para pengembang mengambil pendekatan yang lebih ilmiah, atau menggunakan pendekatan ilmiah sebagai referensi. Tolok ukur apa pun tidak berguna jika tidak dapat direproduksi, dan bahkan lebih tidak berguna lagi jika diperoleh di laboratorium.
Dalam versi Linux dari WireGuard, ini memanfaatkan penggunaan GSO - Pembongkaran Segmentasi Generik. Berkat dia, klien membuat paket besar 64 kilobyte dan mengenkripsi / mendekripsi sekaligus. Dengan demikian, biaya pemanggilan dan penerapan operasi kriptografi berkurang. Jika Anda ingin memaksimalkan throughput koneksi VPN Anda, ini adalah ide yang bagus.
Tapi, seperti biasa, kenyataannya tidak sesederhana itu. Mengirim paket sebesar itu ke adaptor jaringan mengharuskannya dipotong menjadi banyak paket yang lebih kecil. Ukuran pengiriman normal adalah 1500 byte. Artinya, raksasa kami sebesar 64 kilobyte akan dibagi menjadi 45 paket (informasi 1240 byte dan 20 byte header IP). Kemudian, untuk sementara, mereka akan sepenuhnya memblokir pekerjaan adaptor jaringan, karena harus dikirim bersamaan dan sekaligus. Akibatnya, ini akan mengarah pada lompatan prioritas, dan paket-paket seperti VoIP, misalnya, akan diantrekan.
Dengan demikian, throughput tinggi yang diklaim oleh WireGuard dengan berani dicapai dengan biaya memperlambat jaringan aplikasi lain. Dan tim WireGuard sudah ini kesimpulan saya.
Tapi mari kita lanjutkan.
Menurut tolok ukur dalam dokumentasi teknis, koneksi menunjukkan throughput 1011 Mbps.
Menakjubkan.
Ini sangat mengesankan karena fakta bahwa throughput teoretis maksimum dari satu koneksi Gigabit Ethernet adalah 966 Mbps dengan ukuran paket 1500 byte dikurangi 20 byte untuk header IP, 8 byte untuk header UDP, dan 16 byte untuk header WireGuard itu sendiri. Ada satu header IP lagi dalam paket yang dienkapsulasi dan satu lagi di TCP untuk 20 byte. Jadi dari mana datangnya bandwidth ekstra ini?
Dengan bingkai besar dan manfaat GSO yang telah kita bicarakan di atas, maksimum teoretis untuk ukuran bingkai 9000 byte adalah 1014 Mbps. Biasanya throughput seperti itu tidak dapat dicapai dalam kenyataan, karena dikaitkan dengan kesulitan besar. Jadi, saya hanya dapat berasumsi bahwa pengujian dilakukan menggunakan bingkai berukuran besar yang bahkan lebih besar dari 64 kilobyte dengan maksimum teoretis 1023 Mbps, yang hanya didukung oleh beberapa adaptor jaringan. Tapi ini sama sekali tidak dapat diterapkan dalam kondisi nyata, atau hanya dapat digunakan antara dua stasiun yang terhubung langsung, secara eksklusif di dalam bangku tes.
Tetapi karena terowongan VPN diteruskan antara dua host menggunakan koneksi Internet yang sama sekali tidak mendukung bingkai jumbo, hasil yang dicapai di bangku cadangan tidak dapat dijadikan tolok ukur. Ini hanyalah pencapaian laboratorium yang tidak realistis yang tidak mungkin dan tidak dapat diterapkan dalam kondisi pertempuran nyata.
Bahkan duduk di pusat data, saya tidak dapat mentransfer bingkai yang lebih besar dari 9000 byte.
Kriteria penerapan dalam kehidupan nyata benar-benar dilanggar dan, menurut saya, penulis "pengukuran" yang dilakukan secara serius mendiskreditkan dirinya sendiri karena alasan yang jelas.
Secercah harapan terakhir
Situs web WireGuard berbicara banyak tentang wadah dan menjadi jelas untuk apa itu sebenarnya.
VPN sederhana dan cepat yang tidak memerlukan konfigurasi dan dapat diterapkan dan dikonfigurasikan dengan alat orkestrasi masif seperti yang dimiliki Amazon di cloud mereka. Secara khusus, Amazon menggunakan fitur perangkat keras terbaru yang saya sebutkan sebelumnya, seperti AVX512. Ini dilakukan untuk mempercepat pekerjaan dan tidak terikat dengan x86 atau arsitektur lainnya.
Mereka mengoptimalkan throughput dan paket yang lebih besar dari 9000 byte - ini akan menjadi bingkai besar yang dienkapsulasi untuk wadah untuk berkomunikasi satu sama lain, atau untuk operasi cadangan, membuat snapshot atau menggunakan wadah yang sama ini. Bahkan alamat IP dinamis tidak akan memengaruhi pengoperasian WireGuard dengan cara apa pun dalam skenario yang saya jelaskan.
Permainan yang bagus. Implementasi yang brilian dan protokol yang sangat tipis, hampir referensi.
Tapi itu tidak cocok dengan dunia di luar pusat data yang Anda kendalikan sepenuhnya. Jika Anda mengambil risiko dan mulai menggunakan WireGuard, Anda harus terus berkompromi dalam desain dan penerapan protokol enkripsi.
Keluaran
Mudah bagi saya untuk menyimpulkan bahwa WireGuard belum siap.
Itu dipahami sebagai solusi yang ringan dan cepat untuk sejumlah masalah dengan solusi yang ada. Sayangnya, demi solusi tersebut, ia mengorbankan banyak fitur yang relevan bagi sebagian besar pengguna. Itu sebabnya tidak bisa menggantikan IPsec atau OpenVPN.
Agar WireGuard menjadi kompetitif, perlu menambahkan setidaknya pengaturan alamat IP dan perutean serta konfigurasi DNS. Jelas, untuk inilah saluran terenkripsi.
Keamanan adalah prioritas utama saya, dan saat ini saya tidak punya alasan untuk percaya bahwa IKE atau TLS entah bagaimana dikompromikan atau rusak. Enkripsi modern didukung di keduanya, dan keduanya telah dibuktikan dengan pengoperasian selama beberapa dekade. Hanya karena sesuatu lebih baru tidak berarti itu lebih baik.
Interoperabilitas sangat penting saat Anda berkomunikasi dengan pihak ketiga yang stasiunnya tidak Anda kendalikan. IPsec adalah standar de facto dan didukung hampir di semua tempat. Dan dia bekerja. Dan tidak peduli bagaimana tampilannya, secara teori, WireGuard di masa depan mungkin tidak kompatibel bahkan dengan versi yang berbeda.
Perlindungan kriptografi cepat atau lambat rusak dan, karenanya, harus diganti atau diperbarui.
Menyangkal semua fakta ini dan secara membabi buta ingin menggunakan WireGuard untuk menghubungkan iPhone Anda ke workstation rumah Anda hanyalah kelas master dalam membenamkan kepala Anda di pasir.
Sumber: www.habr.com