OpenVPN EC vs ED: эдгээр нэр яагаад хүчний шат биш вэ
EC, ED, ECDHE болон auth нь өөр өөр асуултад хариулдаг. Ямар нэг зүйлийг харьцуулах эсвэл засахын өмнө OpenVPN профайлыг нэр бүрийн хийдэг ажлаар нь эрэмбэлээрэй.
Нэг профайлд ec, ed, ecdh, ecdsa, auth болон TLS шифрүүдийн жагсаалтыг зэрэгцүүлэн тавибал файл зургаан байрлалтай хүчний тохируулагч мэт харагдаж эхэлнэ. Гэвч тийм биш. Нэр бүр өөр асуултад хариулдаг бөгөөд тэдгээрийн аль нэгээр ялгаатай хоёр профайл заавал нэг нь нөгөөгөөсөө хүчтэй эсвэл сул байх албагүй. Нэрсийг хийж буй ажлаар нь эрэмбэлэхэд таван минут орчим зарцуулагдаж, хүмүүс ажиллаж буй тохиргоонд хийсэн муу өөрчлөлтийн ихэнхийг сэргийлдэг.
Доорх эрэмбэлэлт нь төөрөгдлөөс өөрөөс нь эхэлж, дараа нь гадагш, профайлын таны урсгалыг үнэхээр юу хамгаалж байгааг тодорхойлдог хэсгүүд рүү шилждэг. Хэсэг бүр ээлжлэн нэг буруу уншилтыг авч, нэр үнэхээр юунд холбогдож байгааг харуулна.
Хоёр үсэг, хоёр өөр асуулт
Хамгийн их маргаан үүсгэдэг хос бол EC ба ED бөгөөд маргаан ихэвчлэн тэднийг нэг асуултын өрсөлдөгч хариулт гэж үздэг. Тэд нэг тэнхлэг дээр ч байдаггүй. EC нь математикийн нэг гэр бүлийг тодорхойлдог: эллипс муруйн криптограф, энд аюулгүй байдал нь том хязгаарлагдмал талбарт биш, муруй дээрх салангид логарифмын хүндрэлээс ирдэг.
ED нь тухайн гэр бүлийн доторх муруйн хэлбэрийг тодорхойлдог. Twisted Edwards муруйнууд нь хурд болон хэд хэдэн хэрэгжүүлэлтийн алдаанд тэсвэртэй байх үүднээс сонгосон дүрслэл бөгөөд Ed25519 бол хүмүүсийн ихэвчлэн хэлдэг нэр юм. Муруй нь эллипс муруйн криптографын өрсөлдөгч биш; энэ нь эллипс муруйг бичих нэг арга юм. ED-г "илүү шинэ, илүү хүчтэй EC" гэж унших нь анхны буруу эргэлт бөгөөд дараах бүхэн ижил чиглэлд буруу байх хандлагатай.
Гарын үсэг зурах ба солилцох нь тусдаа ажил
Гэр бүлийн асуудал шийдэгдсэний дараа үлдсэн нэрс хэзээ ч бие биеийг орлохгүй хоёр баганад хуваагдана. Нэг багана гарын үсэг зурдаг, нөгөө нь нийтлэг нууцад санал нэгддэг.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA болон ECDSA хоёулаа гарын үсэг зурдаг боловч тэд өөр түлхүүрийн форматтай өөр схемүүд тул нэгэнд олгосон гэрчилгээг нөгөөгийнхөөр ашиглах боломжгүй. EdDSA нь цөөн тооны муруйд тодорхойлогдсон; P-256 тэдгээрийн нэг биш тул P-256 гэрчилгээг ECDSA-аар шалгадаг бөгөөд хэзээ ч Ed25519-ээр шалгахгүй.
Солилцооны баганад EdDH гэсэн нэртэй дүйцэх зүйл байхгүй. Curve25519 түлхүүр дээрх түр зуурын тохиролцоо нь X25519 бөгөөд энэ нь тодорхой муруйтай ECDH, яг P-256-ийн адил. Ed25519 нь гарын үсгийн схемийг хатуу илэрхийлдэг боловч хоёр муруй холбоотой тул нэрийг солилцоонд ч сул хэрэглэдэг: гарын үсэг зурахад ашигладаг Edwards хэлбэр ба X25519-д ашигладаг Montgomery хэлбэр нь нэг ижил суурь бүлгийг тодорхойлдог.
Яагаад EC профайлд dh файл байхгүй вэ
dh файл нь хязгаарлагдмал талбарын Diffie-Hellman-д зориулсан урьдчилан үүсгэсэн параметрүүдийг агуулдаг бөгөөд эдгээр параметрүүд нь том анхны тоо болон генератор хаа нэгтээгээс ирэх ёстой учраас байдаг. Эллипс муруйн солилцоонд тэд хэрэггүй: нэрлэсэн муруй нь параметрийн багц бөгөөд хоёр тал үүнийг аль хэдийн мэддэг. Энэ бол EC профайл зааварчилгааг орхиж болох бүх шалтгаан юм.
Бусад талаар орчин үеийн харагдах профайлд хоёр нөхцөл байдал одоо ч dh мөр үүсгэдэг. Эхнийх нь хязгаарлагдмал талбарын бүлгүүдийн талаар үнэхээр хэлэлцдэг хоёр дахь сонсогч эсвэл хуучин түнш юм. Хоёр дахь нь RSA эриний загвараас хуулагдсан бөгөөд хэзээ ч арилгаагүй үлдэгдэл текст юм. Солилцоонд муруй нэрлээд 2048 битийн dh файлыг ачаалж байгаа профайл үүнийг хийснээр илүү аюулгүй болохгүй; энэ нь ашиглагдаагүй зүйлийг авч явдаг.
TLS 1.3 түлхүүрийн солилцоог нэрнээс хасав
TLS_AES_256_GCM_SHA384-ийг TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384-тай харьцуулахад богино нэр нь бууралт мэт санагддаг. Энэ бол нэр солих бөгөөд шалтгаан нь бүтцийн: TLS 1.3 статик RSA болон хязгаарлагдмал талбарын Diffie-Hellman түлхүүрийн солилцоог хассан тул түр зуурын эллипс муруйн солилцоо нь PSK бус цорын ганц үлдсэн сонголт болсон. Үүнийг багц бүрт нэрлэх нь нэг баримтыг арван хоёр удаа давтах байсан.
Гэрчилгээний төрөл нэрнээс холбоотой шалтгаанаар алга болсон. 1.3-д гэрчилгээ нь гар барилтын гарын үсгийг баталгаажуулдаг, түлхүүрийн тохиролцоог биш, тиймээс багцыг цаашид сонгохгүй. Тиймээс тохиргоонд 1.3-д зориулсан тусдаа шифрийн жагсаалт байдаг: багцуудыг нэр сольж, дахин зохион байгуулсан бөгөөд сулруулаагүй.
Нэг үр дагаврыг шууд хэлэх нь зүйтэй. ECDHE бол түлхүүрийн солилцооны алгоритм бөгөөд хэзээ ч шифр биш. "Эллипс" гэж тодорхойлсон багц нь хоёр тал нийтлэг түлхүүрт хэрхэн хүрсэн тухай ярьдаг бөгөөд дараа нь ачааг юу шифрлэдэг тухай юу ч ярьдаггүй.
auth пакетийг баталгаажуулдаг, ачааг биш
auth зааварчилгаа нь пакетийг баталгаажуулдаг HMAC хайлтыг сонгодог бөгөөд түүний түүхэн өгөгдмөл утга нь SHA1 юм. AEAD бус өгөгдлийн шифртэй үед OpenVPN шифрлэсэн текст дээр хайлтыг тооцоод нэмдэг, энэ нь шифрлэ-дараа-MAC зохион байгуулалт бөгөөд дүүргэлттэй ажиллахыг практик бус болгодог.
Энд байгаа домог нь auth-ыг SHA512 руу өсгөх нь туннелийг хатууруулдаг гэсэн юм. Энэ нь шифрлэлтийн хүчийг нэмэгдүүлэхгүй бөгөөд хэрэв тохиролцсон өгөгдлийн шифр нь AES-256-GCM зэрэг AEAD горим бол хайлт нь өгөгдлийн пакетуудад огт хэрэглэгдэхгүй. GCM шошго тэдгээрийг аль хэдийн баталгаажуулдаг бөгөөд auth утга нь хяналтын сувгийн HMAC болон одоо ч ашиглагдаж буй AEAD бус шифрт үлддэг.
Тиймээс зааварчилгаа чухал боловч файл дахь байрлалаас нь харахад илүү нарийн газарт чухал. Аль шифр үнэхээр тохиролцсоныг шалгах нь энэ нь огт хамаарах эсэхийг хэлнэ.
Профайлыг баганаар уншина, зэрэглэлээр биш
Гурван асуулт давхаргуудыг цэвэрхэн ялгадаг бөгөөд асуулт бүрт тохиролцсон сессийн өөр хэсэг хариулдаг. Аль шифр ачааг хамгаалдаг вэ? Аль шошго эсвэл хайлт пакет бүрт батлан даалт өгдөг бөгөөд ашиглагдаж буй шифрт энэ огт хэрэгтэй юу? Хэний гэрчилгээ гар барилтыг хаасан бэ, хяналтын суваг нэмж tls-auth эсвэл tls-crypt-аар хамгаалагдсан уу?
EC эсвэл ED шошгонд тэр гурвын аль нэгийг ч шийддэг юу ч байхгүй бөгөөд багцын нэр дангаараа ч тэдгээрийн алийг нь ч шийддэггүй. Тохиролцсон үр дүн л цорын ганц нотолгоо тул үгсийн сангаас хүч таамаглахын оронд түүнийг уншина уу:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logЭхний команд нь таны гэрчилгээ үнэхээр ямар гарын үсгийн схемийг ашиглаж байгааг хэлдэг бөгөөд та ECDSA эсвэл Ed25519-ээр ажиллаж байгаа эсэхийг мэдэх цорын ганц найдвартай арга нь энэ юм. Хоёр дахь нь клиент сессийн хувьд бүртгэсэн хяналтын сувгийн мөрийг TLS хувилбар болон түүний тогтсон багцын хамт харуулна. Хэрэв профайлын өөрчлөлтийг эдгээр хоёр гаралтын аль нэгээр ч зөвтгөж чадахгүй бол энэ нь шинж чанарын бус, нэрийн өөрчлөлт байх магадлалтай.