OpenVPN tls-ciphersuites enfront de tls-version-min: què imposa cadascun

Tres fets diferents es col·lapsen en una línia en la majoria de debats sobre OpenVPN i TLS: què pot fer la vostra compilació de client, què permet el perfil i què ha negociat realment la sessió. Una llista curta de suites TLS 1.3 només respon a mitges la pregunta del mig, i no diu res sobre el llindar mínim de la versió del protocol. Feu les comprovacions següents en ordre i atureu-vos a la primera que no es compleixi, perquè cada comprovació posterior assumeix que les anteriors ja estan resoltes.

Comproveu la compilació abans de llegir cap llista

Una directiva de configuració no pot afegir suport de protocol a un binari que no en té. Comenceu pel bàner de versió, que indica la biblioteca criptogràfica compilada:

openvpn --version

Una compilació 2.6 enllaçada amb OpenSSL accepta tant tls-cipher com tls-ciphersuites. Una compilació amb mbed TLS no té cap selecció de suites TLS 1.3, i el manual 2.6 marca tls-ciphersuites com una opció d'OpenSSL. Si el servidor es recompila amb un altre backend, el mateix perfil pot canviar de comportament sense que canviï ni una línia de configuració.

Mentre sou aquí, executeu openvpn --show-tls i guardeu la sortida. És l'inventari amb què comparareu més endavant, i és barat capturar-lo abans que ningú comenci a editar perfils.

Escriviu el bàner i la llista al tiquet de canvi, no en una finestra de xat. Quan dues persones discuteixin si un client podria oferir una suite d'aquí a sis setmanes, la sortida capturada ho resol en una línia.

Manteniu els límits de versió separats de les llistes de xifratges

Al manual 2.6 aquests són tres controls, no un:

• tls-cipher fixa la política de xifratges per a TLS 1.2 i anteriors, i es passa a la llista de xifratges d'OpenSSL;
• tls-ciphersuites selecciona suites TLS 1.3;
• tls-version-min i tls-version-max limiten les versions de protocol que la connexió pot utilitzar.

Així, una llista de suites TLS 1.3 cuidadosament retallada no demostra res sobre si una versió més antiga encara està permesa. Si el requisit és «només TLS 1.3», el llindar de versió és qui el sosté, i la llista de suites només estreny les opcions dins d'aquest llindar:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

Aquesta parella fa dues feines. Esborrar una de les línies deixa l'altra imposant menys del que penseu, i aquesta és precisament la fallada que tota aquesta comprovació existeix per atrapar.

El canal de dades és un quart control. data-ciphers negocia el xifratge simètric dins del túnel, i el seu resultat no diu res sobre la versió de TLS del canal de control. Veure AES-256-GCM al resum de la sessió no és evidència sobre TLS 1.3 en cap sentit.

Llegiu show-tls com un inventari local

--show-tls enumera les suites que admet la biblioteca criptogràfica amb què s'ha enllaçat aquest binari, per ordre de preferència. No és un informe de la passarel·la. El manual diu explícitament que la llista ve de la biblioteca local, cosa que significa que un portàtil amb OpenSSL 3.x i un encaminador amb una compilació més antiga imprimiran llistes diferents mentre parlen amb el mateix servidor.

Suposeu que un client admet les suites A, B i C i que una sessió tria B. Això no estableix res sobre si el servidor permet A o C, ni sobre si B és la seva única opció permesa. Manteniu les tres files separades i la majoria de fils de TLS confusos es resoldran sols.

L'inventari encara val la pena conservar-lo. Quan una sessió falla, comparar la llista de la biblioteca amb la del perfil us diu si el client tenia cap possibilitat d'oferir el que volia el servidor. També mostra si un canvi de backend ha retirat silenciosament TLS_CHACHA20_POLY1305_SHA256 del conjunt amb què compten els clients més antics — el tipus de regressió que es manifesta com un grapat d'usuaris que no es poden connectar mentre tothom no nota res.

Pregunteu a la passarel·la una cosa que pugui respondre

Si administreu el servei, inspeccioneu la configuració efectiva de la instància en execució en lloc d'un fitxer al disc. Pot ser que OpenVPN s'hagi iniciat amb un camí --config diferent, que incorpori inclusions i que no s'hagi reiniciat des de l'edició. La política del dimoni en execució és la que troben els clients.

Si no l'administreu, demaneu a l'operador els requisits de client suportats o una prova d'acceptació acotada. Un intent rebutjat no és automàticament una suite rebutjada: un llindar de versió, comprovacions d'identitat de certificat com remote-cert-tls, o un desajust entre tls-auth i tls-crypt poden acabar l'intercanvi abans que la selecció de suites importi. Llegiu l'error del servidor abans de canviar la llista del client, perquè «handshake failed» cobreix quatre causes diferents i només una és un desajust de xifratge.

Apuntar openssl s_client al port VPN tampoc reprodueix la pregunta. El canal de control funciona dins del propi encapsulat d'OpenVPN, així que una sonda TLS crua prova un protocol diferent en un port que espera una altra cosa. Qualsevol conclusió que se'n tregui és sobre la sonda, no sobre el túnel.

Registreu dos resultats i manteniu-los separats

Una sessió permesa nova produeix una línia del canal de control que indica la versió del protocol i el xifratge seleccionat, i una línia separada del canal de dades que indica el xifratge del túnel. Captureu totes dues amb la versió del client i el nom del perfil, i anoteu quina instància del servidor ha respost:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

Després llegiu les dues línies d'aquest fitxer, no de memòria. La parella és l'evidència; un nom de suite sol és una preferència, i el límit de versió és una afirmació separada sobre què refusa el servidor.

Feu les comprovacions en aquest ordre. Confirmeu la compilació i el backend amb --version. Captureu --show-tls abans de canviar res. Enuncieu el llindar de versió requerit per separat de la llista de suites. Confirmeu la política efectiva de la instància en execució amb el seu propietari. Observeu una sessió permesa i, si el pla ho permet, un intent refusat amb una versió més antiga. Registreu els resultats del canal de control i del canal de dades com a troballes separades.

Si un client requerit no pot assolir un nou mínim, preneu aquesta decisió de migració o excepció explícitament en lloc de rebaixar en silenci una regla d'acceptació no relacionada perquè el desplegament sembli acabat.