Defaults.Exposed › Javítások › Modern titkosítás (TLS verzió és titkosítók)

Hogyan javítsd ki: Modern titkosítás (TLS verzió és titkosítók)

A TLS az a zár, amely titkosítja a látogatók és a webhelyed között áramló adatokat. Két dolog teszi ezt a zárat megbízhatóvá: a TLS modern verziójának használata (nem a régi, törött verzióké), és erős titkosítók használata (a tényleges titkosítási recept). Ez az oldal mindkettőt lefedi – plusz néhány kapcsolódó beállítást, amelyek nem befolyásolják a besorolásodat, de érdemes tudni róluk.

Az üzleted szempontjából lényeg: Ha az oldal elavult titkosítással vagy gyenge titkosítókkal fut, az ügyfelek által beírt privát részletek – bejelentkezések, kártyaszámok, kapcsolatfelvételi adatok – csendesen el lehet fogni és elolvasni megosztott hálózatokon, és megbukhat azon biztonsági ellenőrzésen, amelyet a bankok, fizetési feldolgozók és nagyobb ügyfelek most már megkövetelnek az üzletkötés előtt.

Mibe kerülhet ez neked

Egy ügyfél fizet vagy belép szállodai vagy kávézói Wi-Fi-ről; egy elavult kapcsolat vagy gyenge titkosító lehetővé teszi, hogy egy idegen ugyanazon a hálózaton olvassa a kártyaját és jelszavát, és a csalás – és a dühös telefonhívás – egyenesen az oldaladig vezet.
Kártyafizetéseket akarsz vállalni (vagy a fizetési szolgáltatód újra auditál), és elutasítanak, mert az elavult TLS vagy egy tiltott titkosító megtöri a fizetési biztonsági szabályokat – az online pénztárad befagy, amíg ki nem javítod.
Egy nagyobb ügyfél IT-csapata rutin vizsgálatot végez az aláírás előtt, látja, hogy az oldal még mindig engedélyezi a törött titkosítást, és kockázatként jelöl meg – a szerződés megáll egy probléma miatt, amelynek javítása semmibe sem kerül.
Egy adatvédelmi panasz vagy feltörés kerül az asztalodra, és a szabályozók első kérdése az, hogy 'megfelelően' védetted-e az ügyféladatokat – az évek óta nyilvánosan ismert-törött titkosítás futtatása nagyon nehéz válasz.
Az oldal lakatot mutat, tehát mindenki feltételezi, hogy teljesen biztonságos, és ez a rés évekig észrevétlen marad – amíg egy elfogott bejelentkezés vagy kártyaszám olyan incidenssé nem válik, amely sokkal drágább, mint az ingyenes javítás lett volna.

Miért fontos. A biztonságos titkosítás láthatatlan; az elavult vagy gyenge titkosítás egy felelősség, amely csendben ül, amíg az ügyfeledbe, egy szerződésbe vagy egy megfelelési átmenőbe nem kerül. A TLS-verzió és a titkosítói ellenőrzések azok a két rész, amelyek ténylegesen mozdítják a besorolásodat, és mindkettő általában egyetlen ingyenes beállítás – a régi, törött opciók bekapcsolva hagyásának nincs előnye.

Egyszerű szavakkal

Amikor valaki meglátogatja a weboldaladat, minden, amit begépelnek – bejelentkezések, kártyaszámok, nevek, telefonszámok, üzenetek – titkosítva van átvitel közben, hogy idegenek ne olvashassák el. A titkosítást végző technológiát TLS-nek hívják (régebbi nevén SSL-ként is ismerheted). Ahhoz, hogy ez a titkosítás valóban biztonságos legyen, két dolognak helyesnek kell lennie:

