Које OpenVPN пакете штити auth диџест?
Опција auth покрива мање него што профил сугерише. Пређите кроз канал, случај AEAD и заштиту контролног канала пре него што поставите политику диџеста.
Већина расправа о OpenVPN диџестима почиње од погрешног пакета. Читати auth SHA256 као „прихвати само партнере који нуде SHA256“ је прва ствар од које треба одвикнути. Опција именује диџест за одређене пакете, а који су то пакети зависи од канала и од тога да ли је тај канал AEAD. Прођите кроз четири питања испод по реду; свако сужава шта подешавање може да значи у вашем распоређивању.
Именујте канал који подешавање треба да штити
OpenVPN има контролни канал који носи саобраћај TLS руковања и податковни канал који носи корисни терет тунела. auth диџест има улогу у оба, али не исту, и профил ретко чини разлику видљивом. Запишите који од два покушавате да ограничите пре него што додирнете конфигурациону датотеку.
Табела испод је кратка верзија тога како иста опција слеће у сваки контекст.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Проверите да ли је податковни канал AEAD пре него што се на њега ослоните
Ако је договорена податковна шифра AES-GCM или CHACHA20-POLY1305, податковни канал сам себе аутентификује и одвојени диџест не обавља посао који можда замишљате. Оба су AEAD конструкције, па интегритет настаје истом операцијом која шифрује терет. То није деградација, али значи да је политика оправдана као „сваки податковни пакет је HMAC-SHA256“ чињенично погрешна на том тунелу. Потврдите договорену вредност у дневнику сервера или у излазу статуса клијента пре него што препишете политику.
Испитајте шифру која је заиста договорена, а не списак у профилу, јер преговори могу да се заврше на другом члану скупа. data-ciphers AES-256-GCM:AES-128-GCM је листа за преговоре, и оба уноса су AEAD, па ниједан од њих не троши auth диџест за заштиту терета.
Третирајте заштиту контролног канала као посебну одлуку
tls-auth додаје HMAC пакетима контролног канала и узима свој диџест из подешавања auth, зато један AEAD тунел и даље може имати смислен диџест конфигуриран. tls-crypt је другачији распоред са сопственом фиксном заштитом, па не претпостављајте да наслеђује свако својство tls-auth. Читајте документацију за механизам који сте изабрали уместо да преносите претпоставке између њих.
Две стране такође морају да се сложе око распореда и око смера кључа. Диџест који се поклапа, али датотека кључа употребљена у погрешном смеру, даје руковање које не успева због разлога које подешавање диџеста не може да објасни.
Држите auth одвојено од преговора о шифрама и од сертификата
Три подешавања се стално мешају: auth диџест, списак податковних шифара и алгоритам потписа сертификата. Промена првог не издаје поново сертификат, не бира његов диџест потписа и не ствара метод корисник-лозинка. Дефиниције протоколских опција у изворима OpenVPN 2.6 описују сваку у сопственом одељку, што је користан подсетник да су то независни регулатори.
Када партнер одбије да се повеже после промене диџеста, узрок је обично неслагање у једном од друге две подешавања. Прочитајте оба краја пре него што промените било које.
Запишите политику и упоредите је са конфигурацијама које раде
Изјава на нивоу флоте треба у истој реченици изричито да наведе дозвољене режиме податковног канала и изабрану заштиту контролног канала. Та реченица је проверљива; „користимо SHA256“ није. Затим је упоредите са стварним профилима сервера и клијента, а не са шаблоном у складишту.
Завршите записивањем шта је сваки тунел заиста договорио и који механизам је аутентификовао његове пакете. Видљив auth ред у профилу је доказ само намере конфигурације, а намера је најјефтинији део провере.