A https biztonságos kapcsolatot biztosít minden webfejlesztő számára
Hogyan működik a HTTPS? Ez egy olyan kérdés, amellyel több napig küzdöttem dolgozó munkámban.
Webfejlesztőként rájöttem, hogy a HTTPS használatával a felhasználói adatok védelme nagyon, nagyon jó ötlet, de sosem volt kristályszerű megértésem arról, hogy a HTTPS hogyan működik.
Hogyan védettek az adatok? Hogyan tud egy ügyfél és egy szerver biztonságos kapcsolatot létesíteni, ha valaki már hallgatja csatornáját? Mi a biztonsági tanúsítvány, és miért fizetnem kell valakit, hogy megkapja?
csővezeték
Mielőtt belevetnénk ennek működésébe, röviden mondjuk el, miért olyan fontos az internetkapcsolat védelme és a HTTPS védelme.
Ha egy böngésző kérést tesz kedvenc webhelyére, akkor ezt a kérelmet több különböző hálózaton keresztül kell végrehajtani, amelyek bármelyikét potenciálisan felhasználhatják a megkötött kapcsolatok meghallgatásához vagy azok zavarásához.
A saját számítógépről a helyi hálózaton lévő más számítógépekre, routereken és kapcsolókon, az internetszolgáltatóján és sok más köztes szolgáltatón keresztül - hatalmas számú szervezet továbbítja az adatokat. Ha egy támadó legalább egyikben találja magát - képes megnézni, hogy milyen adatokat továbbítanak.
Általános szabályként a kéréseket a normál HTTP-n keresztül továbbítják, amelyben mind az ügyfél kérése, mind a kiszolgáló válasz tiszta formában kerül továbbításra. És sok súlyos érv szól, hogy a HTTP nem használja az alapértelmezett titkosítást:
• Ehhez több számítási teljesítmény szükséges
• Több adatot továbbítanak
• Nem használható a gyorsítótár
Bizonyos esetekben azonban, amikor a kommunikációs csatornán keresztül rendkívül fontos információkat (például jelszavakat vagy hitelkártya-adatokat) továbbítanak, további intézkedéseket kell hozni az ilyen kapcsolatok meghallgatásának megakadályozására.
Transport Layer Security (TLS)
Most a titkosítás világába fogunk merülni, de ehhez semmilyen különleges élményre nincs szükségünk - csak a leggyakoribb kérdéseket vesszük figyelembe. Így a titkosítás lehetővé teszi, hogy megvédje a kapcsolatot potenciális támadókkal, akik szeretnének dolgozni a kapcsolaton, vagy csak hallgatni.
Az SSL utódja, a TLS, a legelterjedtebb protokoll, amely biztonságos HTTP-kapcsolatot biztosít (HTTPS néven). A TLS a HTTP protokoll alatti szinten található az OSI modellben. Az ujjakon elmagyarázva ez azt jelenti, hogy a kérés végrehajtása során először a TLS-kapcsolathoz társított összes "dolgot", majd minden, ami a HTTP-kapcsolathoz kapcsolódik.
A TLS egy hibrid kriptográfiai rendszer. Ez azt jelenti, hogy több titkosítási megközelítést alkalmaz, amelyeket tovább fogunk fontolni:
1) Az aszimmetrikus titkosítás (nyilvános kulcsú kriptográfiai rendszer) megosztott titkos kulcs és hitelesítés létrehozásához (azaz azon személyazonossághoz, amellyel te vagy az, akinek kiadod).
2) Szimmetrikus titkosítás. Titkos kulcs használatával kéréseket és válaszokat titkosít.
Public Key Cryptosystem
A nyilvános kulcsú kriptográfiai rendszer egyfajta kriptográfiai rendszer, ahol mindkét oldalon nyitott és magánkulcs van, matematikailag egymáshoz viszonyítva. A nyilvános kulcs titkosítja az üzenet szövegét "gibberish" -ban, miközben a privát kulcsot használják a forráskód dekódolásához és megszerzéséhez.
Ez azt jelenti, hogy ha valaki az ügyfél és a kiszolgáló között van, és figyelemmel kíséri a kapcsolatot, akkor sem fogja tudni az ügyfél privát kulcsát, a szerver titkos kulcsát vagy a titkos kulcsot.
Hogyan lehetséges ez? Math!
A Diffie-Hellman algoritmus
Az egyik legelterjedtebb megközelítés a Diffie-Hellman kulcscsere-algoritmus (DH). Ez az algoritmus lehetővé teszi az ügyfél és a szerver számára, hogy megegyezzenek a közös titkos kulcson anélkül, hogy át kellene adniuk a titkos kulcsot a kapcsolat fölött. Így a csatornát hallgatók nem tudják meghatározni a titkos kulcsot, még akkor sem, ha minden adatcsomagot kivétel nélkül elfognak.
Amint volt DH kulcscsere, a kapott titkos kulcs felhasználható további kapcsolatok titkosítására ebben a munkamenetben sokkal egyszerűbb szimmetrikus titkosítással.
Egy kis matematika ...
Az algoritmust alátámasztó matematikai függvények fontos megkülönböztető képességgel rendelkeznek - viszonylag könnyen előre kiszámíthatóak, de gyakorlatilag nem fordított irányban vannak kiszámítva. Pontosan ez a terület, ahol nagyon nagy prímszámok jönnek létre.
Legyen Alice és Bob a két fél, akik a DH-algoritmust kicserélik a kulcsokat. Először egy bizonyos gyökérről (általában egy kis számról, például 2,3 vagy 5-ből) és nagyon nagy prímszámról (több mint 300 számjegy) egyetértenek. Mindkét értéket világos formában küldi el a kommunikációs csatornán, anélkül, hogy veszélyeztetné a kapcsolatot.
Emlékezzünk arra, hogy mind az Alice, mind a Bob saját (több mint 100 számjegyű) kulcsa van, amelyeket soha nem közvetítenek a kommunikációs csatornákon keresztül.
A kommunikációs csatornán a keveréket elkeverjük. Ez a privát kulcsokból, valamint az elsődleges és a gyökér értékekből származik.
Így:
Alice keveréke = (gyökér ^ Alice's Secret)% prime
Bob keveréke = (root ^ Bob titka)% prime
ahol a% a megosztás fennmaradó része
Így Alice létrehozza keverék keverékét a konstansok (gyökér és primer) jóváhagyott értékei alapján, Bob ugyanígy csinálja. Miután megkapták egymás keverékének értékét, további matematikai műveleteket hoznak létre, hogy privát szekciókulcsot kapjanak. nevezetesen:
Alice számításai
(Bob keveréke Alice's Secret)% prime
Bob számításai
(Alice keveréke ^ Bob titka)% prime
Ezeknek a műveleteknek az eredménye ugyanaz a szám mind Alice, mind Bob számára, és ez a szám lesz a titkos kulcs ennek a munkamenetnek. Ne feledje, hogy egyik oldal sem továbbította a saját kulcsát a kommunikációs csatornán, és a kapott titkos kulcsot sem a nyitott kapcsolaton keresztül sem továbbították. Nagy!
A kevésbé matematikusok számára a Wikipédia gyönyörű képet ad. ezt a folyamatot a színkeverés példájával magyarázza:
Figyeljük meg, hogy a kezdeti szín (sárga) végül ugyanabban a "vegyes" színben változik mind Bobban, mind Alice-ban. Az egyetlen dolog, amit egy nyitott kommunikációs csatornán keresztül továbbítanak, az az, hogy félig kevert színű, valójában értelmetlen minden link-hallgató kapcsolatra.
Szimmetrikus titkosítás
A kulcscsere kapcsolatonként csak egy munkamenet után történik. Amikor a felek már egy titkos kulcsról állapodtak meg, az ügyfél-kiszolgáló kommunikáció szimmetrikus titkosítással történik, ami sokkal hatékonyabb az információátvitelnél, mivel a megerősítéshez további költségek nem szükségesek.
A korábban kapott titkos kulcs használatával, valamint a titkosítási móddal egyetértésben az ügyfél és a kiszolgáló biztonságosan adatcserét, titkos kulcs segítségével titkosítja és dekódolja az egymásról kapott üzeneteket. Egy olyan támadó, aki csatlakozik a csatornához, csak a "szemetet" fogja látni a hálózat mentén előre-hátra.
hitelesítés
A Diffie-Hellman algoritmus lehetővé teszi a két fél számára, hogy magántitokkulcsot szerezzen. De hol lehet mindkét fél biztos, hogy valóban beszélnek egymással? Még nem beszéltünk a hitelesítésről.
Mi van, ha hívom a barátomat, végrehajtjuk a DH-kulcscserét, de hirtelen kiderül, hogy a hívásomat elfogották, és ténylegesen közöltem valakivel. Még biztonságban tudok kommunikálni ezzel a személlyel - senki más nem hallgat ránk - de ez nem az, akivel véleményem szerint kommunikálok. Nem túl biztonságos!
A hitelesítési probléma megoldásához nyilvános kulcsú infrastruktúrára van szükségünk. így biztosak lehetünk benne, hogy a tantárgyak azok, akiknek kiadják magukat. Ez az infrastruktúra célja a digitális tanúsítványok létrehozása, kezelése, terjesztése és visszavonása. A tanúsítványok azokat a bosszantó dolgokat jelentik, amelyeket meg kell fizetnie ahhoz, hogy a webhely a HTTPS-en dolgozhasson.
De valójában mi ez a tanúsítvány, és hogyan nyújt biztonságot?
bizonylatok
Valójában a tanúsítványok összekapcsolják a tartományneveket egy adott nyilvános kulcsgal. Ez megakadályozza annak lehetőségét, hogy a támadó nyilvános kulcsot adjon, és kiszolgálóként jelenjen meg az ügyféllel.
Bármelyik webböngésző bízik meg, akkreditált tanúsító hatóságnak (CA, tanúsítvány hatóság, CA) kell aláírnia. A CA-k manuális ellenőrzést végző vállalatok, az a tény, hogy a tanúsítvány megszerzésére törekvő személy megfelel a következő két feltételnek:
1. valós;
2. hozzáférhet a domainhez, a tanúsítványhoz, amelyhez megpróbálja megszerezni.
Miután a CA tanúsítja, hogy a kérelmező valódi, és valóban ellenőrzi a domainet, a hitelesítésszolgáltató az ezen a webhelyen tanúsítványt állít ki, valójában egy visszaigazoló bélyegző beállításával azon a tényen, hogy a webhely nyilvános kulcsa tulajdonképpen hozzá tartozik, és megbízható.
A böngészője már előre betölti az akkreditált CA listáját. Ha a szerver olyan tanúsítványt ad vissza, amelyet nem egy akkreditált CA ír alá, akkor egy nagy piros figyelmeztetés jelenik meg. Ellenkező esetben mindenki képes aláírni a fiktív bizonyítványokat.
Így még ha egy hacker vette a nyilvános kulcsot a szerver, és létrehoz egy digitális tanúsítvány igazolja, hogy a nyilvános kulcs kapcsolódó oldalon facebook.com, böngészője nem hisz benne, mert a tanúsítvány nem írta alá az akkreditált hitelesítésszolgáltató
Egyéb dolgok, amelyekről tudni kell a tanúsítványokról
Bővített érvényesítés
A szokásos X.509 tanúsítványokon kívül kiterjesztett érvényesítési tanúsítványok is rendelkezésre állnak, amelyek magasabb szintű bizalmat biztosítanak. Az ilyen tanúsítvány kiadásával a CA még több ellenőrzést végez a tanúsítványt átvevő személy ellen (általában útlevéladatokkal vagy számlákkal).
Több weboldal kiszolgálása egyetlen kiszolgálón
A Wikipédiában egy csomó adat van ebben a témában, Coursera tanfolyam van. Külön köszönet a srácoknak a security.stackexchange.com csevegésből. aki ma reggel válaszolt a kérdéseire.