A TLS verzió – a technológia melyik generációját használod. A korai verziók (TLS 1.0 és 1.1) nyilvánosan töröttek évek óta; a biztonságosak a TLS 1.2 és TLS 1.3.
A titkosító – az a speciális recept, amelyet a TLS a titkosításhoz használ. Egyes titkosítók (mint az RC4, DES és 3DES) fel lettek törve, és most tiltottak; a modern titkosítók még erősek.

Ez az oldal mindkettőt lefedi, mert egy oldal megkaphatja az egyiket helyesen és a másikat rosszul. Lehet modern zár egy régi, feltörhető recepttel még bekapcsolva – vagy erős recept egy elavult zárral. Bármelyik rés nyitott ajtó. Mindkettőt általában ugyanaz az egyetlen ingyenes módosítás zárja be a szerver vagy a tárhely beállításaiban.

Mibe kerülhet ez neked

Egy ügyfelet kirabolnak a nyilvános Wi-Fi-n. Valaki bejelentkezik a fiókjába vagy fizet egy szállodából, kávézóból vagy reptérről. Mivel az oldal még mindig elfogad egy régi TLS-verziót vagy egy gyenge titkosítót, egy idegen ugyanazon a hálózaton letörhető opcióra kényszeríti a kapcsolatot, és valós időben olvassa a jelszavát és kártyaszámát. A csalás az ügyfélre hull, de a felelősség – és az ügyfélszolgálati hívás – rád hárul.
A kártyás fizetésed kikapcsolódik. A fizetési biztonsági szabályok (PCI DSS) a TLS 1.2-t minimumként írják elő, és kifejezetten tiltják a gyenge titkosítókat, mint az RC4. Amikor a feldolgozód újra auditál, vagy amikor kártyás fizetésért jelentkezel, egy elavult konfiguráció megbukik az ellenőrzésen, és a pénztárad befagy, amíg ki nem javítod – pontosan a legrosszabb pillanatban a pénzforgalom szempontjából.
Egy üzlet biztonsági felülvizsgálatban megáll. Mielőtt egy nagyobb ügyfél aláírna, az IT-csapatuk rutin vizsgálatot futtat. Azonnal jelöli, hogy az oldalad még mindig elfogad törött titkosítást – az a fajta megállapítás, amely gondatlannak tűnik, és arra készteti a vevőt, hogy mit kérdezzen még. A szerződés megvárja a problémát, amelynek javítása semmibe sem kerül.
Egy szabályozó felteszi a kínos kérdést. Bármely panasz vagy feltörés után az adatvédelmi hatóság első kérdése az, hogy ‘megfelelően’ védetted-e a személyes adatokat. Az évek óta nyilvánosan ismert-törött titkosítás futtatása nagyon nehéz védekezni, és ‘nem vettük észre, hogy a régi verzió még be volt kapcsolva’ kényelmetlen válasz.
Évekig a lakat mögé bújik. Mivel az oldal még mindig normál lakatot mutat, senki nem veszi észre a rést – amíg egyetlen elfogott bejelentkezés vagy kártyaszám nyilvános incidenssé nem válik, sokkal drágábban, mint az öt perces javítás lett volna.

Mi is ez pontosan

A TLS verzió

Egy oldal nem csak egy TLS-verziót támogat – egyszerre több verziót is kínálhat, és minden látogató böngészője a legújabb elérhető verziót fogja választani. A veszély az, hogy a régi, törött verziók ott ülhetnek a jókkal együtt mint egy nyitott hátsó ajtó: egy támadó rákényszerítheti a látogató kapcsolatát, hogy „visszaminősüljön” a TLS 1.0-ra vagy 1.1-re, majd kihasználhatja az ismert gyengeségeket (a BEAST és POODLE támadások a híresek), hogy visszafejtse a forgalmat.

Ezért az ellenőrzésünk csatlakozik az oldaladhoz, és egyenként teszteli az egyes verziókat – TLS 1.0, 1.1, 1.2 és 1.3 –, hogy meglássa, melyeket fogad el még a szervered. Íme, mi minősül „jónak”, és hogyan pontozódik:

