Dotaz: Omezení pístupu na webové stránky

[Pepa]

Ahoj. Chtěl bych na serveru nastavit přístup k webovým stránkám pouze pár lidem a dočetl jsem se, že to jde bezpečně pomocí nějakého certifikátu. Na serveru mi běží Debian a Nginx.

Našel jsem konfiguraci pro ten Nginx, ale nevím kde mám sehnat nebo jak vytvořit soubor client-ca.crt.

ssl_client_certificate /etc/client-CA/client-ca.crt;
ssl_verify_client on;

Můžete mi prosím poradit? P.

Odpovědi

[X]

Resil jsem to vlastni CA s pomoci EasyRSA, jen je potreba do prohlizece importovat kompletni PKCS12 sadu.

[Pepa]

Hm, že se tady vůbec na něco ptám...

[PetebLazar]

Ona to je odpověď na Vaší otázku.

Ty v úvodním příspěvku uvedené řádky konfiguračního souboru znamenají, že pro úspěšné navázání SSL spojení mezi klientem(webový prohlížečem) a serverem(web serverem) je zapotřebí, aby se klient serveru prokázal platným klientským certifikátem, který bude vystaven webserveru známou certifikační autoritou (soubror client-ca.crt obsahuje certifikát certifikační autority vydávající klientské certifikáty).

Easy-RSA je sada skriptů nad OpenSSL, jež umožní vytvoření self-signed CA a následné vydávání a revokaci klientských(či serverových) certifikátů.

Při řešení využívající na obou stranách certifikáty soukromé CA je zapotřebí do OS/prohlížeče doplnit certifikát CA (aby se stránky jevily prohlížeci důvěryhodné). U řešení využívajících prohlížečům/OS již známé(předinstalované) CA toto zapotřebí není.

Pro případ cíleného omezení přístupu konkrétního uživatele, či při kompromitaci konkrétního klientského certifikátu je třeba tento certifikát revokovat. Webserver by kromě časové platnosti cerfikátu měl ověřovat i to zda klientský certifikát není revokován.

[Z55]

Stačí importovat do systému macOS pouze client.crt, žádnou sadu PKCS12 není potřeba generovat a importovat. EasyRSA taky není potřeba instalovat pro generování certifikátů, openssl zvládne levou zadní vše co k tomu potřebuješ. V klíčence macOS si můžeš přímo pomocí klikátka vygenerovat jak vlastní ověřovací autoritu tak veškeré potřebné certifikáty včetně klientských.

[Jendа]

Je to dost složité, v prohlížečích podpora všelijaká a celkově na prd, nestačilo by nastavení HTTP autentizace heslem?

[tttttttttttttt]

> v prohlížečích podpora všelijaká a celkově na prd,

Vím o tom, že nastavení je dost schované. Jsou s tím i další problémy? Se složitostí souhlasím, nastavit a udržovat to je celkem opruz.

K dotazu: budeš potřebovat CA (certificate authority) a pak certifikáty podepsané tou autoritou, které importuješ do prohlížeče. Dají se vytvořit pomocí openssl, easyrsa. Návod je třeba tu: https://mcilis.medium.com/how-to-create-a-client-certificate-with-configuration-using-openssl-89214dca58ec. A přidám se k ostatním, zvaž, jestli ti to stojí za to nebo chceš raději něco jednoduššího.

[X]

Pred 14 dny jsem to nasazoval na Wedos VPS + Firefox a problemy absolutne zadne, kdyz vis co delas..

[Andrej]

…v prohlížečích podpora všelijaká a celkově na prd…

To je zajímavá novinka. To jsem se zase něco dozvěděl, po víc než dekádě bezproblémového používání právě téhle všelijaké na prd podpory.

To pak asi žádná z větších internetových firem ve skutečnosti vůbec neexistuje, což, když se žádní zaměstnanci nemůžou dostat na žádný firemní web.

Alternativní realita, par excellence.

[Pepa]

Tak jsem to zkusil ale stejně pořád dostávám chybu

400 Bad Request
No required SSL certificate was sent
nginx/1.22.1

[tttttttttttttt]

Nemáš v prohlížeči nainstalovaný platný klientský certifikát, vidíš chybu, která se zobrazí těm, co tam nemají přístup.

