Bevezetés
Amikor egy felhasználó meglátogatja a HTTPS webhelyet, válaszolnia kell egy dolgozóval nyilvános kulcs, és egy érvényes SSL-tanúsítvány, amely a kulcsot személyként, vállalatként vagy szervezetként társítja személyazonosságához. A tanúsítványoknak mindig egy előre meghatározott lejárati dátumot adnak ki, amelyet magában az aláírt tanúsítvány tartalmaz, és a böngészők mindig ellenőrzik a lejárati dátumot, és elutasítanak minden lejárt tanúsítványt.
Bizonyos esetekben azonban a tanúsítványt érvénytelennek kell jelölni (és a tanúsítványokba vetett bizalomnak kell lennie visszavont) előtt lejár. Gyakori példák: egy kiszolgálótulajdonos bizonyítékokkal rendelkezik (vagy egyszerűen gyanítja), hogy a magánkulcsa sérült (azaz elveszett, ellopták vagy megsemmisült), mivel egy harmadik fél, aki ezt a magánkulcsot birtokolja, lényegében megkerülheti az összes böngésző hálózati biztonsági ellenőrzését.
Ennek következtében a böngésző gyártói szükségesek nyilvánosan megbízható tanúsító hatóságok (CA) legalább egy módszer megvalósítása a problémás tanúsítványok visszavonására és a böngészők értesítésére a visszavont tanúsítványok elutasítására.
A visszavonás ellenőrzésének (problémáinak) rövid története
Az SSL kezdeti napjaiban a CA-k által használt módszer az volt, hogy a tanúsítvány visszavonási állapotát nyilvánosan hozzáférhető dokumentumokba tették közzé tanúsítvány visszavonási listák (C.R.L.). A CRL egyszerűen azon tanúsítványok listája, amelyeket a CA bármikor visszavont a lejárat előtt. A CA-k rendszeresen közzétették a CRL-ek legújabb verzióját, amelyet a böngészőknek konzultálniuk kellett előtt minden HTTPS kapcsolat.
Természetesen, mivel a HTTPS (és az SSL /TLS) az évek során nőtt az elfogadás, így a közzétett CRL-ek nagysága is. Az a követelmény, hogy minden kapcsolat előtt le kell töltenie és elemeznie kell egy nagy CRL-t, egyre növekvő hálózati rezsit jelent. Gyorsan nyilvánvalóvá vált, hogy a CRL módszer nem méretezhető jól.
A méretezési problémák enyhítése érdekében a böngészők és a CA-k megtervezték és bevezették a Online tanúsítványállapot-protokoll (OCSP). Nyilvánosan megbízható CA-k, mint pl SSL.com, most karbantartja az úgynevezett egyszerű HTTP szervereket OCSP válaszadók. A böngészők most kapcsolatba léphetnek egy válaszadóval, hogy kérjék a CA által kiadott egyetlen tanúsítvány visszavonási státusát ahelyett, hogy meg kellene szerezni és feldolgozni a teljes CRL-t.
Az OCSP válaszadói a CA saját aláíró kulcsával írják alá válaszaikat, és a böngészők ellenőrizhetik, hogy a kapott visszavonási állapotot valóban a tényleges CA generálta-e.
Sajnos, bár az OCSP eleinte hatékony megoldásnak tűnt, az új protokollnak bizonyult bizonyos gyakorlati teljesítmény-, biztonsági és adatvédelmi kérdései.
Teljesítménybeli problémák
Ha minden tanúsítvánnyal, amellyel a böngésző találkozik, megkeresjük a válaszadót, az azt jelenti, hogy a böngészőknek további HTTP-kérést kell végrehajtaniuk minden új HTTPS-kapcsolat esetén. Ez a hálózati költség érzékelhető volt a felhasználók számára, különösen azokon az oldalakon, amelyek távoli tartalomelosztó szervereken tárolt, harmadik féltől származó tartalmat tartalmaztak (amelyek mindegyikén lehet egy vagy több tanúsítvány).
Fogékonyság a jó felhasználói felület tervezésének alapvető elve. A hosszú késések a felhasználók csalódásának egyik fő okát okozhatják, és arra késztethetik a felhasználókat, hogy azt higgyék, az Ön webhelye nem működik, vagy figyelmen kívül hagyták a beviteli gesztusukat.
Sőt, sokan tanulmányok a múltban összekapcsolta a gyors oldalbetöltési sebességet és az alkalmazkodóképességet a továbbfejlesztett SEO és a megnövekedett konverziós arányokkal. Valójában az Amazon kiszámította, hogy mindössze egy másodperces késleltetés számíthat számukra $1.6 milliárd évi.
(Az oldalbetöltési sebességnek az Ön webhelyére gyakorolt hatásáról és a javasolt optimalizálásról bővebben nézze meg a cikkben annak leírása, hogy a vegyes tartalom eltávolítása a webhelyről javítja annak teljesítményét.)
Biztonsági kérdések
Az OCSP-vel is fontos biztonsági aggályok merülnek fel. Az a tény, hogy a gyakorlati OCSP-megvalósítások többsége nem volt elég megbízható (hálózati lemaradás, konfigurációs vagy alkalmazáshibák miatt), motiválta a böngészőket és más kliens szoftvereket az OCSP-bejelentkezés megvalósításához soft-fail mód.
Ez azt jelenti, hogy ha egy OCSP-kiszolgálót nem lehet elérni, vagy ha időt ad le a válasz megadása közben, akkor a böngészők megteszik a tanúsítványt érvényesnek tekinti és mindenképp folytassa a HTTPS kapcsolatot.
Ennek oka az, hogy mivel egy OCSP-kiszolgáló potenciálisan több millió webhelyet képes kiszolgálni, és lehetséges, hogy az OCSP-kiszolgáló bármelyik pillanatban meghibásodjon, a kapcsolat minden OCSP-meghibásodás esetén történő elhagyása megzavarná a felhasználók millióinak böngészési élményét. Még akkor is, ha az OCSP-kiszolgáló működik, de sokáig tart a válaszadás, ez növeli az észlelt lemaradást és a felhasználói frusztrációt.
Közép-ember (MITM) a támadókról ismert, hogy blokkolással használják ki ezt a viselkedést minden kapcsolatok az OCSP válaszadóival, ami gyakorlatilag azt jelenti, hogy ellopott tanúsítványt és kulcspárt használhatnak egy rosszindulatú webhelyhez, függetlenül a tanúsítvány visszavonási állapotától.
Adatvédelmi problémák
Végül, mivel a tanúsítvány egy kulccsal és egy tartománynévvel van összekapcsolva, és a böngészők minden új HTTPS-kapcsolat előtt kérik a visszavonási állapotot, ez azt jelenti, hogy a böngészők a felhasználók webelőzményeinek jelentős részét kiszivárogtatják az OCSP-válaszadóknak.
Természetesen a nyilvánosan megbízható hitelesítésszolgáltatók nem rosszindulatú szervezetek, amelyek a felhasználók adatvédelmét veszélyeztetik. (A jó hírű CA-k mindig aktívan próbálkoznak védelme felhasználóik biztonsága és adatvédelme.) Azonban a CA OCSP válaszadójának veszélyeztetése esetén az adott nem megbízható szerverrel kicserélt adatok érzékeny és privát információk nyilvánosságra hozatalához vezethetnek.
OCSP Tűzés a mentéshez
E problémák enyhítése érdekében a böngészők és a CA-k egy új módszert állítottak elő a tanúsítvány állapotának meghatározására, az úgynevezett OCSP tűzés. Az OCSP tűzés lehetővé teszi, hogy a webszerverek (a böngészők helyett) aláírt OCSP válaszokat szerezzenek tanúsítványaikhoz, amelyek akár 7 napig is tárolhatók.
A szerverek tartalmazzák (vagy legfontosabb) a gyorsítótárazott OCSP válasz a HTTPS válaszaikban, maga az SSL tanúsítvány mellett. Így a böngészők ellenőrizhetik a hitelesítésszolgáltatók aláírását az OCSP-válaszon, és megbizonyosodhatnak arról, hogy a tanúsítványt nem vonták vissza, még mielőtt a biztonságos kapcsolat létrejött volna, és anélkül, hogy maguknak kellene végrehajtaniuk az OCSP-kiszolgálónak a drága kiegészítő kérést.
Az OCSP tűzés egyszerű, de nagyon hatékony megoldás a fent említett problémákra. A kiszolgálók a saját idejükben lekérhetik a gyorsítótárazott OCSP-válaszokat, ami megszünteti a CRL-ek és az OCSP által előírt teljesítmény-általános költségeket, valamint a hozzá tartozó adatvédelmi aggályokat.
Az OCSP tűzése azonban önmagában nem oldja meg teljesen az OCSP soft-fail biztonsági problémáját. Mivel a tűzés megvalósításra kerül a szerveren, a böngészők nem tudhatják, hogy egy szerver valóban támogatja-e a tűzést vagy sem.
Ennek eredményeként az ellopott (de visszavont) tanúsítvánnyal rendelkező MITM támadók lefokozási támadást hajthatnak végre, a tanúsítvány OCSP tűzés nélküli kiszolgálásával. Az áldozatok böngészője nem tudja megerősíteni, hogy a szerver valóban támogatja-e a tűzést, és folytathatja az OCSP válaszadójának lekérdezését, mint általában.
A MITM támadók ezt követően egyszerűen blokkolhatják ezt az OCSP lekérdezést, és hatékonyan arra kényszeríthetik a böngészőket, hogy fogadják el érvényesnek a tanúsítványt.
OCSP kötelező tűzés
Ez a támadás arra ösztönözte a CA-kat és a böngészőgyártókat, hogy vezessenek be egy kiterjesztést az SSL tanúsítványokhoz, definiálva a következőben: RFC 7633, amelyet általában hívnak OCSP Must-tűzés (bár maga az RFC nem említi ezt a nevet, ami némi zavart okozhat.) Ez egyszerűen előírja az OCSP tűzését a tanúsítványhoz. Ha egy böngésző egy tanúsítvánnyal találkozik ezzel a kiterjesztéssel, amelyet OCSP tűzés nélkül használnak, akkor azt elutasítják. Az OCSP must-Staple enyhíti a fent említett downgrade támadást, és csökkenti a CA OCSP válaszadóinak felesleges forgalmát is, ami szintén hozzájárulhat az OCSP általános teljesítményének javításához.
Ha érdekli az OCSP Must-Staple kiterjesztés engedélyezése tanúsítványaiban, lépjen kapcsolatba egyik támogatási ügynökünkkel a következő címen: support@ssl.com fül alatt találsz.
Engedélyezze az OCSP tűzést a szerveren
Annak érdekében, hogy megkímélje ezt a problémát, a következő szakaszok tartalmazzák az OCSP tűzés engedélyezésével kapcsolatos utasításokat Apache és a nginx környezetek:
Apache
Az OCSP tűzés engedélyezéséhez a Apache szerver, kérjük, adja hozzá a következő sorokat a szerver konfigurációs fájljához.
# OCSP tűzés, csak a httpd 2.3.3 és újabb verziókban
nginx
Az OCSP tűzés engedélyezéséhez a nginx szerver, kérjük, adja hozzá a következő szöveget a szerver konfigurációs fájljához.
# OCSP tűzés --- # töltse le az OCSP rekordokat az URL-ről az ssl_certificate fájlban, és tárolja azokat ssl_stapling segítségével; ssl_stapling_verify on;
Következtetés
A web egy bonyolult hálózat, amely egymástól függő összetevőket alkot, amelyek (általában) összhangban működnek, hogy zökkenőmentes böngészési élményt nyújtsanak. Ennek a rendszernek az egyre növekvő összetettsége azonban egyre szélesebb támadási felületet hoz létre, és lehetővé teszi új hálózati támadások kidolgozását és végrehajtását.
Az összetevők puszta száma természetesen növeli a késleltetést és késéseket okoz, ami azt jelenti, hogy a vállalkozásoknak meg kell találniuk a biztonság javításának módjait anélkül, hogy befolyásolnák a felhasználói élményt. Az OCSP tűzés engedélyezése azt a ritka lehetőséget kínálja a biztonság javítására és a egyidejűleg a webhely teljesítményét.
Mint mindig, örömmel válaszolunk az OCSP tűzéssel vagy más kérdésekkel kapcsolatos kérdéseire - egyszerűen küldjön nekünk e-mailt support@ssl.com.