TLS 1.3 (1.2-vel vagy anélkül), és nincs régi verzió: a legjobb eredmény – modern, tiszta konfiguráció. Teljes pontszám.
Csak TLS 1.2, nincs 1.3: biztonságos és megfelel, de hagyod ki a legújabb, leggyorsabb verziót. A legtöbb pont; az 1.3 engedélyezése megéri.
Még mindig elfogad TLS 1.0-t vagy 1.1-et: automatikus meghibásodás, nulla pontszám és kritikusnak jelölve – nem számít, hogy a 1.2/1.3 is működik, mert a törött verziók a nyitott ajtók. Ezt kell javítani.

A titkosító

A verzió kiválasztása után a TLS kiválaszt egy titkosítót – azt a tényleges algoritmust, amely titkosítja az adatokat. A modern titkosítók többsége erős. Néhány törött, és soha nem szabad használni: RC4 (a titkosítása torzított és szivárog a sima szöveg), DES (a kulcsa annyira rövid, hogy brute force-olható), 3DES (sérülékeny a „Sweet32” támadásra), plusz NULL (egyáltalán nincs titkosítás), EXPORT-grade titkosítók (szándékosan gyengítve – a FREAK és Logjam támadások), és névtelen titkosítók (nincs személyazonosság-ellenőrzés, tehát egy támadó a közepén ülhet).

A titkosítói ellenőrzésünk két dolgot tesz. Először megvizsgálja azt a titkosítót, amelyet a szervered velünk tárgyalt le. Aztán – és ez a fontos rész – aktívan megpróbál kézfogást számos ismert-törött titkosítóval (RC4, 3DES, EXPORT, NULL és névtelen variánsok). Egy szerver választhat erős titkosítót, amikor egy modern ügyféllel kommunikál, mégis elfogad egy gyengét, ha egy támadó ragaszkodik hozzá – és ez valós visszaminősítési kockázat.

A három tájékoztató extra

Három kapcsolódó tétel van bejelentve, de nem befolyásolják a besorolásodat – tájékoztatóként vannak megjelölve, mert nem lehet megbízhatóan ellenőrizni őket kívülről, és bármely modern szerveren vagy CDN-en már helyesen vannak kezelve:

TLS tömörítés (CRIME támadás): egy régi funkció, amely, ha be van hagyva, lehetővé teheti egy támadónak a munkamenet-sütik kinyerését. Évek óta alapból letiltott minden modern webszerveren.
OCSP stapling: teljesítmény- és adatvédelmi kényelem, ahol a szervered előre lekéri a bizonyítékot, hogy a tanúsítványa nincs visszavonva, így minden látogatónak nem kell magának kérdezni a tanúsítványkibocsátót. A Cloudflare-hez hasonló CDN-ek ezt automatikusan végzik.
Biztonságos újratárgyalás: egy régi hiba (CVE-2009-3555) javítása, amely lehetővé tette a támadóknak adatok befecskendezését a munkamenetbe. A TLS 1.3 teljesen eltávolította az újratárgyalást, és a modern TLS 1.2 szerverek alapból implementálják a javítást.

Hogyan javítsd ki (ingyenes, ~30 perc)

Add ezt az IT-személyednek – a javítás ingyenes. Ez a rész annak szól, aki a domained, weboldaladat vagy tárhelyedet kezeli. A javítás konfigurációs módosítás, nem vásárlás; mi csak azért számítunk fel díjat, hogy figyeljük, hogy a titkosítás idővel helyesen van-e konfigurálva. Az alábbi egyetlen modern konfiguráció egyszerre javítja a verziót és a titkosítói megállapításokat.

