Hlavní navigace

Vlákno názorů k článku Proč (ne)zavádět háčky a čárky v české doméně od czechsys - Proc tam chybi pro/proti argument z hlediska certifikatu?...

  • Článek je starý, nové názory již nelze přidávat.
  • 6. 1. 2020 11:19

    czechsys

    Proc tam chybi pro/proti argument z hlediska certifikatu? To je dost vyznamny problem.

    Proc tam chybi pro/proti argument z hlediska regexpu? To je dost vyznamny problem.

  • 6. 1. 2020 11:46

    czechsys

    A jeste bych pridal jeden hint...jak si IDN predstavuji takovou konfiguraci ve firewallech? A jinych ACL typech sluzeb/zarizeni...

  • 6. 1. 2020 13:17

    Ondřej Caletka

    Můžete ty své argumenty nějak rozvést? U certifikátů nevidím žádný problém. Regexp je příliš široký pojem.

  • 6. 1. 2020 14:09

    czechsys

    Certifikaty..­.Serverove sluzby overuji, ze (subdomain.)do­main.tld odpovida retezci v certifikatu v konkretnich parametrech. Standardne se davaji "SAN" pro vice nez 2 domeny, pripadne "klasika" pro www/non-www variantu. Pridani nabodenicek -> vsechny certifikaty budou muset prejit na SAN a vsechny varianty (mozne, nebo chtene) budou muset byt definovany predem.
    ->
    To stoji penize navic.

    K tomu se vazou napr. ty firewally. Mam povoleny napr. pristup na kosik.cz. Pokud ale nekdo bude pouzivat nabodenicka, tak napise košík.cz a pres firewall to neprojde.
    ->
    Mam snad definovat kazdou domenu extra s ruznymi nabodenicky, aby fungovala, navic v libovuli, ze neni znamo, co vsechno ma definovane pro tu domenu?
    ->
    kosik.cz vs kosik.cz a košik.cz a košík.cz atd...

  • 6. 1. 2020 14:18

    Ondřej Caletka

    Ano, doménová jména s diakritikou jsou jiná doménová jména je potřeba to reflektovat v certifikátech, konfiguraci DNS, webserveru i všeho dalšího jako u jakékoli jiné domény. Ano, to stojí i nějaké peníze, ale nikdo nikoho nenutí investovat, to je stejné jak v doméně .CZ, tak i jinde, kde IDN zavedli.

  • 6. 1. 2020 14:54

    Filip Jirsák

    czechsys: Standardně se dávají SAN pro všechny domény, webové prohlížeče už pár let odmítají certifikáty, kde jméno není v SAN. Všechny používané varianty opravdu musí být definovány v certifikátu předem, na tom se nic nemění. Certifikáty Let's Encrypt je možné mít zdarma.

    Mam povoleny napr. pristup na kosik.cz.
    Proč?

    Mam snad definovat kazdou domenu extra s ruznymi nabodenicky, aby fungovala, navic v libovuli, ze neni znamo, co vsechno ma definovane pro tu domenu?
    Známo to je, stačí se podívat do DNS. Stejně, jako to děláte dnes – zjistíte si, jestli používají variantu s www i bez, jestli používají variantu s pomlčkou i bez…


    kosík ani košik nejsou česká slova, asi nebude důvod je registrovat. Může to mít provozovatel jako překlepovou doménu, pak je samozřejmě na vás, když provádíte takové vylomeniny s firewallem a lezete do šifrované komunikace, zda budete chtít podporovat i překlepové domény. Což je úplně stejné, jako dnes – také se musíte rozhodnout, zda budete podporovat i kosyk.cz a seynam.cy atd.

  • 6. 1. 2020 16:01

    czechsys

    Jirsaku, takove kecy.

    Blokace pristupu na externi sluzby a povoleni jen urcitych neni lezeni do sifrovane komunikace.

    Ne, ja se rozhodne nedivam, zda to ma www/non-www varianty, ja dostanu 1 domenu a tim to hasne. A hledat, zda ma cilovy subjekt vice "preklepovych domen" - jste snad upadl na hlavu???

  • 6. 1. 2020 18:41

    Filip Jirsák

    czechsys: Nechtěl jsem to psát hned v prvním komentáři, ale měl jsem silné podezření, že vůbec netušíte, o čem píšete. Pokud nelezete do šifrované komunikace, můžete blokovat nanejvýš na základě IP adresy, ne doménového jména. A pak vám je úplně jedno, jestli je to košík.cz nebo kosik.cz, protože to obojí nejspíš poběží na stejné IP adrese (se stejnou pravděpodobností, s jakou poběží i www/non-www varianta na stejné IP adrese).

    A pokud píšete o službách ale myslíte jen HTTPS a chcete argumentovat tím, že SNI se přenáší nešifrovaně, pak za prvé už se připravuje šifrovaná varianta, za druhé platí, že si pak holt vaši uživatelé budou muset pamatovat, že jim kosik.cz funguje a košík.cz, protože to neumíte nastavit. Ve vaší síti jim bude fungovat divně všechno, takže další ujeté pravidlo je nepřekvapí.

  • 7. 1. 2020 10:21

    czechsys

    Vazne?

    VAZNE?

    ACL umi blokovat i na zaklade fqdn. Jestli to umi jen prekladem na IP nebo to zvlada i primo na urovni ACL, je veci daneho systemu. Nebo si vazne myslite, ze takova haproxy blokuje prekladem fqdn na IP ? :D :D :D :D

    A pokud myslite, ze ASA, squid a jine tvori ACL systemy zpusobuji, ze v me siti to funguje divne, tak prosim, radeji mlcte. Bezte trollovat jinam.

  • 7. 1. 2020 14:04

    Filip Jirsák

    Vážně.

    ACL = Access Control List, řízení přístupu na základě seznamu. Je to obecná zkratka používaná v IT, neoznačuje žádnou konkrétní technologii. Na základě ACL může být řízen přístup k souborům (kdo má právo číst, kdo zapisovat, kdo nastavovat atributy…), přístup ke zdrojům na webu atd. Jako ACL může být označena i nějaká technologie používaná pro filtraci síťového provozu – např. pokud různým uživatelům dává různá oprávnění.

    FQDN = Fully Qualified Domain Name, úplné doménové jméno. Může být IDN – pak záleží na tom, zda je zakódované pomocí Punycode (tj. do 7bitového kódování, ve kterém se přenáší po síti), nebo může být zapsáno v libovolném jiném kódování (např. UTF-8) – pak musí příslušný software umět převést jej do Punycode.

    IP pakety mají v hlavičce IP adresu odesílatele a IP adresu příjemce. Žádné jméno v hlavičkách paketu není. TCP/IP pakety a UDP/IP pakety mají v hlavičkách navíc číslo portu odesílatele a číslo portu příjemce. Žádné jméno v hlavičkách není. Jména (FQDN) se objevují až uvnitř aplikačních protokolů – např. v HTTP (nepovinně), v HTTPS (nepovinně jako nešifrované SNI, resp. nepovinně jako šifrované SNI, což je novinka, která ještě ani není standardizovaná).

    Obecné TCP/IP spojení tedy nemůžete blokovat podle jména – nanejvýš můžete jméno v nějakém okamžiku převést na IP adresy a blokovat spojení s příslušnými adresami. Přičemž samozřejmě vy provedete překlad na firewallu v nějakém okamžiku na základě nějaké DNS odpovědi, klient ale navazuje spojení v jiném okamžiku a může pracovat s jinou DNS odpovědí. Na druhou stranu, zejména u webu je běžné, že na jedné IP adrese běží mnoho různých webů (mají různá FQDN), takže zablokováním IP adresy jednoho webu zablokujete i spoustu jiných webů.

    Squid je web proxy server. Protokol HTTP může filtrovat bez problémů, FQDN v hlavičce vidí. Ale dnes už nikdo rozumný nešifrované HTTP nepoužívá. HTTPS přes web proxy server prochází tak, že klient požádá příkazem CONNECT o vytvoření tunelu se zadanou adresou, dovnitř šifrované komunikace už pak proxy server nevidí. V příkazu CONNECT se přenáší buď FQDN (v síťové notaci, tedy jako Punycode) nebo IP adresa. Web proxy server tedy nemusí o IDN vůbec nic vědět. Pokud ale IDN zná, může vám pomoci v tom, že pravidla pro filtrování můžete zadávat pomocí IDN a server si je na Punycode převede sám. Nevýhodou filtrování na web proxy serveru je to, že klient může příkazem CONNECT požádat o spojení na jedno FQDN nebo IP adresu, ale když dostane vytvořený tunel na cílový server, může jej požádat o úplně jiný web, který běží na tomtéž serveru. Pro neznalé uživatele je to dostatečná překážka, ale znalý uživatel dokáže filtrování obejít a dostat se i na weby, které by měl mít zakázané.

    Tohle všechno by ale měl správce firewallu znát, včetně IDN – protože jsou to věci, které dnes normálně fungují a běžné klientské aplikace (např. webové prohlížeče) je podporují a používají.

  • 6. 1. 2020 21:44

    Jehovista

    "kosík" je malý kos. A co ted... ma ornitolog milujici tento druh pravo na domenu? A ma na ni pravo troll, ktery chce jen podojit kosik.cz? Jak uz tu mnohokrat padlo... jsem pro, aby si takovou domenu mohl zaregistrovat jen majitel ascii varianty. Pak mi ale unika smysl narodnich znaku v domenach. Ta zivotne dulezita potreba mit v adresnim radku košík.cz by se lip vyresila doplnkem do prohlizece, ktery bude lidem non-ascii znaky zobrazovat kdyz je napisou, ale nikam neposilat.

  • 8. 1. 2020 20:56

    Petr M

    Jo jasně, místo aby se prostě povolilo pár znaků navíc ( a firma připlatila řádově stokoruny za doménu, pokud by nebyl IDN alias zdarma) a všechno fungovalo, tak:

    - si firma zaplatí vývoj pluginu pro Chrome a FF,
    - zákazníkům oznámí, že aby u nich mohli nakupovat, tak si musí stáhnout jejich plugin,
    - čímž efektivně 90% zákazníků odradí
    - a zbylých 10% sběratelů pluginů si zaplevelí prohlížeč tak, že se bude sekat i about::config

    Tohle asi na nobelovku nebude, zkus to znovu a líp.

  • 8. 1. 2020 21:26

    Filip Jirsák

    Pak mi ale unika smysl narodnich znaku v domenach.
    Smysl je strašně jednoduchý. Lidé vidí na reklamách „Košík.cz“, slyší „košík.cz“, do adresního řádku napíšou „košík.cz“ a v adresním řádku prohlížeče vidí „košík.cz“. Je to jednoduché a dává to smysl. Před padesáti lety dávalo smysl šetřit každá bit a používat 7bitové kódování znaků, počítače byly vzácné, setkávalo se s nimi pár lidí. Dnes už ale počítače umí trochu víc, jejich používání se stalo běžnou součástí života velkého množství lidí, takže by jejich fungování mělo být přizpůsobené běžnému životu. Děrné štítky jsme také nahradili klávesnicí, přestože děrné štítky vyhovují počítačům lépe.

    Ta zivotne dulezita potreba mit v adresnim radku košík.cz by se lip vyresila doplnkem do prohlizece, ktery bude lidem non-ascii znaky zobrazovat kdyz je napisou, ale nikam neposilat.
    Jasně, místo celosvětově používaného, odzkoušeného a funkčního řešení si vymyslíme českou cestu, která bude úplně k ničemu, ale bude naše. Zapomněl jste ještě na plugin do poštovních klientů, do mobilů, tabletů, chytrých televizí a zkrátka do všech klientů.

  • 6. 1. 2020 16:07

    SB

    Tak to už se budete muset sám rozmyslet, zda chcete nastavovat v síti i verzi s IDN, ale dobrou zprávou pro vás je, že se dosud nepodařilo získat důkaz, že by domény IDN měly být povinné.