Ĉu RSA-atestilo povas funkcii kun dh none en OpenVPN?

Jen servila agordo kiu diras dh none apud atestilo kiu diras RSA, plus ĝena suspekto ke unu el ili devas esti malĝusta. Nenio estas malĝusta. La atestilo subskribas kaj aŭtentigas; la ŝlosilinterŝanĝo establas komunan sekreton. Tiuj estas du malsamaj taskoj en la sama intermano, kaj TLS permesas al RSA-atestilo aŭtentigi intermanon kiu uzas efemeran elipsan-kurban interkonsenton.

La konfuzo kutime alvenas kun migrada gvidilo. Ĝi diras anstataŭigi la DH-parametran dosieron per dh none, la leganto rimarkas ke la atestilo ne estas elipsa-kurba atestilo, kaj la du faktoj estas traktataj kiel kontraŭdiro.

Kial la du agordoj ŝajnas rilataj

La pli malnova agordo de OpenVPN postulis DH-parametran dosieron ĉar finia-kampa Diffie-Hellman bezonas domajnajn parametrojn pri kiuj ambaŭ flankoj konsentas. La direktivo dh montris al tiu dosiero. Kiam deplojo transiras al ECDH, la parametroj venas el nomita kurbo anstataŭe, kaj la dosiero ne plu necesas, kion esprimas dh none.

Atestiloj estas aparta akso. Ili portas publikan ŝlosilon kaj subskribon kiuj pruvas la identecon de la servilo, kaj tiu ŝlosilo povas esti RSA aŭ elipsa kurbo sendepende de kiel oni interkonsentas la sesian ŝlosilon. Intermano kiu uzas ECDHE por ŝlosila interkonsento kaj RSA por aŭtentigo estas ordinara kaj vaste deplojita.

La nomado plimalbonigas la koincidon. Elipsa kurbo aperas en ambaŭ ECDHE kaj ECDSA suito-nomoj, do facile supozi ke ajna konekto mencianta kurbo devas enhavi kurban atestilon. Ne tiel estas.

Kiel ĝuste legi TLS 1.2 suito-nomon

Prenu ECDHE-RSA-AES256-GCM-SHA384. La unua ĵetono estas la ŝlosilinterŝanĝa familio: efemera elipsa-kurba Diffie-Hellman. La dua estas la aŭtentiga familio: RSA. La resto priskribas rekordan protekton kaj la haketon uzatan en la intermano.

Suito ECDHE-ECDSA uzas la saman ŝlosilinterŝanĝan familion kun malsama aŭtentiga metodo, do ĝi bezonas elipsan-kurban atestilon. Suito DHE-RSA uzas finia-kampan efemeran Diffie-Hellman kun RSA-aŭtentigo, kaj tiu ja bezonas DH-parametrojn.

Legu suito-nomon de maldekstre dekstren kaj atribuu ĉiun parton al ĝia tasko. Post kiam la ĵetonoj estas apartigitaj, la demando ŝanĝiĝas de «ĉu mia atestilo kongruas kun dh none» al «ĉu mia servilo permesas suiton kies ŝlosilinterŝanĝo ne bezonas DH-dosieron».

Kion dh none fakte malŝaltas

dh none diras al la servilo ne ŝargi finia-kampan DH-parametran dosieron. Ĝi ne malŝaltas aŭtentigon, atestilan validumon aŭ TLS mem. Ĝi tamen postulas ke la interkonsentita ŝlosilinterŝanĝo estu tiu kiu ne bezonas tiujn parametrojn, kio praktike signifas ECDHE-suiton aŭ TLS 1.3-intermanon.

El tiu postulo venas la paneo. Se la TLS-ĉifra politiko de la servilo limiĝas al DHE-suitoj, aŭ se kliento proponas nur ilin, forigo de la parametra dosiero lasas neniun uzeblan ŝlosilinterŝanĝan metodon kaj la intermano malsukcesas. La eraro kutime aperas dum la intermano de la rega kanalo, antaŭ iu ajn uzanta aŭtentigo. Legu la ĉifran liston antaŭ ol kulpigi la mankan dosieron.

Ĉe la elipsa-kurba flanko, la kurbon elektas la TLS-agordo de la servilo, kaj OpenVPN proponas opcion elekti ĝin en pli malnovaj branĉoj. TLS 1.3 pritraktas la grupan interkonsenton ene de la protokolo kaj tute ne konsultas la DH-dosieron.

dh none mem ne estas sekureca malaltigo. La forto de la interŝanĝo tiam dependas de la kurbo kaj suito kiuj fakte interkonsentiĝas, tial la sekva paŝo estas rigardi kion la partneroj elektis, ne la mankan dosieron.

Konfirmi la interkonsenton antaŭ redaktado

Altigu la detalnivelon de la servilo kaj kliento kaj legu la regkanalan linion kiun OpenVPN presas post konekto. Ĝi nomas la TLS-version kaj la interkonsentitan ĉifron, kaj raportas la ŝlosilan tipon de la partnersa atestilo. Tiu sola linio respondas la demandon kiun la agorda dosiero nur implicas.

Se ĝi montras TLS 1.2 kun ECDHE-RSA-suito kaj RSA-atestilo, la kombinaĵo estas ĝuste tio, kion dh none atendas, kaj nenio estas riparinda. Se ĝi montras DHE-suiton aŭ intermanan malsukceson sen komuna ĉifro, la riparo estas en la ĉifra politiko aŭ la klientaj kapabloj, ne en la atestilo.

Testu la plej malnovan klienton kiun vi intencas subteni, ĉar nuntempa kliento povas interkonsenti TLS 1.3 dum pli malnova limiĝas al TLS 1.2-suitoj. Se la plej malnova kliento havas neniun koincidon, aŭ vastigu la permesitajn suitojn aŭ ĝisdatigu tiun finpunkton.

Ne malŝaltu atestilan kontrolon por preterpasi intermanan malsukceson. La malsukceso diras al vi ke la partneroj ne povis interkonsenti pri ŝlosilinterŝanĝo, kaj malŝalti la kontrolon forigas la identecan garantion sen solvi la interkonsenton.

Kontrola listo: ĉu la atestilo estas RSA, ĉu ECDHE-suito estas permesita, ĉu la protokolo montras tiun suition, kaj ĉu la plej malnova subtenata kliento ankaŭ interkonsentas ĝin? Se ĉiuj kvar estas jes, dh none faras sian taskon.