Provoz po HTTPS v produkci

Re:Provoz po HTTPS v produkci
« Odpověď #30 kdy: 15. 12. 2022, 11:40:35 »
Tak to je teda gól, certifikační autorita si podle pana Jirsáka nevydává svoje vlastní kořenové certifikáty. Kdybyste se alespoň na ten jejich kořenový certifikát podíval, tak byste tam viděl, že Issuer je Internet Security Research Group, tedy Let's Encrypt. Stejně tak to má třeba DigiCert (Issuer: CN=DigiCert Global Root CA, zde máte dokonce Root CA v názvu)...
Vše X.509 certifikáty se dají rozdělit do dvou disjunktních skupin – certifikáty podepsané certifikační autoritou a self-signed certifikáty. To označení „self-signed certifikát“ vzniklo právě proto, aby existovalo jednoduché označení pro „certifikát nepodepsaný certifikační autoritou“.

Kořenový certifikát certifikační autority logicky nemůže být podepsaný certifikační autoritou, protože v době, kdy ten certifikát vzniká, neexistuje ještě ten certifikát certifikační autority (protože právě vzniká).

Možná vás mate to, že certifikační autoritu považujete za nějakou instituci. Ve skutečnosti se pojmem „certifikační autorita“ v tomhle kontextu myslí konkrétní certifikát (nebo certifikáty), jejichž veřejné klíče jsou někým považovány za veřejné klíče důvěryhodné certifikační autority. Protože třeba Let's Encrypt si může vydat kolik certifikátů chce, ale jako certifikační autorita vydává jenom ty certifikáty, které jsou (třeba zprostředkovaně) podepsané buď čtyřkilovým RSA klíčem LE začínajícím na 00:ad:e8:24:73:f4:14:37:f3:9b:9e:2b:57:28:1c nebo 384bitovým EC klíčem LE začínajícím na 04:cd:9b:d5:9f:80:83:0a:ec:09:4a:f3:16:4a:3e.

V položce Issuer self-signed certifikátu jsou jen zkopírované položky ze Subject toho certifikátu – právě proto, že je self-signed, je tedy podepsaný sám sebou, tedy vydavatel je ten samý jako držitel certifikátu. Ovšem ten text nevypovídá vůbec o ničem, self-signed certifikátů, které budou mít v Issuer uvedeno „Internet Security Research Group“, vám klidně vyrobím sto. A dalších sto certifikátů může mít jako Issuer uvedeno „Root CA of Root CA of Root CA“, a stejně to nebude znamenat, že je to ten nejkořenovější kořenový certifikát na světě.

Upravujete si realitu, aby seděla k vašim argumentům.
Nikoli, popisuju realitu tak, jak se to doopravdy používá. Jaký je rozdíl mezi vlastní CA a self-signed certifikáty si dobře uvědomíte, až byste těch self-signed certifikátů vyrobil 150 a těch 150 certifikátů byste musel instalovat na všechna zařízení, která jim mají důvěřovat. A každý týden by vznikaly další self-signed certifikáty a vy byste je musel pořád distribuovat a instalovat. Pak by vám asi došlo, že jste měl raději vytvořit jednu certifikační autoritu, jejíž certifikát nainstalujete jednou.

Když už, tak certifikační autorita nepodepisuje certifikáty, ale na základě CSR (Certificate Signing Request) nebo obdobné žádosti vystavuje NOVÝ certifikát. Z CSR si bere pouze veřejný klíč a zbytek obvykle ignoruje. Ostatní informace pak do certifikátu doplňuje dle sebe a dle toho, co uvedete v nějakém doplňkovém formuláři.
Certifikační autorita podepisuje certifikáty. Technicky není CSR vůbec potřeba, když si budete provozovat vlastní CA, klidně můžete certifikáty vydávat jen na základě dodaného veřejného klíče, nebo dokonce můžete klíčovou dvojici vyrobit sám a předat držiteli certifikátu jeho certifikát i s privátním klíčem. Z hlediska bezpečnosti to není dobré, ale technicky to jde.

Důležitý je ale právě ten podpis autority na certifikátu, kterým autorita stvrzuje, že údaje na certifikátu jsou pravdivé. Podpis zároveň zajistí neměnnost těch údajů (abyste jim opravdu mohl věřit), a díky podpisu můžete hledat, zda ten certifikát podepsala nějaká autorita, které důvěřujete. Tím, že je vše standardizované, dá se to algoritmizovat – takže dodáte seznam certifikátů certifikačních autorit, kterým důvěřujete, dodáte ověřovaný certifikát a případně s ním dodané  mezilehlé certifikáty, a algoritmus rozhodne, zda ten dodaný certifikát byl podepsán (i zprostředkovaně) autoritou, které důvěřujete.


