VPN-ийн хувийн түлхүүрийн нууц үг юуг үнэхээр хамгаалдаг вэ

VPN клиент эхлэх үед гарч ирэх хүсэлтийг буруу уншихад хялбар. Энэ нь VPN бүртгэлийн нууц үг биш, туннелийн нууц үг биш бөгөөд оруулсан нь холболт аюулгүй гэдгийг нотлохгүй. Энэ нь хувийн түлхүүрийн нэг хадгалагдсан дүрслэлийг онгойлгож, клиент түлхүүрийн материалыг уншиж, баталгаажуулалтад ашиглах боломжийг олгоно. Дараа нь болох бүх зүйл өөр асуудал юм.

Практикт хариулт ирмэг дээр эвдэрдэг: хүмүүс нууц үг нь ажиллаж буй туннелийг хамгаалдаг эсвэл өөрчлөх нь аль хэдийн алдагдсан түлхүүрийн хуулбарыг хүчингүй болгодог гэж үздэг. Хоёр таамаглал хоёулаа бүтэлгүйтдэг бөгөөд итгэмжлэл нээлттэй үлдэж, оператор үүнийг шийдсэн гэж итгэдэг байдлаар бүтэлгүйтдэг.

Нэг харилцаа, хэд хэдэн өөр нууц

Хувийн түлхүүрийн нууц үг файлыг тайлна. Бүртгэлийн нууц үг таныг үйлчилгээнд баталгаажуулна. PKCS#12 импортын нууц үг түлхүүр болон түүний гэрчилгээг агуулсан багцыг тайлна, энэ нь түлхүүрийн өөрийн нууц үгтэй ижил мөр байх албагүй. Эдгээр хүсэлтүүд бараг ижил харагдаж болох бөгөөд аль нууц хаашаа явахыг таах нь түлхүүрүүд буруу талбарт наалдах шалтгаан болдог.

Туннелийн өөрийнх нь шифрлэлт дөрөв дэх зүйл. Өгөгдлийн суваг гар барих үед тохиролцсон сессийн түлхүүрүүдийг ашигладаг; хувийн түлхүүрийн нууц үг нь бие даасан пакетуудыг хамгаалахад ямар ч үүрэггүй. Хэрэв хэн нэгэн түлхүүрийн файлыг уншиж чадвал нууц үгийг офлайн таах оролдож болно, гэхдээ пакетуудыг уншиж чадвал нууц үг хамаагүй.

Диск дээрх шифрлэлт юуг хамардаг

Шифрлэгдсэн PEM түлхүүр хоёр хэлбэртэй бөгөөд гарчиг нь аль нь байгааг хэлнэ. Орчин үеийн PKCS#8 хэлбэр -----BEGIN ENCRYPTED PRIVATE KEY------ээр эхэлдэг; хуучин OpenVPN тохиргоонд түгээмэл хэвээр байгаа хуучин PEM хэлбэр -----BEGIN RSA PRIVATE KEY------ээр эхэлж, яг доор нь Proc-Type: 4,ENCRYPTED болон DEK-Info мөрийг агуулна. Файл хувийн түлхүүрийг таны нууц үгнээс гаргасан түлхүүрийн дор шифрлэж хадгалдаг бөгөөд ихэвчлэн заасан давталтын тоо эсвэл ажлын коэффициент бүхий нууц үгэнд суурилсан KDF ашигладаг. OpenSSL pkey баримт бичиг форматууд болон унших үед хэрэглэгдэх нууц үгийн сонголтуудыг хамарна.

Үүнээс хоёр үр дагавар гарна. Сул нууц үгийг KDF-ийн зөвшөөрсөн хурдаар офлайн довтолж болох тул файл шифрлэгдсэн ч файлын зөвшөөрөл, нөөц хуулбарт хандах хандалт чухал хэвээр. Мөн нууц үггүйгээр зөвхөн файлыг авсан довтолгооч таах ёстой; файл болон нууц үгийг хоёуланг нь авсан хүн түлхүүртэй, яг л хэзээ ч шифрлэгдээгүй мэт.

head -3 vpn.key
openssl pkey -in vpn.key -noout -pubout
openssl pkcs12 -in bundle.p12 -info -noout

