Pot funcionar un certificat RSA amb dh none a OpenVPN?

Aquí teniu una configuració de servidor que diu dh none al costat d'un certificat que diu RSA, més una sospita persistent que un dels dos ha d'estar malament. No hi ha res malament. El certificat signa i autentica; l'intercanvi de claus estableix un secret compartit. Són dues feines diferents en el mateix handshake, i TLS permet que un certificat RSA autentiqui un handshake que fa servir un acord efímer sobre corba el·líptica.

La confusió sol arribar amb una guia de migració. Diu que se substitueixi el fitxer de paràmetres DH per dh none, el lector nota que el certificat no és un certificat de corba el·líptica, i els dos fets es tracten com una contradicció.

Per què els dos paràmetres semblen relacionats

La configuració antiga d'OpenVPN demanava un fitxer de paràmetres DH perquè Diffie-Hellman en camp finit necessita paràmetres de domini en què les dues bandes coincideixin. La directiva dh apuntava a aquell fitxer. Quan un desplegament passa a ECDH, els paràmetres provenen d'una corba amb nom en lloc d'aquell fitxer, i el fitxer ja no cal, que és el que expressa dh none.

Els certificats són un eix separat. Porten una clau pública i una signatura que proven la identitat del servidor, i aquesta clau pot ser RSA o de corba el·líptica independentment de com s'acordi la clau de sessió. Un handshake que fa servir ECDHE per acordar la clau i RSA per autenticar és habitual i està àmpliament desplegat.

L'anomenament empitjora el solapament. La corba el·líptica apareix tant als noms de suite ECDHE com ECDSA, així que és fàcil suposar que qualsevol connexió que esmenti una corba ha d'incloure un certificat de corba. No és així.

Com llegir correctament un nom de suite TLS 1.2

Agafeu ECDHE-RSA-AES256-GCM-SHA384. El primer testimoni és la família d'intercanvi de claus: Diffie-Hellman efímer sobre corba el·líptica. El segon és la família d'autenticació: RSA. La resta descriu la protecció de registres i el hash emprat en el handshake.

Una suite ECDHE-ECDSA fa servir la mateixa família d'intercanvi de claus amb un mètode d'autenticació diferent, així que necessita un certificat de corba el·líptica. Una suite DHE-RSA fa servir Diffie-Hellman efímer en camp finit amb autenticació RSA, i aquesta sí que necessita paràmetres DH.

Llegiu el nom de la suite d'esquerra a dreta i assigneu cada part a la seva feina. Un cop separats els testimonis, la pregunta canvia de «el meu certificat coincideix amb dh none» a «el meu servidor permet una suite l'intercanvi de claus de la qual no necessita un fitxer DH».

Què desactiva realment dh none

dh none diu al servidor que no carregui un fitxer de paràmetres DH de camp finit. No desactiva l'autenticació, la validació de certificats ni TLS mateix. El que sí que exigeix és que l'intercanvi de claus negociat no necessiti aquests paràmetres, cosa que a la pràctica vol dir una suite ECDHE o un handshake TLS 1.3.

És d'aquest requisit d'on surt l'avaria. Si la política de xifratges TLS del servidor es limita a suites DHE, o si un client només n'ofereix d'aquestes, treure el fitxer de paràmetres no deixa cap mètode d'intercanvi de claus utilitzable i el handshake falla. L'error sol aparèixer durant el handshake del canal de control, abans de qualsevol autenticació d'usuari. Llegiu la llista de xifratges abans de culpar el fitxer que falta.

Pel costat de la corba el·líptica, la corba la tria la configuració TLS del servidor, i OpenVPN ofereix una opció per triar-la en branques antigues. TLS 1.3 gestiona la negociació del grup dins del protocol i no consulta el fitxer DH en absolut.

dh none no és una rebaixa de seguretat per si sol. La força de l'intercanvi depèn llavors de la corba i la suite que realment es negocien, i per això el pas següent és mirar què han triat els parells i no el fitxer que falta.

Confirmar la negociació abans d'editar

Augmenteu la verbositat del servidor i del client i llegiu la línia del canal de control que OpenVPN imprimeix després d'una connexió. Anomena la versió de TLS i el xifratge negociat, i informa del tipus de clau del certificat del parell. Aquesta sola línia respon la pregunta que el fitxer de configuració només insinua.

Si mostra TLS 1.2 amb una suite ECDHE-RSA i un certificat RSA, la combinació és exactament el que dh none espera, i no hi ha res a reparar. Si mostra una suite DHE o un error de handshake sense xifratge comú, la solució és a la política de xifratges o a la capacitat del client, no al certificat.

Proveu el client més antic que vulgueu suportar, perquè un client actual pot negociar TLS 1.3 mentre un d'antic es limita a suites TLS 1.2. Si el client més antic no té cap solapament, amplieu les suites permeses o actualitzeu aquell extrem.

No desactiveu la verificació de certificats per superar un error de handshake. L'error us diu que els parells no s'han pogut posar d'acord en un intercanvi de claus, i desactivar la comprovació elimina la garantia d'identitat sense resoldre l'acord.

Llista de comprovació: el certificat és RSA, es permet una suite ECDHE, el registre mostra aquesta suite i el client compatible més antic també la negocia? Si totes quatre respostes són sí, dh none fa la seva feina.