Re:Provoz po HTTPS v produkci
« Odpověď #31 kdy: 15. 12. 2022, 12:48:01 »
Tak to je teda gól, certifikační autorita si podle pana Jirsáka nevydává svoje vlastní kořenové certifikáty. Kdybyste se alespoň na ten jejich kořenový certifikát podíval, tak byste tam viděl, že Issuer je Internet Security Research Group, tedy Let's Encrypt. Stejně tak to má třeba DigiCert (Issuer: CN=DigiCert Global Root CA, zde máte dokonce Root CA v názvu)...

Je uplne sumak ako sa nazve certifikat, k tomu aby bol platny CA certifikat, ci uz korenovy alebo medzilahly, tak musi mat nastavene rozsirenia:
Kód: [Vybrat]
basicConstraints=critical,CA:TRUE
keyUsage=critical,keyCertSign, cRLSign
Dalej aby bol ako CA certifikat uznany za platny, musi byt zaradeny medzi znamimi autoritami systemu (alebo browseru, ak ten nepouziva systemove ulozisko).

Kdezto certifikat pre web server bude mat nastavene:
Kód: [Vybrat]
keyUsage=critical,digitalSignature, keyEncipherment
K tomu aby bol uznany za platny, ak je self-signed, staci aby bol zaradeny medzi platnymi certifikatmi systemu (alebo browseru).

« Poslední změna: 15. 12. 2022, 12:49:53 od Death Walker »

vpn22

Re:Provoz po HTTPS v produkci
« Odpověď #32 kdy: 15. 12. 2022, 19:48:01 »
Franta, Pepa a Lojza si založí klub leteckých modelářů. Franta je předseda a je pro všechny důvěryhodný (CA). Rozhodnou se vydat si členské průkazy (certifikáty). Aby byly průkazy důvěryhodné, musí všechny podepsat předseda. Když je podepisuje Pepovi a Lojzovi, tak je podepisuje z titulu předsedy, ale když ho podepisuje sám sobě, tak už ho z titulu předsedy nepodepisuje? To se snažíte říct?

Re:Provoz po HTTPS v produkci
« Odpověď #33 kdy: 15. 12. 2022, 20:17:05 »
Franta, Pepa a Lojza si založí klub leteckých modelářů. Franta je předseda a je pro všechny důvěryhodný (CA). Rozhodnou se vydat si členské průkazy (certifikáty). Aby byly průkazy důvěryhodné, musí všechny podepsat předseda. Když je podepisuje Pepovi a Lojzovi, tak je podepisuje z titulu předsedy, ale když ho podepisuje sám sobě, tak už ho z titulu předsedy nepodepisuje? To se snažíte říct?
To, co jste popsal, odpovídá tomu, když si Let's Encrypt vystaví certifikát třeba pro svůj web letsencrypt.org – a když se podíváte, opravdu je certifikát certifikát s předmětem CN = lencr.org, který má v SAN i letsencrypt.org, vydaný (zprostředkovaně) autoritou LE, tj. ověřovací cesta vede až k ISRG Root X1. To je ale jiný certifikát, můžete si porovnat jejich veřejné klíče. Existují tedy dva certifikáty (ve skutečnosti jich je podstatně víc), jeden je certifikát certifikační autority Let's Encrypt (který je self-signed, ale zároveň ke stejnému klíči existuje křížově podepsaný certifikát od „Digital Signature Trust Co.“, ale to radši neřešte), druhý je certifikát webu letsencrypt.org, který je shodou okolností podepsaný certifikační autoritou Let's Encrypt.

Když to popíšeme na tom vašem příkladu, bavíme se o situaci, kdy Franta ještě není předseda. Může si klidně sám sobě podepsat papír, že je předseda a může podepisovat průkazky, ale ten papír nebude mít žádnou váhu, nikdo mu nebude věřit. Teprve když to odhlasují Pepa a Lojza, začnou mu oni dva věřit, že je opravdu předseda a budou věřit jím podepsaným průkazkám. To je jako když si vyrobíte svou soukromou CA. A teprve až se ten zápis, že Frantu zvolili předsedou, objeví ve veřejném rejstříku, začnou tomu věřit i ostatní a začnou uznávat průkazky podepsané Frantou.

