Неге AES-256 VPN шифрлау жиынтығын сипаттамайды
Жиынтық төрт рөлді атқарады: жаппай шифрлау, тұтастық, кілттерді орнату және серіктесті аутентификациялау. Шифр атауы солардың бірін ғана, бір деңгейде қамтиды.
VPN қандай шифрлауды пайдаланады деп сұрасаңыз, жауап әдетте бір сөзбен келеді: AES-256, немесе ChaCha20, немесе мүмкін WireGuard. Бұл жауап бір деңгейдің бір компонентін атайды, ал байланысты шын мәнінде қорғайтын нәрсе төрт түрлі рөлді атқаратын алгоритмдер жиынтығы. Компонентті құрылыммен шатастыру осы әңгімелердегі ең көп тараған қате және шешілмейтін салыстырулар тудырады.
Бір байланыстың ішіндегі төрт жұмыс
Жаппай шифрлау деректер арнасы үшін ашық мәтінді шифрланған мәтінге айналдырады, ал оның кілті жіберілмейді, туындыланады. Тұтастық қорғанысы өзгерісті анықтайды, бұл жеке жұмыс, тіпті бір құрылым екеуін де жасаса да. Кілттерді орнату ортақ трафик материалын жасайды, ал серіктесті аутентификациялау қарсы жақта кім бар екенін шешеді. Солардың бірі жетпесе, байланыс қауіпсіз емес, қалған бөлігі қанша күшті болса да.
Кейбір жобалар екі рөлді біріктіреді. AES-GCM мен ChaCha20-Poly1305 аутентификацияланған шифрлау құрылымдары, сондықтан құпиялылық пен тұтастық бірге келеді; AES-CBC олай емес, оған өз кілті бар бөлек хабарлама аутентификациясының коды қажет. Сондықтан ұсынысты тәуелсіз сандар қабы ретінде оқу жұп ретінде жасалғандарды дұрыс оқымайды.
Рөлдер әр түрлі деңгейлерде де орналасады, сондықтан бір сөз екі өнімде әр түрлі мағына бере алады. ESP ішіндегі блоктық шифр мен TLS ішіндегі блоктық шифр әр түрлі талаптары бар әр түрлі келіссөздердегі бірдей қарапайым элемент. Сондықтан қарапайым элементті оның режимі мен деңгейінсіз келтіру ештеңе келтірмегеннен де нашар болуы мүмкін.
Неге шифр атауы ештеңе дерлік айтпайды
AES-256 тіркесін бір сәт байыппен қабылдаңыз: ол блоктық шифрды және кілт өлшемін көрсетеді. Ол жұмыс режимі, тұтастық беріле ме, кілттер қалай орнатылды немесе серіктес қалай аутентификацияланды туралы ештеңе айтпайды. Екі өнім де AES-256 жарнамалап, қалғанның бәрінде ерекшелене алады, оның ішінде біреуі аутентификацияланбаған режиммен, екіншісі заманауи кілт алмасуы бар AEAD режимімен.
TLS 1.3 бұл бөлуді стандартқа енгізді, бұл ескі лексиканы үйренгендер үшін пайдалы түзету. Оның шифр жиынтықтары тек AEAD пен хэшті атайды, ал кілт алмасу топтары мен қолтаңба алгоритмдері жеке параметрлер ретінде келісіледі. Сондықтан TLS 1.3 жиынтығының атауын TLS 1.2 жиынтығының атауымен тең негізде салыстыруға болмайды, екеуі де конфигурация файлының бір өрісінде көрінсе де. Екі жолды тікелей салыстыратын аудитор протокол қолдамайтын қорытындыға келеді. Келісілген топты және қолтаңба параметрлерін де оқыңыз, әйтпесе салыстыру толық емес.
WireGuard қарсы жолды таңдайды және келіссөзді толығымен дерлік алып тастайды: протокол белгіленген алгоритмдер жиынтығын анықтайды, сондықтан екі іске асыру бірге жұмыс істейді немесе жоқ. Бұл заңды дизайн таңдауы және WireGuard қандай жиынтықты келіседі деген сұрақтың салыстыруға тұрарлық жауабы жоқ екенін де білдіреді. Оны аудиттесеңіз, спецификацияны бір рет оқып, содан кейін оның айналасындағы кілттерді басқаруды аудиттеңіз, келіссөзді емес.
Деңгей лексиканы анықтайды
IPsec орналастыруы екі рет келіседі: басқару арнасы үшін IKE ұсынысы және деректер үшін ESP түрлендіруі, және екеуі заңды түрде ерекшелене алады. Біріншісін оқып, ол екіншісін сипаттайды деп болжау аудит кезіндегі жиі шатасудың көзі, өйткені конфигурация файлы екеуін де атайды және қызықтысы екіншісі.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
Бір кітапханада қолжетімді атау басқа деректер жолы үшін автоматты түрде іске асырылмайды. Сондықтан біздің өнім AES-256-ны қолдайды деген мәлімдеме естілгеннен әлсіз, және сол себепті үйлесімділік мәселесі әдетте екі жақта барлық ескі алгоритмдерді қосу емес, қолдау көрсетілетін қиылысты табу арқылы шешіледі.
TLS 1.3 спецификациясы осы бөлудің ең айқын жарияланған мысалы, өйткені ол жиынтықты жұп ретінде анықтайды және қалғанын өз келіссөзіне ауыстырады. Бұл пішін таныс болғанда, IPsec ұсынысы мен WireGuard-тың бір белгіленген жиынтығы сол идеяның нұсқалары ретінде оқылады.
Келісілген нәтижені оқыңыз, содан кейін тоқтаңыз
Конфигурацияланған ұсыныс екі серіктестің не таңдағанының дәлелі емес. Тірі сессия жауапты алып жүреді, және кез келген негізгі іске асыру оны пакеттерді ұстамай-ақ хабарлай алады.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showШығыста ұсынылған тізімді емес, таңдалған алгоритмдерді оқыңыз. Егер жауап саясат көздегеннен әлсіз болса, түзету бір жақтың ұсыныс конфигурациясында, ал сәйкессіздік заманауи іске асыруларда әдетте үнсіз төмендету емес, сәтсіз келіссөз ретінде көрінеді.
Содан кейін жиынтық нені қамтымайтынын есте сақтаңыз. Маршруттар, қолданба рұқсаттары, журналдау және сақтау өз қарауы бар жеке шешімдер, ал үйлесімді криптографиялық құрылым олар туралы ештеңе айтпайды. Шифр туралы әңгіме тұрарлық, бірақ ол көпшілік шын мәнінде қоятын сұрақтан тар сұраққа жауап береді.
Лексиканы дәл ұстаңыз, дәлел қысқарады. Жиынтық деңгейдегі рөлдер жиынтығы, шифр бір компонент, ал келісілген нәтиже шын мәнінде бар байланысты сипаттайтын жалғыз нәрсе. Салыстырудағы қалғанының бәрі әшекей.