Kan 'n RSA-sertifikaat met dh none in OpenVPN werk?

Hier is 'n bedienerkonfigurasie wat dh none sê langs 'n sertifikaat wat RSA sê, plus 'n kwelende vermoede dat een van hulle verkeerd moet wees. Niks is verkeerd nie. Die sertifikaat onderteken en verifieer; die sleuteluitruil vestig 'n gedeelde geheim. Dit is twee verskillende take in dieselfde handskud, en TLS laat 'n RSA-sertifikaat 'n handskud verifieer wat tydelike elliptiese-kromme-ooreenkoms gebruik.

Die verwarring kom gewoonlik saam met 'n migrasiegids. Dit sê om die DH-parameterlêer met dh none te vervang, die leser merk dat die sertifikaat nie 'n elliptiese-kromme-sertifikaat is nie, en die twee feite word as 'n teenstrydigheid behandel.

Waarom die twee instellings verwant lyk

OpenVPN se ouer konfigurasie het 'n DH-parameterlêer gevra omdat eindige-veld Diffie-Hellman domeinparameters nodig het waaroor beide kante dit eens moet wees. Die dh-richtlijn het na daardie lêer gewys. Wanneer 'n ontplooiing na ECDH beweeg, kom die parameters eerder van 'n benoemde kromme, en die lêer is nie meer nodig nie, wat dh none uitdruk.

Sertifikate is 'n aparte as. Hulle dra 'n publieke sleutel en 'n handtekening wat die bediener se identiteit bewys, en daardie sleutel kan RSA of elliptiese kromme wees, ongeag hoe die sessiesleutel ooreengekom word. 'n Handskud wat ECDHE vir sleutelooreenkoms en RSA vir verifikasie gebruik, is gewoon en wyd ontplooi.

Die naamgewing maak die oorvleueling erger. Elliptiese kromme verskyn in beide ECDHE- en ECDSA-suite-name, so dit is maklik om te aanvaar dat enige verbinding wat 'n kromme noem, 'n kromme-sertifikaat moet behels. Dit is nie so nie.

Hoe om 'n TLS 1.2-suite-naam reg te lees

Neem ECDHE-RSA-AES256-GCM-SHA384. Die eerste token is die sleuteluitruilfamilie: tydelike elliptiese-kromme Diffie-Hellman. Die tweede is die verifikasiefamilie: RSA. Die res beskryf rekordbeskerming en die hash wat in die handskud gebruik word.

'n ECDHE-ECDSA-suite gebruik dieselfde sleuteluitruilfamilie met 'n ander verifikasiemetode, so dit het 'n elliptiese-kromme-sertifikaat nodig. 'n DHE-RSA-suite gebruik eindige-veld tydelike Diffie-Hellman met RSA-verifikasie, en daardie een het wel DH-parameters nodig.

Lees 'n suite-naam van links na regs en ken elke deel aan sy taak toe. Sodra die tokens geskei is, verander die vraag van "pas my sertifikaat by dh none" na "laat my bediener 'n suite toe waarvan die sleuteluitruil nie 'n DH-lêer nodig het nie".

Wat dh none werklik deaktiveer

dh none sê vir die bediener om nie 'n eindige-veld DH-parameterlêer te laai nie. Dit deaktiveer nie verifikasie, sertifikaatvalidasie of TLS self nie. Wat dit wel vereis, is dat die onderhandelde sleuteluitruil een moet wees wat nie daardie parameters nodig het nie, wat in die praktyk 'n ECDHE-suite of 'n TLS 1.3-handskud beteken.

Dit is by daardie vereiste waar breek vandaan kom. As die bediener se TLS-syferbeleid tot DHE-suites beperk is, of as 'n kliënt net hulle aanbied, laat die verwydering van die parameterlêer geen bruikbare sleuteluitruilmetode nie en die handskud misluk. Die fout verskyn gewoonlik tydens die beheerkanalen-handskud, voor enige gebruikerverifikasie. Lees die syferlys voordat jy die lêer wat ontbreek blameer.

Aan die elliptiese-kromme-kant word die kromme deur die bediener se TLS-konfigurasie gekies, en OpenVPN bied 'n opsie om dit op ouer takke te kies. TLS 1.3 hanteer die groeponderhandeling binne die protokol en raadpleeg glad nie die DH-lêer nie.

dh none is nie op sigself 'n sekuriteitsverlaging nie. Die sterkte van die uitruil hang dan af van die kromme en suite wat werklik onderhandel word, en daarom is die volgende stap om te kyk wat die eweknieë gekies het eerder as na die lêer wat afwesig is.

Bevestig die onderhandeling voordat jy redigeer

Verhoog die bediener- en kliëntwoordrykheid en lees die beheerkanalen-lyn wat OpenVPN na 'n verbinding druk. Dit noem die TLS-weergawe en die onderhandelde syfer, en dit rapporteer die eweknie-sertifikaat se sleuteltipe. Daardie enkele lyn beantwoord die vraag wat die konfigurasielêer net impliseer.

As dit TLS 1.2 met 'n ECDHE-RSA-suite en 'n RSA-sertifikaat wys, is die kombinasie presies wat dh none verwag, en daar is niks om te herstel nie. As dit 'n DHE-suite of 'n handskudfout met geen gemeenskaplike syfer wys, is die oplossing in die syferbeleid of die kliëntvermoë, nie in die sertifikaat nie.

Toets die oudste kliënt wat jy van plan is om te ondersteun, want 'n huidige kliënt kan TLS 1.3 onderhandel terwyl 'n ouer een tot TLS 1.2-suites beperk is. As die oudste kliënt geen oorvleueling het nie, brei die toegelate suites uit of gradeer daardie eindpunt op.

Moenie sertifikaatverifikasie afskakel om 'n handskudfout verby te kom nie. Die fout sê vir jou dat die eweknieë nie oor 'n sleuteluitruil kon saamstem nie, en die control wegneem verwyder die identiteitswaarborg sonder om die ooreenkoms aan te spreek.

Kontrolelys: is die sertifikaat RSA, word 'n ECDHE-suite toegelaat, wys die log daardie suite, en onderhandel die oudste ondersteunde kliënt dit ook? As al vier ja is, doen dh none sy werk.