A proti tomu stojí situace, když si budete vydávat self-signed certifikáty. To je jako kdyby si Franta podepsal průkazku sám a oběhl všechny okolo, že tohle je platná průkazka a mají jí věřit. Pak si Pepa podepíše sám svou průkazku a zase oběhne všechny okolo, že mají té průkazce věřit. A pak si podepíše svou průkazku i Lojza, a zase oběhne všechny okolo, že mají té průkazce věřit.

Pokud vás problematika certifikátů a PKI (public key infrastructure) zajímá, doporučuju např. knížku Velký průvodce protokoly TCP/IP: Bezpečnost. Na Rootu na ní kdysi vyšla recenze: recenze. Sice je starší, ale tam popsané principy jsou stále platné.


Re:Provoz po HTTPS v produkci
« Odpověď #34 kdy: 15. 12. 2022, 20:27:07 »
A teprve až se ten zápis, že Frantu zvolili předsedou, objeví ve veřejném rejstříku, začnou tomu věřit i ostatní a začnou uznávat průkazky podepsané Frantou.
Zapomněl jsem napsat, že tohle odpovídá situaci, když se certifikát certifikační autority dostane na seznamy všeobecně uznávaných certifikačních autorit.


Re:Provoz po HTTPS v produkci
« Odpověď #35 kdy: 16. 12. 2022, 00:47:28 »
Franta, Pepa a Lojza si založí klub leteckých modelářů. Franta je předseda a je pro všechny důvěryhodný (CA). Rozhodnou se vydat si členské průkazy (certifikáty). Aby byly průkazy důvěryhodné, musí všechny podepsat předseda. Když je podepisuje Pepovi a Lojzovi, tak je podepisuje z titulu předsedy, ale když ho podepisuje sám sobě, tak už ho z titulu předsedy nepodepisuje? To se snažíte říct?

změnil jsi definiční obor, tvoje přirovnání je špatně. Důležité je, co podepisuje, self-sign podepisuje sebe svým podpisem a pak tenhle dokument přikládá ke každému dalšímu podpisu.

Proč neuznáš, že se pleteš a píšeš tady nesmysly?



Re:Provoz po HTTPS v produkci
« Odpověď #36 kdy: 16. 12. 2022, 09:34:25 »
Franta, Pepa a Lojza si založí klub leteckých modelářů. Franta je předseda a je pro všechny důvěryhodný (CA). Rozhodnou se vydat si členské průkazy (certifikáty). Aby byly průkazy důvěryhodné, musí všechny podepsat předseda. Když je podepisuje Pepovi a Lojzovi, tak je podepisuje z titulu předsedy, ale když ho podepisuje sám sobě, tak už ho z titulu předsedy nepodepisuje? To se snažíte říct?

Certifikat ale nie je clensky preukaz. Primarnym ucelom certifikatu je overit ze podpisovatel ma vo vlastnictve privatny kluc ktorym podpisuje. To aby certifikat overoval identitu konkretneho subjektu nie je nutne, iba je mozne k do certifikatu tieto udaje vlozit.

Primarny obsah certifikatu je verejny kluc, aby bolo mozne overit podpis vytvoreny privatnym klucom, ktory tvori par s uverejnenym klucom. Dalsia nutna vec ktoru musi obsahovat je sposob pouzitia privatneho kluca. V zavislosti na sposobe pouzitia su povinne dalsie udaje, ktore su ale pre samotny princip fungovania certifikatu irelevantne. A nakoniec je cela tato datova struktura podpisana. Moze byt podpisana vlastnym privatnym klucom (self-signed) alebo klucom nejakej autority. Ci je ten ktory podpis validny sa rozhodne na zaklade zoznamu validnych privatnych klucov, ktory je reprezentovany certifikatmi k tymto klucom.

Ak to chcete vysvetlit na takto stupidnom priklade, tak ten priklad musite dat do kontextu (integracia v skolstve bol fakt blby napad). Cize aby vas priklad bol pouzitelny, tak by sme museli predpokladat ze kazdy uzivatel podpisuje perom s unikatnym atramentom. Pritom nemusi vlasnit len jeden atrament. Certifikat potom obsahuje vzorku podla ktorej je mozne jednoznacne identifikovat atrament. To ze moze obsahovat naviac identifikacne udaje vlastnika atramentu nie je podmienka. Takze Franta(nemusi to byt nutne Franta, moze delegovat na niekoho ineho) podpise vzorky atramentu na preukazkach atramentom urcenym len k tomuto ucelu, vratane tej svojej. Takto vytvorene preukazy ale primarne overuju pravost atramentu, ak overuju sucastne identitu vlastnika atramentu, tak je to udaj naviac.