[Pepa]

Nahrál jsem certifikát do systému (macOS), nastavil mu "Vždy důvěřovat" a všechno proběhlo OK. Restartoval jsem celý systém ale chyba stejná.

[X]

Jak jsi generoval certifikaty, jakou mas aktualni konfiguraci Apache a jaky certifikat jsi nahral do prolizece/ssytemu?

[PetebLazar]

Nešlo pouze o serverovy certifikat (ten co se jim prokazuje HTTPS server)? V případě, že šlo opravdu o klientský certifikát má webserver povědomí o CA jež ho podepsala?

[tttttttttttttt]

Ta chyba znamená pořád totéž. Nepíšeš žádné detaily, těžko říct. Není správně vygenerovaný klientský certifikát, nastavený CA pro ověření na serveru, je naimportovaný jinam, prohlížeč ho bere z jiného zdroje, …

Zkus to rozchodit nejdřív bez prohlížeče přes curl, tam máš pod kontrolou, co se posílá:

curl https://example.com --cert client.cert.pem --key client.key.nopass.pem --cacert ca.cert.pem

Ve výstupu z s_client můžeš vidět, které klientské CA nabízí server:

echo "\n" | openssl s_client -connect example.com:https

[Andrej]

Osobnímu certifikátu nemáš kde (a nemáš jak (a nemáš proč)) nastavovat „vždy důvěřovat“.

Takže jsi udělal něco špatně. Znova přečíst návod a začít od začátku.

[Max]

Máš dvě možnosti. Buď se budou ověřovat certifikátem, nebo uživatelským jménem a heslem (Basic HTTP authentication).
Certifikát je sice z hlediska bezpečnosti nejlepší, ale nese to sebou nutnost údržby. Tj. ty si vytvoříš nějakou certifikační autoritu, vydáš si certifikáty pro uživatele, ti uživatelé si celý balík musí naimportovat do prohlížeče (případně do OS). Tzn., že v PC do všech prohlížečů, které chtějí používat, pak do telefonů atd.
Certifikát se vystavuje většinou na rok. Po roce vygeneruješ noví, uživatelé si jej zase budou muset všude naimportovat atd.
Můžeš samozřejmě vydat cert i s delší platností, ale pak je otázka, zda to nezačne něco odmítat.
Otázkou tedy je, zda chceš jít super bezpečnou komplikovanou cestou, nebo dostatečně bezpečnou a zároveň i jednoduchou?
Zdar Max

[Pepa]

Chtěl bych jít bezpečnější cestou i na úkor složitosti.

[Max]

V tom případě si musíš:

• vytvořit vlastní certifikační autoritu (CA) - ca.key, ca.crt
• v rámci ní vygenerovat serverový certifikát - server.key, server.crt
• v rámci web serveru povolit auth via client cert
• vygenerovat csr žádost pro klientský cert (vygeneruje se csr + privátní klíč - client1.csr, client1.key)
• svojí CA podepíšeš client1.csr / vystavíš certifikát client1.crt
• do prohlížeče na straně klienta naimportuješ ca.crt jako důvěryhodnou autoritu, pak client1.cer a client1.key

Návod pro Apache třeba zde: Mutual Authentication Using Apache and a Web Client.

Buď to celé můžeš projít ručně pomocí openssl, nebo použiješ skripty jako již zmíněný Easy-RSA 3, nebo nějaké klikátko jako xca.
Zdar Max

[alkoholik]

Laskave nemichej dohromady server a client certifikaty.
Je naprosto bezne mit server s certifikatem treba od Let's Encrypt a klientske vydane vlastni CA.

[tttttttttttttt]

Není tam problém s bezpečností? V klientovi se většinou pro ověření zadává CA serveru. Když tam bude letsencrypt, je jednoduché vytvořit altervativní server, resp. MITM, kterému bude klient důvěřovat.

[X]

Presne tak, je tam problem s "SSL renegotiation", ktera ma odstranenou podporu kvuli MITM. To zaroven neumoznuje overovani klienta na serveru per-directory, ale je potreba subdomena.

[Max]