head -3 гарчгийг, хуучин файл дээр шифрлэлтийг нотлох Proc-Type болон DEK-Info мөрүүдийг харуулна; ганц мөр нь аль ч чиглэлд нотолгоо биш. pkey мөр нууц үгийг асууж, зөвхөн нийтийн хагасыг хэвлэдэг нь файл болон нууц үг ажиллаж байгааг хувийн түлхүүрийг илчлэхгүйгээр нотолно. Тэр шалгалтад -text ашиглаж болохгүй: энэ нь хувийн бүрэлдэхүүн хэсгүүд болох privateExponent, prime1, prime2 болон бусад хэсгийг хэвлэдэг бөгөөд энэ гаралтыг хэзээ ч хаана ч нааж болохгүй, тасалбарт ч, чатад ч, логт ч. PKCS#12 команд нь багцад тусдаа MAC эсвэл шифрлэлтийн нууц үг байгаа эсэхийг хэлдэг бөгөөд хамт олонд өгөхөөс өмнө мэдэх нь зүйтэй.

Түлхүүр ачаалагдсаны дараа юуг хамгаалахаа болих вэ

Онгойлгох нь тэр процессын хувьд нэг чиглэлийн үйл явдал. Клиент KDF-ээс түлхүүрийг хүсч, файлыг тайлж, шаардлагатай хугацаанд хувийн түлхүүрийг санах ойд хадгална. Тэр мөчөөс эхлэн нууц үг ажиллаж буй сессийн талаар юу ч хамгаалахгүй: процессын санах ойг ч, цөмийн дампыг ч, клиентэд холбогдсон дибаг сессийг ч, түлхүүрийг ашиглаж байх үед авсан машины нөөц хуулбарыг ч биш.

Энэ нь нууц үгтэй SSH түлхүүр эсвэл нууц үгийн менежерийн онгойлгосон сейфийн ижил хил юм. Энэ нь тайван байгаа файлыг хулгайлах өртгийг өсгөдөг бөгөөд таны хэрэглэгчийн нэрээр ажиллаж буй хортой програм, клиентээс гарын үсэг зурахыг хүсдэг зөвшөөрөгдсөн програм, эсвэл санах ойг уншиж чаддаг админтай тэмцэхгүй. Үүнийг нэг давхарга гэж үзээрэй, түлхүүрийг орхиод явахад аюулгүй болгодог хяналт гэж биш.

Хүсэлт яагаад байнга буцаж ирдэг вэ

Дахин холбогдох бүрт дахин асуудаг клиент заавал эвдэрсэн байх албагүй. Зарим клиент нууц үгийг сессийн кэшэд хадгалдаг, зарим нь үйлдлийн системийн түлхүүрийн багцад хадгалдаг, заримыг нь нийлүүлдэг туслах руу чиглүүлж болох тул авах зан төлөв нь клиент болон түүний тохиргооноос хамаарна, түлхүүрийн файлаас биш.

Хэрэв давтагдах хүсэлт нь жинхэнэ гомдол бол түлхүүрээс шифрлэлтийг арилгахаас өмнө клиентийн кэш болон баталгаажуулалтын сонголтуудыг шалгаарай. Нууц үгийг арилгах нь хамгаалагдсан файлыг энгийн текст түлхүүр болгож, дахин холбогдох нь таны байсан цорын ганц тайван хяналтын өртгөөр намжина. Илүү сайн хариулт нь ихэвчлэн ижил файлын зөвшөөрөлтэй дэмжигдсэн итгэмжлэлийн сан юм.

Алдагдал ба илчлэлт нь ижил засвар биш

Алдагдсан нууц үгийг гэрчилгээнээс сэргээх боломжгүй. Гэрчилгээ нь нэрийг түлхүүртэй холбосон нийтийн материал; үүнд хувийн түлхүүр рүү буцах зам ч, нууц үгийн тухай сануулга ч байхгүй. Практик сонголтууд нь түлхүүрийн зөвшөөрөгдсөн нөөц хуулбар эсвэл операторын ердийн процессоор олгогдсон шинэ таних тэмдэг юм. Нууц үгийг 'сэргээх' гэж санал болгож буй хэн бүхэн түүнийг таахыг санал болгодог.

Илчлэлт нь өөр хариулт шаарддаг. Ижил түлхүүрийг шинэ нууц үгээр дахин шифрлэх нь түлхүүрийн материалыг өөрчлөхгүй орхидог тул өөр газар аль хэдийн онгойлгосон хуулбар ажилласаар байна. Засвар нь итгэмжлэлийг цуцлах эсвэл солих: шинэ түлхүүр, гэрчилгээ олгож, тарааж, хуучин нь түнш дээр тэтгэвэрт гаргах. Энэ болтол файлын нууц үгийг өөрчлөх нь гэрийн ажил, хязгаарлалт биш. Хуучин файлыг нөөц хуулбараас гадуур байлгахыг зөвхөн шинэ таних тэмдэг ажиллаж байгааг баталсны дараа, аль серийн дугаар эсвэл хурууны хээ үүнийг сольсоныг тэмдэглээрэй.