S localhostem stejně prohlížeče zacházejí jinak i v mnoha dalších případech. Stejně tak zacházejí jinak s vlastními certifikačními autoritami. Pokud už se chcete testování na lokálním počítači co nejvíc přiblížit produkci, je lepší použít skutečnou doménu a k ní si nechat vystavit certifikát od Let's Encrypt.
Proboha nastudujte si alespoň nějaké základy, než o tom začnete diskutovat. Neexistují žádné „klíče domény“. Existují certifikáty vydané na doménové jméno (nebo jména), případně na žolíkové jméno. Doménových jmen si můžete ve své doméně vyrobit mraky.
Takže ve firmě, která dělá weby a má svou hlavní doménu example.com
, se vytvoří jméno třeba localhost.dev.example.com
, nasměruje se na ::1 (nebo na 127.0.0.1) a vystaví se na tu doménu certifikát od Let's Encrypt (ověřením přes DNS). Certifikát s privátním klíčem se rozdá vývojářům. Samozřejmě je potřeba to zautomatizovat, nebudete to dělat každé tři měsíce ručně. Betaverzi projektu pak můžete vystavit třeba na projekt.beta.example.com
, to už můžete třeba i vystavit do internetu, aby se tam dostal i zákazník. A zase k tomu vystavíte certifikát od LE.
Triviální, že? No, a když máte koupenou tu jednu hlavní doménu, můžete si pod ní vytvářet poddomény jak je libo. Omezen jste jenom celkovou délkou DNS názvu – 255 oktetů, a délkou jednoho labelu – 63 oktetů. No a pokud byste to chtěl opravdu dát na jinou doménu, než je hlavní doména firmy, můžete si pořídit třeba vyvojari-example.com
a ty vývojové domény vytvářet tam.
Pri nadvazovani spojenia cez HTTPS nepotrebujete privatny kluc?
Ne, při navazování HTTPS spojení (HTTPS spojení navazuje klient – prohlížeč) fakt nepotřebujete privátní klíč. Když napíšete do prohlížeče https://www.root.cz, váš prohlížeč naváže HTTPS spojení se serverem Rootu, a privátní klíč k certifikátu používanému Rootem určitě nemáte.
(Prohlížeč se může vůči serveru autentizovat privátním klíčem uživatele. Ale na veřejném webu se to prakticky nepoužívá. A prohlížeč privátní klíč stejně neposílá při navazování spojení, ale až na výzvu serveru.)
Vy jste ale asi myslel privátní klíč k serverovému certifikátu. Ocituji znovu část komentáře, na který jste reagoval:
Certifikát s privátním klíčem se rozdá vývojářům.
S privátním klíčem. Vidíte to? Privátní klíč se rozdá vývojářům. Myslíte, že se jim dává proto, že ho nepotřebují?
Fakt si JA mam nastudovat ako to funguje?
Ano, vy. Pořád se ptáte na triviální věci a ještě špatně. Takže se přestaňte pokoušet mne na něčem nechytat. Přečtěte si znovu mé komentáře, všechno v nich je napsané správně. Pokud se vám bude zdát, že je v tom komentáři něco špatně, přečtěte si to znova – a dokola pořád tak dlouho, dokud to nepochopíte. Ne že bych měl všechny komentáře bezchybné. Ale vy zatím stále rozporujete tvrzení, která v mých komentářích nejsou. Nikde jsem nepsal o cizí doméně, to jste si vymyslel vy. Nikde jsem nepsal o tom, že vývojáři nebudou mít privátní klíč od té vývojářské domény, to jste si vy vymyslel.
18. 11. 2020, 18:43 editováno autorem komentáře
Pane Jirsaku:
> je lepší použít skutečnou doménu a k ní si nechat vystavit certifikát
Takze neviem ako casto vyvijate pre VLASTNU domenu ja take nerobim, preto som sa pytal ako si predstavujete a este k tomu jednoducho?
Aj keby to bolo pre vlastnu domenu tak si neviem predstavit ze mi admin poskytne privatny kluc pre MOJ SERVER beziaci na MOJEJ masine pre localhost. Takze to je asi jediny pripad kedy by sa to mozno dalo ak by som admina nejako sialene ukecal ale asi aj tak nie pretoze potom mozem vystavovat 'svoje' stranky. Pre nikoho normalneho to nie je priechodne nie to napriklad pre banku alebo inu financnu instituciu.
Ak nahodou dochadza k nejakym problemom HTTP/HTTPS tak to mate zle napisane. Opat ja som s takym problem uz roky nestretol ak pouzivate nejake zauzivane standardy takze sa mozete na na cele HTTPS pri vyvoji rovno vykaslat.
A ANO privatny kluc potrebujete mat na svojej vyvojarskej masine nainstalovany.
> Nikde jsem nepsal o tom, že vývojáři nebudou mít privátní klíč od té vývojářské domény, to jste si vy vymyslel.
Nie to som si nevymyslel, to ste napisal vy:
> Neexistují žádné „klíče domény“.
Takze existuju kluce k certifikatu a ten privatny kluc potrebujete.
Vyvíjet pro banku, která má doménu www.banka.comm ještě neznamená, že na vývojovém stroji použiju také doménu www.banka.comm, může to být www.bankahankatest.infoo . Používat HTTPS je rozhodně dobrý nápad i ve vývojovém prostředí, jelikož po síti nelítají nezašifrovaná data a z pohledu aplikace, browserů apod. to prostředí má chování stejné či podobné jako na produkci.
Fakt si myslite ze vam banka zariadi taky certifikat pre vasu masinu? Myslite si ze ludia poznaju ako to funguje? Je na konci firmat.cz? JE. Je tam zeleny zamocek? JE.
Sedíte před tím počítačem vy? ANO. Napálil jste jenom sám sebe? ANO.
Pořád zkoušíte dělat hlupáky z ostatních, a pořád děláte hlupáka jenom ze sebe. Už tady padlo asi milionkrát, že ten doménový záznam bude směřovat na 127.0.0.1. Už i vy byste mohl pochopit, že když máte privátní klíč k doménovému jméno, jehož A
záznam ukazuje na 127.0.0.1 a žádné jiné záznamy k tomu jménu nejsou, můžete ubližovat akorát sám sobě.
Taky už tu asi milionkrát zaznělo, že to banka samozřejmě nemusí provozovat na subdoméně své hlavní domény, ale může si klidně pořídit nějakou jinou doménu jenom pro vývoj.
Ale ne, vy trváte na tom, že ze sebe musíte dělat hlupáka.
Takze neviem ako casto vyvijate pre VLASTNU domenu ja take nerobim, preto som sa pytal ako si predstavujete a este k tomu jednoducho?
Zase se ptáte úplně hloupě. Vy jste se chtěl zeptat, jestli se bude prohlížeč chovat nějak jinak, když vývojáři budou vyvíjet na doméně firma-x.projekt.vyvojova-firma.cz</cz> a výsledný web pak poběží na doméně
firma-x.cz. Odpověď zní: nebude, prohlížeč se bude v obou případech chovat úplně stejně.
Aj keby to bolo pre vlastnu domenu tak si neviem predstavit ze mi admin poskytne privatny kluc pre MOJ SERVER beziaci na MOJEJ masine pre localhost.
Dítě v první třídě v září si také nedovede představit, jak může někdo sčítat čísla. A vidíte, za pár měsíců se to naučí. Takže z toho, že si to nedovedete vy představit, si nic nedělejte. Až si nastudujete základy, představit si to dokážete.
Navíc administrátor nemusí poskytovat žádný privátní klíč – stačí, když nechá ověřit doménu. A nebo pokud byste dělal admina vy, stačí, když oddelegujete subdoménu na DNS server, který budou mít ve správě ti vývojáři. A kdyby i to byl problém, domény se dnes dají pořídit velmi levně.
Takze to je asi jediny pripad kedy by sa to mozno dalo ak by som admina nejako sialene ukecal ale asi aj tak nie pretoze potom mozem vystavovat 'svoje' stranky.
Ano, na localhostu toho hodně vystavíte… Když ten admin nebude mamlas, může si nechat DNS ve správě, vytvoří to hostname localhost.example.com
, nasměruje ho na ::1 a 127.0.0.1 a má hotovo. Pro většinu případů to bude stačit a zároveň tím má zajištěno, že nikdo nic do internetu nevystaví.
Tohle už jsem ale psal v druhém komentáři.
Pre nikoho normalneho to nie je priechodne nie to napriklad pre banku alebo inu financnu instituciu.
Když by to banka nechtěla provozovat nikde v rámci své hlavní domény, může si koupit nějakou doménu čistě pro vývoj. Doména stojí 200 Kč ročně, to by banku nemuselo položit.
Ale to už jsem také psal.
Ak nahodou dochadza k nejakym problemom HTTP/HTTPS tak to mate zle napisane.
Já jsem nepsal, že dochází k nějakým problémům HTTP/HTTPS. Psal jsem, jak to zařídit, když chcete při vývoji používat HTTPS.
Mimochodem, už se dostatečně ukázalo, že o problematice nevíte vůbec nic. Tak nepište, že je něco „zle napísané“, ale zeptejte se, jaké problémy s tím mohou nastat. Některá Web API – ta novější s dopadem na bezpečnost (třeba zjišťování polohy) – fungují jen v secure contextu. To znamená na webech s HTTPS, ale také na localhostu. localhost v tomto případě tedy nevadí, ale jiné interní domény bez HTTPS už ano. Ale pojďme dál. HTTP/2 prohlížeče implementují jenom v šifrované variantě. Takže když budete chtít ladit některé věci specifické pro HTTP/2 (třeba optimalizovat paralelní stahování nebo server push), potřebujete použít HTTPS. A než se patlat se self-signed certifikáty, to si radši nechám vystavit certifikát od LE. K tomu ale potřebuju veřejnou doménu.
Opat ja som s takym problem uz roky nestretol
No, já jsem se také už roky nepotkal s problémy při operaci srdce – ale pravděpodobně to bude dané tím, že jsem srdce nikdy neoperoval. Vy nevíte nic o doménách ani o certifikátech, takže asi nebude úplně relevantní, že jste se nesetkal s problémy ohledně HTTPS.
Nikde jsem nepsal o tom, že vývojáři nebudou mít privátní klíč od té vývojářské domény, to jste si vy vymyslel.
Nie to som si nevymyslel, to ste napisal vy:
> Neexistují žádné „klíče domény“.
Takze existuju kluce k certifikatu a ten privatny kluc potrebujete.
Porovnejte si ta dvě tučná slova. Připadají vám stejná? Mně ne. Takže netvrďte, že jsem něco napsal, když je to ve skutečnosti jenom vaše špatná interpretace textu, protože problematice vůbec nerozumíte.
Klíče domény existují v DNSSEC. Pokud se bavíme o HTTPS, existuje klíčová dvojice, soukromý a veřejný klíč. Veřejný klíč je součástí certifikát, a certifikát je vystavena na jedno nebo více doménových jmen, případně může být vystaven certifikát s žolíkem.
No, a pokud je doménové jméno localhost.example.com
nasměrované na loopback adresy, není problém na něj vystavit certifikát a privátní klíč k tomu certifikátu (ne k žádné doméně – na tom certifikátu klidně může být víc doménových jmen) nasdílet vývojářům.
Takze existuju kluce k certifikatu a ten privatny kluc potrebujete.
Jistě, pokud chcete komunikaci podepsat serverovým certifikátem, potřebujete privátní klíč k tomu certifikátu. V tom je právě vtip používání certifikátů. Jak jsem psal brzy po začátku diskusi, nastudujte si základní principy, pak vás nebudou takovéhle triviality překvapovat. Já jsem to v komentáři explicitně nepsal, protože jsem předpokládal, že každý, de se téhle diskuse chce zúčastnit, takovouhle samozřejmost ví.
Uz to teraz netahajte niekam inam. Vy ste povedali ze je jednoduche a bezpecne nechat si vystavit certifikat k realnej domene kde sa bude aplikacia prevadzkovat. To je blbost. Teraz mi nevysvetlujte ako to funguje ked na zaciatku ste rovno tvrdili ze nepotrebujete privatny kluc ked sme zistili ze potrebujete. Mne nemusite vysvetlovat zaklady HTTPS.
Vy ste povedali ze je jednoduche a bezpecne nechat si vystavit certifikat k realnej domene kde sa bude aplikacia prevadzkovat.
Ne, to jsem netvrdil. Já jsem psal o reálné doméně, to „kde sa bude aplikacia prevadzkovat“ jste si doplnil vy. A protože jste hlupák, tak se v tom tady vrtáte, místo abyste zalezl do kouta a vtloukal si do hlavy, že příště si nebudete vymýšlet cizí komentáře.
na zaciatku ste rovno tvrdili ze nepotrebujete privatny kluc
Nic takového jsem netvrdil. Už jsem vám ukázal, kde jste udělal chybu. Ale protože jste hlupák, tu chybu opakujete.
Mne nemusite vysvetlovat zaklady HTTPS.
Když základy HTTPS nechápete, dává smysl pokusit se vám to vysvětlit. Bohužel se ukázalo, že máte problém s daleko základnějšími věcmi, třeba rozlišit, že „certifikát“ a „doména“ jsou dvě různá slova s různým významem. Takže vysvětlovat vám základy HTTPS je marné.
Abych to pochopil i já. Takže když chci nějaký intranet v korporaci, potřebuji privátní klíč k té subdoméně, který je zadarmo forever? Nemusím škemrat na finančním? Neberme v potaz, že TEĎ to LetsEncrypt zadarmo dělá. já se ptám z principu, protože u http jsem to měl zaručeno by-design, tak jestli prostě postačí i v budoucnu jen požádat ITS o další subdoménu v DNS a mám vystaráno.
Ptám se fakt ze zvědavosti, protože většinou to tak funguje, že uvnitř se rozjede nějaká HTTP služba pro nějaké oddělení, nějaký interní monitoring služeb (bez vstupu, jen output) a pokud by používali FF s implicitně vynucenou HTTPS, tak se mi to nezdá jako pružné řešení.
Ale třeba to pro neveřejné IP nebude vynucené, tak se omlouvám za pesimismus :-)
Obvykle sa to aj tak riesi predradenym reverse proxy ktory robi HTTPS termination. Potom sa na vasu masinu natlaci certifikat firmy aby vam to hlasilo zeleny zamocek. Aplikacie za reverse proxy bezia v reale uz na HTTP. Tam aj vznika v reale najviac problem ak sa napriklad pri generovani liniek spoliehate na informacie vasho requestu. Obvykle je treba citat hlavicky X-Forwarded-*.
No a este k tomu self signed certifikatu firmy. Ten vam do stroja natlacia aj tak aby mohli smirovat vasu zakryptovanu trafiku takze ked ho tam uz mate mozte ho pouzivat aj na vyvoj.
Pavel Tavoda 23:41: Gratuluju, sice jste vůbec neodpověděl na dotaz, zato jste nenapsal ani jednu větu, která by byla fakticky správně.
Nepokoušejte se nikomu nic vysvětlovat a raději běžte bádat nad tím, koho můžete poškodit, když máte privátní klíč od certifikátu, který obsahuje jediné DNS jméno, přičemž v DNS má to jméno jediný záznam typu A
s hodnotou 127.0.0.1.
Pavel Tavoda, 10:25: Ano, distribuci privátních klíčů se bráníte správně – vám by opravdu nikdo žádné privátní klíče svěřovat neměl. Naopak svěřit svéprávným lidem nějakou testovací doménu není žádný problém. Hlavně jim v tom nemůžete nijak zabránit. Veřejnou doménu dneska pořídíte za 200 Kč na rok, provoz DNS serveru máte v ceně. Nic jiného nepotřebujete. Takže pokud by vývojáři měli neschopného admina, mohou se na ty dvě stovky ročně složit. Za ty ušetřené nervy, že by vám nemuseli vysvětlovat fungování TLS certifikátů, by to stálo.
Takže když chci nějaký intranet v korporaci, potřebuji privátní klíč k té subdoméně, který je zadarmo forever?
Bavíme se tu o HTTPS, takže žádný „privátní klíč k subdoméně“ neexistuje, to je jen výmysl Pavla Tavody. Když prohlížeč komunikuje s HTTPS serverem, předloží server prohlížeči certifikát vystavený certifikační autoritou, a komunikaci podepíše privátním klíčem, který přísluší k tomu certifikátu. Tím prokáže, že privátní klíč vlastní. Na certifikátu jsou uvedené domény, pro které byl certifikát vystaven – a prohlížeč zkontroluje, že požadované jméno serveru (třeba www.root.cz) je na tom certifikátu uvedeno.
Certifikát si můžete vyrobit sám, ale pak musíte přesvědčit prohlížeč (každý, který tu stránku zkusí otevřít), že ten certifikát je důvěryhodný. Nebo vám ten certifikát může vystavit nějaká nedůvěryhodná certifikační autorita (třeba firemní) – ale pak máte stejný problém, musíte přesvědčit prohlížeč, že té autoritě nebo tomu certifikátu má věřit. Na firemních počítačích to třeba u prohlížečů, které berou certifikáty ze systému, může být zařízené firemní správou. Jenže také mohou prohlásit, že Firefox nepodporují, že nepodporují mobilní zařízení, když se přihlásíte do VPN ze soukromého počítače taky tam ten certifikát nebudete mít…
Nebo použijete certifikát nějaké důvěryhodné certifikační autority, tedy takové, jejíž certifikáty jsou v prohlížečích zařazené mezi důvěryhodné. Taková autorita vám ale vystaví certifikát jedině tehdy, pokud jí prokážete, že příslušnou doménu vlastníte (nebo aspoň že dokážete vystavit soubor na webový server, na který směruje ta doména, případně přijímat e-maily pro tu doménu). Dneska takový certifikát můžete získat zadarmo od Let's Encrypt, ale samozřejmě vám nikdo nezaručí, že bude navěky existovat nějaká certifikační autorita, která bude mít štědré sponzory a která tudíž bude vydávat certifikáty zdarma.
Je to privatny kluc k tomu certifikatu ktory je priradeny prislusnej subdomene, ci na co vam je ten certifikat? Takze ked sa ma vasa masina tvarit ako iny server musi mat aj ten privatny kluc, bez neho to nejde.
A potom je to zneuzitelne. Lebo developeri maju pristup a na svojich masinach nainstalovany privatny kluc k nejakej dev subdomene co v pripade uniku predstauje bezpecnostne riziko pretoze sa utocnik moze tvarit ako ta subdomena. Co si bezny uzivatel ani nevsimne pripadne uz bol napad ze to browsre budu priamo skryvat.
A nasmerovat nieco na localhost v DNS servri je tiez blbost pretoze DNS hijact sa este nikdy nestal, ze .... pockajte naposledy iba minuly tyzden sa riesil unos alza.cz. Takze nedajte sa oklamat podkutym odbornikom p. Jirsakom a nerozdavajte developerom ziadne realne subdomenove certifikaty a privatne klucne k 'neskodnym' subdomenam.
Pavel Tavoda, 0:35: Aha, takže už to není privátní klíč k doméně, už je to privátní klíč k certifikátu. Pomalu to začínáte měnit. Zkuste pokročit dál a zjistit, že neexistuje žádný „certifikát přiřazený k subdoméně“. Už jsem vám tu několikrát psal, že certifikát obsahuje seznam jmen (v případě HTTPS seznam doménových jmen). Ta jména mohou být z různých domén, klidně z různých TLD.
Takze ked sa ma vasa masina tvarit ako iny server musi mat aj ten privatny kluc, bez neho to nejde.
Tady ale nikdo nechce, aby se můj počítač tvářil jako jiný server.
Lebo developeri maju pristup a na svojich masinach nainstalovany privatny kluc k nejakej dev subdomene co v pripade uniku predstauje bezpecnostne riziko pretoze sa utocnik moze tvarit ako ta subdomena.
Ne, to nepředstavuje bezpečnostní riziko. To, že má nějaká osoba přístup k privátnímu klíči od nějakého certifikátu, je naprosto běžná věc – u běžných webů je privátní klíč uložen prostě jako soubor na disku, takže k němu mají přístup určitě alespoň všichni správci daného web serveru a také root daného serveru. A rozhodně neplatí, že by administrátoři s tím privátním klíčem zacházeli paušálně nějak lépe, než vývojáři – vždyť i vy jste pravděpodobně administrátor, a melete tu jeden nesmysl za druhým.
Další věc je to, že úplně ignorujete to, o jakou se jedná doménu. Pokud to bude doména používaná jenom pro vývoj (vždyť to stojí pár korun), nemůžete zneužít ani případný uniklý privátní klíč, protože tu doménu žádný uživatel nebude používat.
A nasmerovat nieco na localhost v DNS servri je tiez blbost pretoze DNS hijact sa este nikdy nestal, ze ....
Není to blbost. To, jestli se někomu podaří unést doménu, vůbec nezávisí na tom, zda ten záznam směřuje na loopback adresu nebo na jinou IP adresu.
pockajte naposledy iba minuly tyzden sa riesil unos alza.cz
Zase vedle. Neřešil se únos domény, ale „únos“ IP adres – ve skutečnosti podvržené adresy odesílatele paketu.
Takze nedajte sa oklamat podkutym odbornikom p. Jirsakom a nerozdavajte developerom ziadne realne subdomenove certifikaty a privatne klucne k 'neskodnym' subdomenam.
Naštěstí neexistují žádné „subdoménové certifikáty“ ani (ve světě TLS) „privátní klíče k subdoménám“. Privátní klíče k subdoménám existují v DNSSEC, ale o tom také nic nevíte.
Sice máte plnou hubu keců, jak je to nebezpečné, ale nedokážete pochopit jednoduchý komentář. Opakovaně používáte špatné termíny (kdyby to bylo jednou, dá se to pochopit, že jste to napsal jen tak rychle; ale když vás na to upozorním, a vy to příště napíšete jinak a podobně nesmyslně, je jasné, že tomu nerozumíte a ten váš terminologický guláš je jenom obrazem guláše, který v tom máte). A opakovaně tvrdíte, jak je to nebezpečné, ale nebyl jste schopen uvést jediný příklad, jak by někdo mohl zneužít toho, co jsem uváděl – tedy vývojářská doména s DNS záznamem směrovaným na loopback.
Tak když máte pocit, že nejste hlupák, konečně to předveďte. Dejme to mu, že má Komerční banka (která má internetové bankovnictví na doméně mojebanka.cz a informančí web na kb.cz) své in-house vývojáře. Tito vývojáři používají pro vývoj doménové jméno localhost.kbibdev.cz
. V DNS je ke jménu localhost.kbibdev.cz
jediný záznam a to typu A
, který směřuje na 127.0.0.1. Doména kbibdev.cz
je podepsaná pomocí DNSSEC. Vývojáři mají na svých stanicích privátní klíč od certifikátu vystaveného na jméno localhost.kbibdev.cz
, certifikát byl vystaven autoritou Let's Encrypt. Jak bude vypadat ten útok, o kterém neustále píšete?
Děkuji. Sice to moc nepobírám kvůli té hádce, ale tak nějak chápu, že je to trend (to HTTPS) a že s vaničkou vylili i dítě (intranetu). Nu, vypadá to konec hurástylům typu - rozjeďte interně HTTP server na týhle ajpině, lidi se tam budou připojovat, zda dva měsíce to stopnem, a protože jsme všichni na neveřejný, tak nevadí, že to někdo může odposlechnout, bo všeci kopů za jeden tým (a není reálně co ukrást).
GPO moc nepůjde, jak jste popsal trefně, v době HO (VPN) a BYOD je to prostě heterogenní prostředí. Prostě prohlížeč (konvenční) je primárně pro extranet a nějaký intranet je na okraji zájmu.
Jsem zvědavý, kdy s tím přijde Safari, protože tam GPO už vůbec nehrozí :-)
Arnold Schwanzenegger: Problém je v tom, že když povolíte HTTP pro intranet, povolíte ho všude. A nejjednodušší útok na HTTPS je ten, že uživatel použije HTTP. Takže jediný způsob, jak z toho ven, je přejít postupně všude na HTTPS, aby se mohla v prohlížečích podpora HTTP úplně vypnout.
Špatně jsou ty intranety na privátních adresách (jak IP, tak DNS). DNS bylo od začátku navrženo jako hierarchický systém, takže nikdy nebyl problém provozovat intranet na DNS názvu, který patří do toho jednoho globálního stromu (aniž by se ten název musel v celém internetu překládat). Vymýšlení lokálních domén zneužilo některé možnosti DNS – a teď nás to dobíhá. Čím dřív se těch lokálních domén zbavíme, tím lépe – mají jen samé nevýhody, žádnou výhodu.
Velmi jednoducho. Znovu narazam na vase povodne tvrdenie ze nie je treba privatny kluc ktory JE TREBA.
Utok samozrejme stazite cez DNSSEC ktory ale zdaleka nie je beznym standardom. Ostatne je uz uplne trivialne. To ze viete uniest domenu z nejakeho smeru neznamena ze viete uniest domenu z kazdeho smeru. V kazdom pripade je to potencionalne nebezpecny napad a developer ktoy si neviem pridat self signed certifikat do browsera asi neexistuje.
A este jedna vec, technicky sa ohanate tym ze kluc je k certikatu a nie k domene.
Tak aspoň k něčemu ta diskuse byla. Tuhle věc jste zdá se alespoň na chvíli pochopil.
Vo chvili ale ked si ale nechate ten certifikat priradit k domene
Nic jako „přiřazení certifikátu k doméně neexistuje“. Už jsem vám vysvětloval, že důvěryhodný certifikát pro TLS obsahuje seznam doménových jmen. Ta jména mohou být úplně odlišná, můžete mít v jednom certifikátu třeba example.com, example.net a pluto.mff.uk.cz. Co přesně by podle vás znamenalo, že byste si ten certifikát nechal přiřadit k doméně? K jaké doméně? Kým?
je privatny kluc toho certifikatu klucom tej domeny
Nikoli. V TLS neexistuje žádný klíč domény.
To je to co Let's encrypt robi. Urobi z vasho kluca kluc prislusnej domeny.
Nikoli. Ale jak už jsem psal, když nevíte, co je TLS certifikát a jak vypadá, nechápu, proč se pouštíte do takovéhle debaty.
Znovu narazam na vase povodne tvrdenie ze nie je treba privatny kluc
Já jsem nic takového netvrdil. Už jsem vám to psal několikrát. Když nechápete takhle jednoduchou věc, proč se snažíte diskutovat o bezpečnosti, což je o několik řádů složitější věc?
Ostatne je uz uplne trivialne.
To je jako když děcko ve školce vykládá o tom, jak je triviální pilotovat letadlo. Vždyť vy nedokážete pochopit ani jednoduchou českou větu.
V kazdom pripade je to potencionalne nebezpecny napad
Každý správce, který není úplný hlupák, si s tím dokáže poradit tak, aby to nebylo vůbec nebezpečné.
developer ktoy si neviem pridat self signed certifikat do browsera asi neexistuje
Nejde o to, že by takový vývojář neexistoval. I když kdybyste byl vývojář, byl byste žhavý kandidát na takového neumětela. Problém je v tom, že se self-signed certifikát chová v některých věcech jinak než certifikát vydaný uznávanou certifikační autoritou.
Nes.. si do huby, zaciatok diskusie bol:
> Ne, při navazování HTTPS spojení (HTTPS spojení navazuje klient – prohlížeč) fakt nepotřebujete privátní klíč.
Ja som napisal viac riadkov kodu nez ste vy v zivote precital.
Co je podla vas co robi Let's encrypt? Priraduje privatny kluc k domenam. TO JE TO CO ROBIA. Technikality naokolo sluzia iba k tomu aby sa neprezradzal privatny kluc a nejako sa dalo poziadat o ten podpis (cez certifikat). To je uz ale asi prilis alpha level pre pochopenie kedze ste zamotany do tych technikalit. To ze tych domen ku ktorym moze priradit ten privatny kluc (vsetky v certifikate) moze byt naraz viac nic nemeni na principe priradenia privatneho kluca k domene.
Nes.. si do huby, zaciatok diskusie bol:
> Ne, při navazování HTTPS spojení (HTTPS spojení navazuje klient – prohlížeč) fakt nepotřebujete privátní klíč.
Ne, to nebyl začátek diskuse. Ale když tak trváte na tom, že při navazování spojení s HTTPS serverem potřebuje prohlížeč privátní klíč, tak nám povězte, jaký privátní klíč použije váš prohlížeč při navazování spojení s https://www.root.cz, a kde ten privátní klíč vezme.
Co je podla vas co robi Let's encrypt? Priraduje privatny kluc k domenam. TO JE TO CO ROBIA.
Pomalu se blížíte. Ve skutečnosti Let'S Encrypt vystavuje certifikáty na doménová jména.
To ze tych domen ku ktorym moze priradit ten privatny kluc (vsetky v certifikate) moze byt naraz viac nic nemeni na principe priradenia privatneho kluca k domene.
Začněte tím, že si ujasníte rozdíl mezi doménou (třeba root.cz) a doménovým jménem (třeba www.root.cz). Doména může obsahovat spoustu jmen, doménové jméno je vždy právě jedno. Certifikáty se vydávají na doménová jména, ne na domény. S přimhouřením oka by se dalo o doméně mluvit u hvězdičkového certifikátu, ve skutečnosti je ale i hvězdičkový certifikát vydáván na sadu doménových jmen splňujících určité pravidlo.
Privátní klíč se nikam ani k ničemu nepřiřazuje. Privátní klíč se drží v tajnosti (proto je privátní) a nikdo jiný než oprávněný provozovatel daného doménového jména se k němu nesmí dostat.
Pro jedno doménové jméno může být (a v drtivé většině případů je) vydáno více certifikátů. Mohou být ke stejnému veřejnému klíči nebo k různým, od jedné autority nebo od více autorit. A naopak jeden veřejný klíč může být na více certifikátech (opět to není nic výjimečného).
Takže abych to shrnul. Máte problém s pochopením jednoduchých vět, dosazujete si do nich své vlastní hloupé nápady, a i když vás na to upozorním, opakujete ten vlastní nesmysl pořád dokola. Máte hokej v tom, jak fungují TLS certifikáty, nevíte, kdy se používá privátní klíč a kdy veřejný. O tom, jak fungují prohlížeče, nevíte vůbec nic. Pořád strašíte tím, jak je mé řešení nebezpečné, ale když jsem ho popsal a chtěl jsem od vás konkrétní popis možného útoku, nenapsal jste ani čárku.
Ta podobnost s vystupováním jistého prezidenta, který vyhrál volby, je zarážející.
Howgh.
19. 11. 2020, 10:58 editováno autorem komentáře
> jaký privátní klíč použije váš prohlížeč při navazování spojení
Bavili sme sa o tom ake je podla vas jednoduche si odsimulovat skutocnu domenu na svojom stroji.
Ste zahrabany v technikalitach a absolutne nechapete co sa vlastne deje. Kazdy kto podpisuje nejaky cudzi certifikat (nebavime sa o HTTPS) z pocinu svojho mena nieco potvrdzuje. Takze z pohladu Let's encrypt priraduje privatny kluc danej domene. Z pohladu osobneho certifikatu priraduje cloveka k danemu privatnemu klucu, ... to je ta uroven ktora vam unika. Ste zahrabany v technickych detailoch a snazite sa ma napratat do niecoho co som ja tiez nepovedal.
Takze na zaver
- Privatny kluc potrebujete
- Autority priraduju privatny kluc k niecomu skutocnemu (domena, clovek, ...)
- Je nebezpecne developerom distribuovat privatne kluce a certifikat k akelkolvek ostrej domene alebo subdomene lebo vieme ze za chvilu sa objavi na githube spolu s projektom kde si developer iba nevsimol ze to zabudol pridat do .gitignore
- Ste slusny demagog
Certifikační autority žádný privátní klíč nikam nepřiřazují. Privátní klíč je privátní od toho, že se nesmí dostat do ruky nikomu nepovolanému, ani certifikační autoritě. certifikační autorita pracuje vždy jen s veřejným klíčem žadatele o certifikát. Pořád si chcete hrát na odborníka, přitom nechápete ani tak základní věc, že privátní klíč nesmíte dát z ruky a certifikační autorita samozřejmě nemůže pracovat s vaším privátním klíčem.
Demagog jste vy. Já jsem nikdy nepsal, že server nepotřebuje privátní klíč. naopak vy píšete, že privátní klíč je potřeba při navazování spojení (spojení ale navazuje klient a ten samozřejmě serverový privátní klíč nesmí mít) nebo že privátní klíč někam přiřazuje certifikační autorita (k vašemu privátnímu klíči se ale nesmí dostat ani certifikační autorita). Nikdy jsem nepsal, že by vývojáři měli mít klíč k ostré doméně. Pořád akorát mlžíte a píšete nesmysly, protože problematice nerozumíte.
> certifikační autorita samozřejmě nemůže pracovat s vaším privátním klíčem
Ale ved som vam napisal ze vy nechapete tu uroven co vlastne certifikacna autorita principialne robi a ze technikalie v ktorych sa vy hrabete sluzia iba na to aby sa privatny kluc nemusel nikam distribuoovat. Citajte.
> Nikdy jsem nepsal, že by vývojáři měli mít klíč k ostré doméně
Ale pisal, pretoze to co vy chcete je REALNA OSTRA SUBDOMENA. Co pri skryvani subdomeny v URL ktore chce napriklad implementovat Chrome je navod na slusny disaster.
A ked nechapete ze odvtedy ako niekto priradi privatny kluc k vasej osobe (cez podpisany certifikat, co je technikalia) tak akykolvek pravny dokument podpisany tym privatnym klucom je platny a vymahatelny. Takto cez ten certifikat dochadza k priradeniu skutocnej osoby k tomu privatnemu klucu. To je to co sa skutocne deje a v pripade osobneho certifikatu dokonca sme uz v rovine pravnych nalezitosti. Presne to iste sa deje pri podpisovani certifikatu pre domenu, priraduje sa skutocna domena/organizacia k privatnemu klucu (cez certifikat co je ale iba technikalia ako to urobit a nemusi byt jedina). Ale vidim ze tento alfa level vam unika. To su tie mosty kde sa spaja svet skutocneho (clovek, organizacia) so svetom digitalnym.
Ale ved som vam napisal ze vy nechapete tu uroven co vlastne certifikacna autorita principialne robi a ze technikalie v ktorych sa vy hrabete sluzia iba na to aby sa privatny kluc nemusel nikam distribuoovat. Citajte.
Když nechápete, co certifikační autorita dělá, klidně vám to napíšu. Certifikační autorita ověří identitu osoby (u osobních certifikátů) nebo oprávnění k doménovému jménu (u TLS certifikátů). Následně vystaví certifikát (tj. podepíše ho svým vlastním soukromým klíčem), kterým stvrzuje, že vlastník privátního klíče příslušného k veřejnému klíči uvedenému v certifikátu je osoba identifikovaná v certifikátu (u osobního certifikátu) nebo oprávněný uživatel doménového jména (jmen) – u TLS certifikátu. Certifikát tedy obsahuje veřejný klíč (nikdy nemůže obsahovat privátní klíč – ten musí zůstat utajený), identifikační údaje a podpis certifikační autority. S privátním klíčem držitele certifikátu certifikační autorita nijak pracovat nesmí a pokud žadatel není úplné nemehlo, privátní klíč se k autoritě ani nedostane.
Vazbu mezi privátním klíčem a příslušným veřejným klíčem zajišťuje použitý kryptografický algoritmus, certifikační autorita s tím nemá nic společného. Ta řeší jen ten veřejný klíč a stejně jako všichni ostatní spoléhá na to, že privátní klíč k tomu veřejnému klíči je jenom jeden.
Ani veřejný klíč ani privátní klíč nejsou nijak přiřazené doméně ani doménovému názvu, a doména ani doménový název nejsou nijak přiřazené ani veřejnému ani privátnímu klíči. Když znáte doménové jméno, nedokážete žádným způsobem získat seznam všech certifikátů vystavených k tomu jménu, tedy ani veřejné klíče těch certifikátů (než přijdete s CT listem – certifikát, který si sám vystavím, na žádný CT list dávat nebudu, přesto bude existovat). Stejně tak když znáte veřejný klíč, nijak nezískáte seznam všech certifikátů, kde se ten klíč používá, tedy ani seznam doménových jmen uvedených na těch certifikátech.
Ale pisal, pretoze to co vy chcete je REALNA OSTRA SUBDOMENA.
Ne, já nic takového nechci. Opravdu je pro vás tak těžké takovou trivialitu pochopit?
A ked nechapete ze odvtedy ako niekto priradi privatny kluc k vasej osobe
Mám pro vás takovou mnemotechnickou pomůcku. Vždycky, když napíšete, že já něco nechápu, znamená to, že to nechápete vy.
Takto cez ten certifikat dochadza k priradeniu skutocnej osoby k tomu privatnemu klucu.
Zrovna předevčírem jsem si obnovoval kvalifikovaný certifikát pro elektronický podpis, jehož privátní klíč je uložen na kvalifikovaném prostředku pro vytváření elektronických podpisů. Mohu vás ujistit, že privátní klíč nikdo nikam nepřiřazoval, protože k tomu privátnímu klíči se nedostane nejen certifikační autorita, ale nedostanu se k němu ani já. Kvalifikovaný prostředek totiž umožňuje jenom privátní klíč vygenerovat, smazat ho a něco jím podepsat. Neumožňuje (bez užití nepřiměřeného úsilí) ten privátní klíč vyexportovat ani jiným způsobem získat.
Vaše představa, že certifikační autorita provádí cokoli s privátním klíčem žadatele o certifikát je tedy mylná, jak už jsem vám mnohokrát napsal. Certifikační autorita pracuje samozřejmě jen s veřejným klíčem žadatele. Tak konečně přestaňte mlít ty hlouposti o přiřazování privátního klíče.
Pane jirsak vy nerozumiete pisanemu textu. To ze sa podpise certifikat vam pisem v tom prispevku na ktory reagujete, zbytocne mi pisete co sa deje a ako to funguje ja sam som kedysi napisal SW pre certifikacnu autoritu.
Certifikacna autorita prehlasuje ze ten kto ma privatny kluc k tomuto public klucu je tato osoba alebo majitel tejto domeny. Takze zopakujem to z toho pripevku na ktory reagujete (zbytocnymi technikaliami): "Certifikacna autorita (cez certifikat) priraduje privatny kluc k domene alebo cloveku".
Pavel Tavoda, 13:49: Já psanému textu rozumím. Jenže vy to stále popisujete špatně, proto jsem vám napsal, jak je to doopravdy.
Certifikační autorita něco prohlašuje pouze o veřejném klíči. Privátní klíč není součástí certifikátu, takže o něm certifikační autorita nemůže nic prohlašovat. To, že k veřejnému klíči existuje právě jeden privátní klíč, garantují kryptografické algoritmy – certifikační autorita s tím nic nenadělá, takže to nemůže garantovat. Kdyby se někomu podařilo vygenerovat druhý privátní klíč k jednomu veřejnému klíči, nebude to chyba certifikační autority.
Pořád také píšete o „přiřazení“, ale o žádné přiřazení se nejedná. Z domény nelze zjistit veřejný klíč a z veřejného klíče nejde zjistit doménu. Certifikát je osvědčení, certifikační autorita tím něco stvrzuje – ale nemění se tím stav ani doménového jména ani veřejného klíče. Certifikát vám může vystavit třeba škola, že jste složil zkoušku z angličtiny. Neznamená to ani že se vy přiřazujete angličtině, ani že se angličtina přiřazuje vám. Tak konečně přestaňte trvat na té nesmyslné formulaci „přiřazení privátního klíče“, když nejde ani o privátní klíč ani o přiřazení.
Privatny a verejny kluc tvoria JEDINECNY par.
No vida, vy to nakonec pochopíte. Certifikační autorita něco prohlásí pouze o veřejném klíči. Díky tomu, že vytvořit k veřejnému klíči odpovídající privátní (ať už ten původní, nebo jiný), je u používaných kryptografických algoritmů reálně nemožné (alespoň podle veřejně dostupných informací), můžeme na základě toho certifikátu k veřejnému klíči něco usuzovat i o vlastníkovi odpovídajícího privátního klíče.
Uz som vam pisal 20 prispevkov dozadu ze mne nemusite vysvetlovat ako to funguje. Ja som programoval certifikacnu autoritu voci HW HSM modulu. Ovladam rozhranie pre PKCS#11 kde som pripajal SW tokeny. Mozem vam diktovat ako funguje certifikacna autorita rovno prikazmi openssl. Takze ma uz laskovo neotravujte vasimi triviliatami na urovni ze privatny kluc nemozme nikomu davat. Ked nedokazete odhadnut uroven toho s kym sa bavite je to problem ale nie moj. A ked nechapete principialnosti ktore vam hovorim tak prepacte lepsie to neviem.
"Bavili sme sa o tom ake je podla vas jednoduche si odsimulovat skutocnu domenu na svojom stroji."
IMHO: jste si jistý, že musíte simulovat skutečnou doménu na svém stroji? Pokud Vám Váš projekt nesnese nastavení jiné domény, https nebude Váš největší problém. Pak bych se taky mohl zeptat, jak vůbec spouštíte testy, když (předpokládám) nemůžete ani nastavit jinou doménu ... atd.
19. 11. 2020, 11:56 editováno autorem komentáře
"Distribuovat kluce a certifikaty developerom k skutocnej subdomene pre ktoru vyvijate."
Pokud to chápu správně, tak vy chcete fyzické soubory - certifikáty - z produkčního serveru/ů distribuovat do vývojového prostředí. Jinak se asi to, že pořád nepřijímáte vysvětlení p. Jirsáka a neustále říkáte něco o klíčích a cerifikátech, vysvětlit nedá.
Za prvé, to byste skutečně dělat neměl, za druhé nemáte vyvíjet proti ani proti produkční doméně, ani proti serveru/ům. Pak takový problém s distribucí vůbec mít nebudete a nebudete muset nic takového provádět. Doporučuji napravit development proces. Ale možná mě někdo opraví.
19. 11. 2020, 13:06 editováno autorem komentáře
To ale nechcem ja, to chce on. Iba sa tvari ze ked si necha podpisat subdomenu dev.mojabanka.sk od certifikovanej autority a potom certifikat a privatny kluc rozdat developerom, tak to nie je nebezpecne lebo taka adresa v 'skutocnosti' neexistuje. Ja tvrdim ze to nebezpecne je. Teda okrem inych skutocnosti.
Nie, ja hovorim presne to co vy. Pan Jirsak tvrdi ze je to OK nechat si vyrobit prave dev certifikaty na ostre subdomeny. Nebojte ja robim IT uz 30+ rokov, mna len tak nieco nedostihne. My mame samozrejme vlastnu certifikacnu autoritu a to dokonca oddelenu DEV a INTRANET aby ani nahodou nedoslo k vydaniu zleho certifikatu. Developeri (vratane mna) su ako male deti, dajte im hracku a oni ju za tyzden rozbiju, treba ich strazit.
Pan Jirsak tvrdi ze je to OK nechat si vyrobit prave dev certifikaty na ostre subdomeny.
Že vás huba nepálí. To vás nenapadlo, že si tu každý může mé komentáře přečíst a zjistit, že jsem nic takového nikde netvrdil?
Nebojte ja robim IT uz 30+ rokov, mna len tak nieco nedostihne.
Takoví jsou nejhorší. Jeden takový, co už to dělá čtyři sta padesát let, tudíž to má na háku a nikdo mu nebude říkat, jak to má dělat, letěl loni z Řecka do Prahy na jeden motor.
"Jeden takový, co už to dělá čtyři sta padesát let, tudíž to má na háku a nikdo mu nebude říkat, jak to má dělat, letěl loni z Řecka do Prahy na jeden motor."
Zde jste vedle. Viděl jsem rozhovor s profesionálním pilotem a ten vysvětlil, že to co se stalo a to co udělal kapitán bylo v pořádku, přestože to odborníci z médií prezentovali jinak.
Úplné detaily samozřejmě neznám.
"Pan Jirsak tvrdi ze je to OK nechat si vyrobit prave dev certifikaty na ostre subdomeny. "
To nepsal. Jak to vidím já, tak jste si tam přidal minimálně to "ostré" - proč, to nevím.
19. 11. 2020, 15:30 editováno autorem komentáře
Pretoze p Jirsak zjavne nechape ze ked ma domena v nazve na zaciatku dev ale je certifikovana verejnou autoritou je to potencionalne riziko. Pretoze to ze aktualny verejny DNS zaznam na tu adresu nesmeruje nikam neznamena ze niekto nevie zariadit aby nesmerovala niekam v buducnosti. A uplne najhorsie je ze si mysli ze dat to developerom je dobry napad.
Pavel Tavoda: Ještě jste zapomněl dodat, kde v localhost.kbibdev.cz vidíte to dev na začátku. Že si vy tuhle doménu spletete s mojebanka.cz, to vám věřím, ale to je jenom váš problém. A když jste takový expert, tak byste si taky mohl zjistit, že doménu si může zaregistrovat každý. Takže vývojáři se vás naštěstí na nic ptát nemusí.
@Pavel Tavoda
Vy to nechápete pane Tavodo. Nemáte co vyvýjet proti produkční doméně ani serverům. Pak se nemusíte pořád dokola zavývat nějakým "dev" na produkční doméně.
Vaše vývojové servery mají být na localhostu, případně za VPN, protože by mohly, mimo jiné, např. poslat na výstup něco, co nemají a neměly by být běžně přístupné. Nicméně ani od takové domény stejně nemusíte nikomu nic nikam dávat. Tím si buďte jistý, protože jak na localhostu, tak oproti test a review serveru vyvíjím denně, včetně dneška, zatímco si s Vámi píšu.
Vaše námitky a zatvrzelost mi připomíná mé minulé kolegy, kterým se nechtělo přijít na chuť Dockeru a neustále se snažili vymýšlet různé nespecifikované důvody, proč je lepší vyvýjet oproti vzdálenému server a ještě všichni najednou, jako se to dělalo před deseti lety.
Co přesně dát developerům je špatný nápad, co je to "to"?
To je takový rovnák na ohýbák, self-signed funguje jen na půl a kdo ví jestli ho pro blaho uživatele v příští verzi nezakážou, localhost je taky omezený, nějaké kontejnery a virtuálky to by se jeden utuneloloval. Vlastní CA má taky omezení, nechat si vystavit certifikát je celkem jistota, teda pokud testovací prostředí není oddělené... modla https si hold žádá oběti. Jediná jistota je curl, tam ještě uživatel dostane to o co žádal.
Tak po několika dnech zkušeností musím bohužel říct, že doplněk je lepší varianta než nové nastavení. U některých webů (např. obchodní rejstřík SK) se nedá v některých formulářích vyhledávat - někde je web https a po zadání dotazu už jen http, místo dotazu naběhne error a výsledky nezobrazíte. Jistě, že to je chyba těch stránek, ale když ty weby potřebujete k práci...
A trochu mě otravuje dotaz na to jestli chci opravdu otevřít pouze http stránku, lepší by bylo jen nějaké upozornění v adresním řádku.
26. 11. 2020, 08:03 editováno autorem komentáře