Aztán a blog STARTTLS
Hirtelen kiderült, hogy szinte minden internetes protokollok továbbítja az értékes adatok egyszerű szövegként. És minden ember, aki elfoghatja a forgalmat, hogy képes legyen kivonat az értékes adatokat. Természetesen fotochki tömítések és filmek ismert tartalom - nem igazán, és értékes. De itt van a belépési jelszót az online hozzáférést biztosít a tömítések, vagy a munkamenet azonosítóját, amikor a bejelentkezési jelszó már szerepel, - értékes.
Ezért SSL találta. Az alkalmazások terén - szinte mint egy normál TCP socket, csak az átvitt adatok titkosítva. És senki a közepén a tömítések többé nem fogja látni. Kivéve persze, hogy nem működik a megfelelő szervezet, amelynek feladata a bdit.
SSL / TLS - egy hibrid kriptográfiai rendszerek között. Van egy ügyfél, és van egy szerver. Az ügyfél mindig csatlakozik a szerverhez. A szerver egy titkos kulcsot, ami mindig vele. És a szerver egy nyilvános kulcsot, által aláírt igazolást néhány hitelesítésszolgáltató. Vagy írja alá a kulcsot a szerver is - a saját maga által aláírt tanúsítványt. A tanúsítvány tartalmazza a nevét, a szerver információt a tulajdonos és a cucc. Az ezen adatok helyességéért megerősítette az aláírás. CA aláírja tanúsítványok készpénzre. Ezek azok a szervezetek értékelik a jó hírnevét, és bízunk bennük. És ez a bizalom és a gazdaságban.
Ügyfél, amikor csatlakozik a szerverhez, megkapja tanúsítványt. Ez ellenőrzi: például azt, hogy a tanúsítvány a kiszolgáló, amelyhez csatlakozni? És ha még nem járt le érvényességi idejét az igazolást? Ne bízunk benne, hogy a CA aláíró tanúsítvány? Néha előfordul, és egy igazolást az ügyfél, és ez teszi a szerver, a szerver végzi ezeket azonos módon ellenőrzik. Ha minden rendben van, akkor megy tovább.
Használata aszimmetrikus titkosítást. privát kulcsot és a nyilvános kulcsokat a bizonyítványok, a kliens és a szerver egyetért a session kulcsot. Ez egy szimmetrikus titkosítási kulcsot. És ez a kulcs lesz titkosítva az adatok későbbi. Minden biztonságos és szép, ha használ friss megvalósítások TLS. Minden SSL változat 1,0-3,0, most is biztonságos. Biztonságos - jelentése TLS 1.1 vagy 1.2, és talán, TLS 1.0.
Nos, van egy megbízható módja annak, hogy titkosítja a TCP kapcsolatokat. De mi is a régi szép napok, már dolgoznak protokollokat. Hogyan adjunk titkosítást őket?
Kezdetben úgy döntött: nevezzük ezt az új protokollt, és tarts egy TCP port. A neve a protokoll az általában bukovku S - Biztonságos. Tehát HTTP vált HTTPS és költözött port 80 443-as porton FTP lett FTPS. 21-20 helyett port kezdtek használni portok 990-989. Nem tévesztendő össze SFTP. amely felhasználja a titkosított SSH, SSL helyett. SMTP. Mail Transfer Protocol lett SMTPS és vándoroltak port 25 port 465. Általában sok mail protokollok: POP3 → POP3S - 110 → 995, IMAP → IMAPS - 143 → 993. Még Jabber, más néven XMPP. először ment ezen az úton, hogy a port 5223 kapcsolatokat helyett mezhduservernyh 5269 került port 5270. Ó, Istenem, még telnets találták, a port 992 helyett port 5222 ügyfél az SSL kapcsolatokat.
Ez a megközelítés, amikor kiosztott egy külön port, forrás protokoll önmagában nem változtatja meg, hanem egyszerűen csomagolt SSL SSL csomagoló szólított SSL titkosítást. Még nagyon sok helyen használható, amely az úgynevezett sslwrap. és lehetővé teszi, hogy adjunk SSL bármely jegyzőkönyv.
Egy ilyen csomagolás a maga hátrányai. Létrehoztunk egy új portot. Az jó, akkor kell nyilvántartásba IANA. Úgy kell nyitni a tűzfalon. Ez a port kell lennie valakinek, hogy figyelj, és akkor lesz kétszer annyi démonok: a régi sima port, és az új SSL port. Végül, mivel a csere bizonyítványok és megállapodás a titkosítási paramétereket előtt történik a művelet megkezdése mi alkalmazás protokoll, néhány jellemzője ennek a protokollnak nem működnek.
Egy jó példa: a virtuális tárhely HTTP, már nem működik a HTTPS. Van egy HTTP szervert, és arra szolgál, több helyszínen, különböző domain nevek. A HTTP / 1.1 kliens minden kérelem meghatároz egy fogadó fejlécet. amely hozza az érintett része az URL. A szerver megnézi a fejléc, és válassza amelyek fenntartják a helyszínen utal a kérelmet. Ez egyszerű. De abban az esetben, SSL ügyfél kéri és ellenőrzi a szerver tanúsítvány küldése előtt fejléceket. És a tanúsítvány tartalmazza a domain név szerver. Mind az ügyfél gondoskodik arról, hogy ez pontosan mi a neve, amelyre vonatkozik. A békés úton, mindkét oldalon kell saját tanúsítványt. És itt kiderül, hogy az ugyanazon a 443-as porton lehet csak egy igazolás arról, hogy nem tud eleget tenni a helyszínek egyszerre. Ez nem működik.
A kísérlet megkerülni ezeket a nehézségeket úgy döntött, hogy menjen a másik irányba. Hosszabbítsa meg a protokollt, hogy képes legyen kommunikációt kezdeményezni nem titkosított, majd kapcsoljuk be a titkosítást, ha mind a kliens és a szerver támogatja. Ez a gyönyörűen úgynevezett opportunista TLS. A csapat, köztük a titkosítás, az úgynevezett STARTTLS.
Először is, a kliens csatlakozik a szerverhez, mint rendesen, titkosítás nélkül. Kezdetben a tárgyalások, a szabályok szerint a protokoll, a kliens és a szerver megpróbálja kideríteni képességeiket. Ha az ügyfél és a kiszolgáló és szeretné titkosítani, a kliens küld egy parancsot STARTTLS. Ezt követően, a szokásos eljárás a TLS tanúsítvány cseréjét és a legfontosabb megállapodást. Ha ez sikerül, akkor az ezt követő parancsok egy munkamenet a kliens és a szerver már a titkosított csatornán.
Abban az esetben, SMTP, hogy néz ki. Meg tudja nézni a szokásos telnet.
Az ügyfél kéri a szerver milyen funkciókat támogatja: EHLO parancsot. A szerver azt mondja, hogy többek között tudja a StartTLS: 250 STARTTLS. Az ügyfél azt mondja STARTTLS. A szerver azt mondja: én készen áll. Ezt követően, és meg kell kezdeni a TLS, csak telnet nem.
Az XMPP, mivel ez a protokoll alapján XML. STARTTLS külleme XML tag.
Az OpenSSL egy beépített kliens, amely képes megtenni STARTTLS. Például SMTP.
Az ügyfél meglehetősen gyenge, de ez érthető, hiszen csak tesztelés céljából. Lát egy nagyon szórakoztató, egyes karakterek, így SMTP parancsok nagyobb nyereségű kis betűkkel: rcpt a. mert egy nagy K okoz az ügyfél, hogy nem kapcsolja újra. Mégis képes megtenni STARTTLS SMTP, POP3, IMAP, és az ftp (-starttls opció).
Ugyanazt a portot használja a kódolatlan és kódolt kapcsolat volt annyira kényelmes, hogy külön portokat SSL gyorsan bejelentett elavult. Tehát most a standard és kóser módja TLS - jelentése STARTTLS.
Úgy tűnhet, hogy ez nem biztonságos, mert kezdjük a munkamenet nincs titkosítva. De titkosítás be van kapcsolva, amint a két fél úgy dönt, hogy szükségük van rá. Sima szöveg csak támogatja az általános lehetőségeit a kliens és a szerver. Mind a kliens és a szerver lehet állítani úgy, hogy megkövetelik a STARTTLS parancs. Ebben az esetben van szükség, mert a STARTTLS egyike volt az első csapat az ülésen, az átutalás előtt az érzékeny adatok. Ellenkező esetben további munkára van tiltva protokoll szerint.
De HTTPS valahogy nem jött össze. Talán azért, mert a HTTP nem biztosít hosszú ülések között az ügyfél és a kiszolgáló, a STARTTLS egyszerűen nincs hova tolóerő. Azonban egy hasonló kísérlet történt az RFC 2817. de nem élte túl. Volt ajánlkozott Upgrade protokoll TLS, kb mint most történik HTTP vagy WebSocket támogatást és egyidejű HTTP / 2.
OpenSSLny ügyfél és használja az SSL wrapper. (Host alá kérheti HTTP / 1.1 opcionális)
De most ez a virtuális tárhely alatt él HTTPS, kihajtható. Akkor egy helyettesítő tanúsítványt. tartomány * .myhost.example. és minden aldomain fogja fedezni ezt a bizonyítványt. Meg lehet venni egy igazolást a több domain nevek, gyakran segítségével bővítmények bizonyítványok nevű subjectAltName. Egyszerűen rámutatni egy igazolást domain nevek az oldal valamennyi szerverünkön. Ez csak adni igazolást az újból kiadják a másik oldalon.
A HTTP / 2 minden változatlan marad. A specifikáció nem TLS, vannak URL program http és https. Ugyanakkor a meglévő implementációk csak dolgozni TLS. Ez megköveteli a TLS 1.2 vagy magasabb támogatás Szerver neve jelzése.
Azonban a HTTP / 2-tervezet érezd opportunista Security for HTTP. Annak érdekében, hogy a http URL dolgozott TLS, ha az ügyfél megállapodott a szerver. Ahelyett, hogy az egyik STARTTLS parancs jelenik meg a tervezetben állítólag cserélni JSONami.