TLS és az SSL szükséges minimális ismeretek
Mi az SSL és TLS mi?
SSL - Secure Socket Layer, a Secure Sockets Layer. TLS - Transport Layer Security Transport Layer Security. Az SSL, a korábbi rendszer, TLS később jelentek meg, és ez alapján az SSL 3.0 specifikáció által kifejlesztett Netscape Communications. A probléma azonban az egyik ilyen protokoll - amely biztonságos adatátvitelt két számítógép között az interneten. Az ilyen sebességváltókat használják a különböző honlapok, e-mail, azonnali üzenetküldés és még sok más, amit. Elvileg lehetséges, hogy át minden olyan információt oly módon, ebben az alábbiakban.
Biztonságos átvitel révén biztosított továbbított információk hitelesítés és titkosítás. Lényegében ezeket a protokollokat, TLS és az SSL, ugyanúgy működnek, nincs alapvető különbség. A TLS, azt mondhatjuk, az utódja SSL, bár lehet használni egyszerre, még ugyanazon a szerveren. Az ilyen támogatásra van szükség annak érdekében, hogy a munka mind az új ügyfelek (eszközök és böngészők) és az idősebb, aki nem támogatja a TLS. Az előfordulásuk sorrendjében Ezen protokollok így néz ki:
A működési elve az SSL és a TLS
A működési elve a TLS és az SSL, ahogy azt már ugyanaz. A tetején a TCP / IP protokoll megy titkosított csatornát, amelyen belül a továbbított adatok Application Protocol - HTTP, FTP, és így tovább. Itt van, hogyan lehet grafikailag ábrázolható:
Alkalmazásprotokollok "csomagolva" a TLS / SSL, és viszont, a TCP / IP. Valójában az adatokat az alkalmazási protokollt továbbított TCP / IP, de titkosítva. És dekódolja a továbbított adatok csak akkor lehet ugyanazon a gépen, hogy létrehozta a kapcsolatot. Mindenki másnak, aki megkapja a továbbított csomagokat, ez az információ lesz értelme, ha nem tudják megfejteni.
Egy kapcsolat létesítését, feltéve, több szakaszban:
1) Az ügyfél a kapcsolatot a szerverrel, és kéri a biztonságos kapcsolatot. Ez úgy biztosítható, akár kapcsolat létrehozását port, amely eredetileg tervezték, hogy az SSL / TLS, például 443 vagy további ügyfél kérésére a biztonságos kapcsolat telepítés után a szokásosnál.
2) Ha az ügyfél kapcsolat egy listát titkosítási algoritmusok, hogy ő „tudja”. A szerver ellenőrzi a kapott listát listáját algoritmusok „tudja” a szerverrel, és kiválasztja a legmegbízhatóbb algoritmust, majd közli az ügyféllel, amely algoritmust használja
3) A kiszolgáló elküldi a kliens egy digitális tanúsítvány által aláírt igazoló hatóság és a szerver nyilvános kulcsával.
4) Az ügyfél képes kommunikálni egy megbízható hitelesítésszolgáltató szerver, amely aláírta a kiszolgáló tanúsítványt, és ellenőrizze, hogy a kiszolgáló tanúsítvány érvényes. De nem tud kommunikálni. Az operációs rendszer általában már telepítve gyökér CA tanúsítványok, amelyek össze aláírások szerver tanúsítványokat, mint például a böngészők.
5) létrehoz egy session kulcsot biztonságos kapcsolatot. Ez úgy történik, az alábbiak szerint:
- Az ügyfél generál véletlenszerű digitális sorozat
- Az ügyfél titkosítod szerver nyilvános kulcsával, és elküldi az eredményt a szerver
- Szerver dekódolja a kapott szekvencia a privát kulcs
Tekintettel arra, hogy a titkosítási algoritmus aszimmetrikus, megfejteni a sorrend csak szerver. A magán- és állami - ha használja aszimmetrikus titkosítást két kulcsot használ. Nyilvános elküldött üzenet titkosítva van, és megfejtett titkos. Dekódolja az üzenetet a nyilvánosság, nem lehet a kulcs.
6) Ez létrehoz egy titkosított kapcsolat. A továbbított adatok rajta, titkosított és visszafejthető mindaddig, amíg a kapcsolat megszakad.
főtanúsítványt
Aláírási kérelem (CSR, Certificate Sign kérelem)
ügyféltanúsítványt
A kliens tanúsítvány generált készülékekben való használatra, és a felhasználók számára. Tipikusan az ilyen tanúsítványok ellenőrzéséhez használt duplex, ahol az ügyfél ellenőrzi, hogy a szerver valóban, aki azt állítja, hogy, és a szerver ugyanazt csinálja. Ez a kölcsönhatás az úgynevezett kétutas hitelesítés kölcsönös hitelesítést. Kétoldalú ellenőrzés növeli a biztonsági szintet, mint egy egyoldalú, és tud is helyettesíthetik hitelesítést használ felhasználónevét és jelszavát.
Lánc intézkedések előállító tanúsítványok
Lássuk a gyakorlatban, hogy a cselekvések generálásával kapcsolatos igazolások, az elejétől, és ezzel egyidejűleg a gyakorlatban.
Az első dolog - ez a generáció a gyökér tanúsítványt. A gyökér tanúsítvány által aláírt magát. És akkor ezt a tanúsítványt aláírja egyéb igazolásokat.
Most a kapcsolat sikeres, és lehet telepíteni egy szerver tanúsítványt a Web szerver, a kliens küld az ügyfélnek, és együtt dolgozni velük.
biztonság
Ha az SSL / TLS egyik legfontosabb módszer a módszer MITM (Man In The Middle), «közbeékelődéses”. Ez a módszer alkalmazására alapuló néhány webhelykiszolgálóján tanúsítványt és kulcsot fogja hallgatni a forgalom és visszafejteni közötti információcsere a szerver és a kliens. Ahhoz, hogy hallgatni a szervezet lehet használni, például egy programot sslsniff. Ezért a gyökér tanúsítvány és a kulcs általában kívánatos, hogy a gép, hogy nem csatlakozik a hálózathoz, hogy aláírja kéréseket, hogy a látogatók a flash meghajtót, írja alá és csak úgy. És persze, hogy készítsen biztonsági másolatot.
Kapcsolódó hozzászólások:
Hozzászólás navigáció
CSR kliens generál maga a megrendelés során igazolást, hogy hol tárolja a privát kulcs megoldja kliens tanúsítvány kiállítására, nem kell egy privát kulcsot és egy ügyfél számunkra nem továbbítja. Természetesen, ha ez megtörténik, a rendszeres virtuális, akkor a rendszergazda root hozzáférést a szerverhez, és férhetnek hozzá a kulcsokat tárolnak.
Az is. De néhány tanúsító központok létrehozására CSR magukat, például WoSign. Ügyfél és nem továbbítja a kulcsot, akkor továbbítja egyetlen jele kérelmet. A virtuális szerver hosting adminisztrátorok férhetnek egyáltalán semmit. De van egy dolog. Ha egy jelszót, akkor a hozzáférést a tanúsítvány kulcs használhatatlan nélkül. Bár van egy mínusz. Itt van ez a mondat, hogy vezessenek be a kezét, amikor elindítja a szervert, így a szerver nem tudja elindítani a rendszer indításakor.
Tárgy mellek nem hozták nyilvánosságra, ahogy PKI technológia működik semmi köze a témához címet. Ha csak azért, mert a referencia RFC vezetett.
Ui Volt anekdota egy kutya és egy bolha.
Mint mondják, hogy tagadja meg - ajánlatot.
Figyelemmel a leírt technológia közvetlenül csatlakozik, mert mi van leírva a legtöbb esetben, és az úgynevezett „Hogyan SSL».
Nos, az RFC olvasó alkalmazás:
RFC 6101: A Secure Sockets Layer (SSL) Protocol Version 3.0
RFC 5246: A Transport Layer Security (TLS) Protocol Version 1.2
És igen, akkor is jó.
A zöld vonal a szervezet nevét csak akkor érhető el a EV tanúsítványt?
Amennyire emlékszem, igen
§ «SSL és TLS elve», «Az ügyfél létrehoz egy véletlenszerű digitális sorozat.”
Biztos voltam benne, hogy az ügyfél létrehoz egy munkamenet zárva, és ennek megfelelően a nyilvános kulcsot (amit nyilván, és az úgynevezett „digitális sorozat”). A nyilvános kulcsot továbbítja a szerver és a szerver titkosítja a csomagokat a kliens oldalon a kliens-nyitott gombot.
Inkább adni egy linket technet.microsoft.com. «Kulcscsere» részén. A cikk meg van írva, persze, leegyszerűsítő egyszerűen elmagyarázni a működési elve, hogy nem sokkal belemennénk a részletekbe.
Általában vannak különbségek. Általában egy saját maga által aláírt gyökér tanúsítványt. És ez csak akkor kell használni, hogy aláírja egyéb igazolásokat. A szerver tanúsítványt jellemzően által aláírt egy gyökér vagy köztes, ami által aláírt gyökér. Gyökértanúsítványok oszlanak nyilvánosan részeként operációs rendszer frissítések, szerver nem kell alkalmazni. Nos, a szempontból kriptográfia, elvileg ugyanaz a dolog.
Úgy döntöttünk, hogy kapcsolja be ezt a görbét fertőzés. Nem volt ott! A vezérlőpanel a fogadó le. Hozzáférés a helyszínen az eltűnt hálózatot. Még dob https protokoll, böngészők és esküszöm:
«Site.ru használ érvénytelen biztonsági tanúsítványt. A tanúsítvány nincs bizalom, hiszen saját maga írta alá. A tanúsítvány nem érvényes a név site.ru. »
Nyújtott támogatás ... visszaállítani a biztonsági másolatból honlapon!
Így állok a járdán, öltözött síléc. Vagy nem megy a síelés, vagy ...
Kérem, mondja meg a teáskannát. Ez úgy van, ahogy működnie kell? Vagy ez görbék tanúsítványok hajlított konfigurációban szerverek a fogadó, vagy mindkettő?
Köszönöm. Üdvözlettel
Vitali
Jó napot kívánok.
Ez nem működik jól. Általában normál bizonyítvány szerint a DNS-nevek, amelyek alapján azt ki (a www és www nélkül).
Amit leírja vagy egy igazolást, amelyben a DNS-neve nincs megadva vagy egy helyettesítő bizonyítványok.
Azt hiszem, ez görbék bizonyítványok és a beállításokat a gazda után.
Plusz, ez lehetséges a helyszínen zahardkozhen http protokoll különböző helyeken, így a tartalom jelenik meg részben. Ezek a problémák megoldódnak, vagy proxy, illetve szerkesztésével az oldalon.
Köszönöm, Max.
Az a tény, hogy a helyszín az egyik komponens gyakorlattá vált görbe mutatja miatt zahardkozhennogo http, rájöttem. De kiderült, hogy az admin felületen nem volt ott, hogy nézd meg ezeket a zátonyokat)))
A fogadó kínál technikai támogatás visszaállítása egy backup))) helyett, az én megértés, hogy foglalkozik a szerver beállításait, amely annak ellenére, hogy az eltávolítása a tanúsítvány még kezdeményezi https-kapcsolat.
Míg érvelek velük, és olvassa el, hogy az SSL, amely időpontban, és van, hogy a webhely, kevéssé ismert, hogy hogyan kell dolgozni, és hogy valójában nem működik megfelelően.
Köszönöm erősítse meg a feltételezéseket. Meg kell felfedezni a téma további.
Üdvözlettel
Vitali
Köszönöm. Nagyon kérhető.
Jó napot kívánok. Be kell, hogy új igazolások megadásával IP a kiszolgáló nevét (CN mező), ez ugyanaz FQDN. A már létrehozott igazolásokat nem csinál semmit.
Ez, amellett, hogy a tanúsítvány, hozzá kell férnie a https? Beállítása egy webszervert? Piszkálni felé a kívánt irányba.
Tanúsítvány, kulcs, tanúsítvány lánc, amely aláírta a szerver tanúsítvány (általában), és igen, konfigurálja a szervert, meg kell adnia a beállításokat az út, hogy a tanúsítvány fájlt, a legfontosabb, és néha a lánc. De általában, a lánc egyszerűen csatolt tanúsítványkiszolgálónak. A cikk csak azt Nginx és az Apache konfigurációs példák