Pode funcionar un certificado RSA con dh none en OpenVPN?

Aquí hai unha configuración de servidor que di dh none xunto a un certificado que di RSA, ademais da incómoda sospeita de que un dos dous debe estar mal. Nada está mal. O certificado asina e autentica; o intercambio de claves establece un segredo compartido. Son dúas tarefas distintas no mesmo handshake, e TLS permite que un certificado RSA autentique un handshake que usa un acordo efémero sobre curva elíptica.

A confusión adoita chegar cunha guía de migración. Di que se substitúa o ficheiro de parámetros DH por dh none, o lector nota que o certificado non é un certificado de curva elíptica, e ambos os feitos trátanse como unha contradición.

Por que os dous axustes parecen relacionados

A configuración antiga de OpenVPN pedía un ficheiro de parámetros DH porque Diffie-Hellman de campo finito necesita parámetros de dominio nos que ambas as partes coincidan. A directiva dh apuntaba a ese ficheiro. Cando un despregamento pasa a ECDH, os parámetros proveñen dunha curva con nome no seu lugar, e o ficheiro xa non fai falta, que é o que expresa dh none.

Os certificados son un eixe aparte. Levan unha clave pública e unha sinatura que proban a identidade do servidor, e esa clave pode ser RSA ou de curva elíptica independentemente de como se acorde a clave de sesión. Un handshake que usa ECDHE para o acordo de clave e RSA para a autenticación é habitual e está amplamente despregado.

A nomenclatura empeora o solapamento. A curva elíptica aparece tanto nos nomes de suite ECDHE como ECDSA, así que é fácil supor que calquera conexión que mencione unha curva debe incluír un certificado de curva. Non é así.

Como ler correctamente un nome de suite TLS 1.2

Tome ECDHE-RSA-AES256-GCM-SHA384. O primeiro token é a familia de intercambio de claves: Diffie-Hellman efémero sobre curva elíptica. O segundo é a familia de autenticación: RSA. O resto describe a protección de rexistros e o hash usado no handshake.

Unha suite ECDHE-ECDSA usa a mesma familia de intercambio de claves cun método de autenticación distinto, así que necesita un certificado de curva elíptica. Unha suite DHE-RSA usa Diffie-Hellman efémero de campo finito con autenticación RSA, e esa si necesita parámetros DH.

Lea un nome de suite de esquerda a dereita e asigne cada parte á súa tarefa. Unha vez separados os tokens, a pregunta cambia de «o meu certificado coincide con dh none» a «o meu servidor permite unha suite cuxo intercambio de claves non necesita un ficheiro DH».

Que desactiva realmente dh none

dh none indica ao servidor que non cargue un ficheiro de parámetros DH de campo finito. Non desactiva a autenticación, a validación de certificados nin o propio TLS. O que si esixe é que o intercambio de claves negociado sexa un que non necesite eses parámetros, o que na práctica significa unha suite ECDHE ou un handshake TLS 1.3.

Dese requisito vén a rotura. Se a política de cifrados TLS do servidor se limita a suites DHE, ou se un cliente só ofrece esas, eliminar o ficheiro de parámetros non deixa ningún método de intercambio de claves utilizábel e o handshake falla. O erro adoita aparecer durante o handshake da canle de control, antes de calquera autenticación de usuario. Lea a lista de cifrados antes de culpar o ficheiro que falta.

Do lado da curva elíptica, a curva elíxea a configuración TLS do servidor, e OpenVPN ofrece unha opción para escollala en ramas antigas. TLS 1.3 xestiona a negociación do grupo dentro do protocolo e non consulta o ficheiro DH en absoluto.

dh none non é unha baixada de seguridade por si mesmo. A forza do intercambio depende entón da curva e a suite que realmente se negocien, por iso o seguinte paso é mirar que elixiron os pares e non o ficheiro que falta.

Confirmar a negociación antes de editar

Suba a verbosidade do servidor e do cliente e lea a liña da canle de control que OpenVPN imprime tras unha conexión. Nomea a versión de TLS e o cifrado negociado, e informa do tipo de clave do certificado do par. Esa única liña responde a pregunta que o ficheiro de configuración só insinúa.

Se mostra TLS 1.2 cunha suite ECDHE-RSA e un certificado RSA, a combinación é exactamente o que dh none espera, e non hai nada que reparar. Se mostra unha suite DHE ou un fallo de handshake sen cifrado común, a solución está na política de cifrados ou na capacidade do cliente, non no certificado.

Probe o cliente máis antigo que pretenda soportar, porque un cliente actual pode negociar TLS 1.3 mentres un máis antigo se limita a suites TLS 1.2. Se o cliente máis antigo non ten solapamento, amplíe as suites permitidas ou actualice ese extremo.

Non desactive a verificación de certificados para superar un fallo de handshake. O fallo dille que os pares non puideron acordar un intercambio de claves, e desactivar a comprobación elimina a garantía de identidade sen resolver o acordo.

Lista de comprobación: o certificado é RSA, permítese unha suite ECDHE, o rexistro mostra esa suite e o cliente compatible máis antigo tamén a negocia? Se as catro son si, dh none fai o seu traballo.