Unu malnova peer devigas TLS 1.0: limigu la escepton, ne la gastiganton

Unu malnova aparato aperas, malsukcesas konektiĝi, kaj la plej rapida ŝajna riparo estas malfortigi la tutan gastiganton ĝis la konekto sukcesos. Tiu interŝanĝo estas nevidebla en la momento kaj daŭra en la praktiko, ĉar neniu forigas minimumon, kiu finfine funkcias. Du tre malsamaj difektoj kreas la premon, kaj nur unu el ili entute temas pri ĉifroj. Unue ordigu la difekton, poste metu la escepton tie, kie ĝi ne povas disvastiĝi.

Dividu la malsukceson en du antaŭ ol redakti direktivon

Linio en la servila registro pri mankanta komuna ĉifro, aŭ pri nesubtenata protokola versio, venas de la rega kanalo: la du flankoj ne povis interkonsenti pri tio, kiel protekti la intertraktadon mem. Male, la klienta linio, ke neniu metodo por kontroli la servilan atestilon estas ŝaltita, venas de tute alia loko, ĉar tiu kliento tute ne kontrolas, kiu respondis. Ŝanĝi datuman ĉifron nenion faras en la dua kazo, kaj aldoni rolan kontrolon nenion faras en la unua.

Prenu la plej frue malsukcesintan linion de ĉiu flanko anstataŭ la lastan linion antaŭ la malkonekto, ĉar la lasta kutime estas sekvo. Poste konstatu, kiun dosieron la kliento efektive malfermis: importita profilo ofte ekzistas dufoje sub malsamaj montraj nomoj, kaj redakti la kopion, kiun neniu legas, produktas konvinkan neniun ŝanĝon. Kuranta procezo konservas la agordojn, kun kiuj ĝi komenciĝis, do konservita dosiero ne estas ŝargita dosiero. La subaj komandoj montras la intertraktadon de la kliento apud la vido de la servilo pri la sama provo.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Dua aŭskultanto estas la honesta loko por pli malforta minimumo

Kiam la aparato plu altas nur ĝis TLS 1.0 kun datuma kanalo antaŭ 2.5, la servilo devas proponi pli malaltan minimumon por la rega kanalo kaj datuman ĉifron, kiun la malnova kliento rekonas. La rezerva direktivo ekzistas ĝuste por tia peer, dum la ĉifra listo tenas modernajn klientojn sur modernaj aroj. Ambaŭ direktivoj apartenas al la aŭskultanto, ne al uzanto aŭ konekto, kaj neniu opcio por unuopa kliento mallarĝigas ilin poste. Tial unu malnova aparato sur la ĉefa pordo estas decido pri ĉiu peer, kiu ĝin dividas.

Kie la platformo permesas, funkciigu la malnovan aŭskultanton kiel propran instancon sur aparta pordo, permesu tiun pordon nur el la adreso de la aparato, kaj lasu la ĉefan servon trankvila. Notu, kial ekzistas la dua aŭskultanto, en la dosiero, kiu portas ĝian agordon, ĉar estonta purigado alie legus ĝin kiel restaĵon. La divido valoras nur se la pli malforta minimumo finiĝas tie, kie finiĝas la aparato.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Kion malnova provizanta atestilo efektive rompas

La kontroleraro estas mankanta rola ligo: sen ĝi la kliento akceptos ĉiun atestilon, kiu ĉeniĝas al fidinda CA, sendepende ĉu ĝi estis eldonita por servilo. Unue ligu la atestilon al la servila rolo, kaj traktu la ligon kiel postulon anstataŭ agordan butonon. Nur profilo, kiu ankoraŭ malsukcesas post tiu paŝo, havas veran atestilan problemon.

Malnova provizanta atestilo, kies ŝlosila grando aŭ subskriba algoritmo jam ne plenumas la defaŭltan politikon de OpenSSL, estas la kazo por limigita ŝanĝo de la sekurecnivelo sur la rega kanalo. Malaltigi la nivelon tie ne malŝaltas la kontrolon, kaj ĝi neniam rajtas esti kombinata kun malplena CA, malŝaltita kontrola agordo aŭ nekontrolita gastiganta nomo. Tenu la linion ene de la sola profilo, kiu bezonas ĝin; tutmonda eksporto de malstreĉita OpenSSL-agordo donus la saman malstreĉon al ĉiu programo sur la maŝino.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Legu la intertraktitajn valorojn, ne la rubandon

Ĉe detalnivelo 4 ambaŭ flankoj presas la TLS-version kaj ĉifron de la rega kanalo, pri kiuj ili interkonsentis, kaj la datuman ĉifron de la seanco. Legu tiujn liniojn anstataŭ la komencan rubandon, kiu raportas sukceson kaj ne ĝiajn kondiĉojn. Poste rekonektu modernan klienton al la ĉefa aŭskultanto kaj konfirmu, ke ĝi ankoraŭ surteriĝas sur moderna aro, ĉar escepto, kiu likis en la komunan agordon, montriĝas unue ĉi tie. La valoroj, kiujn vi kopias, fariĝas la bazlinio por la sekva revizio.

Testu la malnovan aparaton sola: ĝi devus konektiĝi, kaj ĝi devus esti la sola seanco en la registroj, kiu montras la pli malfortajn parametrojn. Se dua peer ankaŭ intertraktas la malnovan aron, la escepto estas pli vasta ol celite kaj la divido de la aŭskultanto ne vere okazis. Notu ambaŭ observojn anstataŭ nur la konkludon.

Ĉiu escepto bezonas posedanton kaj daton

Escepto sen foriga kondiĉo silente fariĝas la defaŭlto, do metu la aparaton, la posedanton, la kialon kaj la daton, kiam ĝi foriros, apud la agordon, kiun ĝi pravigas. Sen tiu linio la pli malforta minimumo postvivas la aparataron, kiu bezonis ĝin.

Anstataŭigi la klienton, aŭ peti de la provizanto aktualan profilon, estas la celenda rezulto; la escepto estas prokrasto kaj ne dezajno. Kiam la aparato emeritiĝos, forigu la aŭskultanton kaj la profilon en la sama ŝanĝo, por ke neniu duono restu funkcianta. Nenio el tio igas la malnovajn parametrojn sekuraj, ĝi nur malhelpas, ke la limo de unu aparato fariĝu la bazo por ĉiuj.