Mengapa saya begitu bersemangat tentang IPsec - bisa dibilang tumpukan protokol paling kompleks untuk mengamankan jaringan? Bagaimanapun, kompleksitas adalah musuh utama dari keandalan dan keamanan! Pertama, semakin Anda mempelajari protokolnya, terutama IKEv2, semakin Anda memahami berapa banyak kemungkinan yang dimasukkan ke dalamnya dan Anda terkesan dengan perhatiannya, berbeda dengan pendekatan populer pengembang "tongkat penopang penopang" dan memecahkan masalah serius "sampai guntur pecah". Kedua, protokol IPsec dipikirkan dengan baik dari sudut pandang kriptografi, dan bahkan ESP / IKEv1 yang lama, pada kenyataannya, adalah satu-satunya protokol yang digunakan secara massal di industri yang tidak memiliki kerentanan serius. SSL yang sama (tahun 1995) menjadi dipikirkan dengan baik hanya dari versi 1.3. Dan banyak orang tidak menyukai IPsec karena kompleksitas IKEv1 yang luar biasa,yang tidak lagi di v2.
Idealnya, jika pengembang sistem operasi tidak memperlambat waktu mereka dengan implementasi dan implementasi IPsec dan IPv6 (untuk ketersediaan komputer, sehingga tidak ada NAT), maka pada prinsipnya tidak ada SSL / TLS. Dunia ternyata tidak sempurna, tetapi sekarang IPsec di luar kotak (setidaknya SA / SP + ESP bagian dari tumpukan) ada di setidaknya beberapa OS yang tersebar luas (secara pribadi saya hanya tahu DragonFly BSD , yang meminum IPsec karena kurangnya pengembang untuk mendukungnya), dan IPv6 di beberapa negara maju segera tersedia untuk sebagian besar orang.
IPsec adalah kumpulan protokol, panggilan API, kerangka kerja sehingga aplikasi dan / atau administrator dapat mengetahui keamanan apa yang mereka butuhkan selama komunikasi dan itu akan dipastikan secara transparan di tingkat jaringan ( IP detikkemurnian). Kita dapat berbicara tentang kedua paket IP hanya dari satu soket (misalnya, koneksi TCP), dan tentang lalu lintas antara seluruh jaringan.
Keamanan lalu lintas berarti: memastikan kerahasiaan data, keaslian / integritasnya dan perlindungan terhadap serangan replay . Seperti hampir semua protokol, IPsec memiliki bagian transport yang mengamankan paket IP dan bagian jabat tangan yang terkait dengan negosiasi kunci, parameter, konfigurasi, dan otentikasi para pihak.
TLS 1.3 : hanya menyediakan perlindungan data per soket untuk koneksi TCP. DTLS dapat memberikan perlindungan untuk datagram (DTLS 1.3 belum menjadi standar), tetapi tidak semua library mendukung ini.
Protokol transportasi
Transport IPsec menggunakan protokol IP:
- AH (header otentikasi). Saya tidak akan berbicara lebih lanjut tentang AH, karena tidak memberikan kerahasiaan data dan, sejauh yang saya dengar, itu dibuat semata-mata untuk "menerima" undang-undang beberapa negara pada tahun 1990-an tentang pembatasan penggunaan enkripsi. Enkripsi sangat ringan dibandingkan dengan yang lainnya sehingga tidak masuk akal untuk mengorbankan itu. Namun hampir di semua tempat ESP disebutkan, AH juga dimaksudkan.
- ESP (merangkum muatan keamanan). ESP telah berkembang sedikit dari waktu ke waktu dan sekarang menggunakan versi ESPv3-nya, yang seringkali kompatibel dengan versi sebelumnya dan tidak berbeda dari versi sebelumnya.
Lalu lintas IP diamankan hanya oleh lapisan transport. Dan karena kita dapat berbicara tentang jutaan paket per detik, ESP de facto diimplementasikan pada tingkat kernel sistem operasi, setidaknya dalam tumpukan jaringannya, agar tidak membuat peralihan konteks yang mahal antara kernel dan ruang pengguna (seperti yang biasanya terjadi dengan TLS , SSH, OpenVPN, dan lainnya).
Saya menekankan bahwa AH dan ESP adalah protokol lapisan IP, jaringan, bukan transportasi. Mengapa tidak UDP? Checksum berlebihan dan membakar CPU, dan kriptografi akan memastikan integritasnya. Tapi, jika NAT Anda tidak tahu apa-apa tentang ESP (dan dia tidak tahu), maka semua ini tidak akan berhasil untuknya. Kemudian mereka datang dengan kruk NAT-T (NAT traversal), ketika lalu lintas IPsec dibungkus dalam paket UDP pada port 4500 dan akan dapat melewati NAT, tetapi ini adalah overhead yang tidak perlu dan kebutuhan untuk mengedit tumpukan IPsec di kernel, karena seharusnya sudah memahami paket UDP khusus ini dan mengekstrak ESP darinya untuk itu pemrosesan reguler.
SP, SA, SPI dan enkripsi IPsec pertama kami
Bagaimana kernel mengetahui apa yang harus dilakukan dengan paket IP: apakah akan mengenkripsinya menggunakan beberapa kunci, mendekripsi ESP yang masuk, atau membiarkannya lewat tanpa menyentuhnya? Untuk melakukan ini, kernel memiliki Kebijakan Keamanan ( SP ). Ini adalah aturan seperti di firewall. Selain mereka, inti berisi Asosiasi Keamanan ( SA ): konteks untuk melakukan operasi kriptografi (kunci, penghitung, pemutaran ulang jendela, dll.). Secara umum, baik SP tidak spesifik IPsec, maupun SA - mereka dapat digunakan untuk tugas / protokol lain (misalnya OSPF).
SP / SA dapat dikonfigurasi baik melalui API khusus ( PF_KEYv2 ), atau dengan tangan melalui beberapa utilitas setkey . Misalnya, jika kita ingin memberi tahu kernel bahwa semua paket IP berasalAlamat fc :: 123 di fc :: 321 harus diamankan melalui ESP, maka ini dapat dengan mudah dilakukan dengan memanggil dari baris perintah:
$ echo "spdadd fc00::123 fc00::321 any -P out ipsec esp/transport//require;" | setkey -c
Sebelum perintah ini, kami melihat ping:
IP6 fc00::123 > fc00::321: ICMP6, echo request, seq 0, length 16
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 0, length 16
IP6 fc00::123 > fc00::321: ICMP6, echo request, seq 1, length 16
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 1, length 16
Kami tidak akan melihatnya nanti, karena kernel belum tahu "apa" yang harus dienkripsi. Perlu menambahkan SA dan ini juga dapat dilakukan secara manual, pengaturan kemudahan enkripsi AEAD algoritma AES-GCM-16 dan kunci acak 160-bit:
echo "add fc00::123 fc00::321 esp 0xdeadbabe -E aes-gcm-16 0x0c09d1d90f804b0b4cef80e255e29c0894db1928 ;" | setkey -c
Jika kita menjalankan perintah yang sama pada host jarak jauh (tidak lupa untuk menentukan -P in ), kita akan melihat:
IP6 fc00::123 > fc00::321: ESP(spi=0xdeadbabe,seq=0x1), length 52
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 0, length 16
IP6 fc00::123 > fc00::321: ESP(spi=0xdeadbabe,seq=0x2), length 52
IP6 fc00::321 > fc00::123: ICMP6, echo reply, seq 1, length 16
Permintaan dienkripsi oleh ESP, tetapi balasannya tidak. Karena ESP bekerja dengan "satu cara" secara default dan untuk komunikasi dua arah perlu menambahkan SP / SA lain untuk arah yang berlawanan.
0xdeadbabe dalam contoh ini adalah Indeks Parameter Keamanan ( SPI ) - pengenal unik untuk "terowongan" ESP antara dua alamat IP, di mana kernel dapat menemukan konteks SA yang sesuai dan mengambil kunci dekripsi darinya. Dan esp / transport // require adalah persyaratan untuk menggunakan ESP dalam mode transport (lebih lanjut tentang itu di bawah).
Giblets ESP
Paket ESP disusun secara skematis sebagai berikut:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| Security Parameters Index (SPI) | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A
| Sequence Number | | u
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t
~ IV (variable) ~ | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | e -----
| Payload Data (variable) | | n ^ E
~ ~ | t | n
| | | i | c
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c | r
| | TFC Padding * (optional, variable) | | a | y
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t | p
| | Padding (0-255 bytes) | | e | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d | e
| | Pad Length | Next Header | v v d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------
~ Integrity Check Value-ICV (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- SPI - pengenal unik 32-bit untuk sesi / terowongan / koneksi ESP antara alamat IP. Biasanya, {SrcIP, DstIP, SPI} adalah SA dan konteks kriptografi.
- SeqNum — 32- . . , replay attack.
- payload — ESP, .
- TFC padding — (Traffic Flow Confidentiality), , - , . TFC , , payload , . , payload IP , . TFC - , .
- Padding — ESP payload 32- , . , ( CBC) . . .
- Pad Length — 8- Padding .
- Next Header — 8- IP payload. «no next header», ESP- — , . TFC — .
- ICV — Integrity Check Value, (MAC).
Seluruh bagian paket dari payload ke Next Header dienkripsi. Semuanya kecuali MAC diautentikasi. Panjang ICV, keberadaan IV (vektor inisialisasi) tergantung pada mode enkripsi dan otentikasi / algoritma yang digunakan.
TLS 1.3 : padding opsional data ke ukuran tertentu hanya muncul di versi 1.3. Jika tidak, enkripsi dan otentikasi sama sekali serupa. TLS 1.3 mewajibkan hanya menggunakan algoritma AEAD, yang benar dan baik. ESP mendukung AEAD, tetapi ada pilihan solusi yang lebih kuno. Ketik bidang SPI atau SeqNumtidak, karena TCP menjamin urutan dan pengiriman, sebagai tambahan, dalam praktiknya, tidak ada vektor inisialisasi yang dikirimkan secara eksplisit - oleh karena itu, paket lapisan data TLS sedikit lebih pendek. DTLS sudah berisi SeqNum serta data fragmentasi pesan.
Nomor paket 32-bit mungkin terlalu pendek dalam praktiknya. Ini hanyalah 4+ miliar paket IP, yang dengan kecepatan 10+ Mpps dapat terbang dalam beberapa menit. Apa yang terjadi ketika penghitung meluap? Ini akan diatur ulang ke nol. Tetapi, ini berarti bahwa nilai SPI + SeqNum akan mulai berulang untuk kami dan paket ESP yang sebelumnya dicegat dapat digunakan untuk memutar ulang serangan. Untuk mengatasi masalah ini, ESN diciptakan(Extended Sequence Number). Ini adalah pencacah 64-bit, tetapi hanya 32-bit "bawah" yang ditransfer ke bidang SeqNum , dan 32-bit atas disimpan dalam memori. Nilai penuh ESN diautentikasi - oleh karena itu para pihak berkewajiban untuk menyetujui penggunaan ESN sebelumnya.
Enkripsi ESP
Bagaimana sebenarnya enkripsi / otentikasi paket ESP terjadi, misalnya, saat menggunakan AES-GCM-16? Untuk bekerja dengan ESP, ini menggunakan vektor inisialisasi 64-bit yang terletak di awal muatan . Ini juga menggunakan garam 32-bit sebagai bagian dari bahan utama. Dalam contoh untuk setkey, saya tidak memberikan kunci 128-bit, tetapi kunci 128 + 32-bit. Mungkin ada situasi di mana kunci digunakan kembali dan IV diisi dengan penghasil nomor acak semu (PRNG) yang nilainya dapat diulang. Salt dirancang untuk melindungi dari kasus paling berbahaya ini, yang berpotensi mengarah ke dekripsi paket yang dicegat. Enkripsi / otentikasi ESP itu sendiri dalam mode AES-128-GCM-16-ESP adalah sebagai berikut:
AES-GCM(
key = 128-bit key,
plaintext = 64-bit IV || payload || TFC || pad || padLen || NH,
nonce = 32-bit salt || IV,
associated-data = SPI || {ESN SeqNum},
) -> encrypted-payload || 128-bit ICV
ESP = SPI || SeqNum || IV || encrypted-payload || ICV
Untuk algoritme GOST Rusia (sandi Magma atau Belalang), data masukannya serupa. Kedua cipher digunakan dalam mode MGM (saya akan mengatakan versi GCM yang ditingkatkan ), dan rotasi material kunci ESPTREE biasa diterapkan menggunakan HMAC-Stribog-256. Ini mengurangi beban pada kunci. Terutama dalam konteks IPsec, ini tidak terlalu banyak untuk meningkatkan waktu penggunaannya tetapi untuk mengurangi permukaan serangan melalui saluran samping. Misalnya, karena key meshing (teknologi serupa dengan rotasi kunci konstan), block cipher GOST 28147-89 dengan ukuran blok 64-bit ternyata kebal terhadap serangan SWEET32 .
Dari segi keamanan, tidak ada keluhan tentang ESP dengan algoritma AEAD. Tetapi untuk algoritma AEAD, IV hanyalah penghitung 64-bit, yang secara eksplisit dikirimkan dengan setiap paket yang membuang-buang ruang dalam paket. SeqNum terlalu pendek, dan ESN tidak sepenuhnya dikirim, meskipun itu akan benar-benar cocok sebagai IV. Untuk algoritme non-AEAD, IV mungkin sudah diperlukan dan memiliki nilai yang tidak dapat diprediksi, tetapi sama sekali bukan penghitung. Ini warisan, menggerogoti ruang berharga dalam paket dan berat tidak memengaruhi keandalan di sini.
Jika IV untuk AEAD dapat memiliki nilai dari 128-bit, maka dimungkinkan untuk menggunakan algoritme seperti XSalsa20 / XChaCha20 dengan nonce 192-bit, 128-bit di antaranya dibuat secara acak semu saat startup, dan 64-bit sisanya dapat digunakan untuk penghitung ... Ini bisa menjadi penyelamat untuk sistem yang telah kehilangan status penghitungnya, tetapi ingin terus menggunakan kunci yang ada.
TLS 1.3 : XOR digunakan sebagai nonce antara penghitung pesan dan vektor inisialisasi yang dibuat dengan kunci. Karena baik meteran maupun IV tidak ditransmisikan secara eksplisit, TLS 1.3 sedikit lebih kompak. Jika ESP menggunakan algoritme non-AEAD, maka mereka mungkin memerlukan pembuatan IV yang tidak dapat diprediksi, yang dapat terasa intensif CPU.
Terowongan dan moda transportasi
Apa saja yang termasuk dalam payload paket? Itu tergantung pada apakah ESP beroperasi dalam mode transportasi atau mode terowongan . Modus transport menggantikan payload dari paket IP yang dikirimkan dengan ESP dengan payload ini. Artinya, itu adalah:
---------------------------------------
| orig IP hdr |[ext hdrs]| TCP | Data |
---------------------------------------
menjadi:
---------------------------------------------------------
| orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<--- encryption ---->|
|<---- authenticity ----->|
Dalam mode terowongan, seluruh paket IP dibungkus sepenuhnya dalam ESP dan paket IP baru terbentuk, biasanya dengan header dan alamat SrcIP / DstIP baru. Mode ini digunakan untuk menyalurkan paket antar jaringan.
----------------------------------------------------------
| new* |new ext| | orig*|orig ext| | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
----------------------------------------------------------
|<--------- encryption --------->|
|<---------- authenticity ---------->|
Misalnya, melalui setkey saya dapat menentukan bahwa semua paket antara 2001: jaringan ac :: / 64 dan 2001: dc :: / 64 harus melewati terenkripsi melalui dua titik akhir terowongan dengan alamat 2001 :: 123 , 2001 :: 321 ...
spdadd 2001:ac::/64 2001:dc::/64 any -P out ipsec esp/tunnel/2001::123-2001::321/require ;
spdadd 2001:dc::/64 2001:ac::/64 any -P in ipsec esp/tunnel/2001::321-2001::123/require ;
Moda transportasi sering disebut sebagai koneksi host-ke-host. Jika beberapa protokol GRE atau IPv * -over-IPv * digunakan untuk tunneling, yang sudah bekerja di antara dua titik akhir, maka tidak masuk akal, dalam hal ini, untuk menggunakan mode tunneling pada level IPsec. Namun, mode transportasi tidak mengotentikasi header IP. Biasanya, ini tidak penting dan tidak kritis, tetapi jika Anda ingin memastikan bahwa tidak ada header IPv6 yang diperpanjang atau label aliran paket yang diubah, Anda harus menggunakan mode terowongan, bahkan jika di antara dua host, dengan biaya overhead.
ISAKMP
Apa yang terjadi jika saya me-reboot komputer, SA dengan semua nilai penghitung menghilang dari memori mereka, dan saya memuat lagi perintah SP / SA lama dengan tangan saya? Pertama, paket yang memiliki IV yang sama dapat didekripsi, karena ini sama saja dengan menggunakan cipher pad dua kali. Kedua, karena SPI / salt / ESN / SeqNum cocok, maka semua paket yang sebelumnya dicegat akan diautentikasi secara valid dan Anda dapat memutarnya kembali. Menggunakan kembali setkey SA seperti itu berbahaya bagi keamanan. Ketiga, terutama jika ESN tidak digunakan (misalnya, di FreeBSD pada saat penulisan ini, belum didukung), dengan operasi SA yang lama, Anda mungkin tidak memperhatikan bahwa penghitung "habis".
Semua ini berarti kita perlu mengubah kunci ESP secara teratur. Dan juga menyetujui algoritma enkripsi, keberadaan ESN, TFC, mode transport / tunnel, nilai SPI. De facto, protokol ISAKMP (Internet Security Association dan Key Management Protocol) digunakan untuk ini . Meskipun, Anda dapat dengan mudah mengacaukan beberapa IM dengan enkripsi terotentikasi OTR / PGP / OMEMO dan hanya mengirim perintah setkey skrip shell ke server, di mana kunci dihasilkan dengan membaca / dev / urandom . Tidak masalah bagi kernel bagaimana hal itu disetujui. Seperti di OpenVPN: otentikasi X.509 dengan sertifikat dan negosiasi kunci umumnya dilakukan melalui TLS, dan protokol transport VPN itu sendiri sudah menjadi miliknya sendiri.
Dalam bentuk "murni" nya, ISAKMP tidak digunakan, karena tidak ada kriptografi di dalamnya. Untuk mengautentikasi lawan bicara dan menghasilkan materi kunci, protokol pihak ketiga digunakan yang merangkum ISAKMP di dalamnya. Aku tahu:
- KINK - Negosiasi Internet Kunci Kerberized , di mana KDC Kerberos ketiga terpercaya digunakan untuk otentikasi dan negosiasi. Selain deskripsi dari Wikipedia, saya tidak tahu apa-apa lagi tentang KINK dan belum melihatnya secara langsung.
- IKE (v1) - Pertukaran Kunci Internet . Mungkin masih protokol yang paling populer, meskipun dibuat pada awal tahun 1998.
- IKEv2 adalah versi kedua dari IKE 2005, yang akan saya bicarakan.
Protokol IKE sangat dapat diperluas karena banyaknya jenis muatan yang berbeda. IKEv1 memiliki banyak pilihan untuk mengonfigurasi hanya satu terowongan agar berfungsi. Lebih dari selusin RFC yang menggambarkan keseluruhan ISAKMP dan IKEv1 dengan muatan umum. Kompleksitas yang mengintimidasi. Ditambah kemampuan untuk dengan mudah mengacaukan konfigurasi yang tidak-bodoh dan mitos yang terkenal, sebagian memang benar, bahwa IKEv1 dijamin hanya akan berfungsi jika, hampir sepenuhnya, menyalin file konfigurasi.
Untungnya, IKEv2 telah muncul: satu RFC yang nyaman (untuk sebagian besar fitur), protokol yang disederhanakan secara signifikan untuk menegosiasikan parameter dan, karenanya, konfigurasinya. Sebagai aturan, ia memiliki lebih sedikit perjalanan bolak-balik untuk seluruh jabat tangan dan proses kesepakatan utama daripada di IKEv1. Oleh karena itu, hanya dia yang akan dipertimbangkan, karena tidak ada gunanya lagi di IKEv1 (tetapi hampir tidak ada gunanya mengejar untuk mengganti contoh yang sudah berjalan dan bekerja, karena mereka bekerja). IKEv2, tidak seperti IKEv1, menggunakan algoritma dan pendekatan yang sangat mirip untuk mengenkripsi pesannya sendiri seperti yang dilakukan ESP. Itu juga memperkenalkan otentikasi EAP dan kemampuan untuk setiap pihak untuk mengautentikasi dengan metode yang berbeda (misalnya, klien menggunakan PSK, dan server X.509 menggunakan sertifikat).
Daemon IKE
+-------------+
| |
+-------------+
| |
| |
| | /userspace
=====[PF_KEY]====[PF_INET]====================
| |
+-----------+ +-------------+
| | |TCP/IP, |
| SA SP |---| IPsec|
+-----------+ +-------------+
|
+-----------+
| |
| |
+-----------+
Bagian dari tumpukan IPsec ini sudah berjalan, biasanya di ruang pengguna. Pertama, ini bukan daemon yang memuat banyak: mereka dapat berkomunikasi satu sama lain setidaknya sekali sehari, dan jabat tangan awal membutuhkan beberapa kali bolak-balik melalui UDP. Kedua, jumlah kemampuan ISAKMP / IKE yang ratusan kali lebih banyak kode daripada di implementasi penuh SA / SP / ESP. Ada banyak implementasi daemon ISAKMP: strongSwan (IKEv1 / v2) (serta Openswan , Libreswan ), isakmpd (IKEv1), OpenIKED (IKEv2), racoon (IKEv1), racoon2 (IKEv1 / v2, KINK) dan lain-lain.
Catatan: benar untuk menulis dan mengucapkan "Daemon» ( daemon), seperti yang telah saya lihat dalam terjemahan fiksi. Tapi di lingkungan teknis berbahasa Rusia, "setan" telah mengakar.
TLS 1.3 : secara umum, seluruh tumpukan TLS adalah fungsi pustaka yang bekerja di setiap aplikasi individu dan menyimpan materi utama di memorinya sendiri. Semua kriptografi dilakukan dengan beralih ke ruang pengguna, yang merupakan overhead besar. Namun, setidaknya FreeBSD dan Linux sudah memiliki implementasi pembongkaran kernel TLS, ketika, mirip dengan IPsec, bagian transport diproses seluruhnya di kernel, dan jabat tangan berlangsung di ruang pengguna.
IKEv2 dijalankan melalui UDP, secara default pada port 500 ( isakmplayanan). Daemon membuat saluran aman, mengautentikasi satu sama lain, menegosiasikan / membuat / menghapus ESP SA / SP, memperbarui kunci, melakukan detak jantung (Dead Peer Detection ( DPD )), dan banyak lagi. Semua komunikasi antara daemon terjadi dalam bentuk pertukaran sepasang pesan permintaan / tanggapan. Setiap permintaan harus dijawab. Karena ini UDP, apa yang harus dilakukan jika sebuah paket hilang? Pertimbangkan hal ini di negara bagian Anda, kirim ulang permintaan setelah waktu tunggu yang tidak ada tanggapan yang diterima, kirim ulang tanggapan untuk permintaan berulang, abaikan tanggapan berulang. Paket bisa tiba dalam urutan kacau, mereka bisa menghilang tak terduga - banyak yang diperhitungkan dalam standar IKEv2 dan dijelaskan bagaimana berperilaku dalam berbagai kondisi balapan.
TLS 1.3: Sifat TCP dari TLS mengatur urutan dan pengiriman pesan. Tetapi TCP mengambil sumber daya yang signifikan di kernel OS dan sejumlah besar sesi TCP dapat menjadi masalah (tidak seperti UDP). Namun di KPT semua masalah serupa akan muncul dengan cara yang sama seperti di IKE, ditambah wasir dengan pemrosesan pesan terfragmentasi akan ditambahkan. Mengubah alamat IP dari titik akhir untuk UDP tidak menjadi masalah. Koneksi IKE, sebagai aturan, berumur sangat lama (status IKE kecil dan hanya disimpan dalam memori dari userspace daemon) dan oleh karena itu membutuhkan jabat tangan lebih jarang, sedangkan di TLS, setelah kehilangan koneksi TCP, Anda harus melakukannya (walaupun ada juga metode akselerasi melanjutkan sesi jika keadaan tidak hilang, misalnya saat memulai ulang program). Karena daemon IKE adalah satu untuk seluruh sistem (sebagai aturan), maka jika beberapa aplikasi ingin berkomunikasi secara aman dengan itudengan seseorang yang sudah memiliki koneksi IKE, maka dia dapat langsung menggunakannya atau daemon, dalam satu perjalanan pulang pergi, akan membuat ESP SA tambahan untuk aplikasi tersebut.
Giblets IKE
Pertukaran pertama (permintaan-respons) dari daemon adalah IKE_SA_INIT , yang menciptakan IKE SA untuk komunikasi yang lebih aman. Perhatikan bahwa ESP SA "disimpan" di kernel, dan IKE SA ada di daemon userspace. Kemudian datang bursa IKE_AUTH , tempat para pihak diautentikasi. Dalam pertukaran yang sama, SA anak ( Child SA ) dibuat, yang digunakan untuk ESP SA. Secara umum, kedua pertukaran ini cukup untuk mengautentikasi para pihak dan menegosiasikan parameter ESP SA dengan kunci dan kemudian mengarahkan lalu lintas ESP terenkripsi antar komputer. Pada saat yang sama, IKE SA yang berfungsi tetap berada di antara daemon untuk waktu yang lama. Lebih lanjut, kapan saja, mereka dapat membuat pertukaran CREATE_CHILD_SA , untuk membuat lebih banyak SA anak, serta INFORMASIpertukaran (berbagai tujuan).
Semua header pesan IKEv2 memiliki struktur berikut:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Initiator's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE SA Responder's SPI |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | Version | Exchange Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- SPIi - 64-bit IKE SA Inisiator SPI. Pengenal yang dibuat secara acak oleh pemrakarsa sesi IKE.
- SPIr - 64-bit IKE SA Responder SPI. Begitu juga dengan SPI dari sisi responder. Di pesan pertama dari inisiator, bidang ini diisi dengan nol byte.
- NP - Muatan berikutnya 8-bit. Pengenal untuk payload setelah header.
- Versi - versi 8-bit dari protokol IKE.
- ExchType - Tipe pertukaran IKE 8-bit: IKE_SA_INIT , IKE_AUTH , CREATE_CHILD_SA, atau INFORMATIONAL .
- Flags — 8- . .
- MsgID — 32- . , , replay-. — request/response MsgID. , .
- Len — 32- ( + ).
SPIi + SPIr adalah 128-bit. Mengapa begitu banyak ketika ESP hanya memiliki 32 bit? Pertama, karena tidak cocok, tetapi dihasilkan secara pseudo-acak, 64-bit untuk satu sisi akan cukup untuk menghindari tabrakan. Kedua, ESP juga terikat dengan alamat IP, sementara sesi IKE umumnya tidak - para pihak dapat dengan mudah mengubah alamat IP mereka (klien seluler) dan terus berkomunikasi.
TLS 1.3: Mengubah alamat IP akan memutuskan koneksi. Anda perlu melakukan jabat ulang, bahkan dengan iPSK, menghemat sumber daya untuk kriptografi asimetris, ini adalah 1,5 perjalanan pulang pergi ditambah perjalanan pulang pergi untuk membuat koneksi TCP. Pembuatan ESP SA anak pada alamat IP baru, dalam koneksi IKE yang telah dibuat (tidak terikat ke alamat), hanya akan membutuhkan satu perjalanan pulang pergi (+ perjalanan pulang pergi untuk menghapus yang lama, tetapi ini sudah akan terjadi di latar belakang ESP SA yang berfungsi baru).
Header IKE diikuti oleh satu atau lebih payload. Setiap payload memiliki header format umum, diikuti dengan konten khusus untuk tipenya. Konten selaras 32-bit. Header umum untuk semua:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Next Payload — 8- . payload- . payload. payload IKE . Encrypted Payload, payload- NP ( payload IKE ), payload- .
- C — «» payload. IKEv2 payload , IKE . payload . IKE vendor-specific , .
- Len — 16- payload ( + ).
Jadi, pesan IKE terdiri dari header IKE dan muatan yang dihubungkan bersama dalam sebuah rantai. Daemon dapat mengabaikan muatan yang tidak kritis dan tidak dikenal. Isi muatan dari jenis Nonce (setelah tajuk) hanyalah kumpulan data acak, bukan ukuran tetap. Tetapi ada juga struktur yang jauh lebih kompleks. Dalam standar IKE, sebutan singkat untuk jenis payload diterima (misalnya, N * untuk pesan nonce, di mana "*" adalah "i" (inisiator) atau "r" (responder)).
SIGMA
Dari sudut pandang kriptografi, IKEv1 / IKEv2 termasuk dalam kelas protokol pertukaran kunci yang diautentikasi STS, ISO / IEC IS 9798-3, dan SIGMA (SIGn-and-MAc). Ini adalah solusi yang sangat diteliti dan diverifikasi secara matematis (SIGMA). Dalam artikel "P2P F2F E2EE IM dalam satu malam", saya telah menjelaskan prinsip pengoperasian dan implementasi protokol SIGMA-I. IKEv2 sangat mirip. Saat kita membahas keamanan protokol jabat tangan, apa yang kita harapkan?
- kerahasiaan pesan yang dikirimkan;
- keaslian dan integritas pesan yang dikirim - perubahannya harus dideteksi;
- perlindungan terhadap serangan replay - fakta kehilangan atau pemutaran ulang pesan harus dideteksi;
- ;
perfect forward secrecy (PFS) — PSK ( IKE ESP SA). ;
/ ( ) IKE . / ( ) ;
, , . .
Setelah pertukaran IKE_SA_INIT seperti itu , daemon memiliki alamat masing-masing, SPIi + SPIr nilai sesi IKE, algoritma negosiasi SA (dalam kasus IKE, ini adalah kesepakatan kunci ( DH ), enkripsi / otentikasi pesan ( ENCR ), algoritma pembangkitan kunci ( PRF )), kunci publik (DH) dari sisi yang berlawanan. Ini cukup untuk menyimpan status dalam memori dan melakukan kesepakatan kunci (Diffie-Hellman, GOST R 34.10-VKO, curve25519, dll.), Menghasilkan kunci simetris untuk mengenkripsi muatan pesan IKE berikutnya.
TLS 1.3: format pesan jabat tangan sangat berbeda, ada banyak warisan, tetapi pada dasarnya tidak ada yang menonjol. Bidang acak digunakan sebagai pengganti nonce. Alih-alih payload, banyak ekstensi. Alih-alih struktur proposal SA yang kompleks, pengenal ciphersuites digunakan, yang lebih ringkas dan sederhana. Menurut saya, fleksibilitas proposal SA itu berlebihan, tetapi di IKEv2 ini masih tidak menjadi masalah dan nilai yang mirip dengan ciphersuite tertulis di file konfigurasi. Hanya dengan TLS 1.3 versi pertukaran DH menjadi wajib.
Bahan kunci IKE
Setelah IKE_SA_INIT , SKEYSEED dibuat :
SKEYSEED = PRF (Ni [: 8] || Nr [: 8], DH-KEY)
Algoritma PRF dipilih di IKE SA. Misalnya, untuk GOST IKEv2, ini adalah fungsi HMAC-Stribog-512. Kunci PRF adalah potongan 64-bit dari masing-masing nonce.
Kelihatannya sembrono, karena nonce ditransmisikan secara terbuka, yang berarti kunci PRF ini diketahui siapa saja yang mencegat lalu lintas. Tetapi PRF digunakan di sini secara eksklusif untuk menghasilkan kunci dari DH-KEY hasil kalkulasi DH , yang sudah tidak diketahui penyerang . Hasil dari fungsi DH dapat berupa nilai entropi yang besar dan tidak merata, dapat berupa titik pada kurva eliptik - semua ini tidak dapat digunakan sebagai kunci simetris entropi tinggi pendek. Oleh karena itu, Anda perlu mengekstrak entropi dari DH-KEY (ini SKEYSEED ), lalu "luaskan" (perluas ) ke jumlah kunci yang diperlukan:
PRF+(SKEYSEED, Ni || Nr || SPIi || SPIr) ->
SK_d || SK_ai || SK_ar || SK_ei || SK_er || SK_pi || SK_pr
PRF+(K,S) = T1 || T2 || T3 || T4 || ...
T1 = PRF(K, S || 0x01)
T2 = PRF(K, T1 || S || 0x02)
T3 = PRF(K, T2 || S || 0x03)
T4 = PRF(K, T3 || S || 0x04)
Ini semua adalah operasi derivasi kunci klasik dengan tahapan ekstrak / perluasan , mirip dengan fungsi HKDF . Tetapi jika HKDF mengasumsikan penggunaan fungsi hash, maka konstruksi PRF / PRF + ini dapat digunakan hanya dengan cipher simetris - dalam kasus AES-GCM + AES-XCBC-PRF yang umum, kami tidak akan menggunakan fungsi hash di mana pun, tetapi sejumlah kecil primitif bekas selalu bagus.
Kunci berikut dibuat:
- Kunci SK_d untuk menghasilkan kunci bagi ESP SA anak.
- Kunci SK_a [ir] untuk otentikasi pesan IKE. Tidak dibuat / tidak digunakan jika algoritme AEAD disetujui (AES-GCM, Grasshopper / Magma-MGM, ChaCha20-Poly1305, dll.).
- SK_e[ir] IKE .
- SK_p[ir] AUTH.
TLS 1.3: memiliki penjadwalan kunci yang jauh lebih kompleks. Entropi diperas keluar dari seluruh pesan jabat tangan sekaligus, bukan setiap bidang. Urutan diperpanjang yang dihasilkan tidak hanya dipotong menjadi sejumlah kunci (+ garam untuk mereka bila diperlukan), tetapi juga disertai dengan transformasi HMAC dengan label (label) untuk setiap konteks penggunaan kunci ini atau IV yang dihasilkan. Menggunakan label / aplikasi / konteks tekstual untuk semua jenis nilai yang dihasilkan adalah praktik modern yang baik dan selalu lebih mudah dilakukan daripada bertanya-tanya apakah Anda membutuhkannya. Mencirikan semua yang muncul juga merupakan praktik yang sangat baik, "tidak akan bertambah buruk." Namun, ini tidak berarti bahwa keamanan IKEv2 lebih buruk, atau seseorang dapat dengan mudah menemukan setidaknya situasi teoretis jarak jauh di mana tidak adanya label dapat berada di tangan penyerang.Di IKEv2, pendekatannya minimalis, sedangkan di TLS 1.3 "lebih baik untuk menimpa" (karena berapa banyak tiang atau kesulitan yang dilakukan di versi protokol sebelumnya!). IKEv2 masih menggunakan pendekatan dan primitif yang telah terbukti, mengotentikasi semua yang diperlukan, memeras / memperhitungkan semua entropi yang ditransfer, menggunakan kunci yang berbeda untuk setiap sisi dan tugas.
IKE_AUTH
Kemudian pertukaran IKE_AUTH dilakukan , mengautentikasi kedua belah pihak dan menegosiasikan ESP SA:
SK{IDi, [CERT, ...], [CERTREQ], [IDr], AUTH, SAi2, TSi, TSr} -->
<-- SK{IDr, [CERT, ...], AUTH, SAr2, TSi, TSr}
- Pesan IKE berisi muatan terenkripsi ( SK ), yang berisi semua pesan lainnya.
- Pemrakarsa memberikan pengenalnya ( IDi ), pengautentikasi ( AUTH ), penawaran SA untuk ESP ( SAi2 ) dan pasangan inisiator / responder, yang disebut sebagai penyeleksi lalu lintas ( TS * ). Itu juga dapat secara opsional mengirim pengenal responden yang diharapkan, yang dapat dianggap sebagai semacam analog SNI dari TLS.
- Sebagai tanggapan, ia menerima pengenal responden, proposal ESP SA yang dinegosiasikan, pemilih lalu lintas yang divalidasi, dan pengautentikasi.
- Setelah itu, kedua belah pihak menganggap satu sama lain diautentikasi, memiliki kesepakatan tentang ESP SA, lalu lintas yang harus dimiliki oleh ESP ini, dan sudah dapat mengeluarkan perintah ke kernel untuk membuat SA dan, mungkin, SP (ada daemon yang tidak berurusan dengan SP sama sekali).
Sekarang lebih detail tentang payload ini:
- ID - pengidentifikasi pihak. Berisi jenis identifikasi dan data khusus untuk itu. Para pihak dapat diidentifikasi dengan banyak cara: alamat IPv4 / IPv6, FQDN (nama domain yang sepenuhnya memenuhi syarat, hanya string, cara yang paling populer), alamat email RFC822, Nama yang Dibedakan ASN.1 DER (cara paling umum saat menggunakan sertifikat X.509) atau Nama Umum serta khusus vendor.
- AUTH — . PRF ( MAC-), (pre-shared key (PSK)), . (TBS*):
TBSi = Msg0 || Nr || PRF(SK_pi, IDi) TBSr = Msg1 || Ni || PRF(SK_pr, IDr)
(Msg0), nonce (Nr), (IDi), «» . , SK_pi ( ). «».
/ . . ( Ni Nr), . , , .
, . ( ), . , - . round-trip-. SIGMA- , IKEv2, ESP SA, . , , . SIGMA MAC c ( SK_*). IKEv2 PRF, . , PRF(ID*) , brute-force ( ) .
PSK, :
AUTHi = PRF(PRF(PSK, "Key Pad for IKEv2"), TBSi) AUTHr = PRF(PRF(PSK, "Key Pad for IKEv2"), TBSr)
PRF(PSK) PSK ? PSK PRF . PSK , /. PRF() «» . PRF(PSK) PSK PSK , ( Argon2, Balloon ).
- SA*2 — SA , ESP .
- TS* — . : IPv4/IPv6 , IP (), / (), / . :
TSi = ((proto=17, port=100, fc::123 - fc::123), (proto=17, port=200, fc::123 - fc::123)) TSr = ((proto=17, port=300, :: - ffff:..:ffff), (proto=17, port=400, :: - ffff:..:ffff))
, UDP ( = 17), 100- 200- fc::123 , UDP 300 400. , IP . , , IP , ( , ICMP ). , .
UDP . , , , 100 300-, ESP SA .
Pihak yang merespons mengirimkan pilihan penyeleksi yang telah dikonfirmasi, yang cocok atau mungkin memiliki rentang pilihan yang lebih sempit.
Semua muatan ini dienkripsi pada kunci yang dihasilkan oleh IKE SA setelah pertukaran pesan pertama. Enkripsi diperlukan untuk menyembunyikan pengidentifikasi pihak yang ditransmisikan, sertifikat mereka, dan informasi pribadi lainnya di tempat terbuka. Namun, penyerang aktif dapat masuk ke bursa IKE_SA_INIT pertama dan melihat informasi ini, meskipun dia tidak lagi dapat melanjutkan sesi.
TLS 1.3 :
- application ( ServerHello ||… || Finished, , , ), (Client Finished). IKEv2 ESP SA round-trip-, TCP/SCTP handshake.
- , (IDr ), SNI, ClientHello . IKEv2 . ESNI, , DNS, DPI.
- IKEv2 , «»/«» ( ), PSK, , EAP. TLS 1.3 X.509 . TLS 1.3 X.509 . RFC TLS 1.3 «» . IKEv2 / .
- TLS 1.3 , , application ClientHello (EarlyData), application Client Finished . TLS 1.3 EarlyData .
- TLS (session resumption), iPSK , , . IKEv2 , RFC 5723 . IKE , , ( TCP/SCTP/whatever ) IP .
- TLS . IKEv2 IKE SA ESP SA . , () high-grade , . , , , . - ChaCha20-Poly1305, AES-256-GCM-16, -MGM . IKE SA ESP - NIST-.
Enkripsi muatan SK dengan cipher AEAD tidak rumit dan sepenuhnya mirip dengan ESP, misalnya, untuk AES-GCM (di mana, mirip dengan AES-GCM-ESP, garam adalah bagian dari materi utama):
AES-GCM(
key = SK_*e,
plaintext = 64-bit IV || payloads || pad || 8-bit padLen,
nonce = 32-bit salt || IV,
associated-data = IKEHdr || unencrypted payloads
) -> ciphertext
Otentikasi dengan EDS
Bagaimana jika ada pihak yang ingin mengautentikasi dengan tanda tangan dan sertifikat X.509? Untuk ini, sudah di IKE_SA_INIT , muatan CERTREQ dapat dikirim , meminta pihak yang berlawanan untuk memberikan sertifikat dalam bentuk muatan CERT . CERT dan CERTREQ berisi pengenal format sertifikat dan konten khusus format. Biasanya, sertifikat dapat ditampilkan sebagai ASN.1 DER atau sebagai hash SHA1 dari sertifikat + URL tempat sertifikat dapat diunduh. Karena ukuran UDP dibatasi oleh MTU, dan ukuran sertifikat bisa jauh lebih besar, opsi hash + URL adalah penyelamat di sini (meskipun ini dapat dianggap kruk).
Daftar IKEv2 RFC saja, selain sertifikat DER yang dikodekan X.509 dan SHA1 + URL: PKCS # 7 dibungkus sertifikat X.509, sertifikat PGP, kunci bertanda DNS, sertifikat SPKI, Sertifikat atribut X.509, kunci publik mentah. Jika Anda ingin menggunakan IPsec yang mirip dengan TLS kasus penggunaan yang paling sering: server yang diautentikasi oleh sertifikat X.509 dan klien anonim, maka di IKEv2 tidak ada cara untuk tidak mengautentikasi salah satu pihak. Tetapi RFC 5386 menjelaskan pendekatan Keamanan yang Lebih Baik Daripada Tidak Ada di mana "klien" dapat menggunakan kunci publik telanjang dan server dapat memperlakukannya sebagai anonim.
Selain itu, autentikasi EAP didukung secara native, menambahkan perjalanan pulang-pergi ke IKE_AUTHbertukar. EAP dapat mengatakan apakah pihak tersebut diautentikasi atau tidak, serta menghasilkan kunci yang akan diperhitungkan dan digunakan oleh IKEv2. Saya hanya akan menunjukkan kepada Anda diagram tentang bagaimana EAP dapat bekerja:
SAi1, KEi, Ni -->
<-- SAr1, KEr, Nr
SK{IDi, [IDr], SAi2, TSi, TSr} -->
<-- SK{IDr, AUTH, EAP}
SK{EAP} -->
<-- SK{EAP(success)}
SK{AUTH} -->
<-- SK{AUTH, SAr2, TSi, TSr}
TLS 1.3 : di dalamnya, tanda tangan (atau MAC dalam pesan Selesai ) ditempatkan di atas hash dari semua pesan yang terlihat yang berpartisipasi dalam jabat tangan. Juga pendekatan bagus yang sederhana dan andal. Tidak ada variasi metode otentikasi. Tetapi saya ingin melihat beberapa protokol Perjanjian Kunci Kata Sandi Terautentikasi (PAKE) yang kuat, seperti SESPAKE atau OPAQUE Rusia .
Materi utama ESP SA dan pembaruannya
Jadi, kami telah memverifikasi otentikasi, memverifikasi perjanjian kunci benar, menegosiasikan ESP SA dan pemilih lalu lintas. Tetap menghasilkan kunci simetris untuk ESP dan SA / SP yang diperlukan dapat diinstal di kernel:
PRF + (SK_d, Ni || Nr) -> KEYMAT0 || KEYMAT1
Komunikasi dua arah memerlukan dua ESP SA, jadi IKEv2 menghasilkan dua materi utama sekaligus, yang sudah dikirim langsung ke inti di SA yang sesuai. Panjang material bergantung pada algoritma ESP yang digunakan (misalnya, AES-GCM-ESP membutuhkan, selain kunci, garam 32-bit). Nilai SPI adalah nilai SPI yang ditentukan oleh masing-masing pihak dalam proposal ESP SA.
Bagaimana jika kita perlu menyetujui beberapa ESP SA / SP, misalnya, karena tidak semua keinginan dapat ditentukan dalam satu pasangan TSi / TSr ? Untuk ini, pertukaran CREATE_CHILD_SA digunakan yang terjadi kapan saja setelah IKE_AUTH . Pembuatan SA anak terjadi dalam pertukaran berikut:
SK {SA, Ni, [KEi], TSi, TSr} ->
<- SK {SA, Nr, [KEr], TSi, TSr}
Penawaran SA dibuat, nonces, penyeleksi lalu lintas dikirim. Semuanya seperti sebelumnya. Materi kunci sudah dibuat menggunakan nonce baru ini. Secara opsional, Anda dapat menggunakan muatan pertukaran kunci, yang menambahkan entropi dan memaksa para pihak untuk menggunakan kriptografi yang lebih asimetris. Mungkin perlu untuk terus mengamati properti PFS (dalam protokol OTR , kunci DH singkat dikirim dengan setiap pesan). Materi utama dalam kasus ini akan dikerjakan sebagai berikut:
PRF + (SK_d, DH-KEY || Ni || Nr) -> KEYMAT0 || KEYMAT1
Bagaimana jika kita ingin memperbaharui IKE SA koneksi? Kami melakukan pertukaran CREATE_CHILD_SA berikut :
SK {SA, Ni, KEi} ->
<- SK {SA, Nr, KEr}
di mana SA akan berisi proposal IKE SA dan SKEYSEED baru akan dikembangkan :
PRF (SK_d_old, DH-KEY || Ni || Nr) -> SKEYSEED
Kunci ESP SA diperbarui baik dengan membuat ESP SA baru (dengan SPI berbeda) dan menghapus yang lama, atau dengan mengirimkan pemberitahuan khusus (tentang itu di bawah). Mengalihkan lalu lintas untuk menggunakan ESP SA baru akan menjadi transparan dan tanpa kerugian. Untuk waktu yang singkat, para pihak akan memiliki dua ESP SA aktif, yang akan memungkinkan mereka memproses lalu lintas yang masih transit di saluran komunikasi.
Menghapus ESP SA dilakukan dengan mengirimkan muatan DELETE di pertukaran INFORMASI berikutnya yang mencantumkan SPI yang akan dihapus. Karena semua ESP SA ada berpasangan (untuk komunikasi dua arah), setiap sisi mengirimkan nilai SPI hanya ke ESP SA yang bertanggung jawab untuk lalu lintas keluar. Sebagai tanggapan, terima nilai SPI ESP SA untuk lalu lintas masuk.
SK {D (SPIi)} ->
<- SK {D (SPIr)}
Menghapus IKE SA juga dilakukan melalui DELETE , tetapi dengan IKE SPI dan menerima respons terautentikasi yang kosong:
SK {D} ->
<- SK {}
TLS 1.3 : ada mekanisme untuk merotasi kunci melalui pesan KeyUpdate , tetapi tidak ada kemungkinan untuk menambahkan entropi tambahan atau menjalankan DH. TLS jelas tidak dirancang untuk sambungan yang berumur sangat lama. Paling banter, Anda hanya dapat menghentikan sesi dan melanjutkan / membuat sesi baru dengan jabat tangan iPSK-ECDHE.
IKEv1 memiliki prosedur pembaruan kunci IKE yang terpisah dan yang terpisah untuk otentikasi ulang. Tidak ada autentikasi ulang di IKEv2. Untuk melakukan ini, IKE SA baru dibuat dari awal, yang lama dihapus melalui DELETE .
TLS 1.3 : memiliki kemampuan otentikasi klien pasca-jabat tangan kapan saja setelah jabat tangan ( Selesaipesan dari kedua sisi), server dapat mengirim permintaan otentikasi klien menggunakan sertifikat X.509. Misalnya, seorang klien, yang berkeliaran di sekitar situs, membuka halaman akun pribadinya. Di IKEv2, ini tidak mungkin - otentikasi hanya dilakukan pada saat jabat tangan.
MEMBERITAHU
Jadi bagaimana mode terowongan / transportasi dinegosiasikan, TFC? Untuk ini, payload "notifikasi" NOTIFY ( N ) ditambahkan ke permintaan . Ada lusinan jenis pemberitahuan di IKEv2 RFC saja. Peringatan digunakan untuk memberi sinyal kesalahan, masalah negosiasi SA, pemilih lalu lintas, dll.
Untuk memberi sinyal keinginan untuk menggunakan mode transportasi dalam ESP SA yang dinegosiasikan, pengumuman N (USE_TRANSPORT_MODE) ditambahkan oleh pemrakarsa dan responden untuk mengonfirmasi negosiasi mode. N (ESP_TFC_PADDING_NOT_SUPPORTED) memberi sinyal peringatan bahwa TFC tidak didukung. Dan N (HTTP_CERT_LOOKUP_SUPPORTED) menunjukkan bahwa mengunduh sertifikat dari URL didukung.
Kemampuan untuk memperbarui kunci ESP SA, tanpa membuat ESP SA baru, mirip dengan prosedur untuk membuat ESP SA anak, tetapi pemrakarsa menambahkan peringatan N (REKEY_SA) yang berisi SPI dari ESP SA saat ini:
SK {N (REKEY_SA), SA, Ni, [KEi], TSi, TSr} ->
<- SK {SA, Nr, [KEr], TSi, TSr}
DPD
Pertukaran INFORMASI dengan SK kosong digunakan untuk dead peer detection ( DPD ), sebagai detak jantung antar daemon. Jika daemon IKE tidak tersedia untuk waktu yang lama, kemungkinan besar statusnya telah hilang dan oleh karena itu tidak ada yang menonton ESP SA di sisi yang berlawanan, atau mereka tidak lagi aktif. Oleh karena itu, ketika jelas bahwa rekan tidak tersedia, masuk akal untuk menghapus semua ESP / IKE SA terkait. SK kosong berarti tidak ada muatan di dalamnya, tetapi memiliki data yang diautentikasi (setidaknya header IKE dengan penghitung), sehingga otentikasi paket semacam itu adalah tanda kehidupan yang tepercaya.
SK {} ->
<- SK {}
Tetapi bagaimana jika satu sisi dengan cepat memulai ulang, kehilangan status, dan mulai membuat koneksi IKE dari awal? Sisi berlawanan mungkin bahkan tidak menyadari bahwa yang lain tidak tersedia, dan akan berpikir bahwa itu memutuskan untuk mengautentikasi ulang atau membuat SA anak baru di koneksi IKE lain. Tidak ada bencana yang akan terjadi, tetapi ESP SA yang lama masih dapat hidup untuk waktu yang layak. Pemrakarsa MUNGKIN menempatkan peringatan N (INITIAL_CONTACT) di bursa IKE_AUTH -nya , menandakan bahwa ini adalah satu-satunya koneksi IKE yang diketahui ke sisi itu. Melihat pemberitahuan yang disahkan seperti itu, Anda dapat menghapus semua IKE / ESP SA lama dengan hati nurani yang bersih.
DoS dan KE buruk
Sudah di awal IKE_SA_INIT, muatan KEi dikirim dengan kunci publik DH sementara. Tetapi pemrakarsa belum menukar IKE SA, dan bagaimana dia tahu algoritma mana yang didukung oleh pihak penerima? Itu hanya dapat menebak atau mengingat dalam memori jangka panjang apa yang sebelumnya digunakan untuk dikaitkan dengan alamat ini. Jika responder tidak mendukung algoritme tersebut, maka responder akan mengirimkan notifikasi ke N (INVALID_KEY_PAYLOAD) , yang akan menunjukkan pengenal algoritme DH yang disukai. Pemrakarsa harus mengulangi permintaannya, tetapi dengan KEi baru .
TLS 1.3: dapat mengirim beberapa kunci publik efemeral sekaligus menggunakan algoritme berbeda, mungkin beberapa dapat melakukannya. Tapi ini adalah sumber daya dan lalu lintas. Dia mungkin tidak mengirim kunci publik sama sekali dan server akan menanggapinya dengan HelloRetryRequest dengan preferensinya - keuntungannya adalah kriptografi asimetris yang mahal tidak digunakan sama sekali sampai algoritme server yang disukai diketahui, tetapi dengan biaya perjalanan bolak -balik ekstra. Jika klien awalnya memberikan algoritme kunci publik yang tidak sesuai, seperti di IKEv2, klien akan menerima HelloRetryRequest dengan algoritme yang dapat dipilih.
Bagaimana jika Anda mengirim paket awal yang sama dari inisiator? Anda dapat membuat SPI baru setiap saat... Responden minimal akan melakukan komputasi DH dengan jujur dan merespons dengan IKE_AUTH . DH adalah operasi yang sangat intensif sumber daya yang membakar CPU dan sumber entropi - sehingga transponder dapat rusak.
Di IKEv2 (tetapi bukan IKEv1) ada perlindungan terhadap ini, dalam bentuk respon N (COOKIE) dengan pemberitahuan yang berisi string cookie, setelah itu pemrakarsa harus mengulangi permintaannya, tetapi menambahkan muatan N (COOKIE) ini ke dalamnya:
SAi1, KEi, Ni -->
<-- N(COOKIE)
SAi1, KEi, Ni, N(COOKIE) -->
<-- SAr1, KEr, Nr, [CERTREQ]
Permintaan harus memiliki SPI / Ni yang identik dengan yang pertama. Cukup dengan melengkapinya dengan muatan. Responden dapat menyimpan status tentang hubungan antara permintaan dan cookie yang dikirim kepadanya, dan hanya setelah mereka cocok, setelah menyelesaikan pekerjaan ini untuk menambahkan cookie ke permintaan oleh pemrakarsa, responden dapat melanjutkan pertukaran IKE_AUTH secara teratur .
Tetapi dimungkinkan untuk menyimpan negara tepat di dalam cookie, membuatnya "mengautentikasi diri". Hal ini dapat membawa fakta bahwa responden melihat permintaan dari pemrakarsa ( Ni dan SPIi setidaknya melihatnya ):
Cookie = MAC (beberapa rahasia, Ni || SPIi || cap waktu)
Dengan demikian, pencinta DoS harus menyimpan status dan mendaur ulang pesannya yang berulang, yang membuat serangan tersebut jauh lebih mahal. Masuk akal untuk mengaktifkan perlindungan cookie hanya jika ada kecurigaan akan serangan DoS, agar tidak memaksa semua orang untuk melakukan perjalanan bolak-balik ekstra.
TLS 1.3 : Memiliki keamanan opsional serupa. Server MUNGKIN merespons dengan HelloRetryRequest dengan pesan yang berisi ekstensi Cookie , yang harus dimasukkan klien ke dalam ClientHello2 yang berulang .
CP
IKEv2 memungkinkan Anda untuk menegosiasikan konfigurasi jaringan / alamat IP. Konfigurasi payload ( CP ) memungkinkan Anda untuk membuat permintaan untuk menerima konfigurasi ( CFG_REQUEST / CFG_REPLY jenis paket) dan mengatur konfigurasi ke sisi yang berlawanan ( CFG_SET / CFG_ACK jenis). Permintaan konfigurasi berisi atribut yang ingin diketahui / ditetapkan oleh pihak tersebut. Atribut dapat berupa: alamat "internal", alamat DNS, DHCP, pengetahuan subnet, atau jenis lain yang dijelaskan dalam RFC terkait. Misalnya, pemrakarsa di bursa IKE_AUTH dapat membuat permintaan untuk memberinya alamat intranet (menghubungkan ke jaringan perusahaan) dan server DNS:
SK{IDi, [IDr], AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr} -->
<-- SK{IDr, AUTH, CP(CFG_REPLY), SAr2, TSi, TSr}
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
TSi = (proto=0, port=0-65535, :: - ffff:...:ffff)
TSr = (proto=0, port=0-65535, :: - ffff:...:ffff)
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:db8::5/64)
INTERNAL_IP6_DNS(2001:db8::1)
INTERNAL_IP6_SUBNET(2001:db8:abcd::/64)
TSi = (proto=0, port=0-65535, 2001:db8::5 - 2001:db8::5)
TSr = (proto=0, port=0-65535, 2001:db8::0 - 2001:db8::ffff:ffff:ffff:ffff)
- Alamat 2001: db8 :: 5 dialokasikan ke inisiator .
- ESP SA 2001:db8::/64 .
- 2001:db8::1 DNS .
- 2001:db8:abcd::/64 , , ESP SA, 2001:db8:: .
Go?
Untuk menguji implementasi domestik modern dari tumpukan IPsec dengan algoritma GOST, kami memutuskan untuk menulis implementasi yang sepenuhnya independen (dari Linux, FreeBSD, strongSwan, dan tumpukan lainnya). Dan untuk kecepatan dan kemudahan pengembangan dalam bahasa Go , dengan implementasi algoritma GOST pustaka GoGOST yang sudah ada . Sebelumnya, saya sudah memiliki pengalaman mengintegrasikan GOST ke implementasi TLS 1.3 dari pustaka crypto / tls dan crypto / x509 Go.
Proyek gostipsec adalah perangkat lunak gratis yang terdiri dari dua daemon: ESPER (ESPv3) dan IKER (IKEv2):
┌──────┐ ┌────┐ ┌─────┐ ┌────┐
│remote│ │iker│ │esper│ │ipfw│
└──┬───┘ └─┬──┘ └──┬──┘ └─┬──┘
│ │ │ │
╔══════╤═════╪════════════════╪════════════╗ │ │
║ UDP │ │ │ ║ │ │
╟──────┘ │ IKEv2... │ ║ │ │
║ │ <─────────────── ║ │ │
║ │ │ ║ │ │
║ │ IKEv2... │ ║ │ │
║ │ ───────────────> ║ │ │
╚════════════╪════════════════╪════════════╝ │ │
│ │ │ │
│ │ │ │
│ ╔═══════════╪══╤═════════════╪════════════╗ │
│ ║ UNIX-SOCKET │ │ ║ │
│ ╟─────────────setkey-commands│ ║ │
│ ║ │ ───────────────> ║ │
│ ╚═══════════╪════════════════╪════════════╝ │
│ │ │ │
│ │ │ │
│ │ ╔════════════╪═══╤═══════════╪════════════╗
│ │ ║ DIVERT-SOCKET │ │ ║
│ │ ╟──────────────encrypted ESP │ ║
│ │ ║ │ <────────────── ║
│ │ ║ │ │ ║
│ │ ║ │ decrypted ESP │ ║
│ │ ║ │ ──────────────> ║
│ │ ║ │ │ ║
│ │ ║ │ unencrypted IP│ ║
│ │ ║ │ <────────────── ║
│ │ ║ │ │ ║
│ │ ║ │ encrypted IP │ ║
│ │ ║ │ ──────────────> ║
│ │ ╚════════════╪═══════════════╪════════════╝
│ │ │ │
Saat ini, ESPER hanya bekerja dengan soket DIVERT (saya tidak menemukan sesuatu yang sederhana di Linux), oleh karena itu ESPER hanya didukung di FreeBSD (mungkin OpenBSD, tidak memeriksa) OS. ESPER, seperti IKER, tidak menggunakan PF_KEYv2 , yang akan membutuhkan C-binding, sebagai antarmuka antara ESP <-> IKE binding, tetapi antarmuka seperti setkey teks telah disebutkan di awal artikel. Oleh karena itu IKER dapat digunakan untuk menegosiasikan kunci implementasi kernel ESP dengan menjalankan perintah setkey yang sebenarnya . Perintah untuk ESPER ini terlihat seperti ini:
add fc00::ac fc00::dc esp 0x12345678 -u 123 -E aes-gcm-16 0xd3537e657fde5599a2804fbb52d1aaed94b65d3e ;
add fc00::dc fc00::ac esp 0x12345679 -u 234 -E aes-gcm-16 0x9a2dae68e475eacb39d41f23c3cbef890e9f6276 tfc:1320 ;
spdadd fc00::ac/128 fc00::dc/128 all -P in ipsec esp/transport//unique:123 ;
spdadd fc00::dc/128 fc00::ac/128 all -P out ipsec esp/transport//unique:234 ;
ESPER mendukung: AES-128/256-GCM-16, Magma / Belalang-MGM, ESN, TFC, mode transportasi / terowongan, IPv6 / IPv4 (dukungan untuk yang terakhir, jauh lebih kompleks, belum diuji secara menyeluruh, dan siapa yang membutuhkan IPv4 untuk proyek baru?), perlindungan terhadap serangan replay. IKER memungkinkan Anda mencocokkan: AES-128/256-GCM-16 + AES-XCBC + curve25519, Magma / Grasshopper-MGM + HMAC-Stribog-512 + GOST R 34.10-2012-VKO-256/512, ESN / TFC / transportasi / tunnel-mode, autentikasi menggunakan tanda tangan digital PSK dan X.509 (ECDSA, GOST R 34.10-2012). Dikonfigurasi oleh satu file Hjson :
{
IKEAlgos: [
gost128-vko512
aes256gcm16-aesxcbc-curve25519
aes128gcm16-aesxcbc-curve25519
]
ESPAlgos: [
gost128-esn
gost64-esn
aes256gcm16-esn
aes256gcm16-noesn
aes128gcm16-esn
aes128gcm16-noesn
]
SigHashes: [
streebog512
streebog256
sha512
sha256
]
DPDTimeout: 300
Peers: [
{
Autostart: true
OurIP: fc00::dc
TheirIP: fc00::ac
OurId: our.company.net
TheirId: CN=example.com
OurTSS: [
fc00::dc/128[tcp]
fc00::dc/128[udp/53]
]
TheirTSS: [
fc00::ac/128
]
Mode: transport
# Won't be used, because of X.509 signature authentication
PSK: DEADBABE
TheirCertHash: a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447
OurCert: our.company.net.cer.pem
OurPrvKey: our.company.net.key.pem
TFC: 1200
}
]
}
Dalam contoh ini, kami telah menetapkan satu-satunya anggota yang kami ketahui:
- Daemon mana yang secara otomatis akan terhubung
- Lakukan deteksi teman mati setiap lima menit
- ESN, fallback- , TFC 1200 .
- TCP DNS fc00::dc fc00::ac .
- X.509 , CN=example.com subject- SHA256 SubjectPublicKeyInfo . OurId OurCert .
- OurCert/OurPrvKey , PSK FQDN OurId.
IKER belum mendukung set lengkap semua fitur IKEv2 ( CREATE_CHILD_SA , rekeying), tidak memantau hilangnya paket dan tidak peduli dengan prinsip DON'T PANIC . Oleh karena itu, ia belum dapat dianggap sebagai kandidat untuk penggunaan "industri".
Tarball gostipsec sudah berisi semua dependensi, dokumentasi .info yang dikompilasi , dan target untuk sistem redo build, meskipun pembuatan file executable mudah dilakukan dengan panggilan go build biasa .
Hjson?
Tema Holywar, tapi tetap saya akan mengungkapkan phi saya:
- INI tidak mengizinkan Anda untuk menentukan struktur penyapuan seperti itu, dan tidak ada standar untuk file .ini .
- capabilities database , termcap-like, BSD , (, , ), C. IKER .
- XML — .
- JSON — , Python Go . , . - !
- YAML — , , . , . , YAML , , , . . . - . YAML ( ) - ( StrictYAML ).
- TOML — : , , , . , :
[[foo.bar]] baz = 123 [[foo.bar]] abc = 123
:
{ "foo": { "bar": [ {"baz": 123 }, {"abc": 123 } ] } }
«» / , . , TOML, NNCP , . , , . - Hjson — JSON ( , ), Hjson. github.com/hjson/hjson-go Hjson JSON, . . , . , JSON Hjson.
Secara umum, jika Anda menerapkan subset dari kemampuan yang mirip dengan TLS 1.3 (otentikasi hanya dengan sertifikat PSK dan X.509, tidak ada rekeying yang serius), maka ESPv3 dengan IKEv2 dan IPv6 (jauh lebih mudah untuk bekerja dengannya!), Dari sudut pandang pemrogram, akan sedikit lebih sulit dalam implementasi. RFC bahkan tidak berkewajiban untuk mendukung bursa CREATE_CHILD_SA . Keamanan akan sangat baik, tanpa mode operasi TLS 1.3 yang kontroversial dan berbahaya. Kinerja solusi IPsec umumnya akan lebih tinggi karena pengangkutan di tingkat nuklir dan sesi IKE yang berumur panjang.
Dapat dilihat bahwa di IPsec semuanya dipertajam untuk melindungi jumlah trafik yang sangat besar antara seluruh jaringan, tetapi BTNS(keamanan yang lebih baik daripada tidak sama sekali) kelompok kerja IETF telah menulis beberapa RFC yang menunjukkan bahwa IPsec dapat digunakan tanpa masalah untuk koneksi per soket, di mana salah satu pihak (klien) tidak dikenal, sehingga benar-benar mempertanyakan kelayakan penggunaan TLS. Pengikatan koneksi, dalam hal ini, akan memungkinkan aplikasi jaringan apa pun, dengan membuat panggilan sistem sepele seperti setsockopt , untuk menunjukkan bahwa ia memerlukan ESP ke alamat FQDN = bank.com , menampilkan dirinya sebagai sertifikat X.509 (atau tetap anonim), dan kemudian secara transparan, cepat dan bekerja dengan aman menggunakan bank.com ini , tanpa kruk dalam bentuk transportasi ruang pengguna per aplikasi perpustakaan.
Sergey Matveev , cypherpunk, Pengembang Python / Go / C, kepala spesialis FGUP STC Atlas.