Re:Provoz po HTTPS v produkci
« Odpověď #37 kdy: 16. 12. 2022, 10:03:50 »
A k povodnemu dotazu:

Problem dnes je rozsirenost Let's Encrypt a jeho certifikatov s kratkou zivotnostou, kedy nestaci raz za rok, dva.. manualne nahodit novy certifikat co je 5 minutova robota. Nie, dnes sa musi investovat cas a peniaze do vyvoja automatizovaneho riesenia ktore musi riesit challenge, uschovu, reload certifikatov a v spranvom case cely proces opakovat.
To automatizovane riesenie nie je nutne znova vyvijat. Mozete pouzit napr. certbot. Pripadne ine riesenie, ktorych je internet uz plny. Alebo mozete ist starou cestou a vynalozit radovo viac zdrojov na certifikat od nejakej CA.

Ak si vezmem ze 99% pripadov je http challenge, tak nie je mozne vypnut port 80, cize aplikacia musi bezat na dvoch portoch a odlisit ci ide o LE na http a podla toho presmerovat na https verziu alebo spracovat LE challenge.
Vypinat 80 port nie je najstastnejsi napad, je dobre tam dat aspom redirect na port 443. K tomu do aplikacie siahat nemusite, da sa to osetrit uz na urovni http serveru.

Dalsie riesenie je skryt aplikaciu za vlastnu lokalnu proxinu(traefik, nginx, haproxy..), takze aplikacia sa odbremeni od https a dvoch spojeni, co je super, lenze zase ta proxy treaz musi routovat 99.99999% dat na prazdno, a zrat hw, len kvoli LE ktore pride raz tri mesiace. Ale zase to riesi sama uz, takze aplikacia samotna sa o nic starat nemusi. Ale zase na produkcii to prinasa dalsiu starost - namiesto jednej binarky a jej konfiguracie je vyzadovana dalsia binarka pre tuto proxinu a konfiguracia pre nu a dodatocne znalosti pre spavnu konfiguraciu a prevadzku.

Toto ma zmysel len v niektorych pripadoch.
  • Koli vykonu potrebujete skalovat a tym padom to uz mate rozbehane
  • Aplikacia je black box a povodny vyvojar nezvestny
  • Aplikacia je tak sprasena ze ina moznost nie je

Tretia moznost je pouzit externu proxinu typu CloudFlare ktora kompletne odbremeni od riesenia HTTPS za cenu ze prevadzka zo serveru na cloudflare je nesifrovana(prakticky mitm) a teda cloudflare ma plny pristup k datam uzivatelov a taktiez pod kontrolou komplet cele DNS. A ked sa rozhodne ze sa im nepacite, tak vas vypnu a mate mozno aj niekolko-hodinovy vypadok. Takze taktiez nie idealna situacia.
Preco by mal byt nesifrovany? Ked sa snazite ohnut sluzbu ktora je urcena k niecomu inemu, tak musite ratat aj s rovnakom na ohybak...

Preto ma zaujima co dnes fici ako najpouzivanejsi postup?
Aplikacia o https nic vediet nemusi. K tomuto je urceny http server. Location http serveru je smerovana na adresar kde si certbot vytvara challenge. Aplikacia o tejto location nema mat ani len tusenie. Ak pouzivate hosting tretej strany, tak je samozrejme ze toto nastavenie dostanete default. Ak si server spravujete sam, tak by ste to mal zvladnut, je to jedna z tych trivialnejsich zalezitosti ohladne bezpecnej spravy serveru.

Re:Provoz po HTTPS v produkci
« Odpověď #38 kdy: 18. 12. 2022, 11:48:22 »
Co je dnes "mainstream" sposob nasadenia https na webove aplikacie?

Problem dnes je rozsirenost Let's Encrypt a jeho certifikatov s kratkou zivotnostou, kedy nestaci raz za rok, dva.. manualne nahodit novy certifikat co je 5 minutova robota. Nie, dnes sa musi investovat cas a peniaze do vyvoja automatizovaneho riesenia ktore musi riesit challenge, uschovu, reload certifikatov a v spranvom case cely proces opakovat.

Ak si vezmem ze 99% pripadov je http challenge, tak nie je mozne vypnut port 80, cize aplikacia musi bezat na dvoch portoch a odlisit ci ide o LE na http a podla toho presmerovat na https verziu alebo spracovat LE challenge.
https://hub.docker.com/u/nginxproxy
Backend pak bezi na jedinem portu (jakemkoliv) pochopitelne. Bezudrzbove, staci jedno repo a v nem jednoduchy docker-compose.yml
Děkuji za možnost editace příspěvku.