Sledujte Smallstep
Certifikáty a infraštruktúra verejných kľúčov (PKI) sú ťažké. No nie je to pravda? Poznám veľa šikovných ľudí, ktorí sa tejto konkrétnej králičej diere vyhli. Osobne som sa jej dlho vyhýbal a cítil som istú hanbu, že neviem viac. Zrejmým výsledkom bol začarovaný kruh: Bol som príliš zahanbený na to, aby som sa pýtal, takže som sa nikdy nič nedozvedel.
Nakoniec som bol nútený sa tieto veci naučiť, pretože to umožňuje: PKI vám umožňuje kryptograficky definovať systém. Je to univerzálne a neutrálne voči dodávateľom. Funguje všade, takže časti vášho systému môžu bežať kdekoľvek a bezpečne komunikovať. Je koncepčne jednoduchý a mimoriadne flexibilný. Umožňuje používať TLS a zbaviť sa VPN. Môžete ignorovať všetko, čo sa týka vašej siete, a stále budete mať silné bezpečnostné vlastnosti. Je to celkom skvelé.
Teraz, keď som sa to naučil, ľutujem, že som to neurobil skôr. PKI je naozaj mocné a naozaj zaujímavé. Matematika je zložitá a štandardy sú hlúpo barokové, ale základné koncepty sú v skutočnosti celkom jednoduché. Certifikáty sú najlepším spôsobom identifikácie kódu a zariadení a identita je mimoriadne užitočná pre bezpečnosť, monitorovanie, meranie a milión ďalších vecí. Používanie certifikátov nie je až také ťažké. Nie je to ťažšie ako naučiť sa nový jazyk alebo databázu. Je to len trochu otravné a zle zdokumentované.
Toto je chýbajúca príručka. Počítam, že väčšina inžinierov sa dokáže zorientovať vo všetkých najdôležitejších konceptoch a bežných bizarnostiach za menej ako hodinu. To je náš cieľ. Hodina je celkom malá investícia na to, aby ste sa naučili niečo, čo sa doslova nedá urobiť iným spôsobom.
Moje motívy sú najmä didaktické. V rôznych ukážkach však budem používať dva open source projekty, ktoré sme vytvorili v smallstepe: step CLI a step certifikáty. Ak chcete sledovať, môžete si nainštalovať brew step, aby ste získali obidva (kompletný návod na inštaláciu nájdete tu). Ak dávate prednosť jednoduchému tlačidlu, roztočte bezplatnú hostovanú autoritu pomocou našej ponuky Certificate Manager.
Začnime jednou vetou tl;dr: Cieľom certifikátov a PKI je viazať mená na verejné kľúče. To je všetko. Zvyšok sú len implementačné detaily.
Všeobecný prehľad a niekoľko slov, ktoré by ste mali poznať
Budem používať niektoré technické termíny, takže si ich pred začiatkom definujme.
Entita je čokoľvek, čo existuje, aj keď existuje len logicky alebo konceptuálne. Váš počítač je entita. Takisto aj nejaký kód, ktorý ste napísali. Takisto aj vy. Rovnako ako burrito, ktoré ste zjedli na obed. Rovnako ako duch, ktorého ste videli, keď ste mali šesť rokov - aj keď vaša mama mala pravdu a bol to len výplod vašej fantázie.
Každá entita má svoju identitu. Túto je ťažké definovať. Identita je to, čo vás robí vami, viete? Na počítačoch sa identita zvyčajne predstavuje ako súbor atribútov opisujúcich nejakú entitu: skupina, vek, miesto, obľúbená farba, veľkosť topánok, čokoľvek. Identifikátor nie je to isté ako identita. Je to skôr jedinečný odkaz na nejakú entitu, ktorá má identitu. Som Mike, ale Mike nie je moja identita. Je to meno - identifikátor a meno sú synonymá (aspoň na naše účely).
Entity môžu tvrdiť, že majú nejaké konkrétne meno. Iné entity môžu byť schopné toto tvrdenie overiť a potvrdiť jeho pravdivosť. Tvrdenie však nemusí súvisieť s nejakým menom: môžem tvrdiť čokoľvek: svoj vek, váš vek, prístupové práva, zmysel života atď. Autentifikácia je vo všeobecnosti proces potvrdenia pravdivosti nejakého tvrdenia.
Účastník alebo koncový subjekt je subjekt, ktorý je zapojený do PKI a môže byť predmetom certifikátu. Certifikačná autorita (CA) je subjekt, ktorý vydáva certifikáty účastníkom - vydavateľ certifikátov. Certifikáty, ktoré patria účastníkom, sa niekedy nazývajú certifikáty koncových entít alebo listové certifikáty z dôvodov, ktoré budú jasnejšie, keď budeme hovoriť o reťazcoch certifikátov. Certifikáty, ktoré patria certifikačným autoritám, sa zvyčajne nazývajú koreňové certifikáty alebo intermediálne certifikáty v závislosti od druhu certifikačnej autority. A napokon spoliehajúca sa strana je používateľ certifikátu, ktorý overuje a dôveruje certifikátom vydaným certifikačnou autoritou. Aby sme to trochu zamotali, subjekt môže byť zároveň odberateľom aj spoliehajúcou sa stranou. To znamená, že jedna entita môže mať svoj vlastný certifikát a používať iné certifikáty na overovanie vzdialených partnerov (to sa deje napríklad pri vzájomnom TLS).
To nám na začiatok stačí, ale ak vás pedagogika vzrušuje, zvážte, či si RFC 4949 neuložíte na kindle. Pre všetkých ostatných, poďme na to konkrétne. Ako v praxi vytvárame nároky a overujeme veci? Hovorme o šifrovaní.
MAC a podpisy overujú pravosť vecí
Kód na overenie správ (MAC) je kúsok údajov, ktorý sa používa na overenie toho, ktorý subjekt správu odoslal, a na zabezpečenie toho, že správa nebola upravená. Základnou myšlienkou je vložiť zdieľané tajomstvo (heslo) spolu so správou prostredníctvom hašovacej funkcie. Výstupom hashovania je MAC. MAC sa spolu so správou pošle nejakému príjemcovi.
Príjemca, ktorý tiež pozná zdieľané tajomstvo, môže vytvoriť svoj vlastný MAC a porovnať ho s poskytnutým. Hašovacie funkcie majú jednoduchú zmluvu: ak im dvakrát zadáte rovnaký vstup, dostanete presne rovnaký výstup. Ak sa vstup líši - aj o jediný bit - výstup bude úplne iný. Ak sa teda MAC príjemcu zhoduje s MAC odoslaným so správou, môže si byť istý, že správu odoslal iný subjekt, ktorý pozná zdieľané tajomstvo. Za predpokladu, že zdieľané tajomstvo poznajú len dôveryhodné subjekty, môže príjemca správe dôverovať.
Hašovacie funkcie sú tiež jednosmerné: je výpočtovo neuskutočniteľné vziať výstup hašovacej funkcie a rekonštruovať jej vstup. To je rozhodujúce pre zachovanie dôvernosti zdieľaného tajomstva: inak by nejaký narušiteľ mohol odpozorovať vaše MAC, obrátiť vašu hashovaciu funkciu a zistiť vaše tajomstvá. To nie je dobré. To, či táto vlastnosť platí, závisí v rozhodujúcej miere od jemných detailov toho, ako sa hashovacie funkcie používajú na zostavenie MAC. Jemné detaily, ktoré tu nebudem rozoberať. Takže pozor: nesnažte sa vymyslieť vlastný algoritmus MAC. Použite HMAC.
2018-12-11-hmac.jpg
Všetky tieto reči o MAC sú prológom: náš skutočný príbeh sa začína podpismi. Podpis je koncepčne podobný MAC, ale namiesto zdieľaného tajomstva používate dvojicu kľúčov (definovanú čoskoro). Pri MAC musia zdieľané tajomstvo poznať aspoň dve entity: odosielateľ a príjemca. Platný MAC mohol byť vygenerovaný ktoroukoľvek stranou a vy nemôžete povedať, ktorou. Podpisy sú odlišné. Podpis sa dá overiť pomocou verejného kľúča, ale môže byť vygenerovaný len pomocou príslušného súkromného kľúča. Príjemca, ktorý má len verejný kľúč, teda môže overiť podpisy, ale nemôže ich generovať. To umožňuje prísnejšiu kontrolu nad tým, kto môže veci podpisovať. Ak súkromný kľúč pozná len jeden subjekt, získate vlastnosť nazývanú neodmietnutie: držiteľ súkromného kľúča nemôže poprieť (vyvrátiť) skutočnosť, že podpísal nejaké údaje.
Ak ste už zmätení, tak sa upokojte. Podpisy sa nazývajú z nejakého dôvodu: sú rovnaké ako podpisy v reálnom svete. Máte nejaké veci, s ktorými chcete, aby niekto súhlasil? Chcete sa uistiť, že neskôr budete môcť dokázať, že súhlasil? V pohode. Napíšte to a dajte im to podpísať.
Kryptografia s verejným kľúčom umožňuje počítačom vidieť
Certifikáty a PKI sú postavené na kryptografii s verejným kľúčom (nazývanej aj asymetrická kryptografia), ktorá používa páry kľúčov. Pár kľúčov pozostáva z verejného kľúča, ktorý sa môže šíriť a zdieľať s celým svetom, a zodpovedajúceho súkromného kľúča, ktorý by mal vlastník uchovávať v tajnosti.
Zopakujme poslednú časť, pretože je dôležitá: bezpečnosť kryptosystému s verejným kľúčom závisí od zachovania súkromných kľúčov.
S párom kľúčov môžete robiť dve veci:
Pomocou verejného kľúča môžete zašifrovať nejaké údaje. Jediný spôsob, ako tieto údaje dešifrovať, je použiť zodpovedajúci súkromný kľúč.
Niektoré údaje môžete podpísať súkromným kľúčom. Každý, kto pozná zodpovedajúci verejný kľúč, môže overiť podpis a dokázať, ktorý súkromný kľúč ho vytvoril.
Kryptografia s verejným kľúčom je magický dar matematiky informatike. Matematika je určite zložitá, ale nemusíte jej rozumieť, aby ste ocenili jej hodnotu. Kryptografia s verejným kľúčom umožňuje počítačom niečo, čo je inak nemožné: kryptografia s verejným kľúčom umožňuje počítačom vidieť.
Dobre, dovoľte mi to vysvetliť... kryptografia s verejným kľúčom umožňuje jednému počítaču (alebo časti kódu) dokázať druhému, že niečo vie, bez toho, aby sa o tieto znalosti priamo podelil. Ak chcete dokázať, že poznáte heslo, musíte ho zdieľať. Ten, komu ho zdieľate, ho môže použiť sám. Pri súkromnom kľúči to tak nie je. Je to ako s videním. Ak viete, ako vyzerám, môžete zistiť, kto som - overiť moju totožnosť - pohľadom na mňa. Ale nemôžete zmeniť podobu, aby ste sa za mňa vydávali.
Kryptografia s verejným kľúčom robí niečo podobné. Ak poznáte môj verejný kľúč (ako vyzerám), môžete ho použiť na to, aby ste ma videli v sieti. Môžete mi napríklad poslať veľké náhodné číslo. Ja môžem vaše číslo podpísať a poslať vám svoj podpis. Overenie tohto podpisu je dobrým dôkazom, že hovoríte so mnou. To účinne umožňuje počítačom vidieť, s kým hovoria v sieti. Je to také šialene užitočné, že to v reálnom svete považujeme za samozrejmosť. V sieti je to priamo kúzlo. Vďaka matematike.
Certifikáty: vodičské preukazy pre počítače a kód
Čo ak ešte nepoznáte môj verejný kľúč? Na to slúžia certifikáty.
Certifikáty sú v podstate veľmi jednoduché. Certifikát je dátová štruktúra, ktorá obsahuje verejný kľúč a meno. Dátová štruktúra sa potom podpíše. Podpis spája verejný kľúč s menom. Subjekt, ktorý podpisuje certifikát, sa nazýva vydavateľ (alebo certifikačná autorita) a subjekt uvedený v certifikáte sa nazýva subjekt.
Ak nejaký vydavateľ podpíše certifikát pre Boba, tento certifikát možno interpretovať ako vyhlásenie: Je to tvrdenie, ktoré o Bobovi vyslovil Some Issuer. "Some Issuer says Bob's public key is 01:23:42...". Tvrdenie je podpísané Some Issuer, takže ak poznáte verejný kľúč Some Issuer, môžete ho overiť overením podpisu. Ak niektorému vydavateľovi dôverujete, môžete tvrdeniu veriť. Certifikáty vám teda umožňujú využiť dôveru a znalosť verejného kľúča vydavateľa na zistenie verejného kľúča iného subjektu (v tomto prípade Boba). To je všetko. To je v podstate všetko, čím certifikát je.
2018-12-11-drivers-license-cert.jpg
Certifikáty sú ako vodičské preukazy alebo pasy pre počítače a kód. Ak ste ma nikdy predtým nestretli, ale dôverujete dopravnému úradu, môžete na overenie použiť môj vodičský preukaz: overte, či je platný (skontrolujte hologram atď.), pozrite sa na obrázok, pozrite sa na mňa, prečítajte meno. Počítače používajú certifikáty na to isté: ak ste sa nikdy predtým nestretli s nejakým počítačom, ale dôverujete nejakej certifikačnej autorite, môžete použiť certifikát na autentifikáciu: overiť, či je certifikát platný (skontrolovať podpis atď.), pozrieť sa na verejný kľúč, "pozrieť sa na súkromný kľúč" cez sieť (ako je opísané vyššie), prečítať meno.
2018-12-11-license-vs-cert.jpg
Poďme sa rýchlo pozrieť na skutočný certifikát:
2018-12-11-step-certificate-inspect.jpg
Áno, tak som to možno trochu zjednodušil. Podobne ako vodičský preukaz, aj v certifikátoch sú ďalšie veci. V preukazoch sa uvádza, či ste darcom orgánov a či ste oprávnený viesť úžitkové vozidlo. Certifikáty hovoria o tom, či ste certifikačnou autoritou a či sa váš verejný kľúč má používať na podpisovanie alebo šifrovanie. Platnosť oboch certifikátov tiež vyprší.
Je tu veľa podrobností, ale nič to nemení na tom, čo som povedal predtým: certifikát je v podstate len vec, ktorá viaže verejný kľúč na meno.
X.509, ASN.1, OID, DER, PEM, PKCS, ach jaj...
Pozrime sa na to, ako sú certifikáty reprezentované ako bity a bajty. Táto časť je v skutočnosti nepríjemne komplikovaná. V skutočnosti mám podozrenie, že ezoterický a zle definovaný spôsob kódovania certifikátov a kľúčov je zdrojom najväčšieho zmätku a frustrácie v súvislosti s PKI vo všeobecnosti. Tieto veci sú hlúpe. Prepáčte.
Zvyčajne, keď ľudia hovoria o certifikátoch bez dodatočnej kvalifikácie, majú na mysli certifikáty X.509 v3. Presnejšie, zvyčajne hovoria o variante PKIX opísanom v dokumente RFC 5280 a ďalej spresnenom v Základných požiadavkách CA/Browser Forum. Inými slovami, hovoria o certifikátoch, ktoré prehliadače chápu a používajú pre HTTPS (HTTP cez TLS). Existujú aj iné formáty certifikátov. Najmä SSH a PGP majú svoje vlastné. My sa však zameriame na X.509. Ak rozumiete X.509, budete schopní pochopiť aj všetko ostatné.
Keďže tieto certifikáty sú tak široko podporované - majú dobré knižnice a podobne - často sa používajú aj v iných kontextoch. Určite sú najbežnejším formátom certifikátov vydávaných internými PKI (definované o niečo neskôr). Dôležité je, že tieto certifikáty fungujú s klientmi a servermi TLS a HTTPS.
Bez malej lekcie z histórie nemôžete plne oceniť certifikát X.509. Protokol X.509 bol prvýkrát štandardizovaný v roku 1988 ako súčasť širšieho projektu X.500 pod záštitou ITU-T (normalizačný orgán Medzinárodnej telekomunikačnej únie). Projekt X.500 bol snahou telekomunikačných operátorov vytvoriť globálny telefónny zoznam. K tomu nikdy nedošlo, ale jeho pozostatky zostali. Ak ste sa niekedy pozerali na certifikát X.509 a rozmýšľali ste, prečo je v niečom určenom pre web zakódovaná lokalita, štát a krajina, tu je odpoveď: X.509 nebol navrhnutý pre web. Bol navrhnutý pred tridsiatimi rokmi na vytvorenie telefónneho zoznamu.
2018-12-11-cert-distinguished-name.jpg
Norma X.509 vychádza z ASN.1, ďalšej normy ITU-T (definovanej normami X.208 a X.680). ASN je skratka pre abstraktný syntaktický zápis (1 znamená One). ASN.1 je notácia na definovanie dátových typov. Môžete si ju predstaviť ako JSON pre X.509, ale v skutočnosti je to skôr protobuf alebo thrift alebo SQL DDL. RFC 5280 používa ASN.1 na definovanie certifikátu X.509 ako objektu, ktorý obsahuje rôzne bity informácií: meno, kľúč, podpis atď.
ASN.1 má bežné dátové typy ako celé čísla, reťazce, množiny a sekvencie. Má aj neobvyklý typ, ktorý je dôležité pochopiť: identifikátory objektov (OID). OID je niečo ako URI, ale viac nepríjemné. Sú to (mali by byť) univerzálne jedinečné identifikátory. Z hľadiska štruktúry sú identifikátory OID postupnosťou celých čísel v hierarchickom mennom priestore. Pomocou OID môžete označiť kúsok údajov typom. Reťazec je len reťazec, ale ak reťazec označím identifikátorom OID 2.5.4.3, potom to už nie je obyčajný reťazec - je to spoločné meno X.509.
2018-12-11-oids.jpg
ASN.1 je abstraktná v tom zmysle, že norma nehovorí nič o tom, ako by mali byť veci reprezentované ako bity a bajty. Na to existujú rôzne pravidlá kódovania, ktoré špecifikujú konkrétne reprezentácie pre hodnoty údajov ASN.1. Je to ďalšia abstrakčná vrstva, ktorá má byť užitočná, ale väčšinou je len otravná. Je to niečo ako rozdiel medzi unicode a utf8 (eek).
Pre ASN.1 existuje množstvo kódovacích pravidiel, ale existuje len jedno, ktoré sa bežne používa pre certifikáty X.509 a iné šifrovacie veci: rozlišovacie kódovacie pravidlá alebo DER (hoci občas sa používajú aj nekanonické základné kódovacie pravidlá (BER)). DER je pomerne jednoduché kódovanie typu a dĺžky hodnoty, ale v skutočnosti sa oň nemusíte starať, pretože väčšinu ťažkej práce vykonajú knižnice.
Bohužiaľ, príbeh sa tu nekončí. O kódovanie a dekódovanie DER sa nemusíte veľmi starať, ale určite budete musieť zistiť, či je konkrétny certifikát obyčajný certifikát X.509 kódovaný v DER alebo niečo náročnejšie. Existujú dva potenciálne rozmery vymyslenosti: môžeme sa pozerať na niečo viac ako na surový DER a môžeme sa pozerať na niečo viac ako len na certifikát.
Začneme prvým rozmerom, DER je priamo binárny a binárne údaje sa ťažko kopírujú, vkladajú a inak posúvajú po webe. Preto je väčšina certifikátov zabalená v súboroch PEM (čo je skratka pre Privacy Enhanced EMail, ďalší zvláštny historický pozostatok). Ak ste niekedy pracovali s MIME, PEM je podobný: base64 kódované užitočné zaťaženie vložené medzi hlavičku a pätičku. Hlavička PEM má označenie, ktoré má popisovať užitočné zaťaženie. Šokujúce je, že táto jednoduchá úloha je väčšinou spackaná a štítky PEM sú často nekonzistentné medzi jednotlivými nástrojmi (RFC 7468 sa pokúša štandardizovať používanie PEM v tomto kontexte, ale nie je úplné a nie vždy sa dodržiava). Bez ďalších zbytočných rečí vám ukážeme, ako vyzerá certifikát X.509 v3 zakódovaný v PEM:
-----ZAČIATOK CERTIFIKÁTU-----
MIIBwzCCAWqgAwIBAgIRAIi5QRl9kz1wb+SUP20gB1kwCgYIKoZIzj0EAwIwGzEZ
MBcGA1UEAxMQTDVkIFRlc3QgUm9vdCBDQTAeFw0xODExMDYyMjA0MDNaFw0yODEx
MDMyMjA0MDNaMCMxITAfBgNVBAMTGEw1ZCBUZXN0IEludGVybWVkaWF0ZSBDQTBZ
MBMGByqGSM49AgEGCCqGSM49AwEHA0IABAST8h+JftPkPocZyuZ5CVuPUk3vUtgo
cgRbkYk7Ong7ey/fM5fJdRNdeW6SouV5h3nF9JvYKEXuoymSNjGbKomjgYYwgYMw
DgYDVR0PAQH/BAQDAgGmMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAS
BgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRc+LHppFk8sflIpm/XKpbNMwx3
SDAfBgNVHSMEGDAWgBTirEpzC7/gexnnz7ozjWKd71lz5DAKBggqhkjOPQQDAgNH
ADBEAiAejDEfua7dud78lxWe9eYxYcM93mlUMFIzbWlOJzg+rgIgcdtU9wIKmn5q
FU3iOiRP5VyLNmrsQD3/ItjUN1f1ouY=
-----END CERTIFIKÁT-----
Certifikáty kódované v PEM majú zvyčajne príponu .pem, .crt alebo .cer. Surový certifikát zakódovaný pomocou DER bude zvyčajne niesť príponu .der. Opäť tu nie je veľká konzistencia, takže váš postup sa môže líšiť.
Vráťme sa k nášmu ďalšiemu rozmeru fantázie: okrem fantazijného kódovania pomocou PEM môže byť certifikát zabalený do fantazijnejšieho obalu. Niektoré obálkové formáty definujú väčšie dátové štruktúry (stále s použitím ASN.1), ktoré môžu obsahovať certifikáty, kľúče a ďalšie veci. Niektoré veci sa pýtajú na "certifikát", keď v skutočnosti chcú certifikát v jednej z týchto obálok. Takže pozor.
Obálkové formáty, s ktorými sa pravdepodobne stretnete, sú súčasťou súboru štandardov s názvom PKCS (Public Key Cryptography Standards), ktoré vydali laboratóriá RSA (v skutočnosti je príbeh trochu zložitejší, ale to je jedno). Prvým je PKCS#7, ktorý IETF premenovala na Cryptographic Message Syntax (CMS) a ktorý môže obsahovať jeden alebo viacero certifikátov (kódovanie celého reťazca certifikátov, ktoré je opísané v krátkosti). PKCS#7 sa bežne používa v Jave. Bežné prípony sú .p7b a .p7c. Ďalším bežným formátom obálky je PKCS#12, ktorý môže obsahovať reťazec certifikátov (ako PKCS#7) spolu s (zašifrovaným) súkromným kľúčom. PKCS#12 sa bežne používa v produktoch spoločnosti Microsoft. Bežné prípony sú .pfx a .p12. Obálky PKCS#7 a PKCS#12 tiež používajú ASN.1. To znamená, že obe môžu byť zakódované ako surový DER alebo BER alebo PEM. To znamená, že podľa mojich skúseností sú to takmer vždy surové DER.
Kódovanie kľúčov je podobne spletité, ale vzor je vo všeobecnosti rovnaký: nejaká dátová štruktúra ASN.1 opisuje kľúč, DER sa používa ako binárne kódovanie a PEM (dúfajme, že s užitočnou hlavičkou) sa môže použiť ako trochu priateľskejšia reprezentácia. Rozlúštenie druhu kľúča, na ktorý sa pozeráte, je napoly umenie, napoly veda. Ak budete mať šťastie, RFC 7468 poskytne dobrý návod na zistenie, čo je vaše užitočné zaťaženie PEM. Kľúče s eliptickou krivkou sú zvyčajne takto označené, hoci sa nezdá, že by existovala nejaká štandardizácia. Ostatné kľúče sú jednoducho "PRIVATE KEY" podľa PEM. To zvyčajne označuje užitočné zaťaženie PKCS#8, obálku pre súkromné kľúče, ktorá obsahuje typ kľúča a ďalšie metadáta. Tu je príklad kľúča s eliptickou krivkou zakódovaného v PEM:
$ step crypto keypair --kty EC --no-password --insecure ec.pub ec.prv
$ cat ec.pub ec.prv
-----ZAČIATOK VEREJNÉHO KĽÚČA-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEc73/+JOESKlqWlhf0UzcRjEe7inF
uu2z1DWxr+2YRLfTaJOm9huerJCh71z5lugg+QVLZBedKGEff5jgTssXHg==
-----END PUBLIC KEY-----
-----ZAČIATOK SÚKROMNÉHO KĽÚČA EC-----
MHcCAQEEICjpa3i7ICHSIqZPZfkJpcRim/EAmUtMFGJg6QjkMqDMoAoGCCqGSM49
AwEHoUQDQgAEc73/+JOESKlqWlhf0UzcRjEe7inFuu2z1DWxr+2YRLfTaJOm9hue
rJCh71z5lugg+QVLZBedKGEff5jgTssXHg==
-----END EC SÚKROMNÝ KĽÚČ-----
Pomerne často sa stretávame aj so súkromnými kľúčmi zašifrovanými pomocou hesla (zdieľané tajomstvo alebo symetrický kľúč). Tie budú vyzerať približne takto (Proc-Type a DEK-Info sú súčasťou PEM a označujú, že toto užitočné zaťaženie PEM je šifrované pomocou AES-256-CBC):
-----ZAČIATOK SÚKROMNÉHO KĽÚČA EC-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,b3fd6578bf18d12a76c98bda947c4ac9
qdV5u+wrywkbO0Ai8VUuwZO1cqhwsNaDQwTiYUwohvot7Vw851rW/43poPhH07So
sdLFVCKPd9v6F9n2dkdWCeeFlI4hfx+EwzXLuaRWg6aoYOj7ucJdkofyRyd4pEt+
Mj60xqLkaRtphh9HWKgaHsdBki68LQbObLOz4c6SyxI=
-----END EC SÚKROMNÝ KĽÚČ-----
Objekty PKCS#8 môžu byť aj zašifrované, v takom prípade by označenie hlavičky malo byť "ENCRYPTED PRIVATE KEY" podľa RFC 7468. V tomto prípade nebudete mať hlavičky Proc-Type a Dek-Info, pretože tieto informácie sú namiesto toho zakódované v užitočnom zaťažení.
Verejné kľúče majú zvyčajne príponu .pub alebo .pem. Súkromné kľúče môžu mať príponu .prv, .key alebo .pem. Opäť sa môže líšiť.
Krátke zhrnutie. ASN.1 sa používa na definovanie dátových typov, ako sú certifikáty a kľúče. DER je súbor pravidiel kódovania na premenu ASN.1 na bity a bajty. X.509 je definovaný v ASN.1. PKCS#7 a PKCS#12 sú väčšie dátové štruktúry, tiež definované pomocou ASN.1, ktoré môžu obsahovať certifikáty a ďalšie veci. Bežne sa používajú v Jave, resp. v Microsofte. Keďže surový binárny DER sa ťažko presúva po webe, väčšina certifikátov je kódovaná PEM, ktorý kóduje DER v base64 a označuje ho. Súkromné kľúče sú zvyčajne reprezentované ako objekty PKCS#8 kódované v PEM. Niekedy sú tiež zašifrované heslom.
Ak je to mätúce, nie je to vaša chyba. Je to svetom. Skúsil som to.
Infraštruktúra verejných kľúčov
Je dobré vedieť, čo je to certifikát, ale to nie je ani polovica príbehu. Pozrime sa na to, ako sa certifikáty vytvárajú a používajú.
Infraštruktúra verejných kľúčov (PKI) je súhrnný pojem pre všetky veci, ktoré potrebujeme na vydávanie, distribúciu, ukladanie, používanie, overovanie, zrušenie a inú správu a interakciu s certifikátmi a kľúčmi. Je to zámerne nejasný termín, podobne ako "databázová infraštruktúra". Certifikáty sú stavebnými prvkami väčšiny PKI a certifikačné autority sú ich základom. Napriek tomu je PKI oveľa viac. Zahŕňa knižnice, cron úlohy, protokoly, konvencie, klientov, servery, ľudí, procesy, mená, mechanizmy zisťovania a všetky ostatné veci, ktoré budete potrebovať na efektívne používanie kryptografie verejných kľúčov.
Ak si vytvoríte vlastný PKI od základov, užijete si kopec voľnosti. Rovnako ako keď si vybudujete vlastnú databázovú infraštruktúru. Mnohé jednoduché infraštruktúry PKI v skutočnosti ani nepoužívajú certifikáty. Keď upravujete ~/.ssh/authorized_keys, konfigurujete jednoduchú formu PKI bez certifikátov, ktorú SSH používa na viazanie verejných kľúčov na mená v plochých súboroch. PGP používa certifikáty, ale nepoužíva certifikačné autority. Namiesto toho používa model web-of-trust. Na priradenie mien a ich zviazanie s verejnými kľúčmi môžete dokonca použiť blockchain. Jediná vec, ktorá je skutočne povinná, ak budujete PKI od nuly, je, že podľa definície musíte používať verejné kľúče. Všetko ostatné sa môže zmeniť.
Napriek tomu pravdepodobne nechcete budovať PKI úplne od nuly. Zameriame sa na druh PKI používaný na webe a na interné PKI, ktoré sú založené na technológiách webového PKI a využívajú existujúce štandardy a komponenty.
Pri našom postupe si zapamätajte jednoduchý cieľ certifikátov a PKI: spájať mená s verejnými kľúčmi.
Webový PKI verzus interný PKI
S webovým PKI komunikujete prostredníctvom prehliadača vždy, keď pristupujete na adresu HTTPS URL - ako napríklad pri načítaní tejto webovej stránky. Toto je jediné PKI, ktoré mnohí ľudia (aspoň okrajovo) poznajú. Vŕzga, škrípe a škrípe, ale väčšinou funguje. Napriek svojim problémom podstatne zlepšuje bezpečnosť na webe a pre používateľov je väčšinou transparentná. Mali by ste ho používať všade, kde váš systém komunikuje s vonkajším svetom cez internet.
Webová PKI je väčšinou definovaná v dokumente RFC 5280 a zdokonalená fórom CA/Browser Forum (alias CA/B alebo CAB Forum). Niekedy sa nazýva "internetový PKI" alebo PKIX (podľa pracovnej skupiny, ktorá ho vytvorila). Dokumenty PKIX a CAB Forum pokrývajú veľa oblastí. Definujú rôzne certifikáty, o ktorých sme hovorili v poslednej časti. Definujú tiež, čo je to "meno" a kde sa v certifikáte nachádza, aké podpisové algoritmy sa môžu používať, ako spoliehajúca sa strana určuje vydavateľa certifikátu, ako sa určuje obdobie platnosti certifikátu (dátum vydania a dátum vypršania platnosti), ako funguje odvolanie a overenie cesty certifikátu, proces, ktorý certifikačné autority používajú na určenie, či niekto vlastní doménu, a mnoho ďalšieho.
Webový PKI je dôležitý, pretože webové certifikáty PKI štandardne fungujú v prehliadačoch a takmer vo všetkých ostatných zariadeniach, ktoré používajú TLS.
Interná PKI je PKI, ktorú prevádzkujete sami pre svoje vlastné veci: produkčnú infraštruktúru, ako sú služby, kontajnery a virtuálne počítače, podnikové IT aplikácie, podnikové koncové body, ako sú notebooky a telefóny, a akýkoľvek iný kód alebo zariadenie, ktoré chcete identifikovať. Umožňuje vám overovať a vytvárať kryptografické kanály, aby vaše veci mohli bežať kdekoľvek a bezpečne komunikovať, dokonca aj cez verejný internet.
Načo prevádzkovať vlastnú internú infraštruktúru PKI, keď už existuje webová infraštruktúra PKI? Jednoduchá odpoveď znie: Web PKI nebol navrhnutý na podporu interných prípadov použitia. Dokonca aj v prípade certifikačnej autority, ako je Let's Encrypt, ktorá ponúka bezplatné certifikáty a automatické poskytovanie, sa budete musieť vysporiadať s obmedzeniami rýchlosti a dostupnosti. To nie je dobré, ak máte veľa služieb, ktoré neustále nasadzujete.
Okrem toho pri webovom PKI máte len malú alebo žiadnu kontrolu nad dôležitými detailmi, ako je životnosť certifikátu, mechanizmy odvolania, procesy obnovy, typy kľúčov a algoritmy (všetky dôležité veci vysvetlíme o chvíľu).
Nakoniec, základné požiadavky CA/Browser Forum v skutočnosti zakazujú certifikačným autoritám Web PKI viazať interné IP (napr. veci v 10.0.0.0/8) alebo interné názvy DNS, ktoré nie sú plne kvalifikované a preložiteľné vo verejnom globálnom DNS (napr. nemôžete viazať názov DNS klastra Kubernetes ako foo.ns.svc.cluster.local). Ak chcete viazať takýto názov v certifikáte, vydávať veľa certifikátov alebo kontrolovať podrobnosti certifikátu, budete potrebovať vlastný interný PKI.
V ďalšej časti uvidíme, že dôvera (alebo jej nedostatok) je ďalším dôvodom, prečo sa vyhnúť webovej PKI na interné použitie. Stručne povedané, používajte webové PKI pre svoje verejné webové stránky a rozhrania API. Na všetko ostatné používajte vlastný interný PKI.
Dôvera a dôveryhodnosť
Úložiská dôveryhodnosti
Predtým sme sa naučili interpretovať certifikát ako vyhlásenie alebo tvrdenie, napr: "vydavateľ tvrdí, že verejný kľúč subjektu je bla bla bla". Toto tvrdenie je podpísané vydavateľom, takže ho môžu overiť spoliehajúce sa strany. V tomto popise sme zamlčali niečo dôležité: "Ako sa spoliehajúca sa strana dozvie o verejnom kľúči vydavateľa?
Odpoveď je jednoduchá, aj keď nie uspokojivá: spoliehajúce sa strany sú vopred nakonfigurované so zoznamom dôveryhodných koreňových certifikátov (alebo kotiev dôvery) v úložisku dôvery. Spôsob, akým sa táto predbežná konfigurácia uskutočňuje, je dôležitým aspektom každého PKI. Jednou z možností je vychádzať z iného PKI: mohli by ste mať nejaký automatizačný nástroj, ktorý by používal SSH na kopírovanie koreňových certifikátov spoliehajúcim sa stranám, pričom by sa využil už opísaný PKI SSH. Ak pracujete v cloude, váš SSH PKI je zasa založený na webovom PKI plus na overovaní, ktoré vykonal váš dodávateľ cloudu, keď ste si vytvorili účet a dali mu svoju kreditnú kartu. Ak budete sledovať tento reťazec dôveryhodnosti dostatočne ďaleko, vždy nájdete ľudí: každý reťazec dôveryhodnosti končí v meatspace.
2018-12-11-chain-of-trust.jpg
Koreňové certifikáty v dôveryhodných úložiskách sú podpísané samými sebou. Vydavateľ a subjekt sú tí istí. Logicky ide o vyhlásenie typu "Mike tvrdí, že Mikov verejný kľúč je bla bla bla". Podpis na samopodpísanom certifikáte poskytuje istotu, že subjekt/vydavateľ pozná príslušný súkromný kľúč, ale ktokoľvek môže vygenerovať samopodpísaný certifikát s ľubovoľným menom, ktoré v ňom chce mať. Preto je rozhodujúci pôvod: certifikát podpísaný vlastným podpisom by mal byť dôveryhodný len do tej miery, do akej je dôveryhodný proces, ktorým sa dostal do úložiska dôveryhodnosti. V systéme macOS je dôveryhodné úložisko spravované kľúčenkou. V mnohých distribúciách Linuxu je to jednoducho nejaký súbor(y) v /etc alebo inde na disku. Ak vaši používatelia môžu tieto súbory upravovať, radšej dôverujte všetkým používateľom.
Odkiaľ teda pochádzajú dôveryhodné úložiská? Pre webové PKI sú najdôležitejšími spoliehajúcimi sa stranami prehliadače. Úložiská dôveryhodnosti, ktoré štandardne používajú hlavné prehliadače - a takmer všetky ostatné, ktoré používajú TLS - spravujú štyri organizácie:
Program koreňových certifikátov spoločnosti Apple, ktorý používajú systémy iOS a macOS
program koreňových certifikátov spoločnosti Microsoft, ktorý používa systém Windows
program koreňových certifikátov spoločnosti Mozilla, ktorý používajú jej produkty a ktorý sa vďaka otvorenému a transparentnému procesu používa ako základ pre mnohé ďalšie úložiská dôveryhodnosti (napr. pre mnohé distribúcie Linuxu)
Google, ktorý nepoužíva program koreňových certifikátov (Chrome zvyčajne používa dôveryhodné úložisko hostiteľského operačného systému), ale udržiava vlastný zoznam blokov koreňových a špecifických certifikátov, ktorým nedôveruje. (ChromeOS vychádza z programu certifikátov Mozilly.)
Úložiská dôveryhodnosti operačných systémov sa zvyčajne dodávajú s operačným systémom. Firefox sa dodáva s vlastným dôveryhodným úložiskom (distribuovaným pomocou TLS z mozilla.org - zavádzanie z webového PKI pomocou iného dôveryhodného úložiska). Programovacie jazyky a iné veci, ktoré nie sú súčasťou prehliadača, ako napríklad curl, zvyčajne štandardne používajú úložisko dôveryhodnosti operačného systému. Takže úložiská dôveryhodnosti, ktoré sa v predvolenom nastavení používajú takmer vo všetkom, sú predinštalované a aktualizujú sa prostredníctvom aktualizácií softvéru (ktoré sú zvyčajne podpísané kódom pomocou iného PKI).
V dôveryhodných úložiskách spravovaných týmito programami je bežne zahrnutých viac ako 100 certifikačných autorít. Tie najväčšie pravdepodobne poznáte: Let's Encrypt, Symantec, DigiCert, Entrust atď. Môže byť zaujímavé si ich prezrieť. Ak by ste to chceli urobiť programovo, projekt cfssl spoločnosti Cloudflare spravuje repozitár github, ktorý obsahuje dôveryhodné certifikáty z rôznych dôveryhodných úložísk, ktoré pomáhajú pri spájaní certifikátov (o čom budeme hovoriť o chvíľu). Ak chcete získať ľudskejšie skúsenosti, môžete sa opýtať Censys a zistiť, ktoré certifikáty sú dôveryhodné pre Mozillu, Apple a Microsoft.
Dôveryhodnosť
Týchto viac ako 100 certifikačných autorít je dôveryhodných v opisnom zmysle - prehliadače a ďalšie veci štandardne dôverujú certifikátom vydaným týmito certifikačnými autoritami. To však neznamená, že sú dôveryhodné v morálnom zmysle. Naopak, sú zdokumentované prípady, keď webové certifikačné autority PKI poskytovali vládam falošné certifikáty s cieľom sledovať prevádzku a vydávať sa za webové stránky. Niektoré z týchto "dôveryhodných" certifikačných autorít pôsobia v autoritárskych jurisdikciách, ako je Čína. Demokracie tu tiež nemajú morálne výhody. NSA využíva každú dostupnú príležitosť, aby podkopala webovú PKI. V roku 2011 boli kompromitované "dôveryhodné" certifikačné autority DigiNotar a Comodo. Za narušením certifikátu DigiNotar bola pravdepodobne NSA. Existuje aj množstvo príkladov certifikačných autorít, ktoré omylom vydali chybné alebo nevyhovujúce certifikáty. Takže hoci sú tieto certifikačné autority de facto dôveryhodné, ako skupina empiricky dôveryhodné nie sú. Čoskoro uvidíme, že webový PKI je vo všeobecnosti len tak bezpečný ako najmenej bezpečná CA, takže to nie je dobré.
Komunita prehliadačov prijala určité opatrenia na riešenie tohto problému. V základných požiadavkách CA/Browser Forum sú racionalizované pravidlá, ktoré majú tieto dôveryhodné certifikačné autority dodržiavať pred vydaním certifikátov. CA sú kontrolované na dodržiavanie týchto pravidiel v rámci programu auditu WebTrust, ktorý vyžadujú niektoré programy koreňových certifikátov na zaradenie do svojich dôveryhodných skladov (napr. Mozilla).
Napriek tomu, ak používate TLS na interné záležitosti, pravdepodobne nechcete dôverovať týmto verejným certifikačným autoritám viac, ako musíte. Ak tak urobíte, pravdepodobne otvoríte dvere NSA a ďalším subjektom. Akceptujete skutočnosť, že vaša bezpečnosť závisí od disciplíny a svedomitosti viac ako 100 ďalších organizácií. Možno je vám to jedno, ale spravodlivo vás varujeme.
Federácia
Aby to bolo ešte horšie, webové spoliehajúce sa strany PKI (RP) dôverujú každej certifikačnej autorite vo svojom úložisku dôvery, aby podpísala certifikáty pre akéhokoľvek účastníka. Výsledkom je, že celková bezpečnosť webového PKI je len taká dobrá, ako je najmenej bezpečná CA webového PKI. Útok DigiNotar z roku 2011 ukázal tento problém: v rámci útoku bol podvodne vydaný certifikát pre stránku google.com. Tomuto certifikátu dôverovali hlavné webové prehliadače a operačné systémy napriek tomu, že spoločnosť Google nemala žiadny vzťah so spoločnosťou DigiNotar. Ďalšie desiatky podvodných certifikátov boli vydané pre spoločnosti ako Yahoo!, Mozilla a The Tor Project. Koreňové certifikáty DigiNotar boli nakoniec odstránené z hlavných dôveryhodných obchodov, ale takmer určite už bolo spôsobených veľa škôd.
Nedávno bola spoločnosť Sennheiser upozornená na to, že do dôveryhodných obchodov nainštalovala koreňový certifikát s vlastným podpisom spolu so svojou aplikáciou HeadSetup a potom vložila príslušný súkromný kľúč do konfigurácie aplikácie. Tento súkromný kľúč môže ktokoľvek extrahovať a použiť na vydanie certifikátu pre akúkoľvek doménu. Každý počítač, ktorý má certifikát Sennheiser vo svojom úložisku dôveryhodnosti, by týmto podvodným certifikátom dôveroval. To úplne podkopáva protokol TLS. Ups.
Existuje niekoľko zmierňujúcich mechanizmov, ktoré môžu pomôcť znížiť tieto riziká. Autorizácia certifikačných autorít (CAA) umožňuje obmedziť, ktoré certifikačné autority môžu vydávať certifikáty pre vašu doménu pomocou špeciálneho záznamu DNS. Transparentnosť certifikátov (Certificate Transparency, CT) (RFC 6962) nariaďuje certifikačným autoritám, aby každý certifikát, ktorý vydajú, predložili nestrannému pozorovateľovi, ktorý vedie verejný denník certifikátov, aby bolo možné odhaliť podvodne vydané certifikáty. Kryptografický dôkaz o predložení CT je súčasťou vydaných certifikátov. Pripínanie verejných kľúčov HTTP (HPKP alebo len "pripínanie") umožňuje účastníkovi (webovej stránke) povedať RP (prehliadaču), aby akceptoval len určité verejné kľúče v certifikátoch pre konkrétnu doménu.
Problémom všetkých týchto vecí je podpora RP alebo jej nedostatok. Fórum CAB teraz nariaďuje kontroly CAA v prehliadačoch. Niektoré prehliadače majú aj určitú podporu CT a HPKP. V prípade iných RP (napr. väčšina implementácií štandardnej knižnice TLS) sa tieto veci takmer nikdy nevynucujú. Tento problém sa bude opakovať: RP musia presadzovať veľa zásad certifikátov a RP sa málokedy dajú obťažovať. Ak RP nekontrolujú záznamy CAA a nevyžadujú dôkaz o predložení CT, tieto veci nemajú veľký význam.
V každom prípade, ak prevádzkujete vlastnú internú PKI, mali by ste udržiavať samostatné úložisko dôveryhodnosti pre interné veci. To znamená, že namiesto pridávania koreňových certifikátov do existujúceho systémového úložiska dôveryhodnosti nakonfigurujte interné požiadavky TLS tak, aby používali len vaše korene. Ak chcete zlepšiť internú federáciu (napr. chcete obmedziť, ktoré certifikáty môžu vaše interné certifikačné autority vydávať), môžete vyskúšať záznamy CAA a správne nakonfigurované RP. Možno si budete chcieť pozrieť aj SPIFFE, vyvíjajúce sa úsilie o štandardizáciu, ktoré rieši tento problém a množstvo ďalších problémov súvisiacich s internou PKI.
Čo je to certifikačná autorita
Veľa sme hovorili o certifikačných autoritách (CA), ale nedefinovali sme, čo to vlastne je. CA je dôveryhodný vydavateľ certifikátov. Podpisom certifikátu ručí za väzbu medzi verejným kľúčom a menom. V podstate je certifikačná autorita len ďalší certifikát a zodpovedajúci súkromný kľúč, ktorý sa používa na podpisovanie iných certifikátov.
Je zrejmé, že okolo týchto artefaktov musí byť zabalená určitá logika a proces. Certifikačná autorita musí zabezpečiť distribúciu svojho certifikátu v dôveryhodných úložiskách, prijímať a spracovávať žiadosti o certifikát a vydávať certifikáty účastníkom. CA, ktorá vystavuje vzdialene prístupné API na automatizáciu týchto vecí, sa nazýva online CA. CA s vlastným koreňovým certifikátom zahrnutým do dôveryhodných skladov sa nazýva koreňová CA.
Sprostredkovatelia, reťazce a zväzky
V základných požiadavkách CAB Forum sa stanovuje, že koreňový súkromný kľúč patriaci koreňovej CA webového PKI sa môže použiť na podpísanie certifikátu len vydaním priameho príkazu (pozri časť 4.3.1). Inými slovami, webové koreňové certifikačné autority PKI nemôžu automatizovane podpisovať certifikáty. Nemôžu byť online. To je problém pre akúkoľvek rozsiahlu prevádzku certifikačnej autority. Nie je možné, aby niekto ručne zadával príkaz do počítača na splnenie každej objednávky certifikátu.
Dôvodom tejto podmienky je bezpečnosť. Webové koreňové certifikáty PKI sú široko distribuované v dôveryhodných úložiskách a je ťažké ich zrušiť. Kompromitácia súkromného kľúča koreňovej certifikačnej autority by ovplyvnila doslova miliardy ľudí a zariadení. Najlepším postupom je preto uchovávať súkromné kľúče koreňovej certifikačnej autority offline, ideálne na nejakom špecializovanom hardvéri pripojenom k stroju so vzduchovou medzierkou, s dobrým fyzickým zabezpečením a s prísne dodržiavanými postupmi používania.
Rovnakými postupmi sa riadi aj mnoho interných PKI, hoci je to oveľa menej potrebné. Ak môžete automatizovať rotáciu koreňových certifikátov (napr. aktualizovať úložiská dôveryhodnosti pomocou nástrojov na správu konfigurácie alebo orchestráciu), môžete ľahko rotovať kompromitovaný koreňový kľúč. Ľudia sú takí posadnutí správou koreňového súkromného kľúča pre interné PKI, že to odďaľuje alebo zabraňuje internému nasadeniu PKI. Vaše poverovacie údaje koreňového účtu AWS sú prinajmenšom rovnako citlivé, ak nie viac. Ako spravujete tieto poverenia?
Aby bolo vydávanie certifikátov škálovateľné (t. j. aby bola možná automatizácia), keď koreňová certifikačná autorita nie je online, koreňový súkromný kľúč sa používa len zriedkavo na podpísanie niekoľkých medziľahlých certifikátov. Príslušné súkromné kľúče sprostredkovateľov používajú sprostredkovateľské CA (nazývané aj podriadené CA) na podpisovanie a vydávanie listových certifikátov účastníkom. Sprostredkovateľské certifikačné autority nie sú zvyčajne zahrnuté v dôveryhodných úložiskách, čo uľahčuje ich odvolanie a rotáciu, takže vydávanie certifikátov od sprostredkovateľskej certifikačnej autority je zvyčajne online a automatizované.
Tento zväzok certifikátov - listový, sprostredkovateľský, koreňový - tvorí reťaz (nazývanú reťaz certifikátov). List je podpísaný sprostredkovateľom, sprostredkovateľ je podpísaný koreňom a koreň podpisuje sám seba.
2018-12-11-cert-chain.jpg
Z technického hľadiska ide o ďalšie zjednodušenie. Nič vám nebráni vytvárať dlhšie reťazce a zložitejšie grafy (napr. krížovou certifikáciou). Vo všeobecnosti sa to však neodporúča, pretože sa to môže veľmi rýchlo skomplikovať. V každom prípade sú certifikáty koncových entít listovými uzlami tohto grafu. Odtiaľ pochádza názov "listový certifikát".
Pri konfigurácii účastníka (napr. webového servera, ako je Apache alebo Nginx alebo Linkerd alebo Envoy) budete zvyčajne musieť poskytnúť nielen listový certifikát, ale aj zväzok certifikátov, ktorý obsahuje medziprodukty. Niekedy sa tu používajú PKCS#7 a PKCS#12, pretože môžu obsahovať celý reťazec certifikátov. Častejšie sa reťazce certifikátov kódujú ako jednoduchá postupnosť objektov PEM oddelených riadkami. Niektoré veci očakávajú, že certifikáty budú zoradené od listu po koreň, iné veci očakávajú koreň po list a niektorým veciam je to jedno. Ďalšia nepríjemná nekonzistentnosť. Pomôže vám Google a Stack Overflow. Alebo pokus a omyl.
V každom prípade, tu je príklad:
$ cat server.crt
-----BEGIN CERTIFICATE-----
MIICFDCCAbmgAwIBAgIRANE187UXf5fn5TgXSq65CMQwCgYIKoZIzj0EAwIwHzEd
MBsGA1UEAxMUVGVzdCBJbnRlcm1lZGlhdGUgQ0EwHhcNMTgxMjA1MTc0OTQ0WhcN
MTgxMjA2MTc0OTQ0WjAUMRIwEAYDVQQDEwlsb2NhbGhvc3QwWTATBgcqhkjOPQIB
BggqhkjOPQMBBwNCAAQqE2VPZ+uS5q/XiZd6x6vZSKAYFM4xrYa/ANmXeZ/gh/n0
vhsmXIKNCg6vZh69FCbBMZdYEVOb7BRQIR8Q1qjGo4HgMIHdMA4GA1UdDwEB/wQE
AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwHQYDVR0OBBYEFHee
8N698LZWzJg6SQ9F6/gQBGkmMB8GA1UdIwQYMBaAFAZ0jCINuRtVd6ztucMf8Bun
D++sMBQGA1UdEQQNMAuCCWxvY2FsaG9zdDBWBgwrBgEEAYKkZMYoQAEERjBEAgEB
BBJtaWtlQHNtYWxsc3RlcC5jb20EK0lxOWItOEdEUWg1SmxZaUJwSTBBRW01eHN5
YzM0d0dNUkJWRXE4ck5pQzQwCgYIKoZIzj0EAwIDSQAwRgIhAPL4SgbHIbLwfRqO
HO3iTsozZsCuqA34HMaqXveiEie4AiEAhUjjb7vCGuPpTmn8HenA5hJplr+Ql8s1
d+SmYsT0jDU=
-----END CERTIFIKÁT-----
-----ZAČIATOK OSVEDČENIA-----
MIIBuzCCAWKgAwIBAgIRAKBv/7Xs6GPAK4Y8z4udSbswCgYIKoZIzj0EAwIwFzEV
MBMGA1UEAxMMVGVzdCBSb290IENBMB4XDTE4MTIwNTE3MzgzOFoXDTI4MTIwMjE3
MzgzOFowHzEdMBsGA1UEAxMUVGVzdCBJbnRlcm1lZGlhdGUgQ0EwWTATBgcqhkjO
PQIBBggqhkjOPQMBBwNCAAT8r2WCVhPGeh2J2EFdmdMQi5YhpMp3hyVZWu6XNDbn
xd8QBUNZTHqdsMKDtXoNfmhH//dwz78/kRnbka+acJQ9o4GGMIGDMA4GA1UdDwEB
/wQEAwIBpjAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwEgYDVR0TAQH/
BAgwBgEB/wIBADAdBgNVHQ4EFgQUBnSMIg25G1V3rO25wx/wG6cP76wwHwYDVR0j
BBgwFoAUcITNjk2XmInW+xfLJjMYVMG7fMswCgYIKoZIzj0EAwIDRwAwRAIgTCgI
BRvPAJZb+soYP0tnObqWdplmO+krWmHqCWtK8hcCIHS/es7GBEj3bmGMus+8n4Q1
x8YmK7ASLmSCffCTct9Y
-----END CERTIFIKÁT-----
Opäť otravné a barokové, ale nie raketová veda.
Overenie cesty k certifikátu
Keďže medziľahlé certifikáty nie sú zahrnuté v dôveryhodných úložiskách, musia sa distribuovať a overovať rovnako ako listové certifikáty. Tieto medziprodukty poskytujete pri konfigurácii účastníkov, ako je opísané vyššie. Odberatelia ich potom odovzdajú RP. Pri TLS sa to deje ako súčasť handshake, ktorým sa nadväzuje spojenie TLS. Keď účastník posiela svoj certifikát spoliehajúcej sa strane, obsahuje všetky sprostredkovateľov potrebné na reťazenie až k dôveryhodnému koreňovému serveru. Spoliehajúca sa strana overuje certifikáty kmeňových a sprostredkovateľských certifikátov v procese, ktorý sa nazýva overovanie cesty certifikátu.
2018-12-11-cert-path-validation.jpg
Celý algoritmus overovania cesty certifikátu je zložitý. Zahŕňa kontrolu vypršania platnosti certifikátov, stavu odvolania, rôznych politík certifikátov, obmedzení používania kľúčov a množstva ďalších vecí. Správna implementácia tohto algoritmu zo strany PKI RP je absolútne kľúčová. Ľudia šokujúco bežne vypínajú overovanie cesty certifikátu (napr. odovzdaním príznaku -k do príkazu curl). Nerobte to.
Nevypínajte overovanie cesty k certifikátu. Nie je také ťažké urobiť správne TLS a overovanie cesty certifikátu je súčasťou TLS, ktorá vykonáva overovanie. Ľudia niekedy tvrdia, že kanál je stále šifrovaný, takže na tom nezáleží. To nie je pravda. Záleží na tom. Šifrovanie bez overovania je celkom bezcenné. Je to ako slepá spovednica: vaša konverzácia je súkromná, ale netušíte, kto je na druhej strane opony. Lenže toto nie je kostol, ale internet. Takže nevypínajte overovanie cesty certifikátu.
Životný cyklus kľúča a certifikátu
Predtým, ako budete môcť používať certifikát s protokolom, ako je TLS, musíte zistiť, ako ho získať od certifikačnej autority. Abstraktne ide o celkom jednoduchý proces: účastník, ktorý chce certifikát, vygeneruje kľúčový pár a predloží žiadosť certifikačnej autorite. Certifikačná autorita sa uistí, že meno, ktoré bude v certifikáte uvedené, je správne, a ak je, podpíše a vráti certifikát.
Platnosť certifikátov vyprší a vtedy im už RP nedôveruje. Ak stále používate certifikát, ktorého platnosť čoskoro vyprší, musíte ho obnoviť a rotovať. Ak chcete, aby RP prestali dôverovať certifikátu pred uplynutím jeho platnosti, môžete ho (niekedy) zrušiť.
Podobne ako väčšina PKI je aj tento jednoduchý proces klamlivo zložitý. V detailoch sú ukryté dva najťažšie problémy v informatike: zneplatnenie vyrovnávacej pamäte a pomenovanie vecí. Napriek tomu je to všetko dosť jednoduché na pochopenie, keď pochopíte, o čo ide.
Pomenovanie vecí
V minulosti sa v X.509 na pomenovanie subjektu certifikátu (účastníka) používali rozlišovacie mená (DN) X.500. DN zahŕňa bežné meno (pre mňa by to bolo "Mike Malone"). Môže obsahovať aj lokalitu, krajinu, organizáciu, organizačnú jednotku a celý rad ďalších nepodstatných vecí (pripomeňme, že tieto veci boli pôvodne určené pre digitálny telefónny zoznam). Nikto nerozumie rozlišovacím menám. Pre web nemajú zmysel. Vyhnite sa im. Ak ich používate, nech sú jednoduché. Nemusíte používať každé pole. V skutočnosti by ste nemali. Pravdepodobne vám stačí obyčajný názov a možno aj názov organizácie, ak hľadáte vzrušenie.
PKIX pôvodne špecifikoval, že názov hostiteľa DNS webovej lokality by mal byť viazaný na spoločný názov DN. Nedávno CAB Forum túto prax zrušilo a celé DN sa stalo voliteľným (pozri časti 7.1.4.2 základných požiadaviek). Namiesto toho sa podľa moderných osvedčených postupov na viazanie názvu v certifikáte využíva rozšírenie X.509 o alternatívny názov subjektu (SAN).
Bežne sa používajú štyri druhy SAN, pričom všetky viažu názvy, ktoré sú široko používané a zrozumiteľné: názvy domén (DNS), e-mailové adresy, IP adresy a URI. Tieto názvy by už mali byť jedinečné v kontextoch, ktoré nás zaujímajú, a celkom dobre sa vzťahujú na veci, ktoré chceme identifikovať: e-mailové adresy pre ľudí, názvy domén a adresy IP pre stroje a kód, URI, ak chcete byť fantazijní. Používajte siete SAN.
2018-12-11-inspect-san-dns.jpg
Všimnite si tiež, že webové PKI umožňuje viazať v certifikáte viacero mien a umožňuje používať v menách zástupné znaky. Certifikát môže mať viacero SAN a môže mať SAN ako *.smallstep.com. To je užitočné pre webové stránky, ktoré reagujú na viacero názvov (napr. smallstep.com a www.smallstep.com).
Generovanie párov kľúčov
Keď máme názov, musíme pred vytvorením certifikátu vygenerovať kľúčový pár. Pripomeňme si, že bezpečnosť PKI v rozhodujúcej miere závisí od jednoduchého invariantu: že jediným subjektom, ktorý pozná daný súkromný kľúč, je účastník uvedený v príslušnom certifikáte. Aby sme si boli istí, že tento invariant platí, najlepším postupom je, aby si účastník vygeneroval svoj vlastný pár kľúčov, takže je jedinou entitou, ktorá ho vždy pozná. Rozhodne sa vyhnite prenosu súkromného kľúča po sieti.
Budete sa musieť rozhodnúť, aký typ kľúča chcete použiť. To je úplne iný príspevok, ale tu je niekoľko stručných pokynov (k decembru 2018). Pomaly, ale stále prebieha prechod od kľúča RSA ku kľúčom s eliptickou krivkou (ECDSA alebo EdDSA). Ak sa rozhodnete používať kľúče RSA, nech majú aspoň 2048 bitov a neobťažujte sa s ničím väčším ako 4096 bitov. Ak použijete ECDSA, najlepšia je pravdepodobne krivka P-256 (secp256k1 alebo prime256v1 v openssl)... ak sa neobávate NSA, v tom prípade sa môžete rozhodnúť použiť niečo náročnejšie, napríklad EdDSA s krivkou25519 (hoci podpora týchto kľúčov nie je veľká).
Tu je príklad generovania páru kľúčov eliptickej krivky P-256 pomocou openssl:
-genkey -out k.prv: openssl ecparam -name prime256v1 -genkey -out k.prv
openssl ec -in k.prv -pubout -out k.pub
Tu je príklad generovania rovnakého druhu kľúčového páru pomocou kroku:
step crypto keypair --kty EC --curve P-256 k.pub k.prv
Môžete to urobiť aj programovo a nikdy nedovoliť, aby sa vaše súkromné kľúče dotkli disku.
Vyberte si svoj jed.
Vydávanie
Keď má účastník meno a pár kľúčov, ďalším krokom je získanie listového certifikátu od certifikačnej autority. CA bude chcieť overiť (dokázať) dve veci:
Verejný kľúč, ktorý má byť viazaný v certifikáte, je verejným kľúčom účastníka (t. j. účastník pozná zodpovedajúci súkromný kľúč).
meno, ktoré má byť uvedené v certifikáte, je meno účastníka
Prvá podmienka sa zvyčajne dosahuje jednoduchým technickým mechanizmom: žiadosťou o podpísanie certifikátu. Druhý spôsob je ťažší. Abstraktne sa tento proces nazýva preukazovanie identity alebo registrácia.
Žiadosti o podpísanie certifikátu
Na vyžiadanie certifikátu predkladá účastník žiadosť o podpísanie certifikátu (CSR) certifikačnej autorite. CSR je ďalšia štruktúra ASN.1 definovaná v PKCS#10.
Podobne ako certifikát je CSR dátová štruktúra, ktorá obsahuje verejný kľúč, meno a podpis. Podpisuje sa sám pomocou súkromného kľúča, ktorý zodpovedá verejnému kľúču v CSR. Tento podpis dokazuje, že ten, kto vytvoril CSR, pozná súkromný kľúč. Umožňuje tiež, aby sa CSR kopíroval a posúval bez možnosti modifikácie nejakým zásahom.
CSR obsahuje veľa možností na špecifikáciu podrobností certifikátu. V praxi certifikačné autority väčšinu týchto údajov ignorujú. Namiesto toho väčšina certifikačných autorít používa šablónu alebo poskytuje administratívne rozhranie na zber týchto informácií.
Kľúčový pár môžete vygenerovať a CSR vytvoriť pomocou kroku v jednom príkaze takto:
step certificate create --csr test.smallstep.com test.csr test.key
OpenSSL je super výkonný, ale oveľa otravnejší.
Overenie totožnosti
Keď certifikačná autorita dostane CSR a overí jeho podpis, ďalšia vec, ktorú musí urobiť, je zistiť, či meno, ktoré má byť viazané v certifikáte, je skutočne správne meno účastníka. To je zložité. Zmyslom certifikátov je umožniť RP overiť predplatiteľov, ale ako má CA overiť predplatiteľa pred vydaním certifikátu?
Odpoveď znie: záleží na tom. Pre webové PKI existujú tri druhy certifikátov a najväčšie rozdiely sú v spôsobe identifikácie účastníkov a druhu použitého preukazovania totožnosti. Sú to: certifikáty s overením domény (DV), certifikáty s overením organizácie (OV) a certifikáty s rozšíreným overením (EV).
Certifikáty DV sa viažu na názov DNS a vydávajú sa na základe preukázania kontroly nad názvom domény. Preukázanie zvyčajne prebieha prostredníctvom jednoduchého obradu, ako je odoslanie potvrdzujúceho e-mailu administratívnemu kontaktu uvedenému v záznamoch WHOIS. Protokol ACME, ktorý pôvodne vyvinula a používa spoločnosť Let's Encrypt, zlepšuje tento proces lepšou automatizáciou: namiesto overovania e-mailom vydáva certifikačná autorita ACME výzvu, ktorú musí účastník vyplniť, aby preukázal, že kontroluje doménu. Časť špecifikácie ACME týkajúca sa výziev je bodom rozšírenia, ale bežné výzvy zahŕňajú podanie náhodného čísla na danej adrese URL (výzva HTTP) a umiestnenie náhodného čísla do záznamu TXT DNS (výzva DNS).
Certifikáty OV a EV vychádzajú z certifikátov DV a obsahujú názov a sídlo organizácie, ktorá vlastní viazaný názov domény. Spájajú certifikát nielen s názvom domény, ale aj s právnickou osobou, ktorá ho ovláda. Proces overovania certifikátov OV nie je u rôznych certifikačných autorít konzistentný. Na vyriešenie tohto problému zaviedlo CAB Forum certifikáty EV. Obsahujú rovnaké základné informácie, ale nariaďujú prísne požiadavky na overenie (preukázanie totožnosti). Proces EV môže trvať dni alebo týždne a môže zahŕňať vyhľadávanie vo verejných registroch a osvedčenia (na papieri) podpísané vedúcimi pracovníkmi spoločnosti (perom). Po tom všetkom sa pri návšteve webovej lokality, ktorá používa EV certifikát, v niektorých prehliadačoch zobrazí názov organizácie v paneli URL. Mimo tohto obmedzeného použitia v prehliadačoch sa certifikáty EV vo veľkej miere nevyužívajú ani nevyžadujú zo strany spoliehajúcich sa webových PKI.
2018-12-11-github-ev.jpg
V podstate každý webový PKI RP vyžaduje len zabezpečenie úrovne DV, založené na "dôkaze" kontroly domény. Je dôležité zvážiť, čo presne certifikát DV vlastne dokazuje. Má dokazovať, že subjekt, ktorý žiada o certifikát, vlastní príslušnú doménu. V skutočnosti dokazuje, že v určitom časovom okamihu bol subjekt, ktorý žiada o certifikát, schopný prečítať e-mail alebo nakonfigurovať DNS alebo doručiť tajomstvo prostredníctvom protokolu HTTP. Základné zabezpečenie systémov DNS, elektronickej pošty a BGP, na ktoré sa tieto procesy spoliehajú, nie je veľké. Útoky na túto infraštruktúru sa vyskytli so zámerom získať podvodné certifikáty.
Pre internú infraštruktúru PKI môžete na preukázanie identity použiť ľubovoľný proces. Pravdepodobne to môžete urobiť lepšie, ako sa spoliehať na DNS alebo e-mail tak, ako to robí webový PKI. Na prvý pohľad sa to môže zdať ťažké, ale v skutočnosti to tak nie je. Môžete využiť existujúcu dôveryhodnú infraštruktúru: čokoľvek, čo používate na poskytovanie svojich vecí, by malo byť schopné aj merať a potvrdzovať identitu toho, čo sa poskytuje. Ak dôverujete Chefu, Puppetu, Ansible alebo Kubernetes, aby ste mohli umiestniť kód na servery, môžete im dôverovať aj v prípade osvedčovania identity. Ak používate nespracované AMI na AWS, môžete použiť doklady o identite inštancií (GCP a Azure majú podobnú funkciu).
Vaša provisioningová infraštruktúra musí mať určitú predstavu o identite, aby ste mohli umiestniť správny kód na správne miesto a spustiť veci. A musíte jej dôverovať. Tieto znalosti a dôveru môžete využiť na konfiguráciu dôveryhodných úložísk RP a zavádzanie účastníkov do interného PKI. Jediné, čo musíte urobiť, je vymyslieť nejaký spôsob, ako vaša provisioningová infraštruktúra oznámi vašej CA identitu všetkého, čo sa spúšťa. Mimochodom, práve na vyplnenie tejto medzery boli navrhnuté krokové certifikáty.
Vypršanie platnosti
Platnosť certifikátov zvyčajne vyprší. Nie je to sama o sebe striktná požiadavka, ale takmer vždy je to pravda. Zahrnutie exspirácie do certifikátu je dôležité, pretože používanie certifikátov je rozčlenené: vo všeobecnosti neexistuje centrálna autorita, ktorá by bola dotazovaná, keď je certifikát overovaný RP. Bez dátumu vypršania platnosti by certifikáty boli dôveryhodné navždy. Pre bezpečnosť platí pravidlo, že s blížiacou sa večnosťou sa pravdepodobnosť kompromitácie poverenia blíži k 100 %. Platnosť certifikátov teda vyprší.
Certifikáty X.509 obsahujú najmä obdobie platnosti: vydané v čase, nie pred časom a nie po čase. Čas beží dopredu, nakoniec uplynie čas nie po a certifikát zanikne. Táto zdanlivo neškodná nevyhnutnosť má niekoľko dôležitých jemností.
Po prvé, nič nebráni tomu, aby konkrétny RP omylom (alebo zlým návrhom) prijal certifikát, ktorého platnosť vypršala. Opäť platí, že používanie certifikátov je rozčlenené. Je na každom RP, aby skontroloval, či platnosť certifikátu vypršala, a niekedy sa pomýli. To sa môže stať, ak váš kód závisí od systémových hodín, ktoré nie sú správne synchronizované. Bežným scenárom je systém, ktorého hodiny sú resetované na unixovú epochu, ktorá nedôveruje žiadnym certifikátom, pretože si myslí, že je 1. január 1970 - oveľa skôr ako čas not before na akomkoľvek nedávno vydanom certifikáte. Uistite sa teda, že sú vaše hodiny synchronizované!
Na strane účastníka je potrebné po vypršaní platnosti certifikátu správne zaobchádzať s materiálom súkromného kľúča. Ak sa dvojica kľúčov používala na podpisovanie/overovanie (napr. pomocou TLS), budete chcieť súkromný kľúč odstrániť, keď už nebude potrebný. Ponechávanie podpisového kľúča je zbytočným bezpečnostným rizikom: nie je dobrý na nič iné ako na podvodné podpisy. Ak však bol váš pár kľúčov použitý na šifrovanie, situácia je iná. Súkromný kľúč si budete musieť ponechať, kým budú pod ním zašifrované údaje. Ak vám niekedy niekto povedal, aby ste nepoužívali rovnaký pár kľúčov na podpisovanie a šifrovanie, toto je hlavný dôvod. Používanie rovnakého kľúča na podpisovanie a šifrovanie znemožňuje implementáciu osvedčených postupov správy životného cyklu kľúča, keď súkromný kľúč už nie je potrebný na podpisovanie: núti vás to uchovávať podpisovacie kľúče dlhšie, ako je potrebné, ak sú stále potrebné na dešifrovanie vecí.
Obnovenie
Ak stále používate certifikát, ktorého platnosť čoskoro vyprší, budete ho chcieť obnoviť skôr, ako sa tak stane. V skutočnosti neexistuje žiadny štandardný proces obnovy pre webové PKI - neexistuje žiadny formálny spôsob, ako predĺžiť obdobie platnosti certifikátu. Namiesto toho stačí nahradiť certifikát, ktorého platnosť vyprší, novým. Proces obnovenia je teda rovnaký ako proces vydania: vygenerujte a predložte CSR a splňte všetky povinnosti týkajúce sa preukázania totožnosti.
V prípade interného PKI to môžeme urobiť lepšie. Najjednoduchšie je použiť na obnovu starý certifikát s protokolom, ako je vzájomný TLS. Certifikačná autorita môže overiť klientsky certifikát predložený účastníkom, opätovne ho podpísať s predĺženou platnosťou a ako odpoveď vrátiť nový certifikát. Vďaka tomu je automatizovaná obnova veľmi jednoduchá a stále núti predplatiteľov k pravidelnej kontrole u centrálnej autority. Tento proces checkin môžete použiť na jednoduché vybudovanie zariadení na monitorovanie a odvolávanie.
V oboch prípadoch je najťažšie jednoducho pamätať na obnovenie certifikátov pred uplynutím ich platnosti. Takmer každému, kto spravuje certifikáty pre verejné webové stránky, sa už stalo, že jeho platnosť nečakane vypršala, čo spôsobilo takúto chybu. Moja najlepšia rada je: ak niečo bolí, robte to viac. Používajte certifikáty s krátkou životnosťou. To vás prinúti zlepšiť svoje procesy a zautomatizovať tento problém. Služba Let's Encrypt uľahčuje automatizáciu a vydáva 90-dňové certifikáty, čo je pre webové PKI celkom dobré. Pre interné PKI by ste mali pravdepodobne použiť ešte kratšiu dobu: dvadsaťštyri hodín alebo menej. Sú tu určité problémy s implementáciou - rotácia certifikátov bez zásahu môže byť trochu zložitá - ale stojí to za námahu.
Rýchly tip: na kontrolu času platnosti certifikátu z príkazového riadku môžete použiť krok:
certifikátu: step certificate inspect cert.pem --format json | jq .validity.end
step certificate inspect https://smallstep.com --format json | jq .validity.end
Je to maličkosť, ale ak to skombinujete s prenosom zóny DNS v malom skripte bash, môžete získať slušné monitorovanie okolo vypršania platnosti certifikátov pre všetky vaše domény, ktoré pomôže zachytiť problémy skôr, ako sa stanú výpadkami.
Zrušenie platnosti
Ak je súkromný kľúč kompromitovaný alebo certifikát už jednoducho nie je potrebný, možno ho budete chcieť zrušiť. To znamená, že ho možno budete chcieť aktívne označiť ako neplatný, aby mu RP prestali dôverovať okamžite, ešte pred vypršaním jeho platnosti. Zrušenie certifikátov X.509 je veľký problém. Podobne ako pri vypršaní platnosti, aj pri odvolaní je zodpovednosť na RP. Na rozdiel od vypršania platnosti nemôže byť stav odvolania zakódovaný v certifikáte. RP musí určiť stav odvolania certifikátu prostredníctvom nejakého mimopásmového procesu. Ak to nie je výslovne nakonfigurované, väčšina webových PKI TLS RP sa tým nezaoberá. Inými slovami, v predvolenom nastavení väčšina implementácií TLS s radosťou akceptuje odvolané certifikáty.
V prípade interných PKI je trendom akceptovať túto skutočnosť a používať pasívne odvolávanie. To znamená vydávanie certifikátov, ktorých platnosť vyprší dostatočne rýchlo na to, aby odvolanie nebolo potrebné. Ak chcete certifikát "odvolať", jednoducho zakážete jeho obnovenie a počkáte, kým vyprší jeho platnosť. Aby to fungovalo, musíte používať certifikáty s krátkou životnosťou. Ako krátke? To závisí od vášho modelu hrozieb (tak hovoria odborníci na bezpečnosť - Ž(ツ)/Ž). Dvadsaťštyri hodín je celkom typické, ale aj oveľa kratšie vypršanie platnosti, napríklad päť minút. Ak príliš skrátite dobu životnosti, nastanú zjavné problémy týkajúce sa škálovateľnosti a dostupnosti: každé obnovenie si vyžaduje interakciu s online certifikačnou autoritou, takže infraštruktúra vašej certifikačnej autority by mala byť škálovateľná a vysoko dostupná. Pri skracovaní životnosti certifikátov nezabudnite synchronizovať všetky hodiny, inak budete mať zle.
V prípade webu a iných scenárov, kde pasívne odvolávanie nebude fungovať, by ste sa mali v prvom rade zastaviť a prehodnotiť pasívne odvolávanie. Ak naozaj musíte mať odvolanie, máte dve možnosti:
Zoznamy odvolaných certifikátov (CRL)
protokol OCSP (Online Certificate Signing Protocol)
Zoznamy CRL sú definované spolu s miliónom ďalších vecí v dokumente RFC 5280. Je to jednoducho podpísaný zoznam sériových čísel identifikujúcich zrušené certifikáty. Zoznam sa doručuje z distribučného miesta CRL: adresy URL, ktorá je súčasťou certifikátu. Očakáva sa, že spoliehajúce sa strany si stiahnu tento zoznam a budú sa ho pýtať na stav zrušenia vždy, keď budú overovať certifikát. Existujú tu niektoré zjavné problémy: Zoznamy CRL môžu byť veľké a distribučné miesta môžu vypadnúť. Ak RP vôbec kontrolujú zoznamy CRL, budú odpoveď z distribučného miesta vo veľkej miere ukladať do vyrovnávacej pamäte a synchronizovať len pravidelne. Na webe sa CRL často ukladajú do vyrovnávacej pamäte na celé dni. Ak bude šírenie CRL trvať tak dlho, môžete rovno použiť pasívne odvolanie. Bežne sa tiež stáva, že RP neotvoria certifikát -- neprijmú ho, ak je distribučné miesto CRL nefunkčné. Môže to byť bezpečnostný problém: môžete RP oklamať, aby prijal odvolaný certifikát tým, že vykonáte útok odopretia služby na distribučný bod CRL.
Aj keď používate zoznamy CRL, mali by ste zvážiť používanie certifikátov s krátkou životnosťou, aby ste znížili veľkosť zoznamu CRL. Zoznam CRL musí obsahovať sériové čísla len pre certifikáty, ktoré sú odvolané a ktorých platnosť ešte nevypršala. Ak majú vaše certifikáty kratšiu životnosť, vaše zoznamy CRL budú kratšie.
Ak sa vám nepáči CRL, vašou ďalšou možnosťou je OCSP, ktorý umožňuje RP požiadať OCSP respondér o sériové číslo certifikátu, aby získal stav odvolania konkrétneho certifikátu. Podobne ako distribučné miesto CRL je adresa URL respondéra OCSP súčasťou certifikátu. OCSP znie dobre (a zjavne), ale má svoje vlastné problémy. Vyvoláva vážne problémy s ochranou súkromia pre webové PKI: odpovedajúci server OCSP môže vidieť, aké stránky navštevujem na základe kontrol stavu certifikátu, ktoré som odoslal. Okrem toho zvyšuje réžiu každého spojenia TLS: na kontrolu stavu odvolania sa musí vykonať ďalšia požiadavka. Podobne ako v prípade CRL, mnohé RP (vrátane prehliadačov) zlyhávajú pri otváraní a predpokladajú, že certifikát je platný, ak je odpovedajúci server OCSP nefunkčný alebo vráti chybu.
OCSP stapling je variant OCSP, ktorý má tieto problémy odstrániť. Namiesto toho, aby spoliehajúca sa strana zasiahla respondér OCSP, urobí to účastník, ktorý vlastní certifikát. Odpoveďou OCSP je podpísané potvrdenie s krátkou platnosťou, v ktorom sa uvádza, že certifikát nie je zrušený. Toto potvrdenie je zahrnuté do podania TLS ("pripevnené" k certifikátu) medzi odberateľom a RP. RP tak získava primerane aktuálny stav odvolania bez toho, aby sa musel priamo pýtať respondéra OCSP. Predplatiteľ môže podpísanú odpoveď OCSP použiť viackrát, kým nevyprší jej platnosť. Tým sa zníži zaťaženie respondéra, väčšinou sa odstránia výkonnostné problémy a vyrieši sa otázka ochrany súkromia pri OCSP. Toto všetko je však tak trochu rube goldberg zariadenie. Ak účastníci narážajú na nejakú autoritu, aby získali krátkodobé podpísané potvrdenie o tom, že platnosť certifikátu nevypršala, prečo neodstrániť sprostredkovateľa: jednoducho používať krátkodobé certifikáty.
Používanie certifikátov
Keď sme sa už zbavili všetkých týchto súvislostí, skutočné používanie certifikátov je naozaj jednoduché. Ukážeme si to na protokole TLS, ale väčšina ostatných použití je dosť podobná.
Ak chcete nakonfigurovať spoliehajúcu sa stranu PKI, poviete jej, ktoré koreňové certifikáty má používať
Ak chcete nakonfigurovať účastníka PKI, poviete mu, ktorý certifikát a súkromný kľúč má použiť (alebo mu poviete, ako si má sám vygenerovať vlastný kľúčový pár a vymeniť CSR pre certifikát).
Je celkom bežné, že jedna entita (kód, zariadenie, server atď.) môže byť zároveň RP aj účastníkom. Takéto entity budú musieť byť nakonfigurované s koreňovým certifikátom (certifikátmi) a certifikátom a súkromným kľúčom. Napokon, v prípade webového PKI sú správne koreňové certifikáty vo všeobecnosti predvolene dôveryhodné, takže túto časť môžete preskočiť.
Tu je kompletný príklad demonštrujúci vydanie certifikátu, distribúciu koreňového certifikátu a konfiguráciu klienta TLS (RP) a servera (účastníka):
2018-12-11-step-ca-certificate-flow.jpg
Dúfame, že to ilustruje, aké jednoduché môže byť správne a správne interné PKI a TLS. Nemusíte používať self-signed certifikáty ani robiť nebezpečné veci, ako je vypnutie overovania cesty k certifikátu (odovzdanie -k do curl).
Takmer každý klient a server TLS prijíma tieto isté parametre. Takmer všetky sa vyhýbajú časti životného cyklu kľúčov a certifikátov: všeobecne predpokladajú, že certifikáty sa zázračne objavujú na disku, rotujú atď. To je tá ťažká časť. Opäť platí, že ak to potrebujete, robí to krok certifikátov.
Zhrnutie
Kryptografia s verejným kľúčom umožňuje počítačom "vidieť" naprieč sieťami. Ak mám verejný kľúč, môžem "vidieť", že máte zodpovedajúci súkromný kľúč, ale nemôžem ho sám použiť. Ak nemám váš verejný kľúč, môžu mi pomôcť certifikáty. Certifikáty viažu verejné kľúče na meno vlastníka príslušného súkromného kľúča. Sú ako vodičské preukazy pre počítače a kódy. Certifikačné autority (CA) podpisujú certifikáty so svojimi súkromnými kľúčmi, čím ručia za tieto väzby. Sú ako dopravný úrad. Ak ste jediný, kto vyzerá ako vy, a ukážete mi vodičský preukaz z DMV, ktorému dôverujem, môžem zistiť vaše meno. Ak ste jediný, kto pozná súkromný kľúč, a pošlete mi certifikát od certifikačnej autority, ktorej dôverujem, môžem zistiť vaše meno.
V reálnom svete je väčšina certifikátov X.509 v3. Sú definované pomocou ASN.1 a zvyčajne sú serializované ako DER kódovaný PEM. Zodpovedajúce súkromné kľúče sú zvyčajne reprezentované ako objekty PKCS#8, tiež serializované ako DER kódovaný v PEM. Ak používate Javu alebo Microsoft, môžete naraziť na obálkové formáty PKCS#7 a PKCS#12. Je tu veľa historickej batožiny, ktorá môže spôsobiť, že práca s týmito vecami je dosť frustrujúca, ale je to skôr nepríjemné ako zložité.
Infraštruktúra verejných kľúčov je súhrnný termín pre všetky veci, ktoré musíte vytvoriť a odsúhlasiť, aby ste mohli efektívne používať verejné kľúče: názvy, typy kľúčov, certifikáty, certifikačné autority, cronové úlohy, knižnice atď. Webová PKI je verejná PKI, ktorú štandardne používajú webové prehliadače a takmer všetko ostatné, čo používa TLS. Webové certifikačné autority PKI sú dôveryhodné, ale nie dôveryhodné. Interná PKI je vaša vlastná PKI, ktorú si vytvoríte a spustíte sami. Chcete ju mať, pretože webová PKI nebola navrhnutá pre prípady interného použitia a pretože interná PKI sa ľahšie automatizuje, ľahšie škáluje a poskytuje vám väčšiu kontrolu nad mnohými dôležitými vecami, ako je pomenovanie a životnosť certifikátov. Webový PKI používajte na verejné veci. Na interné veci (napr. na používanie TLS namiesto VPN) používajte vlastný interný PKI. Smallstep Certificate Manager umožňuje pomerne jednoduché vytvorenie interného PKI.
Ak chcete získať certifikát, musíte veci pomenovať a vygenerovať kľúče. Na názvy použite siete SAN: DNS SAN pre kód a stroje, EMAIL SAN pre ľudí. Ak tieto siete nefungujú, použite siete URI SAN. Typ kľúča je veľká téma, ktorá je väčšinou nedôležitá: môžete meniť typy kľúčov a skutočné šifrovanie nebude najslabším článkom vašej PKI. Ak chcete získať certifikát od certifikačnej autority, predložíte CSR a preukážete svoju totožnosť. Používajte certifikáty s krátkou životnosťou a pasívnym odvolaním. Automatizujte obnovovanie certifikátov. Nevypínajte overovanie cesty certifikátu.
Pamätajte: certifikáty a PKI viažu mená na verejné kľúče. Zvyšok sú len detaily.
Mike Malone pracuje na zjednodušení zabezpečenia infraštruktúry so spoločnosťou Smallstep už šesť rokov ako generálny riaditeľ a zakladateľ. Pred spoločnosťou Smallstep bol Mike technickým riaditeľom v spoločnosti Betable. V srdci je nadšencom distribuovaných systémov, tvorcom open source riešení, ktoré riešia veľké problémy v oblasti produkčnej identity, a publikujúcim autorom výskumov vo svete politiky kybernetickej bezpečnosti.