Tak předpokládal jsem, že nemá nastaveno nic, když se ptá na základy, proto jsem poslal kompletní postup včetně vlastního serverového CA, což je putna, když stejně bude muset nutit ostatním instalovat svojí CA.
Zdar Max

[Andrej]

Je potřeba vygenerovat si (například pomocí OpenSSL) certifikační autoritu. Certifikační autorita je samopodepsaný kořenový certifikát a k němu příslušející pár klíčů.

Kořenový certifikát s veřejným klíčem autority se rozdistribuuje na servery, které pak mají ověřovat osobní certifikáty.

Každý uživatel má svůj osobní certifikát a k němu příslušející pár klíčů. Osobní certifikát je vytvořený za použití soukromého klíče autority veřejného klíče uživatele. Osobní certifikát potvrzuje uznání veřejného klíče uživatele autoritou.

Při autentifikaci se uživatel prokáže certifikátem od autority a veřejným klíčem, který tento certifikát potvrzuje. Následně pak prokáže (pomocí vhodného challenge-response mechanismu), že vlastní soukromý klíč ke svému veřejnému klíči.

[Pepa]

Co přesně znamená tohle okno? Nevím jaké údaje to po mě chce, doufám, že ne uživatelské jméno a heslo, to tam tedy fakt zadávat nechci. Diky

https://ibb.co/GQbwnj2

[PetebLazar]

Bylo by vhodné uvést po jaké činnosti se daný dialog otevřel.

[Pepa]

Po zadaní url která vyžaduje to ověření certifikátem, jako první se zobrazil certifikát, na ten jsem klikl a zobrazilo se tohle okno.

[Jendа]

Tipuju, že jsi naimportoval klientský certifikát (resp. k němu příslušející klíč) do systémové klíčenky, která je zašifrovaná. A tohle chce aby ji to dešifrovalo.

[Pepa]

Ano, importoval jsem certifikát včetně klíče a ověřovací autority. A co s tím? Přece nebudu dávat přístup ke své klíčence, ne? Jsou nějaké možnosti jak to obejít?

[Andrej]

Nepoužívat Macroshit Edge?

Jinak jde většinou o to (a dá se to nastavit), že klíče se odemykají třeba jednou, při spuštění prohlížeče, a pak zůstane klíčenka nějakou dobu odemčená (což může být konkrétní čas nebo celý uptime).

Je to takový kompromis mezi pohodlím a odolností proti neoprávněnému použití soukromého klíče, ať už jakýmikoliv způsobem (odlákáním uživatele něčím rádoby-urgentním, aby si nezamknul session, případně cold boot útokem). Pokud je software rozumně navržený, při zamčené klíčence by dešifrovaný soukromý klíč neměl zůstávat v RAM.

[jejda]

Pokud má server pevnou IP adresu která se nemění a nemáš tam nějaké supertajné data, tak existuje ještě jedna možnost. Na webserveru nastavíš aby odmítl připojení na holou IP adresu, vymyslíš si libovolný hostname a ten potom povolíš jako vitualhost. Na klientovi přidáš natvrdo záznam do /etc/hosts a je to. Odpadá tak veškeré žonglování s certifikátama a heslama. Odhodlaného útočníka který může tvůj http provoz odchytávat tcpdumpem to sice nezastaví, ale náhodné kolemjdoucí a boty to spolehlivě odfiltruje.

[Jendа]

To mi přijde ještě horší než dát to na tajnou URL (například do adresáře s náhodným jménem) - zatímco URL je v HTTPS, takže může uniknout „jenom“ z prohlížeče (různé takové ty dotazy jestli je daná URL phishing), případně když ji někam nemoudře pošleš (aplikace pro instant messaging, které stahují poslaná URL a dělají z nich náhledy), tak subdoména se bude objevovat i v DNS (ano, teoreticky když ji budou mít všichni v /etc/hosts, tak se resolvne vždy lokálně, ale mně by určitě leakla v okamžiku kdy si třeba v prohlížeči nastavím SOCKS proxy, protože adminuju něco s webovým rozhraním ve vzdálené síti, a buď nechám otevřený tab, nebo si prohlížeč vymyslí, že třeba bude refreshovat favicons).

