Egy régi peer TLS 1.0-t kényszerít ki: az kivételt korlátozza, ne a gazdagépet

Megjelenik egy régi eszköz, nem tud csatlakozni, és a leggyorsabbnak látszó javítás az, hogy az egész gazdagépet gyengítjük, amíg a kapcsolat létre nem jön. Ez a csere a pillanatban láthatatlan és a gyakorlatban állandó, mert senki nem távolít el egy alsó határt, amely végre működik. Két nagyon különböző hiba okozza a nyomást, és csak az egyikük szól egyáltalán a titkosításokról. Először rendezze a hibát, aztán tegye a kivételt oda, ahonnan nem tud továbbterjedni.

Ossza ketté a hibát, mielőtt egy irányelvet szerkeszt

A kiszolgálónapló azon sora, hogy nincs közös titkosítás, vagy hogy nem támogatott a protokollverzió, a vezérlőcsatornáról származik: a két fél nem tudott megegyezni abban, hogyan védjék magát az egyeztetést. Ezzel szemben az ügyfél azon sora, hogy nincs engedélyezve semmilyen kiszolgálótanúsítvány-ellenőrzési módszer, egészen máshonnan jön, mert az az ügyfél egyáltalán nem ellenőrzi, ki válaszolt. Az adattitkosítás cseréje semmit nem tesz a második esetben, a szerepkör-ellenőrzés hozzáadása pedig semmit az elsőben.

Minden oldalról a legkorábbi hibás sort vegye, ne a bontás előtti utolsó sort, mert az utolsó általában következmény. Ezután állapítsa meg, melyik fájlt nyitotta meg valójában az ügyfél: az importált profil gyakran kétszer létezik különböző megjelenített nevek alatt, és annak a példánynak a szerkesztése, amelyet senki nem olvas, meggyőző változatlanságot eredményez. A futó folyamat megtartja azokat a beállításokat, amelyekkel indult, tehát a mentett fájl nem betöltött fájl. Az alábbi parancsok az ügyfél egyeztetését mutatják a kiszolgáló ugyanarra a kísérletre vonatkozó nézete mellett.

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

A második listener az őszinte hely egy gyengébb alsó határ számára

Amikor az eszköz a 2.5 előtti adatcsatornával a TLS 1.0-nál megáll, a kiszolgálónak alacsonyabb vezérlőcsatorna-alsó határt és a régi ügyfél által ismert adattitkosítást kell kínálnia. A tartalék irányelv pontosan arra a peerre létezik, míg a titkosításlista a modern ügyfeleket modern csomagokon tartja. Mindkét irányelv a listenerhez tartozik, nem egy felhasználóhoz vagy kapcsolathoz, és semmilyen ügyfelenkénti opció nem szűkíti őket utólag. Ezért egyetlen régi eszköz a fő porton döntés minden peerrel kapcsolatban, amely megosztja azt.

Ahol a platform engedi, futtassa a régi listenert saját példányként külön porton, engedélyezze azt a portot csak az eszköz címéről, és hagyja békén a fő szolgáltatást. Írja le, miért létezik a második listener, abban a fájlban, amely a konfigurációját hordozza, mert egy későbbi takarítás különben maradékként olvassa. A szétválasztás csak akkor éri meg, ha a gyengébb alsó határ ott végződik, ahol az eszköz végződik.

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

Mit tör el valójában egy régi szolgáltatói tanúsítvány

Az ellenőrzési hiba egy hiányzó szerepkör-kötés: nélküle az ügyfél elfogad minden olyan tanúsítványt, amely egy megbízható CA-hoz láncolódik, függetlenül attól, hogy kiszolgáló számára adták-e ki. Először kösse a tanúsítványt a kiszolgálói szerepkörhöz, és a kötést követelményként kezelje, ne hangoló gombként. Csak annak a profilnak van valódi tanúsítványproblémája, amely e lépés után is elbukik.

Egy régi szolgáltatói tanúsítvány, amelynek kulcsmérete vagy aláírási algoritmusa már nem felel meg az OpenSSL alapértelmezett szabályzatának, a vezérlőcsatornán történő korlátozott biztonsági szintű változtatás esete. A szint ottani csökkentése nem kapcsolja ki az ellenőrzést, és soha nem szabad üres CA-val, letiltott ellenőrzési beállítással vagy ellenőrizetlen gazdagépnévvel kombinálni. Tartsa a sort abban az egyetlen profilban, amelynek szüksége van rá; egy lazított OpenSSL-konfiguráció globális exportálása ugyanazt a lazítást adná a gépen minden programnak.

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

A megtárgyalt értékeket olvassa, ne a szalagcímet

4-es részletességi szinten mindkét fél kinyomtatja a vezérlőcsatorna TLS-verzióját és titkosítását, amelyben megállapodtak, valamint a munkamenet adattitkosítását. Azokat a sorokat olvassa, ne az inicializálási szalagcímet, amely sikerről számol be, nem annak feltételeiről. Ezután csatlakoztasson újra egy modern ügyfelet a fő listenerhez, és erősítse meg, hogy továbbra is modern csomagra landol, mert a megosztott konfigurációba szivárgott kivétel itt látszik először. A kimásolt értékek lesznek a következő felülvizsgálat alapvonala.

Tesztelje a régi eszközt egyedül: csatlakoznia kell, és csak ez lehet az a munkamenet a naplókban, amely a gyengébb paramétereket mutatja. Ha egy második peer is a régi csomagot egyezteti, a kivétel szélesebb a szándékoltnál, és a listener szétválasztása nem történt meg igazán. Mindkét megfigyelést rögzítse, ne csak a következtetést.

Minden kivételnek kell egy tulajdonos és egy dátum

Az eltávolítási feltétel nélküli kivétel csendben alapértelmezetté válik, ezért tegye az eszközt, a tulajdonost, az okot és az eltűnés dátumát ahhoz a konfigurációhoz, amelyet igazol. E sor nélkül a gyengébb alsó határ túléli a hardvert, amelynek szüksége volt rá.

Az ügyfél cseréje, vagy a szolgáltatótól aktuális profil kérése a célra vezető eredmény; a kivétel halasztás, nem tervezés. Amikor az eszköz nyugdíjba megy, ugyanabban a változtatásban távolítsa el a listenert és a profilt, hogy egyik fél se maradjon futva. Mindez nem teszi biztonságossá a régi paramétereket, csak megakadályozza, hogy egy eszköz korlátja mindenki alapvonala legyen.