Názory k článku Phishingový útok výměnou IDN znaků v doméně znovu na scéně
Článek je starý, nové názory již nelze přidávat.
-
anon (neregistrovaný) ---.static.orange.sk
tiez nechapem kto toto vymyslel. Povolene znaky A-Z a 0-9 a ziadne kraviny.
inak dost sa smejem, ze v IE11 (a pozeram ze aj v edge) tento "bug" nefunguje a oba prehliadace korektne ukazuju v adresarovom riadky aj pri nabehnuti myskou na linku skutocnu adresu xn--blabla. Co je ale divne, ze ked si kliknem na zamok pre info o cert tak tam uz pise apple.com a epic.com a nie xn--
To akoze firefoxu a chrome ide o co? Su padnuty na hlavu?Ako dobre ze pouzivam vacsinou by default IE :)
-
Starous (neregistrovaný) 2400:4132:9f49:----:----:----:----:----
A co takhle aby registrator udelal dns dotaz na vsechny podobne domeny a pokud uz existuje tak to nepovolil ? Je jedno jestli je registrovana v pakistanu nebo u nas, stejne to pak musi byt dohledatelne pres dns. Podobnost se da definovat jako pocet stejnych znaku s tim ze se berou v potaz i pismena co vypadaji stejne - pak uz staci nastavit jenom nejaky treshold. Trebe ze ápple.com nebo cokoli kde je jen 1 jine písmeno neni v poradku ale napr aaapple.com uz ano. Proste trochu zmenšit adresní prostor. Nevyřeší to vše ale ty největší zvěrstva by mohlo...nebo treba vyuzit databazi certificate transparency a hledat jestli tam uz neni podobna domena ? Hmm ? Phishing stejne miri predevsim na https weby...
-
a1ds (neregistrovaný) ---.19.broadband15.iol.cz
rika se tomu Hummingova vzdalenost.
Ale fungovat to nebude, prijde vam tohle podobne?
https://www.xn--80ak6aa92e.com/ (https://www.apple.com) -
Petr M (neregistrovaný) ---.145.broadband16.iol.cz
Jo, tak se na ten genitální nápad podíváme.
1) Potřebuješ substituční tabulku. Ta definuje znaky se stejnou grafickou reprezentací, jako A a %ALPHA%, že V v azbuce vypadá jako B a podobně.
2) Potřebuješ seznam subdomén v dané doméně
3) při požadavku procházíš doménu po doméně, znak po znaku a kontroluješ, jestli požadavek nekoliduje s něčím v substituční tabulce. Triky s hash table apod. ti nepomůžou.
4) Po nalezení shody musíš zkontrolovat, jestli požadavek dal ten, kdo si registroval původní doménu.A teď si vem, v tabulce bude tak 300k kolizních párů znaků (střeleno od boku) , TLD má řekněme 500k domén sse stejnou délkou jména, jakou má požadavek... Jak dlouho se ti bude hledat kolize? Jak silnou mašinu potřebuješ na ověření řekněm 5 požadavků/s s předpokladem 99% legitimních? (počítej, že se iteruje přes databázi, do RAMky to nenarveš).
-
Petr M (neregistrovaný) ---.145.broadband16.iol.cz
Btw, bude třeba tenhle registrátor cokoliv ověřovat? Jaká je šance ho k tomu donutit?
-
Petr M (neregistrovaný) ---.145.broadband16.iol.cz
Jasně, registr ověří, ale jak a na základě čeho?
Řekněme, že registr má super duper funkci, která zachytí spolehlivě shodu s jinou doménou v registru, která v adresním řádky vypadá stejně. Funkce vyplivne 80% shodu. Je to dost na zakázání, nebo ne? Pokud je požadavek legitimní, nehrozí spory?
A pokud není proces ověření na 100%, lumpárna s registrací projde, tak co? Pude aspoň klepnout přes prsty lumpa? Nepude, registr se pokusil udělat maximum, n-tý registrátor v řetězci je v tramtárii...
Furt je lepší, než se spolehnout na registr/registrátora, je nepřipustit situaci, kdy je potřeba cokoliv z jejich ověřovat. IDN prostě nedává smysl. Buďto se zobrazí znaky, ale to nepoznám A od ALFA nebo C od ruskýho S a dostane na prdel bezpečnost, nebo se zobrazí hatmatilka a v tom případě nevím, kde je smysl čitelnějšího a použitelnějšího DN.
-
Moje odpověď „Pravidla registrace musí být vynucována na úrovni registru.“ patřila k otázce: „Btw, bude třeba tenhle registrátor cokoliv ověřovat? Jaká je šance ho k tomu donutit?“.
Pravidla registrace domén je možné průběžně měnit v reakci na podobné hrozby. Rozhodně si myslím, že „oprava,“ se kterou teď přicházejí prohlížeče, měla spíše přijít ze strany pravidel registrace. Implementovat podobnou logiku do každého DNS klienta je cesta do pekel.
-
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
2Petr M: Taky potrebujes aby ti maminka chodila na zachod utirat ? ... moh by sis potencielne umazat tlapku ...
... je to vyhradne o debilite uzivatele, pokud nekdo do adresy adresu napise, tak zadnej problem nema. Kdyz lezu do banky, tak tam rozhodne nelezu pres nakej odkaz z mailu ...
-
Funkce vyplivne 80% shodu.
Proč byste to řešil jakousi podivnou fuzzy funkcí? Daleko jednodušší je určit pravidla, která budou vracet ano/ne – doména je v konfliktu s jinou registrovanou doménou, nebo není. Stačí pár pravidel:
1. Všechny znaky v doméně kromě pomlček musejí být z jedné znakové sady.
2. Povolené jsou jen znakové sady národních a jiných abeced (tj. žádné smajlíky, šipky, matematické symboly).
3. Z každé znakové sady je povolená jen vybraná množina znaků (např. z latinky jen malá písmena, tj. nejsou povolená velká písmena, slitky apod.).
To jsou pravidla, která jsou nezávislá na ostatních registrovaných doménách. A pak se definují skupiny zaměnitelných znaků – pro generické domény by to byly stejně vypadající znaky, třeba pro TLD .cz se většinou předpokládá, že zaměnitelné znaky by byly znaky s diakritikou a odpovídající znak bez diakritiky (třeba e, é, ě). A toho se využije ve čtvrtém pravidle závislém na jiných registrovaných doménách:
4. Doménu, která se liší od jiné registrované domény jen v zaměnitelných znacích, může zaregistrovat jen majitel té jiné domény.
To je to pravidlo, které by třeba v TLD.czumožnilo domény zive.cz, živě.cz, živé.cz a zíve.cz zaregistrovat jen jednomu majiteli, stejné pravidlo by zafungovalo i pro ten pravý a falešný apple.com. -
NULL (neregistrovaný) ---.freepoint.cz
Ano, a protože se jednou nějaký markeťák ráno vzbudil a řekl si, že ěščřžýáéůúť .... v doméně spasí obrat firmy, tak budeme jak blbečci neustále filtrovat domény, vymýšlet tabulky a slovníkové fuzzy funkce aby se nedalo šmělit s dalším paklem překlepovek. Ještě že takhle onehdá nevymýšleli žebřík nebo kolo . . .
-
Snažili se uchránit uživatele před angličtinou a hodili je někomu do sítě.
Nestačilo by zobrazit "zabezpečeno | https://www.xn--80ak6aa92e.com/ (https://www.apple.com)"?
Stejně se mi nelíbí i nápady schovávat https a www. To už by mohly adresní řádek schovat úplně. Ňoumové ho stejně nepoužívají a píší všechno do hledací řádky seznamu (nebo jiného místního vyhledávače). -
IDN jsou identifikátory pro uživatele, zobrazovat cokoli jiného než IDN je nesmysl, protože uživatel neví, o co jde. Pokud se doménové názvy mají používat jako identifikátor (tak už to je a už to nikdo nezmění), musí registry nastavit pravidla pro to, aby nebylo možné vizuálně podobné domény registrovat. U národních domén je to docela snadné, generické domény to budou mít komplikovanější, protože to znamená blokovat registrace v závislosti na již registrovaných jménech. Protože legitimní je registrace domény apple.com i аррӏе.com, záleží jen na tom, kdo přijde první.
Na webu pak samozřejmě také pomůže, až bude HTTPS všude a doménové certifikáty se budou kontrolovat bez asistence uživatele, a zabezpečení navíc budou OV a EV certifikáty, jejichž jméno se bude u adresy zobrazovat. Pak se uživatelé naučí, že u důležitých webů musí být zobrazené správné jméno. Je nereálné chtít po uživatelích, aby kontrolovali vše, co by měli kontrolovat dnes – HTTP vs. HTTPS, DV certifikát vs. OV vs. EV, ASCII doména vs. IDN… -
ak (neregistrovaný) ---.19.broadband15.iol.cz
> DN jsou identifikátory pro uživatele, zobrazovat cokoli jiného než IDN je nesmysl, protože uživatel neví, o co jde.
nesouhlasim, kdyz kliknu na apple.com (a chci na ascii apple.com), browser by mi mel zobrazit jak navrhoval kolega vyse: apple.com: (xn-idn-garbage-blabla) ---a ja si posoudim, jestli jsem chtel na ascii verzi, nebo na tu idn
-
anon (neregistrovaný) ---.static.orange.sk
pouzivatel sice nemusi vediet co je xn-- a ani mu to netreba vediet, pretoze ked bude v browser vidiet ze je na xn--lalalla namiesto www.mojabanka.sk tak to dojde uplne kazdemu ze oops nieco je zle...
nechapem co si chcel povedat tym ze mozes mat domenu zapisanu na papiery, to akoze ked budes z papiera opisovat apple.com tak sa mozes pomylit a napisat to vazbuke a dostanes sa na fake apple.com ???
-
Ne, když se uživateli zobrazí změť znaků, tak si bude myslet, že je to nějaká úprava prohlížeče, nebo dokonce že je to nějaké zabezpečení.
Navíc celé IDN vzniklo kvůli tomu, aby se mohly používat lidsky čitelné názvy, takže zobrazovat punnycode je jaksi krok zpět. To můžete taky rovnou vylepšit tak, že se nebudou používat DNS názvy ale IP adresy.
Domény se dnes používají jako identifikátory, zdaleka je nepoužívají jen webové prohlížeče. Takže bránit se není možné na straně prohlížečů, ale je potřeba zařídit, aby jako identifikátory skutečně fungovaly – tj. kolizní domény nesmí jít ani zaregistrovat.
Z papíru ten identifikátor nemusím opisovat, ale můžu ho třeba kontrolovat. Opíšu třeba adresu http://bit.ly/12345 a pod tím budu mít, že mám zkontrolovat, že jsem byl přesměrován na adresu sales.europe.apple.com. Podstatné není to, že je to na papíře, ale že je to jednoznačný identifikátor, který je takhle někde daný a nebude tam možnost převádět to na punnycode. Ta adresa může být v PDF dokumentu, v e-mailu, v komentáři na Rootu – není možné tam všude implementovat převádění domén na punnycode. A nedávalo by to žádný smysl. -
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Uzivateli je uplne urite co se mu zobrazi v url ... kdyz se ho to zepta na pin ke karte, tak ho zada ... kdyby takovych debilu nebyly miliony, tak myslis ze by se vyplatilo rozesilat spam?
Co myslis ze ti reknou v bance (zcela libovolny) kdyz ti browser nebo cokoli zacne hlasat, ze certifikat je ... revokovanej/expirovanej/....cokoli ... ??? Reknou ti, abys to odklip.
-
Mimochodem, ta pravá doména Apple.com má ve skutečnosti EV certifikát. Bohužel, jde o certifikát od Symantecu, který Chrome za EV nepovažuje.
Pak je ještě otázka, jestli by náhodou nebylo možné získat EV certifikát i pro falešnou doménu. Třeba založit ruskou firmu s takovým názvem a jejím jménem o certifikát požádat.
-
To už by si měl zařídit Apple, certifikační autoritu vyměnit a požadovat od Symantecu nějaké odškodnění. To je holt součást trestu pro tu certifikační autoritu, když nebyla schopná zajistit důvěryhodnost. Ostatně to, že od ní budou odcházet zákazníci, je jediný skutečný trest – změna důvěryhodnosti v prohlížečích je jen prostředek, jak toho dosáhnout.
EV certifikáty by neměly být jen dražší a možná trochu přísnější ověření daného subjektu, ale měly by zajišťovat i právě i ochranu (registrovaných) značek apod. To je jediný smysl, který můžou EV certifikáty mít.
Akorát se trochu bojím, kdy se toho pročištění certifikačních autorit dočkáme. Vedlo by k tomu rozšíření DANE, kdy by přestaly mít smysl DV certifikáty a certifikační autority by se musely začít zabývat tím, jak za ty peníze poskytovat skutečně něco důvěryhodného. Jenže prohlížeče DANE bojkotují, což vedlo ke vzniku Let's Encrypt a tedy k přesně opačnému tlaku na autority – vydávat co nejvíce certifikátů s co nejnižšími náklady. Doufám, že tahle zajížďka nebude trvat moc dlouho…
-
Podle mě obyčejný uživatel nemá o EV certifikátu potažmo "zeleném adresném řádku" moc tušení. Zkoušel jsem najít, zda někdy vůbec zkoušel udělat o tom průzkum (třeba CAB fórum), ale nenašel jsem žádný výsledek.
EV certifikáty se posuzují dost striktně vůči velmi známým značkám - CA mají blacklist a něco, co se podobá na apple nebo paypal neprojde (minimálně v gTLD jako .com, .net apod). Nicméně pro nějakou bohem a finančním úřadem zapomenutou firmu v Jakazačistánu to nikdo takhle podrobně ověřovat nebude, zda je to "Ahmed's Cars and Used Certificates" nebo její konkurent "Ahmed's Teapots and Used Certificates".
-
Petr M (neregistrovaný) ---.145.broadband16.iol.cz
Asi tak.
Současný přístup k IDN je stejnej, jako když schovávaly Widle přípony a přípona byla to jediný, co rozhodovalo, jestli se při double clicku soubor spustí, nebo otevře v nějakým programu. A furt se řešilo, jak BFU mají poznat, co je to za soubor...
-
http://www.yoynam.sk/ dlhodobo vyuziva zmatenie z povodne nemeckeho qwertz rozlozenia
-
karel (neregistrovaný) ---.net.upcbroadband.cz
Celkem jednoduše ta doména se začne objevovat třeba v podvodných emailech, to by mohlo stačit, já neříkám, že registrátor má takové domény aktivně hledat, ono stačí až by je nahlásil některý z národních cisrt teamů místo toho, že na své stránky do novinek napíšou pozor na emaily od .... vedou na podvodné stránky.
-
karel (neregistrovaný) ---.net.upcbroadband.cz
Ano to by byl ideální stav, ale to jaksi nefunguje.
Úplně ideální by byla kombinace, snažit se o odhalení při registraci a v případě, že už se něco stane tak na to reagovat blokací.
Jinak proto jsem navrhoval veřejný blacklist, ze kterého by mohly čerpat jiní registrátoři. Také by se hodil na vytvoření algoritmů pro odchytávání i při registraci. -
Jakmile to budete porovnávat ručně, bude to drahé a neprůhledné. Neustále se s váma někdo bude soudit, proč jste tohle povolil a tohle nepovolil. Neustále to někdo bude zkoušet – tohle neprošlo, tak zkusíme něco mírně odlišného. Ne, takhle by to nikdy fungovat nemohlo.
Jediné, co může fungovat, jsou jasně daná pravidla, která půjde algoritmem vyhodnotit. Unicode je jasně definovaná znaková sada, význam každého znaku je v ní definován, znaky jsou rozdělené do různých skupin. Takže není problém nadefinovat pravidla, která z toho budou vycházet. Třeba i s tím, že se nejprve definují velmi restriktivní pravidla (jen jedna skupina znaků na doménu, úplně se vyloučí používání znaků, které vypadají jako ASCII znaky apod.).
Sofistikované útoky jsou vedené proti konkrétním cílům, takže nemůžete spoléhat na to, že se to provalí kvůli masovému používání. Když si zaregistrujete doménu аррӏе.com, pošlete na ní odkaz jedinému člověku, po úspěšném napadení zrušíte delegaci DNS serverů a za rok ji necháte propadnout, nikdy se na tu doménu nepřijde. -
Proč by se to porovnávalo v nějakých fontech? Já jsem psal o Unicode znacích. Na to, že „CYRILLIC SMALL LETTER A“ asi bude vypadat stejně, jako „LATIN SMALL LETTER A“, nepotřebujete žádné zobrazení. A pokud už chcete něco porovnávat vizuálně, ty znaky máte zobrazené ve standardu, to je směrodatné. Třeba tu cyrilici najdete zde: http://www.unicode.org/charts/PDF/U0400.pdf.
-
SB (neregistrovaný) 78.156.151.---
Osobně si myslím, že registrátor by neměl odchycovat vůbec nic, zavádí to do systému nedeternimistický bordel a subjektivní posuzování. Jedná-li se technicky o různé domény, pak různými jsou (bez ohledu na překlepy či fonty) a je každého volba či blbost, zda si vybere doménu, ke které se dobře dělají domény podobné. Vedle toho má být uživatel zřetelně upozorněn (v prohlížeči, nyní už i v emailu) na skutečný (technický) zápis domény (který je jediným správným). Není možno donekonečna řešit problémy za líné lemply.
-
Osobně si myslím, že registrátor by neměl odchycovat vůbec nic, zavádí to do systému nedeternimistický bordel a subjektivní posuzování.
Není žádný důvod, aby to bylo subjektivní a nedeterministické. Současné pravidlo v TLD .cz, že nelze registrovat IDN, je deterministické a není subjektivní. Bylo by takové i předpokládané pravidlo, že IDN variantu domény může zaregistrovat jen vlastník odpovídající ASCII domény (která vznikne deterministicky tím, že se z IDN varianty odstraní veškerá diakritika). Stejně se dají definovat pravidla i pro generické domény, a v diskusi byly návrhy uvedeny.Vedle toho má být uživatel zřetelně upozorněn na skutečný (technický) zápis domény
Uživatele technický zápis domény nezajímá a nerozumí mu. Technika je od toho, aby řešila potřeby lidí, ne od toho, aby se jí lidé přizpůsobovali. Stejně tak byste mohl chtít, aby se uživatelům zobrazoval skutečný (technický) zápis webové stránky, tj. HTML kód. -
... jak si má registrátor prohlížet PDFko?
Cože, proč by si měl PDFko prohlížet registrátor? To je snad naprosto zřejmé, že ke grafické podobě znaků se dá dostat i jinak, než otevřením jednoho konkrétního PDFka. A jejich podobnost může posuzovat program při <b>sestavování</b> tabulky podobných znaků. Tedy při <b>kompilaci</b> nástroje, který by identifikoval homografní domény. -
TKL (neregistrovaný) 109.224.74.---
Myslím, že by stačilo, kdyby prohlížeče při pokusu o přístup na takovou adresu zobrazily něco jako:
Pozor! Chystáte se navštívit stránku, jejíž adresa je v jiné znakové sadě, než jakou používáte vy a může se vám tedy zobrazovat jinak. Vaše zobrazení: www.apple.com Skutečné zobrazení: www.xn--80ak6aa92e.com
Opravdu chcete tuto stránku navštívit? ANO | NE
Podobně Firefox už nějakou dobu upozorňuje na zadávání přihlašovacích údajů při nešifrovaném spojení. Chrome zase nějak takhle varuje před návštěvou webu s malwarem. Tak proč nepřidat další varování? Připadá mi to jednodušší, než vymýšlet technické způsoby, jak uživatele ochránit, což může být občas i kontraproduktivní.
-
vodnik (neregistrovaný) ---.ujezd.net
Co srbština? Používá latinku i cyrilici zároveň. Co když budu mít prostředí v arménštině, ale budu navštěvovat anglicky psané weby? A pak tu máme několik případů, kdy dvě různá písmena v latince vypadají stejně, ale v Unicode jsou to dva různé znaky (třeba Ð/Đ, jejich malá písmena jsou ð/đ).
-
fela (neregistrovaný) ---.dynamic.orange.sk
Kazachstan prechádza od azbuky k latinke. Nakoľko spolupracujem s Rusmi či Kazachmi, ja to len vítam. Jednak sa budeme jednoduchšie dorozumievať, a tiež odpadne ten nepekný mix znakových sád, ak im človek posiela ponku, kde napr. stroje sú napísané latinkou a zvyšok textu vb azbuke... Dtto Srbsko (časť)...
-
Azbuka není o nic lepším či horším písmem než latinka.
Pouze filozoficky. Prakticky je každé písmo, které není latinka horší než latinka, právě proto, že dnešní počítače a programy byly vyvinuty v prostředí používající latinku (respektive její nediakritickou část). To je darwinovská evoluce v praxi. Latinka si vyvinula evoluční výhodu (počítače a programy) a teď vytlačuje ostatní písma.
-
Pro zajímavost, generátor homografů (nebo jak se tomu česky).
http://qaz.wtf/u/convert.cgi?text=root.cz -
Tady je jeden, který je přímo šitý na míru IDN: https://www.irongeek.com/homoglyph-attack-generator.php
-
belzebub (neregistrovaný) 82.142.76.---
IDN JE CISTE ZLO!Popravde me prekvapuje, ze se o tomhle pise az ted... ale prijde mi absolutne silene, ze v unicode jsou pravdepodobne DESITKY symbolu, ktere jsou prakticky IDENTICKE, nicmene maji jiny kod.
Mimochodem - nekolikrat jsem silel nad tim, proc nejaky kus kodu co jsem zkopiroval z webu NEFUNGUJE, jenom abych po 2h absolutniho zoufalstvi zjistil ze uvozovky nejsou vzdycky uvozovky... KDOKOLIV kdo podporuje unicode v programovacich jazycich jinde nez uprostred stringu v uvozovkach si zaslouzi facku!
-
adx (neregistrovaný) ---.t-mobile.cz
Psalo se o tom tuším již kolem roku 2000 (vzpomínám si že příkladem byla doména paypal.com). S tím že je to velký problém a musí se to nějak vyřešit. Do té doby IDN nebude.
Koukám, že se to nijak nevyřešilo. A IDN je.
Zase někdo chtěl páchat dobro za každou cenu a vyšel mu z toho prakticky neřešitelný průšvih.
Nejspíše to dopadne tak, že po prvních velkých aférách to začnou prohlížeče zobrazovat jinak než UTF8 písmenky. (a celé IDN tím bude popřeno). Nebo to nějak vybarvovat a upozorňovat (další otravování uživatelů).
Zakázat a basta. Kdo chce používat Internet, ať se naučí latinku. Nebo ať si vynalezne svůj.
IDN je užitečné je to akorát pro podvodníky a zločince. -
j (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Ve skutecnosti se to davno vyresilo, protoze to zadnej problem neni, dela se tu halo kolem velkyho hovna....
Protoze 99,999999% lidi je uplne uprdele, jestli si kliknou na ceskasporitelna mebo ceskakradatelna .... kdyz to to bude chtit jejich heslo, tak ho zadaj.
Tovize jo, tech 6G cinanu, indu, japoncu, arabu ... se kvuli tobe bude ucit psat nejakejma bukvama ...
-
Petr M (neregistrovaný) ---.145.broadband16.iol.cz
Jo, aktorát že
- Čína - silně proexportní, povinná angličtina na škole, není problém.
- Indie - bývalá britská kolonie. Problémy se samostatnou prací bez dozoru, ne s latinkou.
- Japonsko - silná ekonomika, která vyrostla na exportu do USA, takže ASCII / US English není problém
- Arabi - ti ať si klidně IDN nechají. Aspoň jim to zkomplikuje verbování do IS.
- Rusi - taky mám pocit, že je ve škole povinná anglina.
...Takže pro IDN v DNS fakt nevidím důvod.
-
To, že se někde povinně učí angličtina přece neznamená, že tamní obyvatelé v běžném životě angličtinu používají. České weby se taky nejmenují anglicky, i když spousta Čechů anglicky umí.
Podle mě je základním kritériem, jaké znaky lze snadno napsat na místní klávesnici. Pokud je potřeba nějaké úsilí k přepnutí do latinky, pak je určitě na místě používání IDN. Ale ideálně samozřejmě v IDN TLD, i když pro
.comurčitě existuje nějaká zkratka. -
SB (neregistrovaný) 78.156.151.---
Angličtina se svou abecedou není nijak výsadní jazyk (přestože si to někteří myslí), není to tak dávno, co za mezinárodní jazyk platila francouzština. Nikde není psáno, že angličtina nepůjde za 10 let do pr-dele a nebude tu ruština nebo čínština (tu bych teda fakt nerad). Co budete dělat s DNS pak?
Přeloženo: Postavit IT výhradně na angličtině bylo chybou a ještě doteď se z toho svět nevyhrabal. -
SB (neregistrovaný) 78.156.151.---
„...prijde mi absolutne silene, ze v unicode jsou pravdepodobne DESITKY symbolu, ktere jsou prakticky IDENTICKE, nicmene maji jiny kod.“
Obávám se, že zde půjde o absolutní nepochopení kódování - kód určuje význam znaku, ne jeho vzhled. To, že jsou 2 znaky vizuálně shodné, může být čirou náhodou, přičemž za 10 let to už o nich nemusí platit. -
Jenže toto nepochopení se táhne napříč veškerým softwarem. Uživatele nezajímá, jestli kouká na 'a' v latince nebo v azbuce. Takže například pro doménová jména se nikdy neměl začít používat unikód, který rozlišuje význam symbolů, ale jiné kódování, které by znakům se se stejným nebo podobným vzhledem přiřazovalo stejný kód.
Unikód je psán tak, aby "jednoznačnost" byla na straně dokumentu a ne jeho zápisu. Doménová jména mají mít ale jednoznačnost naopak na straně zápisu a ne na straně té které domény. -
Pokusím se to napsat trochu jasněji:
Unicode byl vymýšlen tak, aby dva (graficky) různé dokumenty měly různý zápis. I za cenu toho, že v některých případech několik různých zápisů dává stejný dokument.
Doménové jméno by mělo být přesným opakem. Jeden dokument(doména) musí mít právě jeden zápis, jinak nám v URI vypadává to U. A protože si URI předáváme tak, že ho napíšeme na papír (nebo nakreslíme do obrázku, youtube videa ...), tak by mělo být jednoznačné i graficky. A přesně tohle je bezhlavým zavedením IDN porušováno. -
Takže například pro doménová jména se nikdy neměl začít používat unikód, který rozlišuje význam symbolů, ale jiné kódování, které by znakům se se stejným nebo podobným vzhledem přiřazovalo stejný kód.
To máte pravdu, ale komplikovalo by to, že by bylo nutné tohle nové kódování udržovat v návaznosti na změny v Unicode. A navíc zavádět nové arbitrární kódování – jako by jich už dnes nebylo moc… Navíc byste musel udržovat mapování mezi Unicode a tímhle kódováním, a byl by problém při převodu mimo domény – když někdo zkopíruje adresu apple.com z adresního řádku webového prohlížeče do textového dokumentu, jaké znaky by se tam měly objevit? Latinka nebo cyrilice? Podle mne je to současné řešení lepší, akorát si musí správci jednotlivých domén určit pravidla, které znakové sady jsou přípustné (což dělá většina ne-li všichni správci národních domén), správci generických domén (u kterých se dá předpokládat velké množství povolených znakových sad) by pak měli přidat pravidla pro zamezení registrace domén s ekvivalentními znaky (což můžou udělat i správci národních domén a třeba v TLD .cz se to předpokládá). -
SB (neregistrovaný) 78.156.151.---
To nejde. Význam a vzhled znaku jsou 2 různé věci. A s unicodem to nemá co dělat, i v rámci jedné abecedy existují podobné znaky, (třeba I a l).
Tak vzhledem k tomu, že DNS vzniklo jako lidské pojmenování pro adresu, tak se předpokládá, že budou použity existující abecedy, které své jednoznačné kódování již mají (přestože je zde vůle jej skrýt za každou cenu). Z tohoto pohledu omezení na jednu abecedu jde proti smyslu DNS. Vlastně se říká: Pokusíme se zapsat adresy lidskou řečí, ale nesmí to být zase moc. Řešení pro lidi tak zůstalo na půl cesty. Ale jestli se neanglicky mluvící lidi mezi lidi nepočítají, tak je vše v pořádku. -
emsik88 (neregistrovaný) 178.18.75.---
V .CZ nie sú háčky a čárky?? a čo je potom https://www.lepší.tv/ ???
-
Díky Kapitáne! :D
Pro úplnost dodám, že i v .CZ TLD můžete mít za určitých okolností IDN, třeba ondřej.caletka.cz.
-
Konkrétně lze použít IDN pro každou doménu 3. a vyššího řádu pod TLD
.cz, resp. obecně pro každý doménový název, který už si vytvářím na svém DNS serveru (tj. třeba pod.co.ukto budou až domény 4. řádu). Což je jenom další důvod, proč je odkládání zavedení IDN přímo pod TLD.cznesmyslné, a povede to akorát k tomu, že se to bude zavádět narychlo až o tom „rozhodne“ někdo jiný, zatímco teď si pořád ještě může CZ.NIC zavedení naplánovat. Teď se jenom čeká na to, až se o IDN dozví nějaký markeťák a použije IDN pro to, aby se jeho značka odlišila. -
Lol Phirae (neregistrovaný) 2001:470:6f:----:----:----:----:----
To, že vy to nepotřebujete, není důvod, proč to nedovolit ostatním.
To jistě. Zato to je tu asi tisíc jiných dobrých důvodů, proč podobnou pitomost nezavádět. Svoji doménu s podobnými kravinami si můžeš zaregistrovat u konkurence CZ.NIC.
-
JA (neregistrovaný) ---.cust.nbox.cz
Co se mysli tim "U ostatních prohlížečů taková cesta neexistuje" .... jakoze u IE a Edge se to nastavovat nemusi, protoze to zobrazuji korektne??? A hlavne LOGICKY, pokud jde o jine kodovani nez vychozi, tak je snad jasne, ze ma zobrazit dlouhou formu zapisu, aby se to nepletlo. Se divam na statistiky prohlizecu a ten chromy paskvil ma skoro pulka lidi, to fakt nechapu ....
-
Když už prohlížeče zobrazí punnycode, když se míchají různé znakové sady, proč nezobrazí nějaký identifikátor znakové sady, když je použitá jen jedinná?
Celý problém je v tom že jarr!je v cyrilici vypadá stejně jako apple v latince, a uživatel nevidí zda se dívá na cyrilici nebo na latinku. Tak proč nezařídit aby to uživatel věděl? -
SB (neregistrovaný) 78.156.151.---
Pravdou je, že použití vzdálených znaků v doméně by mělo být zřejmé na první pohled, neboli nějak rozlišit vizuálně znaky, aby v případě podobnosti byl znát rozdíl. Uvedení punycode je určitě možností (která padne, až přejde DNS na unicode), ale např. je možné obarvení znaků - drtivá většina domén by byla jednobarevná, strakatá doména by byla jasně viditelná a podezřelá.
-
Zkousel jsem na nasi hodne predprodukcni verzi https://fireboxxx.cz/#uvod a na fake apple.com jsem se nedostal.Jak pokrocime radi zapujcime k testu za vasi zpetnou vazbu. Staci nechat vas kontak dole na odkazovane strance. Dekuji Pavel
-
karel (neregistrovaný) ---.net.upcbroadband.cz
Tady každý nadává na to jaká je to blbost a jak je to snadno zneužitelné. Přitom už dneska se podobné útoky dají použít i bez IDN. Stačí záměny l1I, 0o apod, které jsou v některých fontech těžko odhalitelné. A přesto se podobné útoky zas tak často neobjevují. Je to čistě technický problém, který se dá rozumně řešit pomocí nastavení pravidel registrace. A pak konečně budeme moct psát česky a cesky. Je to jenom neschopnost/neochota to vyřešit a domluvit se na rozumných pravidlech.
-
. . (neregistrovaný) ---.aoj.io
asi bychom měli začít weby identifikovat podle něčeho jiného než podle domény. Je nereálné, aby si každý přesně zapamatoval všechny domény, na které pravidelně chodí a které jsou zásadní při zneužití.
Tady se řeší záměna podobných písmen, přitom člověk se nechá obelhat i při změna jejich pořadí.
EV certifikáty jsou také matoucí, copak já vím, která společnost je za kterým webem? Už je to ale daleko lépe dohledatelné a ověřitelné.
-
EV certifikáty jsou také matoucí, copak já vím, která společnost je za kterým webem?
OV a EV certifikáty ale mají přesně opačnou funkci – neznám web ale znám společnost. Víc smyslu to dává u starších společností, internetové firmy už se většinou rovnou identifikují se svou doménou.Záměna pořadí písmen je zajímavý problém, podobně jako velké množství TLD. Ale podle mne to nemá řešení na straně identifikace – podle mne by to nezachránila ani žádná jiná identifikace webů (lidé si přeci jen nejlépe zapamatují slova, a ta už se – co do možnosti snadné identifikace – v doménách používají).
Na důležité weby se uživatelé často přihlašují, správce hesel si domény nepoplete – to je jedno z možných řešení. Ale obecně se tomu musíme naučit bránit stejně, jako podvodům v off-line světě.
-
. . (neregistrovaný) ---.aoj.io
Ano, tohle nikam nevede, spoléhat na to, že uživatel 100% pozná doménu je alibismus. Demonstrací, kdy i špičkám v oboru se úspěšně podvrhla nastražená doména jsem viděl několik.
Musíme zrušit hesla, resp. uživatelsky zadávaná hesla, správce hesel by se měl stát chráněnou součástí systému stejně jako antivirus a stroje se budou ověřovat sami mezi sebou, záměna domény pak nebude hrát tak velký vliv. Vidíte někdo jinou cestu?
Ve firemní světě už jsou běžné čipové karty v noteboocích, zadávání hesel se pomalu vytrácí nebo funguje jen jako fyzická ochrana před zneužitím stanice.
-
Clock (neregistrovaný) 175.100.61.---
Mě popisovaný problém nenastává. Jeden website se mi zobrazuje jako xn--něco, druhý jako apple. Ono to totiž závisí prohlížeč od prohlížeče. Myslím si proto že to není problém IDN nebo certifikátů, ale jednotlivých prohlížečů.
Na Linksu problém nenastane, na Firefoxu ano.
-
ebik (neregistrovaný) ---.net.upcbroadband.cz
Už má nějaká verze Linksu CSS? Zrovna jsem si zkusil ROOT otevřít v Linksu, číst se to se zatnutými zuby dá, ale je to hoodně spartánské. Většina webů dopadne bez CSS daleko hůř, lidi si dnes "naked" weby otevírají jen pro zábavu, místo toho aby udělali web alespoň vzdáleně přístupný i nevidomým.
P.S. Tuto odpověď schválně píšu v Linksu (grafické verzi), ale hned jak to zavřu, tak se vracím k mému firefoxu s pentadactylem. (Jako jediný má rozumné ovládání, tedy Vimové)
-
Spousta toho, co mi server zalogoval, jsou nesmysly, co lidi omylem napisi cesky do adresniho radku prohlohlizece. Jednie snad toto: www.xn--lep-tma39c.tv, www.xn--cyklistickdres-4sb.com, www.xn--sandstdcycling-vqb.dk plus nejake odkazy na weby v japonstine a bulharstine. Celkove tak 10 skutecnych pripadu za hodinu.
-
- Konzultant/ka zákaznického centra O2 - SMB Specialista
- Odborný pracovník pro IT
- KOTLIN Developer Junior i Senior
- Lead Programátor pro ERP systém MONEY, v C#.NET Core
- SAP ABAP junior developer
- Customer Success Specialist pro Teamio (náborová aplikace)
-
- Úvod do řízení kvality
- Vzdělávání jako součást života
- Akviziční telefonáty pro zákaznická centra
- Jak správně prioritizovat
- Emoce pod kontrolou II – 5 kroků ke zvládání emocí
- Zkrácená historie etikety a proč se jí zabývat
-
- IT TECHNIK
- Konzultant O2 prodejny (m/ž) - Břeclav
- Konzultant O2 prodejny (m/ž) - Znojmo
- ⋙ IT Support - přesah do businessu ⋘
- Backend Engineer (Java) pro FinTech Scale-up
- KOTLIN Developer Junior i Senior
-
- Úvod do řízení kvality
- Vzdělávání jako součást života
- Kalendář na maximum
- Akviziční telefonáty pro zákaznická centra
- The End of Procrastination
- Zkrácená historie etikety a proč se jí zabývat