A legegyszerűbb megbízható megközelítés egy ismert-jó konfiguráció generálása, nem kézzel írása: illeszd be a szerver típusát a Mozilla SSL Configuration Generátorba a https://ssl-config.mozilla.org/ oldalon, és válaszd az „Intermediate” profilt (széles kompatibilitás) vagy a „Modern”-t (csak TLS 1.3, ha nem kell semmit régi verziót támogatni). Kiadja a helyes ssl_protocols és ssl_ciphers sorokat neked.

Platform szerint:

Cloudflare vagy kezelt host – általában egy-két kattintás. Cloudflare-ben: SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2, és a titkosítási csomagok ott kezelt neked. A legtöbb kezelt host és site-builder (Squarespace, Wix, Shopify, modern WordPress hostok) már alapból TLS 1.2+-t kényszerít erős titkosítókkal.

Nginx. Állítsd be a csak modern verziókat és egy explicit erős titkosítólistát, majd töltsd újra:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

Apache. Tiltsd le a régi verziókat és rögzítsd az erős titkosítólistát, majd indítsd újra:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder on

Windows / IIS. Használd az ingyenes IIS Crypto eszközt, hogy letilts TLS 1.0-t és 1.1-et, letiltsd az RC4/DES/3DES/NULL/EXPORT titkosítókat, és hagyd engedélyezve a TLS 1.2-t és 1.3-t erős titkosítókkal. Az eszköz „Best Practices” sablonja mindezt egy kattintással elvégzi.
A tájékoztató extrák (opcionális, ingyenes). Ha teljes söprést akarsz: Nginx-ben add hozzá az ssl_stapling on; ssl_stapling_verify on; sorokat az OCSP stapling-hez; Apache-ban SSLUseStapling On. A TLS tömörítés és a biztonságos újratárgyalás alapból biztonságos a modern szervereknél. Cloudflare-en mindhárom automatikusan kezelt.
Ellenőrizd, majd vizsgáld meg újra itt. Erősítsd meg, hogy csak a biztonságos verziók és titkosítók maradnak – például az nmap --script ssl-enum-ciphers -p 443 yourdomain.com paranccsal –, majd futtasd újra ezt az ellenőrzést.

Általános hibák

„Lakatunk van, tehát rendben vagyunk.” A lakat csak bizonyítja, hogy biztonságos kapcsolat létezik. Semmit sem mond arról, hogy egy régi verzió vagy egy tiltott titkosító még mindig elfogadott-e a háttérben – ami pontosan az a rés, amelyet ezek az ellenőrzések megtalálnak.
A verzió javítása, de nem a titkosítók (vagy fordítva). A TLS 1.0/1.1 letiltása nem automatikusan eltávolítja az RC4-et vagy 3DES-t, és az erős titkosítók rögzítése nem automatikusan letiltja a régi verziókat. Mindkettőt állítsd be – a generált konfiguráció fentebb mindkettőt elvégzi.
‘Régi’ vagy ‘régi böngészőkompatibilitás’ kapcsolók bekapcsolva hagyása. Sok host és CDN-nek van egy opciója, amely csendesen újra engedélyezi a törött verziókat vagy gyenge titkosítókat ‘kompatibilitás érdekében’. Ez szinte soha nem segít valódi látogatónak, és közvetlenül okozza ezt a megállapítást.
A szerver újratöltésének/újraindításának elfelejtése. A konfigurációs módosítások addig nem lépnek hatályba, amíg a webszerver újra nem töltődik – meglepően gyakori ok arra, hogy egy ‘javított’ oldal még mindig megbukik az újraellenőrzésen.
Egy szerver konfigurálása, de nem az összes. Ha terheléselosztót, több webszervert vagy különálló aldomaineket (shop, blog, app) futtatsz, minden TLS végpontnak ugyanolyan konfigurációra van szüksége – a leggyengébb az, amit egy támadó célba vesz.

Mit kell megjegyezni