Slyšel jsem, že někteří akademičtí poskytovatelé (typu CESNET ale myslím že šlo o jeho rakouskou obdobu) používají DNS snooping na svých rekurzorech, aby zjistili, jestli někdo v jejich síti nehostuje soukromé domény (e.g. hledají doménu, která nekončí .ac.at nebo podobně whitelistováno, která resolvne na A záznam mířící do akademického rozsahu). Takže minimálně někdo obecně DNS loguje a čte. Taky bych se vůbec nedivil, kdyby nějaký provozovatel „public“ DNS („8.8.8.8“) zveřejnil nějaké anonymizované statistiky, ve kterých by se ale subdomény objevily (ale anonymizace by spočívala v tom, že by tam nebylo napsáno, kdo se na to ptal, a časy dotazů by byly zaokrouhleny třeba na dny)

Navíc na „tajné subdoméně“ nemůžeš mít HTTPS (pro běžné způsoby vydávání certifikátů nevyžadující wildcard), protože se okamžitě objeví v certificate transparency logu a souvisejících věcech.

[jejda]

Nemyslel jsem subdoménu ale nějaký jednoduchý hostname. Ano pokud hostname neobsahuje tečku, některé resolvery můžou frflat, ale to se taky dá snadno změnit v konfiguraci. Jsem měl za to, že když mám záznam přímo v /etc/hosts tak ten dns dotaz vůbec neopustí počítač. Mám takto nastavený apache, kde několika známým zpřístupňuju po nešifrovaném http pár adresářů se souborama a nechcu aby mě tam lezli crawlery nebo nějaká random havěť. I když tam převážně nemám nic extra tajného, sdílet některé věci veřejně by se mohlo znelíbit vrchnosti a nemám čas ani chuť se potom s nějakým hňupem handrkovat, co že se vlastně na tom internetu podle něho publikovat může a co už ne.

Ano je to takové trochu lamerské řešení, ale je to jednoduché, bezůdržbové, nevyžaduje to instalaci žádného speciálního software na straně klienta. Celou dobu se tu řeší akorát ty certifikáty tak mi přišlo fér zmínit taky jinačí možnost jak "omezit přístup na web server".

Dají se taky na serveru nastavit povolené zdrojové ip adresy, ale to už je dneska ůplné scifi protože pevnou veřejnou nesdílenou IP má jenom hrstka vyvolených.

[Peter Golis]

ale to už je dneska ůplné scifi protože pevnou veřejnou nesdílenou IP má jenom hrstka vyvolených

IPv6 za 5 ... 4 ... 3 ... 2 ... 1 ...

[Jendа]

Nemyslel jsem subdoménu ale nějaký jednoduchý hostname. Ano pokud hostname neobsahuje tečku, některé resolvery můžou frflat, ale to se taky dá snadno změnit v konfiguraci. Jsem měl za to, že když mám záznam přímo v /etc/hosts tak ten dns dotaz vůbec neopustí počítač.

Jo takhle. No tak to pro změnu úplně vidím, jak ten jednoslovný hostname dáš do adresního řádku a prohlížeč to interpretuje jako dotaz pro vyhledávač (jasně, asi ti nehrozí útok, že by si toho někdo v Googlu všiml, pak uhádl kde ten server běží a poslal to tam).

Pro zajímavost, proč jsi prostě nepoužil standardní HTTP autentizaci jménem a heslem?

[jejda]

