Les claus de 8192 bits encallen l'apretada de mans; el DH de 1024 bits es rebutja

Un servidor té clients que s'encallen una estona i després es reconnecten, i un altre rebutja les connexions de seguida amb un missatge sobre la mida de la clau. Semblen errors diferents i són el mateix error apuntant en direccions oposades. La criptografia de l'apretada de mans té un cost que creix amb la mida dels paràmetres, i també té un terra per sota del qual les biblioteques modernes no baixen. Dimensionar el material és la llista de comprovació, i el primer punt és decidir quin dels dos errors teniu realment.

Llegiu la fallada abans de regenerar res

El temps us diu la major part. Una apretada que consumeix uns quants segons i després mor sol significar que el càlcul va superar la paciència del parell, cosa que apunta a paràmetres massa grans per al maquinari o per al temps d'espera. Un rebuig immediat que anomena una mida de clau o de grup apunta a l'altra banda, a material que la biblioteca no acceptarà de cap manera.

Aquests dos necessiten correccions oposades, i aquí és on fallen la majoria d'intents. Regenerar paràmetres de 8192 bits en un client que ja ha rebutjat un grup petit empitjora el cas lent mentre no fa res pel ràpid. Anoteu quin símptoma heu observat abans de tocar cap fitxer.

Després comproveu què es demana al parell. Un servidor configurat per a un grup gran de camp finit obliga cada client a gastar el mateix temps de CPU en cada renegociació, no només en connectar-se. Si el problema apareix a un interval regular en lloc de a l'inici, aquest interval és una pista forta de quina configuració és cara. La renegociació repeteix tot el càlcul, així que una aturada que es repeteix cada hora sol ser el mateix cost pagat una altra vegada.

El cas lent: material que el maquinari no es pot permetre

La feina de Diffie-Hellman i RSA creix de pressa amb la mida de la clau, i tot passa abans que hi hagi cap trànsit pel túnel. En un encaminador petit o un client de poca potència, un grup prou gran pot empènyer l'intercanvi més enllà del temps d'espera de l'altra banda, de manera que la connexió reintenta o simplement sembla penjada sense cap error.

La solució és baixar a una mida que tots els parells admetin i que cada dispositiu pugui calcular còmodament. Una clau RSA de 2048 bits i un grup de 2048 bits continuen sent una base àmpliament compatible; anar més enllà només ajuda quan tots els parells hi estan d'acord i la CPU ho pot pagar a cada renegociació. Tot el que supera aquesta base és un intercanvi deliberat, no una millora.

La mida no és una puntuació, i el número més gran d'una taula comparativa no és automàticament l'opció correcta. Trieu el valor més petit que la vostra política permeti i que tots els parells acceptin, i després mesureu l'apretada en lloc de suposar que ha millorat. Un grup més petit que encara esgota el temps us diu que la mida mai no va ser tota la història.

El cas ràpid: un grup que la biblioteca rebutja

Les compilacions modernes d'OpenSSL rebutgen de ple els grups de camp finit més petits, i un nivell de seguretat elevat encara apuja més el terra. El firmware d'encaminador que porta un fitxer de paràmetres de fa dècades és la font habitual, i el símptoma és una connexió que falla de seguida amb un missatge que anomena el grup o la mida de la clau. Res d'aquesta fallada és intermitent, i això és el que la fa fàcil de reconèixer.

Substituïu el fitxer en lloc d'editar la configuració per saltar-vos la comprovació. Genereu un grup actual, valideu-lo i instal·leu-lo allà on el dimoni el llegeix de veritat. Conserveu el fitxer vell fins que un client s'hagi connectat amb èxit amb el nou:

openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pem

L'ordre de comprovació valida el fitxer i no imprimeix res útil quan passa; el llistat confirma que heu substituït el fitxer que carrega el servei i no una còpia antiga al costat. Apunteu la configuració a aquest camí, reinicieu el dimoni i confirmeu que un client que abans fallava ara completa l'apretada.

Si el servidor també fixa un nivell de seguretat o un perfil de certificat, llegiu-los abans de concloure que el grup era dolent. Un perfil que exigeix una classe més estricta pot rebutjar material que el valor per defecte hauria acceptat, i treure aquesta configuració és un canvi més estret que desactivar la comprovació globalment.

Trieu una mida per al parell i el maquinari

Esbrineu què pot suportar l'extrem llunyà abans de generar res exòtic. Un dispositiu massa vell per a un grup de 2048 bits és un dispositiu per substituir, ja que apuntar el servidor a un grup més feble només converteix una queixa de compatibilitat en una caiguda. Les solucions duradores van cap a programari més nou, no cap a paràmetres més vells. Cada excepció temporal en aquest àmbit té la manera de convertir-se en la configuració permanent.

On la CPU del servidor és el límit, canvieu l'algorisme en lloc de baixar per sota de la política. Un intercanvi de claus de corba el·líptica com X25519 és molt més barat que un grup gran de camp finit i té suport ampli, cosa que el converteix en la millor resposta a una queixa de rendiment que un mòdul RSA més petit.

Tant se val què trieu, proveu-ho amb una connexió real i mireu quant triga l'apretada, no només si al final connecta. Una connexió que té èxit en dotze segons té la mateixa causa arrel que una que falla als quinze.

Anoteu l'elecció perquè una reconstrucció no la desfaci

Mantingueu el fitxer de paràmetres sota gestió de configuració i escriviu-hi al costat la mida, el motiu i la data. Un servidor reconstruït que genera en silenci els seus propis valors per defecte és com el mateix error torna sis mesos després sense que ningú pugui explicar la decisió original.

Anoteu la mateixa informació al costat de l'extrem i del perfil, perquè una revisió no hagi de reconstruir-ho a partir de la mida d'un fitxer. Quan la propera connexió s'encalli, aquesta nota és la diferència entre una comprovació de cinc minuts i una investigació nova. També evita que el següent enginyer resolgui el cas lent amb una solució pensada per al ràpid.