Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: mikesznovu 07. 09. 2024, 21:07:23
-
Pokud zadám do browseru https (s!) URL s IP místo domény, ukáže se přirozeně "Alert nezabezpečeno,... Nesouhlas certifikátu, a hlavně :server poslal certifikát pro 'skutecnedns.domena.com'
Pokračovat?" (Web tímto způsobem se načte zdárně)
Může nějakým způsobem uniknout název domény, což může být i subject alt name mimo typického CN "do prostoru"? Tím myslím na různé Safe Browning listy, různé směrovací komponenty v chromu atd , črt transparenty , oscp , ... ?
1. Ve fázi před Pokračovat
2. Poté
Jádro dotazů není "dát si dnes záznamy do pořádku", ani tó u 3.stran nemohu ovlivnit, ale dozvědět se, kde může nastat únik toho jména serveru z certifikátu všude ... Ani rady držet se sto honů od http nebo webu bez zámečku.
-
certifikaty jsou na domenu, protoze domena je na jmeno. ip neni nic, na to certifikat nedostanes.
-
IP adresa samozřejně být v certifikátu může. Viz třeba 1.1.1.1 (https://1.1.1.1).
K původní otázce: Server asi může ten certifikát vzít a někde se na něj přeptat. Jestli to ale některý dělá, to netuším. Každopádně všechny certifikáty jsou dnes veřejné, včetně všech doménových jmen. Viz databázi crt.sh (https://crt.sh).
-
K původní otázce: Server asi může ten certifikát vzít a někde se na něj přeptat. Jestli to ale některý dělá, to netuším.
Delaji to naprosto bezne. Viz https://en.wikipedia.org/wiki/OCSP_stapling (https://en.wikipedia.org/wiki/OCSP_stapling).
-
OCSP stapling je technika, kterou používají servery, ne klienti. Server se při tom zeptá autority na svůj certifikát a odpověď pak předává klientům, aby oni sami se ptaním už nezdržovali.
Při OCSP se ptá klient, ale ptá se autority. Čili k nikomu třetímu se informace o certifikátu nedostává. Navíc ani v OCSP neputuje certifikát samotný, ale jen jeho zahašované identifikátory. Celý certifikát není třeba posílat, autorita ho zná.
Asi by bylo dobré, kdyby tazatel doplnil, o co mu přesně jde a popsal konkrétní problémovou situaci.
-
Pokud jde o důvěryhodný certifikát, musí být při vystavení uveden na několika Certificate Transparency seznamech. Nejjednodušší je získat ho odsud. Z prohlížeče nikam unikat nebude, není k tomu žádný důvod.
-
Text je divně napsaný, není jasné, co autor chce...
-
Z webserveru nutně nemusí leakovat certifikát se všemi doménami co obsluhuje. Pro každé jméno/ip si může zvolit jiný a tak prostým scanem na 443 a přečtení nabídnutého certifkátu moc neprozradí.
Ale co je horší, všechny dnes vydané certifikáty se objevují v Certificate Transparency Logu. Možná se k tomu někde dá dostat formou "streamu", že jsou vydávané certifikáty vidět hned teď v danou chvíli, ale minimálně podle domény jdou vyhledávat na https://crt.sh/ (https://crt.sh/) nebo https://sslmate.com/ct_search_api/ (https://sslmate.com/ct_search_api/).
A někdo ta data z toho fakt těží a vy/zneužívá je, protože se setkávám s tím, že mi časem přijdou script-kiddies requesty i na doménová jména, o kterých vím jen já a třeba už tam ani nic neběží, protože to bylo jen něco dočasného.
-
mi to prijde, ze ma strach ze spatne nastavenyho default chovani webserveru, ze nechce odhalit zatim domenu sveho projektu a ma strach aby to nebylo kdyz nekdo pingne IP. Ale to je jen domysleni
-
Název domény může lesknout na spoustě úrovní. Otázka ale je, o co jde – jestli chceme utajit samotnou existenci domény, nebo fakt, že se ten konkrétní klient připojuje na tu konkrétní doménu.
1. Jak bylo zmíněno, certificate transparency doménu prozradí. S wildcardem neprozradí nejnižší úroveň domény.
2. Doménové jméno může uniknout i přes DNS.
3. Umí-li útočník přečíst komunikaci mezi klientem a serverem, může zkoušet přečíst SNI. Tuším, že TLS 1.3 se tomu snaží bránit, ale nevím přesně předpoklady.
4. Z komunikace mezi klientem a serverem bude též známá IP adresa serveru. Když se k ní připojím a dostanú certifikát, opět tam bude doménové jméno.
-
(To jsem ještě psal před v6ak odpovědí))Všechny uváděné důvody/scénáře jsou možné., ale řešim, když přistupuju přes IP adresu (v intranetu,192.168....), tam certifikát nemam. (Doufám,že jsem nepřiložiil pod kotel)
2 scenář: ppřístup na nějaký web, kde browser hází alert (prošlý certifikát,, špatná -outdated cifersjuijte nebo admin byl laxní vytvořit korektní certifikát a je tam něco na způsob "snakeoil")
-
Viz databázi crt.sh (https://crt.sh).
Z toho se mi trochu stáhli půlky. Tak nějak jsem myslel, že domény nejdou listovat. Že pokud budu mít {{UUIDv4}}.example.org, tak dokud nikomu nedám adresu, tak je defakto tajná.
Ne, že bych na to někde spoléhal :D ale spíš takový předpoklad, že je člověk aspoň chráněn od scraperů atd.
U Seznamu to dává i hezký mailing list :o
https://crt.sh/?Identity=seznam.cz
Issuer Name:
C=CZ, O="Česká pošta, s.p. [IČ 47114983]", CN=PostSignum Qualified CA 2
-
No, stále nevím, o co vlastně jde.
a. Útočník se dozví, že doména existuje.
b. Útočník se dozví, že na doménu přistupuje konkrétní uživatel.
Zároveň úplně nevím, jaké schopnosti útočníka uvažujeme:
a. Někdo náhodný bez dalšího přístupu
b. Někdo schopný sledovat provoz v lokální síti, případně jej i měnit
c. Provozovatel nějaké služby (bylo zmíněno Safe browsing), případně stát, který si od něj vyžádá data.
-
Z toho se mi trochu stáhli půlky. Tak nějak jsem myslel, že domény nejdou listovat. Že pokud budu mít {{UUIDv4}}.example.org, tak dokud nikomu nedám adresu, tak je defakto tajná.
To, jestli domény půjdou nebo nepůjdou listovat, záleží na konfiguraci DNS serveru – jestli nemá povolený zónový transfer kamkoli (a jestli nepoužívá zastaralou verzi DNSSEC).
Přes Certificate Transparency jde vylistovat pouze názvy, na které byl vystaven důvěryhodný certifikát. Pokud chcete zabránit úniku nějakého jména, použijte hvězdičkový certifikát.
-
(To jsem ještě psal před v6ak odpovědí))Všechny uváděné důvody/scénáře jsou možné., ale řešim, když přistupuju přes IP adresu (v intranetu,192.168....), tam certifikát nemam. (Doufám,že jsem nepřiložiil pod kotel)
2 scenář: ppřístup na nějaký web, kde browser hází alert (prošlý certifikát,, špatná -outdated cifersjuijte nebo admin byl laxní vytvořit korektní certifikát a je tam něco na způsob "snakeoil")
Neřešte to. Abyste to mohl nějak smysluplně řešit, musel byste nejprve nastudovat, jak funguje komunikace prohlížeče se serverem a jak fungují certifikáty.
To, jestli máte či nemáte certifikát, záleží na tom, zda použijete HTTPS. HTTPS nemůže fungovat bez certifikátu, takže i když použijete IP adresu, pořád vám server musí poslat nějaký certifikát. Ve kterém mohou být DNS názvy i IP adresy.
Když vám prohlížeč hlásí chybu certifikátu, znamená to, že už ten certifikát od serveru dostal. A vychází z údajů v tom certifikátu. Každý, kdo pošle na server stejný požadavek, dostane od serveru stejný certifikát, jako váš prohlížeč.
Každopádně jak už bylo napsáno, pokud je nějaké doménové jméno uvedeno v uznávaném certifikátu, je veřejné dávno před tím, než ten certifikát pošle server nějakému prohlížeči. Pokud to není uznávaný certifikát, takže není na CT listu, záleží na konfiguraci serveru, jaký certifikát pošle na jaký požadavek.
-
No, stále nevím, o co vlastně jde.
...
Co nechapes na cibuli? Proste nechce aby mu na vhost s k897&hdash.neco.nekde .... lezli lidi, co tam nemaj co pohledavat.
A reseni je primitivni ... pouzivat selfsign cert nebo vlastni neverejnou CA. Pokud chces eliminovat moznosti pres dns ... tak hosts.
-
Myslím, že jsem tam možnosti, jak to lze chápat, rozepsal. Pokud je něco nejasného, mohu odpovědět na konkrétní otázku.
Pokud někdo nechce, aby mu na vhost lezli neznámí lidé, řešení je jednoduché – hodit tam autentizaci. Nejspíš to bude řádově bezpečnější i uživatelsky přívětivější.
-
Co nechapes na cibuli? Proste nechce aby mu na vhost s k897&hdash.neco.nekde .... lezli lidi, co tam nemaj co pohledavat.
Co vlastně chce mikesznovu není moc jasné (jako obvykle), ale nemyslím si, že by to bylo to, co popisujete.
A reseni je primitivni ... pouzivat selfsign cert nebo vlastni neverejnou CA. Pokud chces eliminovat moznosti pres dns ... tak hosts.
To, co popisujete, ovšem není řešení. Pokud se tam nemá dostat někdo nepovolaný, je řešením autentizace (jak píše Vít Šesták) nebo alespoň povolení přístupu na základě IP adresy. Přičemž zprovoznit na libovolném webovém serveru autentizaci alespoň jménem a heslem (klidně napevno zadrátovaným v konfiguráku) je asi tak milionkrát jednodušší, než řešit vlastní CA nebo self-signed certifikát.
A kdyby chtěl, aby neunikl název skrze Certificate Transparency, řeší se to hvězdičkovým certifikátem (jak už tu bylo několikrát napsáno). Používat self-signed certifikát nebo vlastní certifikační autoritu pro web je v drtivé většině případů jen zbytečná komplikace, která přinese víc problémů než užitku.
-
No, stále nevím, o co vlastně jde.
...
Co nechapes na cibuli? Proste nechce aby mu na vhost s k897&hdash.neco.nekde .... lezli lidi, co tam nemaj co pohledavat.
A reseni je primitivni ... pouzivat selfsign cert nebo vlastni neverejnou CA. Pokud chces eliminovat moznosti pres dns ... tak hosts.
Ked si odmyslime ze security through obscurity moc dobre nefunguje... ano, obcas je taky use case ak nejde o citlive veci. Netreba ani SS, ani neoficialnu CA, staci pouzit wild card certifikat. Aj Letsencrypt ich ponuka (DNS validacia).
-
Viz databázi crt.sh (https://crt.sh).
Z toho se mi trochu stáhli půlky. Tak nějak jsem myslel, že domény nejdou listovat. Že pokud budu mít {{UUIDv4}}.example.org, tak dokud nikomu nedám adresu, tak je defakto tajná.
Ne, že bych na to někde spoléhal :D ale spíš takový předpoklad, že je člověk aspoň chráněn od scraperů atd.
U Seznamu to dává i hezký mailing list :o
https://crt.sh/?Identity=seznam.cz
Issuer Name:
C=CZ, O="Česká pošta, s.p. [IČ 47114983]", CN=PostSignum Qualified CA 2
Napr.
https://dnsdumpster.com/
Normalni soucast OSINT.
-
...
Jasne jirsaku, a jak asi tak prihlasovani resi to, ze tam lezou boti a snazej se prihlasit a treba jich je tolik, ze to vyznamne zatezuje tu kalkukacku na ktery to jede? Aha, naprosto nijak vid? Nj, ale ty abys taky necemu rozumel, to by sme museli vyhlasit statni svatek.
...staci pouzit wild card certifikat...
Nestaci, protoze to jmeno ti utece jinak, treba pres DNS dotazy klientu. A jako bonus ... spousta ruznych uberaplikaci(treba od soudruhu z MS) ti vynada, ze server nema spravnej certifikat, protoze neobsahuje jeho nazev.
-
Pokud to poběží na veřejné IPv4, boti se na to budou pokoušet připojit velmi rychle, nehledě na doménu. V této chvíli může server mít leda tak prázdný default vhost, aby nevrátil certifikát s doménou, a aby jej tento provoz zatěžoval co nejméně. Ano, pokud si to můžete dovolit IPv6-only, tak se botům můžete bránit lépe.
A pokud jde jen o zátěž od botů, možná by ten trik s wildcardem (jakkoli má svá proti a není to čisté řešení) mohl být dostatečný, pokud to DNS nepropálí. Ano, název domény nejspíš poputuje někde v cleartextu, ale pokud řešíme jen zátěž od bota, který dělá kobercový nálet, pro tvůrce botů asi nebude ekonomické to zkoušet zachytávat po síti.
V neposlední řadě autentizace nemusí být moc náročná na zdroje, zvlášť pokud řešíme jen zátěž od botů. Ano, na kalkulačce si nemůžeme v takovém případě dovolit náročnější derivační funkce.
Ad überaplikace, co nepodporují wildcard certifikát – máte nějaký príklad takové seriózní aplikace z posledních 10 let?
-
Jasne jirsaku, a jak asi tak prihlasovani resi to, ze tam lezou boti a snazej se prihlasit a treba jich je tolik, ze to vyznamne zatezuje tu kalkukacku na ktery to jede?
Porovnání jména a hesla při HTTP Basic autentizaci zatěžuje server podstatně méně, než TLS.
Nestaci, protoze to jmeno ti utece jinak, treba pres DNS dotazy klientu.
To by ty DNS dotazy nejprve musel někdo odposlouchávat a s odposlechnutými názvy pak něco dělat. Navíc self-signed certifikát ani vlastní CA nijak neeliminují dotazy DNS dotazy klientů. A pokud byste chtěl argumentovat použitím /etc/hosts, tím eliminujete ty DNS dotazy, ale nemá to žádný vliv na certifikáty, takže hvězdičkový certifikát stačí a není potřeba si komplikovat život self-signed certifikátem nebo vlastní CA.
A jako bonus ... spousta ruznych uberaplikaci(treba od soudruhu z MS) ti vynada, ze server nema spravnej certifikat, protoze neobsahuje jeho nazev.
To jste si popletl. Těm aplikacím vadí váš certifikát od neznámé certifikační autority (nebo self-signed). Neznám aplikaci, která by používala HTTPS a nerozuměla hvězdičkovým certifikátům.
Nj, ale ty abys taky necemu rozumel, to by sme museli vyhlasit statni svatek.
No tak si ten celoroční svátek dejte a nepište sem. Pro všechny to bude přínos.
-
Ked si odmyslime ze security through obscurity moc dobre nefunguje...
Nesměšujme security through obscurity (peníze mám schované v kůlně na dříví v sudu na obilí, kde by to nikdo nečekal) a defense in depth (peníze mám schované v trezoru v dílně, kde mám fóĺie v oknech, na vstupu zámek na otisk a po cestě kamerku, a nikomu o tom trezorku neříkám).
-
Pro zajímavost, vypadá to, že domény z CT logu nebo certifikátů opravdu boti zkoumají. A to i SAN.
Mám jednu doménu s diakritikou, kterou nikde neinzeruju. Slouží pro situace, kdy někdo při psaní adresu tu diakritiku napíše. Je přesměrovaná na variantu bez diakritiky. (Přesněji, prvně je přesměrování z HTTP na HTTPS, potom až na správnou doménu, aby fungovalo HSTS.) Obě domény mají společný certifikát. A na této doméně nějací boti hledají WordPress, který tam není.
Vidím dva způsoby, jak to mohl bot zjistit:
a. Z CT logu
b. Scan IPv4 prostoru, dostal certifikát, z něj si přečetl seznam domén v SAN.
Jsou tu teoreticky i další způsoby jako sniffování komunikace (přijde mi nepravděpodobné – neefektivní pro necílený útok, navíc se ta doména fakt moc nepoužívá) nebo automatické doplňování diakritiky do domén bez diakritiky (ála proč to dělat jednoduše, když to jde složitě), ale nic tak realistického jako CT logu a scan 443 na IPv4 mě nenapadá.
-
A to i SAN.
Že boti používají SAN je logické, protože prohlížeče nepoužívají nic jiného, než SAN. Samotné jméno v certifikátu je nezajímá (když se přestaly používat EV certifikáty).
-
Jo, ony vlastně dnes prohlížeče už SAN vyžadují. Tak jako tak:
1. Zpracování SAN není nějaké velké překvapení, jen jsem si toho všiml.
2. Odfláknutý bot by klidně mohl číst CN, a fungoval by.