Vlastně ani nevím, mám to tak už spoustu let. Tenkrát býval adresní řádek opravdu jenom řádkem pro adresu a jedna z prvních věcí kterou po instalaci prohlížeče nastavuju, je zákaz gůglení v řádku kam patří adresa. Z historie prohlížení mi to doplňovat může. Vyhledávat můžu pohodlně přes pravé myšítko nebo klávesou zkratku. Standartní autentizaci jsem nepoužil asi taky proto, že v momentě jak se něco takového vystrčí do internetu tak se na to nalepí spousta botů kteří zkouší hesla. Takže heslo musí být složité a špatně se to pamatuje. Asi by šel na to pověsit fail2ban, ale lepší mi přijde botovi dát hned při prvním pokusu najevo, že tu není co zkoušet ať jde o dům dál, než potom dodatečně řešit jako se ho zbavit. Vetšina uživatelů neskáče od radosti ke stropu když musí v hlavě nosit a někam ručně datlovat další složité heslo. Ano moderní prohlížeč si umí heslo zapamatovat, ale to mi už přijde jak řešení následku místo příčiny. S tím šifrovaným https máš pravdu, ale na tom se mi zase nelíbí, že si každá služba vytváří vlastní šifrovací vrstvu a vzniká tak neuvěřitelný bordel s certifikátama. To mi přijde už lepší vytvořit mezi počítačema jeden šifrovaný tunel kterým všecky služby komunikujou napřímo bez nějakých zbytečných mezivrstev. Otázka je, co by vlastně bylo ve finále menší zlo. Jestli jeden tunel s miliónem služeb nebo jedna služba s bambiliónem datových formátů a komunikačních protokolů(dnešní přebujelý hypertext). Něco mi ale našeptává že obě řešení jsou špatně, že nutně musí vzniknout něco, co bude udržitelné dlouhodobě. Taky se vůbec nelíbí představa, že bych měl někomu platit peníze za něco takového jak jméno domény. Uplně to vidím před očima jak naše vnoučata budou za sto let vykládat svým vnoučatům děsuplné historky o tom, jak jejich dědové před sto lety museli platit nelidské středověké poplatky za takovou samozřejmost jako je internet. Věc na kterou má přece každý tvor ze zákona nezadatelné právo

[Jendа]

Vetšina uživatelů neskáče od radosti ke stropu když musí v hlavě nosit a někam ručně datlovat další složité heslo.

No já nevím co máš za uživatele, ale v mém okolí by asi měli lidi docela problém, když máš jako use-case „přijít k novému počítači“, přeložit tvoji normální doménu (IP si nepamatuju) a výsledek zadat spolu s „heslovým“ hostname do hosts. A ti co to dokážou už zase umí používat password manager nebo si heslo bezpečně a jednoduše (bez pamatování) přenést nějak jinak.

Standartní autentizaci jsem nepoužil asi taky proto, že v momentě jak se něco takového vystrčí do internetu tak se na to nalepí spousta botů kteří zkouší hesla.

Museli by případně uhádnout i uživatele, a hlavně já takhle typicky zahesluju jenom adresář, takže by museli uhádnout ten adresář…

[Pepa]

Můžeš to trochu upřesnit? Jak se dostanu z url na nějaký hostname?

[jejda]

Nějak nechápu na co s ptáš. klient při požadavku posílá serveru hlavičku Host. Pokud tato chybí, tak ho server může přesměrovat na nějakou defaultní stránku nebo spojení může dokonce odmítnout. Záleží na tom jak je nastavený.

[Pepa]

Budu tedy potřebovat do prohlížeče stáhnou nějaké rozšíření které mi umožní odeslat jiný název jak Host?

[Jendа]

Ne. Myslí že si dáš do hosts

mojeheslo  171.25.221.158

a svůj server (s adresou 171.25.221.158) nastavíš tak, aby když mu přijde požadavek s Host: mojeheslo, tak vrátil tvoje tajné stránky. Prohlížeč pošle takovou Host hlavičku sám od sebe, protože to vidí jako zadaný hostname.

Problém je že na mojeheslo rozhodně nikdy nezískáš HTTPS certifikát, že takové použití vyžaduje od uživatelů mít admina aby mohli editovat /etc/hosts (nebo pokročilé kouzlení s LD_PRELOAD) a že ho na některých platformách (hlavně mobily) asi neuděláš vůbec.

[Pepa]

když mu přijde požadavek s Host: mojeheslo, tak vrátil tvoje tajné stránky.

no ale stále nevím jak mám odeslat takový požadavek z prohlížeče. Nebo to je dané tou IP adresou? Pokaždé když se připojím na server s 171.25.221.158 tak to vždy vrátí "tajné stránky"? Proč na to nezískám HTTPS certifikát?

[Jendа]

no ale stále nevím jak mám odeslat takový požadavek z prohlížeče

