Nemam rad, kdyz se pro domaci sit pouzivaji vymyslene top level domeny a to predevsim protoze:
Nemuzete ziskat SSL certifikaty pro pouzivana jmena. Pred 10 lety to vypadalo, ze to nebude nikdy potreba, dneska bych rekl, ze je to potreba napul a za 10 let to pocitam bude zcela nezbytne, prohlizece se budou vzpouzet poslat heslo nesifrovanym kanalem/na IP adresu bez jmena.
Bude hodne tezke v te siti pouzivat DNSsec, bez nej nefunguji ruzne pokrocile DNS zaznamy jako napr. SSHFP.
Kdyz budete mit "stesti" tak vznikne top level domena stejneho jmena. Jak moc je to pravdepodobne je tezko rict, ale treba pro .home se radeji vsichni shodli, ze jeji registrace je vyloucena. Jestli vznikne DOMA corp. velikosti Google tezko odhadovat.
A pokud nekdo chce namitnout, ze nechce aby jeho pocitace byly videt na internetu, tak rovnou rikam, ze to ze je domena zalozena na existujici top level domene vubec neznamena, ze budou vsechna domenova jmena verejne dostupna. Vsechny nameservery umi omezit rozsah IP adres, ktere se mohou ptat na domenove jmeno. I samotnou informaci o tom, kam je dana domena delegovana lze omezit jen na vlastni sit. Na druhou stranu nekoho muze potesit, kdyz bude mit na mobilu permanentne spojeny wireguard domu a bude moct pouzivat verejne DNS a pritom se pripojovat na zarizeni doma. Kdyz to totiz otocite a budete pouzivat domaci DNS skrz VPN, tak bude jednak pomale a jednak kdyz doma nepujde net, tak jste bez internetu i na tom externim zarizeni.
Jinak ten koncept je samozrejme spravny, nikdo si nebude pamatovat IP adresy vsech IoT zarizeni co ma doma, natoz kdyz to budou IPv6 adresy.
Njn, firmy kde sa preferuje svarc a sef je postih ktory kontroluje aj to ako dlho clovek cural je to "normalne". Pre mna je normalne stanovit si ako dlho mi riesenie bude trvat, dodrzat ten cas a na zaklade toho casu fakturovat. Ak s danym casom ten ktory darmozrac nesuhlasi, tak moze skusit stastie a oslovit niekoho kto mu to urobi za kratsi cas, v porovnatelnej kvalite.
Mohou být i jiné důvody.
Já jsem třeba obyčejný "zaměstnanec" (klasický, plnoúvazkový), ale firma si extrémně potrpí na bezpečnost (což v tomto případě chápu) - nejen z pohledu možného ohrožení infrastruktury, ale taky třeba prevence úniku dat. Takže pro práci z domova je v podstatě jedinou věcí, kterou si každý zajišťuje sám, připojení k Internetu. Zbytek je prostě plně ve firemní režii.
Já myslím že mnohdy než reálná bezpečnost je to spíš korporátní paranoia. U nás v práci - v počítači nemáme žádné tajné ani zneužitelné informace. Přesto si musíme každou chvíli měnit heslo jak na přihlášení k PC, tak do informačního systému, odkud si stahujeme pouze výplatní pásky. A samozřejmě že po každém nabootování je potřeba udělat kompletní sken systému na viry, protože proč ne. Co na tom že v kombinaci s mechanickým diskem to udělá počítač na čtvrt hodiny nepoužitelný.
Asi jsem to nenapsal dostatecne jasne, zkusim vic vysvetlit.
Mame domaci sit, kde mame napr. instalaci home assistant na IP 192.168.1.2. A cheme k ni pristupovat mimo jine z mobilu pres VPN. Neresim ted korporatni sit.
A mame bezny mobilni telefon, kam si instalujeme wireguard (nebo cokoliv jineho, ale wg mi prijde jako prvni VPN rozumne pouzitelna pro trvaly provoz na mobilu). Nastavime si split rezim, kdy do te VPN posilame jen provoz pro sit napr. 192.168.1.0/24.
A ted potrebujeme aby ten mobil nejak vedel, ze home assistant ma IP 192.168.1.2. Ja si dokazu na mobilu rozbehnout bind (nebo mozna knot resolver) a forwardovat dotazy podle domeny, ale myslim, ze se do toho nebudu poustet. Takze budu muset pouzit "beznou" konfiguraci meho OS, tedy nastavit IP adresy nameserveru. A bud pouziju IP nameserveru co mam (ma autor clanku) doma a ta bude vedet jakou IP na muj home assistant, ale az mi vypadne spojeni domu tak budu bez DNS a nebo pouziju bezne verejne DNS, jen budu muset zajistit, aby to verejne DNS vedelo, kde je name server, ktery zna IP meho home assistanta. V tuhle chvili mi nevadi, ze ve verejnem DNS ma delegaci zony na privatni IP, protoze ta je bud dostupna pres mou VPN a nebo neni, ale potom tezko bude dostupny ten home assistant, ktery je na stejne siti.
Dovolim si predpokladat, ze 90% zdejsich navstevniku by se do rozbehnuti split DNS na mobilnim zarizeni take nepoustelo. Samozrejme na notebooku by to bylo neco jineho, ale kdo spousti notebook, aby si zapnul cestou domu topeni.
A samozrejme rovnou rikam, ze vim ze 99.9% lidi to vyresi tak, ze si home assistant povesi pod verejny cloud a nebude jeho IP zkoumat vubec nijak. Takze to berte jako stesky nekoho, koho v mladi ucili, ze Internet je sit vzajemne komunikujicich pocitacu a ne sit hloupych terminalu pripojenych k mainframe, pardon cloudu.
Ještě jedno řešení lze použít, byť nevím, nakolik to bude jednoduché na mobilech (omlouvám se, ale můj mobil umí akorát telefonovat, síťařinu na něm neprovozuji): nastavit si dvě DNS, primární z "domácí" sítě, backupový "veřejný". Pokud je domácí síť dostupná (VPN), funguje i překlad adres, ne-li, postačí to, co umí běžná DNSka.
Směrování provozu pak lze nastavit routingem: domácí síť na VPN gateway, zbytek... - ten je "default".
Děkuji za konstruktivní názory. Popsané řešení řeší pouze vnitřní přístupy po vnitřní síti. neřeší spojení zvenku. Moje registrovaná doména prý není vhodná k použití v mé vnitřní síti. Doporučen běh u registrátora s přesměrováním na moji veřejnou IP adresu. Názor technické podpory poskytovatele internetu. Možný konflikt ze systémy providera. Raději jsem se nepřel. Popsané řešení ale není problém upravit pro běžnou registrovanou doménu.
Snažím se pochopit, jak tohle nastavit, když mám doma 1 veřejnou IP adresu. Třeba u active24 si nastavím pro internal.mydomain.tld NS záznam na home.mydomain.tld. Když se mobil bude chtít dostat na homeassistant.internal.mydomain.tld, tak se pokusí získat adresu z home.mydomain.tld. To bych však musel provozovat DNS server veřejně, je to tak? Z textu jsem nabyl dojem, že bych mohl zadat do NS záznamu rovnou IP adresu openwrt z interní sítě, ale to neprojde validací (a podle google správně).
Co mi uniká?
Ano, to neprojde, protože tu adresu nezískává mobil, ale rekurzivní DNS server, který má nastavený - což je typicky DNS server u aktuálního ISP, který dostaneš z DHCP, nebo natvrdo nastavený veřejný typu 8.8.8.8. A ten DNS server samozřejmě nemá přístup do té VPN a nemůže se na tu adresu připojit. Musel by sis pustit na mobilu vlastní rekurzivní DNS server (což někteří lidé dělají když chtějí aby jim fungoval DNSSEC).
Pokud budu mít doma rozsah třeba 192.168.0.0/24, vlastnit domenu domena.cz, a dám si do veřejné dns že pc1.domena.cz je .2, a pak přijdu na návštěvu k sousedovi, který má doma taky 192.168.0.0/24, a mobil se připojí na jeho wifi, najednou se při pc1.domena.local dostanu úplně jidne. To je asi hlavní důvod.
A ne opravdu doma každý nemá ipv6 nebo blok veřejných adres.
No, pri vsi ucte, dnestni manie zbytecneho sifrovani/podepisovani uplne vseho "duveryhodnymi" certifikaty neduveryhodnych CA koupenych pres pofiderni zprostredkovatele se spatlanym web-ui a preoperovanou blonckou na telefonu, navic s maximalni platnosti na 1 rok (certifikat i bloncka), minimalni delkou klice, kterou hromada zarizeni ani nemusi podporovat, nebo dokonce ziskanych ze zatim bezplatnych sluzeb typu "hackni cizi web, a my ti vystavime 3 mesice platny a validovany certifikat", se mi s LAN fakt v hlave zatim tak nejak vubec nepotkava.
Uprimne je mi jedno, jestli bez QUIC, DoH, DNSSEC, sifrovani a vynuceneho podepisovani kdejakych public web stranek (bez bezici aplikace a bez moznosti prihlaseni) je mi kazda CDN nebo ISP schopen s minimalnimi naklady a maximalnim ziskem on-fly nahradit NEVYZADANOU reklamu a sledovani uzivatelu kooperatem Google+Facebook nejakou jinou, stejne nechtenou "sluzbou" - a o nic jineho vetsinou dnestnim progresivistum na poli "security" (jako Google a Facebook) bohuzel ani nejde. Smutny, kolik lidi to nevidi nebo videt nechce.
Pritom zrovna ten google a chromium based edge si vesele stahuji sve objemne a frekventovane updaty ve formatu .exe z CDN bez https ... mozna i proto, ze ty CDN maji zhusta na https nasazene invalid certifikaty ...
K te vnitrni siti: naopak, vzdy kdyz je to mozne (nova LAN) tak i vlastni oddelena domena, obvykle s TLD ".local". Pak se to totiz teprve neplete.
Jen bacha na patlala z RH, co tu ".local" domenu pouzil interne uvnitr avahi sluzby. Ale avahi mi na system NESMI (a RH taky ne).
Dokonce i Microsoft do nastupu O365 doporucoval domnivam se totez - pro lan oddelenou domenu (a CA microsoftu, navic s on-fly generovani cert pro zarizeni i servery, s vazbou na NPS a 802.1x ....)
Neprodavam certifikaty, a kupovat si tuny kvalifikovanych kazdy rok pro pouziti v LAN a nebo strkat stejny wildcard na vsechny interni servery, tak to fakt delat nehodlam a ani nikomu nedoporucuju. Generovat si cert req treba na cisco SMB L3 switchi za 1500 kc, a pak pro nej za par set kazdy rok kupovat certifikat, nebo se (marne) do nej pokouset dostat jiz existujici wildcard pouzity i na verejnych serverech v internetu, a pak premyslet, kterymu volovi z dodavatelu utekl ze ktere nesifrovane zalohy private key bez hesla ? Fakt mi to za ty problemy a prachy stoji ?
Osobne odpojeny sifrovany disk, na nem data vlastni CA pro LAN, openssl. Na online zarizeni jen Sub-CA pro generovani certifikatu pro vpn, hlavne kvuli revokacim (pfsense implementace s UI je celkem slusna).
Cerifikaty pro servery vzdy fqdn hostname, short, a IP. Servery na statice.
K bindu na doma: na malou LAN hw router obvykle podporuje forwarding na ISP s registraci do interniho "DNS" pro interni klienty, nebo lip na sw reseni casto staci unbound ci pdnsd.
Pokud neverim svemu ISP, tak je jedno, jestli forwarduju nebo se nechavam sledovat "dobrotisky" provozujicimi public DNS sluzby jako je Cloudflare nebo Google. Spis pro DNS servery vyrobcu telefonu se mi zhusta muze fake zaznam v domacim DNS, nebo lepe redirekce na fw, + blokace DoH, + DNSBL ....
Bind + DNSSEC by to sice take resil, ale na home a small LAN usera je to dost kanon na vrabce. Treba pfsense balicek bind implementuje UI i s kontrolou syntax, ale stejne je to "nadoma" zbytecne slozity a uzivatel musi znat i principy a terminologii kvuli designem primitivne jednoduche, 35-let stare zakladni pomocne sluzbe nad IP.
Kdyz uz se nekdo IT zivi, nebo ho bavi si hrat, pak proc ne, jen at si "jednim prsten vladne vsem" i doma.
Zase tvoj extremisticky postoj.
Nemozem suhlasit.
Sifrujes svoju beznu komunikaciu mimo digitalneho sveta?
Urcite nesifrujes. Je to zbytocna komunikacia? No nieje. Len je to komunikacia, ktoru nieje potrebne nijak chranit.
A taka komunikacia existuje aj v tom digitalnom svete a dnes je clovek nuteny ju sifrovat(je sifrovana zbytocne).
Do běžné komunikace mimo digitální svět není tak triviální vstoupit a neděje s to. Do digitální komunikace občas vstupují i ti největší ISP. Možná si myslíte, že TLS slouží jen k utajení komunikace. Ale ono slouží i k zajištění integrity. To, že by někdo zjistil, že si čtete článek na Rootu, který je veřejný, to vás opravdu trápit nemusí. To, že by vám někdo k článku přibalil JavaScript na „těžení“ kryptoměn by vám vadit mohlo.
Nešifrovaná elektronická komunikace nemá žádnou podstatnou výhodu. Za to má podstatnou nevýhodu – musíte u každé komunikace znovu a znovu rozhodovat, jestli musí být šifrovaná nebo jestli tahle komunikace je zrovna dostatečně zbytečná na to, aby šifrovaná být nemusela. K čemu je to dobré? A hlavně tohle rozhodování nemusí dělat jen provozovatel nějaké služby, ale hlavně to musí dělat každý její konzument. Každý uživatel webu by u každé webové stránky měl přemýšlet o tom, zda má být šifrovaná a kontrolovat, zda šifrovaná je. Proč, k čemu je to dobré? Dokáží to uživatelé posoudit? A dělají to reálně?
Mno avahi, mdns a pod + .local ide na triko applu, nie RH. Viz https://datatracker.ietf.org/doc/html/rfc6762
> Jen bacha na patlala z RH, co tu ".local" domenu pouzil interne uvnitr avahi sluzby. Ale avahi mi na system NESMI (a RH taky ne).
To bol patlal z Apple, nie RH. Patlal z RH implementoval to, co podla RFC implementovat mal.
> Dokonce i Microsoft do nastupu O365 doporucoval domnivam se totez - pro lan oddelenou domenu (a CA microsoftu, navic s on-fly generovani cert pro zarizeni i servery, s vazbou na NPS a 802.1x ....)
Oni aj patlali v Microsofte si eventualne precitali RFC a zistili, do akych problemov doviedli svojich zakaznikov, ked im odporucali best practices pouzivat .local.
> Na druhou stranu nekoho muze potesit, kdyz bude mit na mobilu permanentne spojeny wireguard domu a bude moct pouzivat verejne DNS a pritom se pripojovat na zarizeni doma.
Tohle jsem si taky myslel, ale minimálně s IPv4 to pak v praxi nefunguje, protože různá DNS v různých sítích odmítají přeložit domény na RFC1918 adresy, které ve své VPN/doma nejspíš používáte. Například dnsmasq to dělá (tj. všechna OpenWRT zařízení v defaultní konfiguraci) https://serverfault.com/questions/419828/dnsmasq-swallows-local-a-entries
Používat doménová jména na domácí LAN tak nad tím jsem taky přemýšlel (10-15 let zpět) ale protože to vyžaduje non-stop zapnuté zařízení, které zásadně nemám( kromě routeru) tak jsem si to nikdy nenastavil. Čekal bych, že dneska ty domací routery(příp. acces pointy) DNS server budou umět již spustit a přiřadit jednotlivá jména zařízením v síti přes MAC či IP. Protože to není zase tak důležitá věc abych kvůli tomu měl non-stop spuštěné zařízení, které to umí.
Umí.
V podstatě tak to používám už desítky let: na routeru je nastavený DNS server, který z vnitřní sítě odpovídá; má nastavena pevná mapování na stroje s pevnou IP adresou, kde je DHCP, bere si to z aktuálně přiřazených.
Akorát to obvykle (kromě OpenWRTček) není nastavované v nějaké konfiguraci, jen "naklikané" na rozhraní routeru.
Vždyť přímo na té stránce v manuálu to je popsané - DNS Static:
/ip dns static add name=www.example.com address=10.0.0.1
/ip dns static add regexp="[*example*]" address=10.0.0.2
Souhlas, že to je dobré na takovéto domácí překládání a ne na to, abych tím dělal autoritatitivní DNS server dostupný z Internetu. Je to doplněk do toho jeho forwarderu, že pro některé zadané jména/domény/regexy má něco vracet místně nastaveného. V podstatě obdoba toho, co můžu dělat s dnsmasq, asi o něco tupější (i když v poslednch verzích ROS doplnili pár věcí).
Ad 1) záznam platí dokud ho nesmažu pomocí del a pořád vrací, že má TTL den. Nějaké TTL to hlásit musí, tak tam dává to, co má nastaveno jako default hondotu pro cache.
Ad 2) Po resetu do továrního nastavneí se to smaže, po normálním restartu nebo výpadku napájení to zůstává platit dál, protože se to ukládá na flashku do konfigurace. Stejně tak když udělám export/backup tam se do to toho vkládá a zálohuje se to (takže se to pak i obnoví zpět).
Jo, Mikrotik to možná umí, ale tak napůl:
Jestliže server DNS v Mikrotiku překládá výlučně některá doménová jména (třeba .lan), pak by měl být pro tyto překlady autoritativním, ale nejenže v něm nejde nastavit záznam SOA (přestože další typy záznamů v posledních verzích přibyly), ale ani takové odpovědi za autoritativní neoznačuje. Na běžné domácí žvýkání to může stačit, ale pro použití veřejně z inetu mi to nefungovalo, takže jsem si stejně musel udělat autoritativní server. (Mimochodem jsem skončil u Yadifa, protože Knot DNS se mi vůbec nepodařilo spustit ani v Dockeru, ani mimo, ještě k tomu má nestandardní záznamy v Lua.)
DNS v mikrotiku je celkovo docela <i>zaujímavé</i>.
Okrem toho, že nevie SOA/autoritatívne zóny, má aj ďalšie obmedzenia:
1) DoH je iba cez HTTP 1.1. Pokiaľ DoH resolver podporuje iba HTTP 2.0 (napr. CZ.NIC ODVR, alebo ľubovoľný knot), tak sa nedohodnú. Cloudflare aj Google vedia HTTP 1.1, tak to v Litve zjavne moc neriešia.
2) Pri zapnutom DoH nefunguje conditional forwarding (statický FWD záznam). Môj plán používať DoH na mikrotiku a forwardovať dotazy na internú doménu na interný autoritatívny DNS vzali za svoje a musím to mať naopak, forwardovať z interného bindu na mikrotik, ktorý resolvuje verejné záznamy.
Uz to mam tak dlouho na mikrobliku ze ani nevim. Uhni i ty to ma taky. A mam to nastavene s vedomim ze je to jak popsal Dan blbe tak ze mi nejdou vystavit certifikaty. Vyprsela mi domena a od ty doby to nejak neresim.
Dokonce i hujaja hovadina od ISP umi lease ip dle MAC. Co se tyce DNS tam je to slabsi. V podstate to umi vzit jmeno nastavenene na hostu na pres dhcp request ho zaregistrovat ho do sveho interniho DNS. Dira v dire jak vrata( nepouzivam, deaktivovano). Perfektne by se dala takhle utocnikem v interni siti spoofnout jmena.
Ale treba se to nejake babicce a dedeckovi s read only IoT petrolejkou a smart papucemi se to muze hodit.
9. 2. 2022, 11:07 editováno autorem komentáře
Je to sice z jineho uhlu pohledu na DNS, ale domnivam se, ze je vhodne to tady zminit: https://lsd.gnunet.org/lsd0001/.
Popsaný návod je asi poplatný umístění souborů v Ubuntu, takže při
použití jiných distribucí je to zřejmě třeba upravit.
K souhlasu s výhradami Dana Ohnesorga ohledně volby "domácí" domény lze
jen dodat, že poměrně vhodnou TLD pro domácí použití může být např.
"localdomain.", která bývá použita ve vzorech /etc/hosts pro localhost a
u které nejspíš nehrozí, že by se stala jednou z nových genTLD (jedinou
nevýhodou je její délka, ale proti "uzanční" home.arpa - viz doporučení od
"M_D" - ne o moc a navíc formálně nezavádí dosti zbytečný 2. řád). Snad
by šla i "local.", ale používat např. "int." (takový návrh byl zaznamenán) je
zcela nevhodné, protože je kolizní (viz např. ecb.int).
Když už domácí resolver, tak moc nechápu, proč forward na resolver
ISP nebo kohokoliv jiného, když lze resolvovat rovnou proti root-serverům
(jen se musí občas kontrolovat jejich množina v iana.org, což lze jednoduše
automatizovat). Dělám to tak už léta a funguje to. Na každém z několika
domácích PC primár poslouchající jen na localhostu. Při změně v localdomain
snadno zónové soubory rozkopíruji a reloaduji named a v /etc/resolv.conf
jako druhý je "pro jistotu" resolver na routeru s forwardem k ISP. Extra server
netřeba. Pro ne-UX systémy (MS-OS, resp. ty v patlafonech) to rodinným
příslušníkům resolvuje jen router přes ISP (má to v DHCP), ale tím se
nezabývám. Je to možná celé trochu svérázné a třeba ne moc bezpečné, ale
zatím nebyly žádné problémy a mně to vyhovuje. :-)
Pridavam se k vyhrade, .local se skutecne pouzivat pro ucely popsane v clanku nema a soucasne se dneska uz casto pouziva pro to mDNS, protoze Apple zarizeni to masivne pouzivaji a navic to pouziva spousta krabicek zalozenych na ESP32 a podobnych IoT platformach.
.localdomain bych taky nepouzil, localhost a localhost.localdomain je na spouste mist zadratovane pro vlastni/interni interface daneho zarizeni. Nemuzu dolozit zadny priklad, ale verim, ze se najde situace kdy nejake zarizeni prelozi jmeno treba nas.localdomain na 127.0.0.1 a nebude fungovat.
Smím vdět, kd eje to .lan definováno, že je k tomu určeno? Ano, často se používá, ale třeba RFC6761 ji mezi specialitkami neuvádí. Že ji často používá WRT a dnsmasq je věc jiná.
I dle tohoto je zatím fáze hledání vhodného kandidáta: https://www.icann.org/en/system/files/files/sac-113-en.pdf
Já bych znovu upozornil na TLS certifikáty, které Dan zmiňoval. I když vymyslíte nějakou „domácí TLD“, která se zaručeně v příštích padesáti letech nestane globální TLD, nebo použijete nějakou „rezervovanou“ TLD – pořád se připravujete o možnost vystavovat na ty názvy důvěryhodné certifikáty.
Možná vám to teď nevadí. Ale jste si opravdu jistý, že vám to nebude vadit ani za pět, deset, dvacet let? Už nyní jsou některá API ve webových prohlížečích dostupná jen pro stránky nahrané přes HTTPS. Dá se předpokládat, že toho bude přibývat – a cílem, i když zatím vzdáleným, je nešifrované HTTP z prohlížečů úplně dostat pryč. Takže pokud bych DNS názvy do domácí sítě zaváděl teď, rozhodně to nebudu dělat způsobem, abych musel ty názvy zase za pár let měnit.
Když už domácí resolver, tak moc nechápu, proč forward na resolver
ISP nebo kohokoliv jiného, když lze resolvovat rovnou proti root-serverům
Kvůli rychlosti. DNS resolver vašeho ISP toho bude mít nakešovaného mnohem víc, než váš domácí DNS resolver. Takže vyřízení dotazů bude rychlejší.
Tohle bych já osobně za problém nepovažoval - na "domácí" servery lze použít "domácí" ("privátní") certifikační autoritu a certifikáty si vydávat ve vlastní režii.
(Nicméně se přikláním k pořízení běžné domény a jejímu následnému použití jak "zvenku" pro webové prezentace či e-maily, tak pro "interní" potřebu.)
Dělat si vlastní certifikační autoritu není něco, co by vám nezabralo vůbec žádný čas. Pak ji musíte instalovat do každého domácího zařízení – opět, někde je to jen práce navíc, některá zařízení se tomu brání (a budou čím dál víc), u některých zařízení to může být nadlidský úkol (třeba takové chytré televize). No a pak do toho vstupují třeba návštěvy, kterým budete chtít povolit třeba zobrazit fotky z jejich mobilu na vaší televizi. A instalovat vlastní certifikační autoritu návštěvám je myslím něco, čemu bych se chtěl vyhnout, i kdybych měl náladu vše předchozí absolvovat.
Nezapomeňte, že i na certifikační autority jsou kladeny stále větší nároky. Privátní jsou z toho (zatím a většinou) vyjmuté. Ale „zatím“ a „většinou“… Přidávat SAN do certifikátů se dalo vyřešit snadno (pokud měl někdo tu autoritu založenou na OpenSSL a ne na Windows AD). Ale jestli v budoucnosti bude požadavek na uvádění i certifikátů privátních autorit na Certificate Transparency list, nebo jestli budou muset podporovat OCSP, nejsou to úplně věci, které bych chtěl implementovat do své domácí certifikační autority.
Takže, pokud zavrhneme věci jako TLD .local, je pořád možné si zařídit vlastní doménu, pod nějakou vhodnou běžnou TLD, s krátkým jménem. A pokud si člověk připlatí i nějaký ten webhosting/mailserver (ano, to už je k tisícovce ročně) u providera s rozumnou politikou pro DNS, není problém na "prázdný hosting" nasměrovat potřebné "virtuální virtuální servery" a nechat si scriptem generovat certifikáty od LE. Ty pak lze "přehazovat" do vnitřní sítě a distribuovat na příslušná zařízení. A domácí DNS resolver na routeru může mít staticky přidané IP adresy oněch "serverů" na vnitřní síti,
Výsledkem bude, že "doma" vše funguje na lokálních IP adresách, s certifikáty od důvěryhodného vydavatele, "zvenku" skončíte na prázdné stránce, opět s platným certifikátem.
Jako bonus je tu prostor pro nějakou tu osobní prezentaci či předávání souborů, a e-mailová adresa s "rodinným jménem".
Jasně, není to řešení pro úplně neznalého "klikače", ale s trochou snahy se to udělat dá.
A jasně - klíče by se kopírovat neměly, když jsou tajné... Ale v rámci zjednodušení a pro tyhle domácí účely bych to s tou bezpečností protentokrát až tak nepřeháněl. Ostatně - i to se dá udělat solidně zabezpečené.
Pro generování LE certifikátů nepotřebujete „virtuální virtuální servery“ a nějaké přehazování certifikátů. Doménové jméno můžete autorizovat přes DNS (ACME DNS-01 challenge), takže jediné, co musí být opravdu venku, je DNS server. Nebo-li stačí si zvolit poskytovatele DNS, který má rozumné API a se kterým si bude rozumět váš nástroj pro automatizované vydávání certifikátů. Dá se k tomu zneužít třeba Cloudflare, jeho API umí kde kdo.
Doufám, že za pár let tohle budou umět rovnou SOHO routery a jenom si to tam naklikáte. Třeba Turris by mohl jít příkladem.
Tak, nemusite to implementovat sam, staci pouzit existujucu. Napr dogtagpki, ma vsetko co by mal od nej clovek chciet. Pouziva ju napr freeipa.
Co sa tyka bezpecnosti takej privatnej CA - rozsirenie name constraints umoznuje definovat pre ake domeny je mozne CA certifikatom vydavat. A implementovane to ma uz aj dokonca osx. Takze mim sa nekona.
Co sa tyka bezpecnosti takej privatnej CA - rozsirenie name constraints umoznuje definovat pre ake domeny je mozne CA certifikatom vydavat.
Problém je, že množina lidí, kteří si name constraints zkontrolují, než si nainstalují certifikát nějaké certifikační autority, bude asi tak stejně velká, jako množina lidí, kteří to u své privátní certifikační autority nastaví. Po zaokrouhlení nula.
Njn, varuje. Ale ako ste sam pisal, tak ani ca certifikat nenainstalujete len tak.
Kedze vedsina binariek je v linuxe mimo repozitare distribuovana cez tar, tak si budte isty ze vam to eXecutable priznak nastavi, staci na to chrome, ktore akonahle zisti ze ide o archiv, tak sa pyta kam to ma rozbalit.
Nanestastie dogtag vyzaduje 389ds. Pokial ste bez LDAP, alebo pouzivate iny, nebodaj s uplne inou schemou (napr. AD/Samba, co bude trosinku viac pouzivane ako freeipa|, tak je dogtag nepouzitelny.
Stale zostavaju openssl, step-ca, alebo scep, podla narokov, alebo klientov co si maju provisionovat certifikaty.
1) ADCS je samostany service, Windows ho ma ako optional, Samba to nema (hovorim o Sambe v AD mode, ked to nie je jasne). Co som videl, tak pomerne dost instancii AD to nema rozchodene.
2) Napriklad taky blazon, co ma Synology a pouziva to v domacnosti alebo malej firme na centralnu spravu uctov. Ked sa tu riesi bind alebo postfix na domace ucely, co je zvlastne na Sambe?
3) Ja som nepisal ze dogtag je zavisly na freeipa. Ja som pisal ze dogtag je zavisly na 389ds. Z https://github.com/dogtagpki/pki/wiki/Architecture:
The Certificate System uses 389 Directory Server as its database for storing information such as certificates, requests, users, roles, ACLs, and other internal information. The Certificate System communicates with the internal LDAP database securely through SSL client authentication.
A ako to viem? Clovek sa dost nauci pri krieseni system, ked dogtagu expiruju certifikaty na to, aby sa dostal k svojmu vlastnemu store a vytvoril si nove (bol to virtualny lab, ktory bol vypnuty prave vtedy, ked by si ich zijuci system obnovil).
4) Naco freeipa, ked mam Sambu? 99% 3rd-party aplikacii vie spolupracovat s AD, ale nie s freeipa. Koniec-koncov aj Samba funguje s freeipa tak, ze ma samostatnu domenu a urobi medzi nimi trust.
FreeIPA som svojho casu prevadzkoval, v jednej malej firme. Ma niektore pekne veci, ktore AD nema (hba, sshfp by default, sudoers), ale na konci dna to bola zbytocna pakaren, integracia tretich stran nulova, clovek mal s tym len zbytocnu pracu. Este aj ten trust so Sambou bolo treba bejbysitovat, tak to islo prec.
1) njn, ved ani dogtag nie je sucastov freeipa, jaksi mi unika zmysel na co sa tym snazite poukazat.
2) tak takych sa vela nenajde, povedal by som ze dost ludi navstevujucich tento server, prevadzkuje sluzby ako openwrt (a klony), nejaky ten nas postaveny na linuxe, enigmu a tak podobne... btw, kolko stoji domaca licencia AD?
3) tak nie je to urcene len na take bastlenie si po veceroch. Ako by to podla vas malo byt ulozene, v plaintexte, vratane privatnych klucov? Ked uz taketo nieco prevadzkujete tak sa o to musite starat.
4) no vidite, ja pouzivam vacsinu aplikacii ktore su spolahlive prave koli tomu ze pouzivaju MIT kerbera a nie tu spatlaninu od malehomakkeho.
Moc nechapem co chcete povedat tym ze prakticky cela vasa siet je zavisla na widlach?
2. 2. 2022, 15:09 editováno autorem komentáře
1) Povodna myslienka bola, ze dogtag _vyzaduje_ na svoj beh LDAP server. A to nie hocijaky, ale konkretne a vylucne 389ds. Takze pokial uz nejaky iny LDAP mate, ci uz MS AD, Samba AD alebo OpenLDAP, tak dogtag s nim nepobezi. Inymi slovami, prevadzkovat dogtag, pokial uz neprevadzkujete 389ds je pomerne _neprakticke_. No a pokial ho uz prevadzkujete, tak na 99% je to s freeipou, kde je bundlovany, takze samostanu CA neriesite.
Odbocka: nepride vam zvlastne, ze prevadzkovat AD v malom povazujete za blaznovstvo, ale rozbiehat konkretny LDAP server pre jednu-jedinu aplikaciu je OK?
2) Napriklad spomenute Synology spadaju do kategorie "nejaky ten NAS postaveny na linuxe" a (tusim v modeloch + a vyssie) je tam klikatko, kde si AD domenu vytvori kazdy. Rovnako je to trivialne rozbehnut napr. v beznych distribuciach, staci nainstalovat prislusne balicky a domenu vytvorite pomocou "samba-tool domain provision".
Takze AD domenu mozete mat za rovnaku cenu ako freeipa: v intervale od 0 po kolko chcete minut.
3) No a tu mame opacny nazor. Kedze ale nechceme flamovat, ale byt konstruktivni, tak:
- je rozdiel medzi tym, co ukladam (obsah: ciphertext vs plaintext) a kam to ukladam (store: LDAP, subor, iny store). Aj do LDAP sa da ulozit plaintext a aj do suboru mozte ulozit ciphertext. Naprklad taky HashiCorp Vault uklada tajomstiev podstatne viac ako dogtag (vid dalsi bod), ale nema problem ani s textovym key/value storage. Teda nema problem so secret engines ako pluginmi celkovo, dokaze ich ulozit bezpecne hocikam, kde to pouzivatel potrebuje.
- PKI system nema co poznat privatne kluce. Privatny kluc ma byt znamy iba klientovi, ktory si ho vygeneroval, inak nie je privatny. PKI ma od zaujemcu o certifikat dostat iba CSR a v pripade kladneho vyhodnotenia odoslat naspat podpisany certifkat. Tym sa dostavame k tomu, ze jedine tajomstvo, ktore PKI ma, je privatny kluc CA. V idealnych podmienkach je tento HSM (v domacich podmienkach to tak povacsinou nebude, aj ked napr. yubikey by sa dal pouzit).
Naproti tomu spomenuty Vault uklada skutocne aj dalsie tajmostva, nielen jediny kluc.
4) Viete o tom, ze okrem MIT Kerbera existuje aj Heimdall? Tak nemusite predkladat falosnu dilemu o MIT vs Microsoft, ked tych moznosti je viac.
A podobne, v mojej sieti, aj ked je tam AD, su "widle" len klient. Neviem ako to este povedat, ale Samba nie je Windows a Samba je plne* pouzitelna implementacia AD.
[*] ano, Samba nema DFS-R a replikacia SysVol medzi domenovymi kontrolermi prebieha, no, nazvime to alternativne. Neriesme nieco, co ine adresarove sluzby vobec nemaju.
2. 2. 2022, 23:25 editováno autorem komentáře
Takze fajn, ja som rad ze nebudeme flejmovat ;)
Ja som v povodnom prispevku nepisal ze musi a jedina spravna cesta je dogtag. Pisal som ze je mozne pouzit napriklad dogtag.
Ak vam dogtag nevyhovuje ale ste odkazany na klon AD v synology tak, je to vas boj. Nemusite vsetkych presviedcat ze vase riesenie je jedine spravne a nevyhnutne dobre pre kazdeho.
Vsak ja som ziadne jedno riesenie nepresadzoval, citujem "zostavaju openssl, step-ca, alebo scep," (to su 3 riesenia, a to som vynechal vault)... a podotkol, ze dogtag nie je pouzitelny bez 398ds, co na 99,9999% ti, co nemaju freeipu nebudu mat nasadene a ti, co freeoipu pouzivaju uz dogtag maju.
"Klon AD v Synology" je uplne standardna Samba.
3. 2. 2022, 13:24 editováno autorem komentáře
Ale vy ste zobral moj prispevok ofenzivne, nevypadalo to tak ze predstavujete len dalsie mozne riesenie.
Tak si skuste tu vasu standartnu sambu pripojit k nadradenemu AD serveru. Podari sa nam to len vtedy ak autoritativny AD server bude len ta vasa "standartna" synology samba.
A uvedomte si jednu podstatnu vec, samba nie je nevyhnutnost.
Synology v starsich verziach naozaj nepodporovalo viac ako jeden DC. Ale to bolo v casoch, ked mali Sambu 4.4. Kde ty lansky casy jsou...
A to nic nehovori o clenstve. Clenstvo v AD bez ohladu na implementaciu podporovali uz vtedy, ked este nepodporovali AD rezim u seba.
3. 2. 2022, 15:13 editováno autorem komentáře