A TLS verzió és a titkosító a titkosításod két olyan része, amelyek ténylegesen mozdítják a besorolásodat, és mindkettő abból áll, hogy kikapcsolsz olyan opciókat, amelyek évek óta nyilvánosan töröttek. A javítás ingyenes, általában egyetlen modern konfigurációs sor szerverenként, és egy normál látogató számára semmi sem változik, kivéve, hogy a kapcsolatuk valóban biztonságos. A kapcsolódó elemek – tömörítés, OCSP stapling, biztonságos újratárgyalás – érdemes tudni róluk, de nem befolyásolják a pontszámodat, és bármely modern beállításban már kezelt neked.

GYIK

Nem vagyok technikai beállítottságú – meg tudom magam oldani ezt?

Nem kell értened a technikai részletekhöz. A legtöbb modern tárhelyen ez egy-két beállítás, és ingyenes. Add át az alábbi 'Hogyan javítsd ki' részt annak, aki a weboldaladat vagy tárhelyedet kezeli (vagy az IT-szolgáltatódnak) – általában öt-tíz perces módosítás, a látogatók számára semmilyen látható különbséggel a biztonságosabb kapcsolaton kívül.

Megszakítja-e a modern titkosításra való váltás a régi ügyfelek böngészőit?

A gyakorlatban nem. Az elmúlt évtizedből minden modern böngésző és telefon már alapból az új titkosítást és az erős titkosítókat használja – évek óta. Egyetlen dolog, amelyek a régi verziókon vagy gyenge titkosítókon alapultak, azok maguk is elavultak és biztonságtalanok, ami pontosan az oka, hogy minden nagy böngésző már elutasítja azokat. Szinte minden vállalkozásnál a módosítás láthatatlan az ügyfelek számára.

Az oldalam rendesen tölt egy lakattal – miért jelöl még ez?

A lakat csak azt jelenti, hogy egy biztonságos kapcsolat létezik; nem mondja el, melyik TLS-verziót vagy melyik titkosítót használja mögötte. Az oldal tökéletesen normál lakatot mutathat, miközben csendesen még mindig elfogad egy régi törött verziót vagy egy tiltott titkosítót a jókkal együtt – és az a nyitott hátsó ajtó az, amelyet ezek az ellenőrzések megtalálnak. A bezárása nem veszi el a lakatot; csupán biztosítja, hogy csak a biztonságos opciók legyenek engedélyezve.

Mi a különbség a TLS verzió és a titkosító között?

Gondolj a TLS-verzióra, mint arra, hogy a zár melyik generációját használod, a titkosítóra pedig, mint arra, hogy az adatok titkosítására melyik speciális receptet használja. Lehet modern zárod (TLS 1.2 vagy 1.3), de még mindig be lehet kapcsolva egy régi, feltörhető recept (mint az RC4 vagy 3DES) – vagy fordítva. Mindkettőnek helyesnek kell lennie, ezért ellenőrizzük őket külön-külön. A jó hír az, hogy ugyanaz az egyetlen soros modern konfiguráció általában egyszerre javítja mindkettőt.

Mi az OCSP stapling és a TLS tömörítés – befolyásolják a besorolásomat?

Nem. Azok (a biztonságos újratárgyalással együtt) csak tájékoztató jellegűek – azért jelentjük be őket, mert fontosak a teljesítmény és a mélységi védekezés szempontjából, de nem mozgatják a pontszámodat. A modern webszervereknél és bármely CDN-nél, mint a Cloudflare, alapból helyesen vannak kezelve, tehát a legtöbb üzemeltetőnek nincs semmit tennie. A részletek az alábbi részben vannak az IT-személyed számára.

A javítás tényleg ingyenes?

Igen. A régi TLS-verziók és a gyenge titkosítók letiltása, és ezen védelmi elemek engedélyezése, konfigurációs módosítások a meglévő szerveredben vagy tárhelyedben – nincs mit venni. Mi csak azért számítunk fel díjat, hogy figyeljük, hogy a titkosítás idővel helyesen van-e konfigurálva, a javításért soha nem.