Úplně stejně jakýkoli jiný. Když zadáš do prohlížeče http://abclinuxu.cz/, prohlížeč se zeptá systému, jakou má abclinuxu.cz adresu, systém se podívá do hosts souboru, tam ho nenajde, tak pokračuje další možností a provede DNS dotaz, dostane odpověď že to je 171.25.221.158, prohlížeč se připojí na 171.25.221.158 a pošle HTTP požadavek s Host: abclinuxu.cz.

Když si do hosts souboru napíšeš 171.25.221.158 mojeheslo a pak do prohlížeče http://mojeheslo/, prohlížeč se zeptá systému, jakou má mojeheslo adresu, systém se podívá do hosts souboru, tam najde 171.25.221.158, předá to prohlížeči, prohlížeč se připojí na 171.25.221.158 a pošle HTTP požadavek s Host: mojeheslo.

Na straně serveru se tomuhle většinou říká virtual hosts, a je to běžný způsob jak udělat, aby na jedné IP adrese mohlo běžet root.cz a lupa.cz.

(ale přijde mi to na „zaheslování“ jako bizarní řešení, které bych nepoužíval)

Pokaždé když se připojím na server s 171.25.221.158 tak to vždy vrátí "tajné stránky"?

Ne, cílem je nastavit server tak, aby jako „defaultní virtualhost“ (tj. to co vrátí když mu v Host hlavičce pošleš IP adresu / neznámou věc / nepošleš ji vůbec) vracel nějaké jiné stránky.

Proč na to nezískám HTTPS certifikát?

Protože certifikát potvrzuje, že vlastníš / máš právo nakládat s doménovým jménem, které je tam uvedeno. Tady bys potřeboval, aby v něm bylo napsáno "mojeheslo", ale to jednak nevlastníš, a jednak se vydávané certifikáty zveřejňují (aby si vlastník abclinuxu.cz mohl kontrolovat, že někomu cizímu nebyl vydán třeba nějakým podvodem certifikát pro abclinuxu.cz), takže by se zveřejnil i certifikát s "mojeheslo" a pak by ho všichni viděli.

[Pepa]

Pokud ale zadám do prohlížeče 171.25.221.158 tak se ty tajne stranky taky načtou, ne?

[tttttt]

Ne, cílem je nastavit server tak, aby jako „defaultní virtualhost“ (tj. to co vrátí když mu v Host hlavičce pošleš IP adresu / neznámou věc / nepošleš ji vůbec) vracel nějaké jiné stránky.

[PetebLazar]

Neignorují některé dnešní webové prohlížeče pod záminkou výchozího "DNS over HTTPS" programově soubor hosts?

[Jendа]

Myslím že lokální stále zkouší. A pokud zadáš něco, co nevypadá jako „doména veřejného internetu“, tak zkouší i systémové DNS -- jinak by nefungovaly různé firemní intranety. Ale zkušenosti s tím nemám, nepoužívám to a nebylo to zatím potřeba zkoumat.

[tttttttttttttttttt]

Jestli má MacOS, tak si může zaplatit $20, aby nemusel editovat /etc/hosts na https://www.localcan.com/, no neber to. Aspoň to vygeneruje ty certifikáty.

[Pepa]

Teď jsem to zkoušel ve Windows, importoval jsem certifikát do MS Edge a okamžitě se načetly stránky které jsou chráněny tím klientským certifikátem, žádné už. jméno a heslo to nechtělo a přitom se jednalo o tentýž certifikát.

[Pepa]

Ne. Myslí že si dáš do hosts

mojeheslo  171.25.221.158

Ještě upřesnění, a do prohlížeče zadám jakou adresu? "http://mojeheslo" ? Ještě k tomu SSL certifikátu, když si vygeneruji vlastní certifikát, tak to přes https pojede, ne?

[Pepa]

Chlapy tak co se zadá do té url? Ať to uzavřeme, díky

[X]

To si snad delas srandu ne? Doporucoval bych Dostalek/Kabelova - Pruvodce TCP/IP & DNS. Laskave si nastuduj zaklady.

[Josef Kufner]

Pozor na to, že název serveru jde po HTTPS nešifrovaně (viz SNI).

Adresář náhodného jména v kombinaci s HTTPS je srovnatelně bezpečný jako prosté heslo, ale generovat si hostname jde snadno odposlechnout a podvrhnout.