Názory k článku Domény v .GOV budou mít povinně HTTPS, vynutí to prohlížeče
-
Z hlediska doménové hierarchie ano, z hlediska HTTPS rozhodně ne. Třeba autority mají seznamy domén, pro které nevystavují certifkáty nebo mají speciální režim a je pro ně potřeba extra ověření. Stejně tak třeba prohlížeče distribuují zvláštní revokační seznamy certifikátů pro vybrané domény, které jsou zajímavější než jiné a podobně. Tady rovnost rozhodně neplatí. Pokud HSTS přeroste, je možné, že se prostě ten seznam nějak redukuje a dostanou se do něj třeba jen nějaké top weby z Alexa nebo podobně.
-
David1234 (neregistrovaný)
A není tenhle postup trochu nefér? Pokud by k tomu došlo - tak bych nechápal proč by Tonda z Horní Dolní nemohl používat HSTS preload, co na tom že mu chodí na web jeden člověk mesíčně? Je nějaká autorita, která objektivně určí kdo je VIP a kdo není? A podle čeho? Podle počtu návštěv?
Přijde mi že HSTS preload je systémově neudržitelný.
-
Jozo (neregistrovaný)
Ked ten zoznam prilis narastie, mozno by slo pouzit Bloom filter. Moze sa sice stat, ze nejaka domena bude "omylom" vyhodnotena ako zaradena v HSTS, no stale je to lepsie ako zapnut HSTS automaticky pre vsetkych. Prip. by sa dal potom udrziavat este zoznam vynimiek, ale uz len pre domeny ktore do HSTS preload listu zaredene explicitne neboli ale dostali sa tam "nedopatrenim" (side-effect bloom filtru).
Domeny zaradene do zoznamu by tam zostali vzdy, co je dobre.
-
BobTheBuilderStříbrný podporovatelNo vidíte, chtěl byste privátní rozsahy a měl byste to blbě - co 172.16.0.0-172.31.255.255?
-
Ondřej CaletkaZlatý podporovatelŘekl bych, že až naroste na takovou velikost, že by to mohl být problém, prohlásí se HSTS za standard a prohlížeče ponesou pouze seznam výjimek. Ten ale nejspíš nebude otevřený pro každého, takže pro obyčejné lidi bude buď HTTPS a nebo nic.
-
Dashiel (neregistrovaný)
Brzo (za pár let) bude HTTPS tak běžné, že HTTP bude jen fallback ze situace, kdy server šifrované spojení odmítne. Prohlížeče budou zobrazovat varování (jako dnes u neplatných certifikátů) a/nebo nebudou dovolovat některé operace (jako odesílání formulářů).
HSTS je jen přechodná funkce a myslím že byla tak i myšlena.
-
j (neregistrovaný)
Ale kdeze ... soudruzi uz stvorili i vylepseni, browser si bude uchovavat seznam klicu ... pripadne jeste lip, to uz vymyslel o nejvetsi guugl ... se bude pred kazdou navstevou dotazovat prave guuglu, jestli prave tenhle cert patri prave tomuhle webu, neni nahodou revokovanej ... a pokud v seznamu nebude, tak zadny browsani, takze smirovani ve velkym ale samo pro nasi bezpecnost.
Milionkrat sem psal, za stavajici situace je http exaktne stejne bezpecny jako https. A zajistit bezpecnost na https se stavajicim fungovani ani nelze. Protoze i kdyby kdokoli smazal vsechny CA v systemu a importoval si jen konkretni klice konkretnich webu (ziskany zcela bezpecne a proverene), tak se mu to cely s prvni aktualizaci rozbije.
-
Ondra Satai NekolaZlatý podporovatelPokud narazis na certificate transparency, tak ti nelze nez ponekolikate doporucit si precist, co to je, nez budes pokracovat v placani nesmyslu. Vysel tady o tom docela dobry clanek:
https://www.root.cz/clanky/certificate-transparency-vydavani-certifikatu-pod-kontrolou/
-
Mohl by mi nekdo laskave vysvetlit, proc ma https na .gov domenach resit prohlizec? Domeny .gov jsou vladni domeny USA. Proc by zbytek sveta mel mit v prohlizeci sracky, ktere vynuti https na americkych vladnich domenach??? Pravdepodobnost, ze treba Cinan bude na .gov delat neco jineho, nez cist nejake zvasty, je dost mala. Pokud by se jednalo o nejake formulare, tykalo by se to leda obcanu USA. Nestacilo by tedy, kdyby se gringos naucili cist? Krome toho nic nebrani administrative USA, aby si nechali vyvinout hutna rozsireni pro browsery, ktera tuto funkcionalitu zajisti.
-
j (neregistrovaný)
Tak pokud tu masinu mas proto, aby ses ji chlubil a ne proto aby sela, tak ti to ze neseje neva ne?
Dtto CA, pokud je protozujes proto, abys moh smirovat veskerej provoz po internetu, tak ti samo nemuze vadit, ze to je z hlediska bezpecnosti uplne khovnu. Nepotrebuju bejt totiz ani moc velkej raketovej vedec, abych z fleku strelil 10+ CAcek, ktery mas ty ve svym systemu/browseru/... jako "duveryhodny". A zcela jiste (kdyz budu chtit) mi minimalne jedna (coz mi bohate staci) vyda na pozadani (pod tim si predstav klidne naditou srajtofli nebo dostatecne dlouhej pendrek) cert k libovolny domene.
Tudiz, abych se vratil na zacatek, vsichni budou vykrikovat, jak oni provozujou ten web bezpecne, protoze oni pouzivaj https ... a je jim uplne jedno, ze je to khovnu.
BTW: Se podivej na nase uzasny banky. Zrovna cumim na RB, ti nezvladaj ani DNS.
-
lojzak (neregistrovaný)
A ty ocelový dveře, to má bejt jako ten tvůj úžasnej systém, kde se vůbec cert neověřuje jo? :D To jsou spíš ocelové dveře, které se dají odemknout libovolným klíčem. Taky dobrý.
FABku možná dokáže odemknout dost nezkušených lidí (nedal jsem úplně nejlpeší příklad) pomocí bump-key. Ale vtip je v tom, že neexistuje žádný "bump-key" pro certifikáty. Neexistuje žádný jednoduchý způsob, jak systém CA přečůrat.
Ale dost bylo teoretických řečí. Jestli chceš dokázat, že systém CA je tak děravý, že ho dokáže úplně každý přečůrat, nech si vystavit validní cert pro root.cz.
-
Dashiel (neregistrovaný)
Ce teda navrhuješ, aby to bylo lepší? Klient stejně musí někomu (bezmezně) věřit. Například kořenovým certifikátům ve svém systému (a jejich vydavatelům). Neexistuje nějaký jiný objektivní způsob, kterým by se důvěra dala nahradit.
Systému by prospěla pružnější (a radikálnější) reakce na excesy CA. Když StartSSL rozdával certifikáty jakoby prodával žvýkačky, tak se rok žvanilo a další rok ještě trvalo vyřazení z prohlížečů.
-
j (neregistrovaný)
Jakykoli cetifikaty v systemu nebo browseru jsou totalni kokotina ktera nemela nikdy spatrit svetlo sveta.
Jednak pro sifrovani komunikace vazne nepotrebuju nikomu duverovat, proc jako? Druhak at uz lezu kamkoli, tak chte nechte musim duverovat DNS. Takze kdyz DNSku verim, ze to IPcko ktery mi vrati vazne vede na ten (nejen) web kam chci jit, vazne nevim, proc bych jeste mel verit nejaky treti osobe, kterou sem vzivote nevidel, o ktery nikdo, ani provozovatel toho webu nevi co a jak dela ...
a) mame tu srv, srv je presne ten typ zaznamu, kterj rika jaka sluzba na jakym IP a jakym portu bezi, takze se na zaklade tohodle zaznamu klidne browser muze rozhodnout, jestli existuje http(s) nebo ne. Pripadne treba muze zjistit, ze existuje oboji ... a treba si vybrat (nebo, svete zbor se, dat vybrat uzivateli).
b) kdyz uz verim tomu dns tu adresu, vazne nevim, proc bych mu nemel verit ten cert, neboli dane. V kazdym pripade narozdil od kompromitace CA, o ktery se jaksi provozovatel webu (natoz uzivatel) nema sanci dozvedet (viz vejs, nejde zdaleka jen o jeho CA ale o libovolnou CA), se o kompromitaci DNS dozvedet muze velmi trivialne.Neresi to samo technicky kompromitaci ze strany registratora (pripadne spravce TLD, alias cznic kradouci domeny), ale omezuje rizika navic na zcela konkretni osoby.
Technicky by riziko kompromitace slo jeste dal snizit nejakym systemem crossdomaincheck = deklaroval bys nejakej dalsi dns zaznam, kterej by odkazoval na jinou domenu (v jiny tld), kde bys dane moh overit. Samo funkcni za predpokladu ze kazda z domen je i jinde registrovana.
-
Jo, co jsem chtěl naznačit je to, že se neeliminovala potřeba důvěryhodné třetí strany, ale jenom se to přehodilo na někoho jiného . . .
Jak myslíte, že certifikační autority ověřují žadatele o DV certifikát? Přes DNS. Takže se to na nikoho nepřehodilo – dnes při použití certifikátu s doménovým jménem důvěřujete CA a DNS, při použití DANE stačí důvěřovat jen DNS. -
To sice ano, ale nakonec za nezměnení vydaného certifikátu by neodpovídal CA ale vlastník DNS záznamů za nezměnění "srv" . Chápeš?
Nejde o žádné „přehození“ důvěry na někoho jiného. Dnes je to založené na důvěře v DNS registrátora a zároveň CA. Při použití DANE stačí důvěra DNS registrátorovi. Jediné, před čím chrání dnešní DV certifikáty, je útok na koncového uživatele, který by zároveň nebyl útokem na CA. Ne že by to byl nepodstatný vektor útoku, naopak je to ten nejsnazší možný útok. Ale CA nemá z DNS žádné speciální informace, jiné než koncový uživatel – závisí na DNS úplně stejně, jako koncový uživatel, akorát by měla mít technické a organizační prostředky k tomu, aby byla méně náchylná k útoku. -
NULL (neregistrovaný)
Nechápeš. Krom této věty
"Nejde o žádné „přehození“ důvěry na někoho jiného. Dnes je to založené na důvěře v DNS registrátora a zároveň CA. Při použití DANE stačí důvěra DNS registrátorovi"
Zbytek je jenom další omáčka pro tuhle konverzaci nepodstatná. Ok. Zkusím to jinak. Celý ten problém je o tom, aspoň jak o tom psal @j a já na něj reagoval, že CA občas vydá buď špatně certifikáty nebo někomu komu nemá, tedy opět špatně.
Q:Jak ale zajistíš, pokud se bude ověření přidávak jenom k DNS (ono "srv") a zruší se CA, tak to někdo nezbodá občas tam?
(Prostě přiřadí někomu něco co němá - prostě chyba. Nezaručíš a proto jsi tam kde jsi byl . . . nedošlo k odstranění toho kroku, kde to závisí na nějakém rozhodnutí člověka, tedy prostoru pro chybu)
-
akorát by měla mít technické a organizační prostředky k tomu, aby byla méně náchylná k útoku.
Jo, jako třeba Startssl/WoSign. To je přesně to o čem tu j-čko tak nevychovaně huláká. Pakliže to závisí na lidech a na strojích které spravujou lidi, a my můžeme z toho řetězce tenhle článek vynechat (pomocí DANE+DNSSEC), tak to udělejme, a nepodporujme ten DV nesmysl. Když certifikačním agenturám snížíme agendu na OV/EV, tak můžeme lépe prověřovat, že OV/EV vydávají správně. Při troše štěstí spousta CA zanikne, čímž bude na ty zbylé lépe vidět a celé se to stane transparentnější.
DV samo o sobě je sice lepší než nic, ale pro OV/EV certifikáty je existence DV certifikátů špatná. -
Jednak pro sifrovani komunikace vazne nepotrebuju nikomu duverovat, proc jako?
Většina lidí nešifruje jen tak pro šifrování samotné, aby si zprávu stejně mohl přečíst každý. Šifruje se pro to, aby si zprávu mohl přečíst pouze oprávněný příjemce. Aby si mohl zprávu přečíst jen oprávněný příjemce, musíte důvěryhodným způsobem získat jeho klíč. Když ho získáte nedůvěryhodným způsobem, nevíte, zda šifrujete skutečně klíčem příjemce nebo klíčem útočníka. A když šifrujete klíčem útočníka, tak sice šifrujete, ale je to tak nějak k ničemu. -
j (neregistrovaný)
Ale starou backoru jirsak, 99,999% komunikace se sifruje proto, aby si to necet nekdo cestou, a nikoho nezajima, jestli komunikuje s frantou nebo pepou. Kdyby ho to zajimalo, tak by se snim musel nejdriv osobne setkat a prevzit si od nej osobne cert. Coz jak sem rek, by mu bylo za stavajici sutuace stejne khovnu.
Ostatne viz mail, pokud ma povoleno ssl, a protistrane umi, tak posle mail sifrovane. Vubec se neresi, kdo jak co kde ... (mohlo by, ale vsichni vedi, ze by se domailovali tak leda do pekel horoucich).
-
j (neregistrovaný)
2MarSik: Ale ty ZADNOU overenou protistranu NEMAS a mit ani nemuzes. Co ti jako asi tak rika nejakej cert podepsanej nejakou CA? No leda tak to, ze nejaka CA vydala nekomu nejakej cert. Ty vubec netusis a ani nemuzes tusit komu, proc, za jakych okolnosti ...
2Dash: Jedinej kdo o tom vi naprosty hovno ses tu ty. Zadny overeni neexistuje. Nikde. A navic ses zjevne retardovanej negramot, protoze sem tu i milionkrat psal proc. Nefunguje to ani v pripade, ze by sis protistranu overil osobne, protoze ten tvuj uberbrowser naprosto vpohode akceptuje LIBOVOLNEJ certifikat LIBOVOLNY CA kterou ti do nej nekdo zvenku naladuje. Jen tu kkti jako TY a spol porad neco zvanej o bezpecnosti tam, kde ABSOLUTNE ZADNA neexistuje.
MITM na tebe dela tvuj vlastni browser, a deje se to porad a opakovane. Prave a presne proto, ze tardi jako ty vubec nechapou, jak ty veci nefungujou a ze nikdy fungovat nemuzou.
-
Dash (neregistrovaný)
Proč se probůh vyjadřuješ k něčemu, čemu vůbec nerozumíš? Ověření identity druhé strany je skoro důležitější než ochrana odposlechnutí.
Bez předinstalovaných veřejných ověřovacích podpisových klíčů (ať už budou od CA nebo správce DNS) prostě kryptografie nemůže nikdy fungovat. Jinak nelze s jistotou vyloučit MITM útok.
-
Ondrej (neregistrovaný)
Nemusí bejt v DNS záznamu jakému certu přímo důvěřovat i když by to bylo žádoucí, protože by sis pak vygeneroval cert sám a ten by sis podepsal na základě přístupu k DNSkám domény. Chápu že pro spousta lidí by to znamenalo přijít o práci, na druhou stranu by to bylo rozhodně lepší než teď kdy ti pár expertů klidně vydá cert i když nedokážeš nadvládu nad serverem. Na druhou stranu situace není i tak růžová, protože LE kterej ti ochotně vydá cert na doménu kde už cert vydanej je, to ti pak stačí mezi autoritou a serverem přesměrovat trafic a máš vystaráno.
Ideálně tedy moct si vygenerovat cert sám, ten si podepsat v dnsku. Na běžné situace to stačí. Kdo chce zelenej řádek, zaplatí si EV cert, kde se snad nějak ověřuje že opravdu Franta Novák je Franta Novák... -
j (neregistrovaný)
... snad nějak ...
Ne, neoveruje se nic. Hlavne porad nemas zadnou moznost jak rict, ze akceptujes danej cert pro danou domenu a zadnej jinej, pripadne, ze akceptujes danou CA pro danej set domen, ale zadny jiny. Takze i kdyby nakrasne mel franta uzasne overenej certifikat, tak tvuj browser se uplne stejne spokoji s libovolnym jinym naprosto neoverenym certifikatem. A to je prave duvod, proc to nemuze fungovat.
Je to exaktne presne stejny, jako kdybys v korporatu udelal prihlasovani klientskym certifikatem ... a misto iterni CA, u kteri vis jak funguje, bys proste "duveroval" CAckum zvenku, ktery by vydavaly certifikaty na zaklade toho, ze dotycnej (treba na webu) prohlasi, ze v ty firme vazne dela. Vazne bys necemu takovymu veril? lol ...
-
VM (neregistrovaný)
Takže:
1. nový FF bude zbytečně obsahovat politiky pro cizí domény, které by měly být v DNSSEC
2. uživatelům se zakáže přidat výjimka, takže cokoliv s webovým rozhraním (např. síťový HW) nebude přístupné přes DNS jméno
3. pokud máte na klientovi špatně nastavené datum a nejste admin, nepřipojíte se a nic s tím neuděláte (zfailuje validace data certifikátu) -
Ad 1) – nic takového se v článku nepíše. V článku je napsáno, že se použije standardní HSTS preload list.
Dvojka je nesmysl, na DNS se nic nemění. Trojka není nic specifického, to platí pro každý certifikát. To, že nejste admin a „samo“ se vám špatně nastaví datum, sice nastat může, ale daleko pravděpodobnější je, že vám odejde disk nebo myš a stejně budete muset admina zavolat. -
VM (neregistrovaný)
1) no právě - s prohlížečem se bude distribuovat seznam hostname, které většina lidí nikdy nenavštíví, a bude se jim pravidelně aktualizovat. Dá se čekat, že časem velmi nabobtná. Tohle by se mělo řešit jinde, asi v DNSSEC, tam to patří.
2) to závisí na tom, zda se opravdu všechny domény (ve smyslu hostname) budou automaticky přidávat. Pokud ano, dostanou se tam i DNS záznamy pro síťový HW a další embedded zařízení, a bude problém. Pořád ale bude dostupný přes IP adresy, tyhle věci většinou nepoužívají virtuální hosty.
3) baterie v RTC odchází daleko radši než HDD a myš, a doteď to nebyl moc velký problém. Když už nejde přidat uživatelská výjimka (už jsem kvůli tomu musel překonfigurovávat jeden Firefox), tak se člověk na korektní web nepřipojí. Jde to proti idei a definici svobodného SW - uživatel má ovládat program, ne že mu program diktuje na co smí a nesmí dát výjimku. -
1) S prohlížečem se distribuuje seznam hostname, které většina lidí nikdy nenavštíví. S tím, že by ten seznam časem velmi nabobtnal, se nepočítá, protože je to považováno za dočasné řešení, které bude zrušeno dřív, než by k tomu velkému nabobtnání došlo. Navíc to celé vůbec nijak nesouvisí s tím opatřením v doméně
.gov, protože HSTS preload listy už dávno existují, používají se a aktualizují.
2) Proč by se tam přidávaly hostname, budou se tam přidávat domény. Problém se síťovým HW a embeded zařízeními nebude, prostě se pro ně vystaví certifikát. Při přístupu přes IP adresu bude prohlížeč hlásit chybu certifikátu (neouhlasí jméno), stejně jako to dělá dnes.
3) Pokud se ze zařízení přistupuje na web, má internetovou přípojku. Takže baterka v RTC není žádný problém, protože čas se sesynchronizuje přes NTP. Idea a definice svobodného softwaru asi moc uživatelů nezajímá. Uživatelé chtějí, aby jim program sloužil k tomu, co chtějí udělat. Když se chce bezpečně podívat na webové stránky, tak mu to má umožnit, a ne že bude někde nastavovat nějaké výjimky proto, že správce jeho počítače neumí zařídit, aby na něm byl správný čas. -
VM (neregistrovaný)
1) S nabobtnáním se nepočítá, jen se teď automaticky přidá jedna celá TLD a všechno v ní, ať to je příklad i pro ostatní. Nějak jsem nezaregistroval tu dočasnost - to jako že už se přechází na něco lepšího, a HSTS preloady budou během pár měsíců vypnuty?
2) Obávám se, že spousta těchto zařízení HTTPS vůbec neumí. Při přístupu přes IP adresu a HTTP samozřejmě prohlížeč chybu hlásit nebude, protože žádná nenastane.
3) Právě - uživatelé chtějí, aby program sloužil k tomu co chtějí udělat, třeba dát výjimku na daný certifikát. Nevím proč by je neměly zajímat jejich vlastní svobody, nebo aspoň zda jim někdo hází klacky pod nohy. -
1) Kdyby se tam přidala celá TLD, přidaly by se tam 3 znaky. Proč si pořád něco vymýšlíte, místo abyste si přečetl alespoň zprávičku, pod kterou diskutujete? Všechny domény pod .gov se do HSTS přidávat nebudou, pouze nové. Přechází se na něco lepšího – postupně se eliminuje HTTP, a až se přestane používat úplně, HSTS se mohou zahodit.
2) A nebo se k tomu zařízení přihlásí telnetem. Když to někomu vyhovuje…
3) Mohl byste mi ukázat nějakého uživatele, který chce dát výjimku na daný certifikát? To se jako ráno probudí a řekne si „dneska je venku hezky, dneska si přidám tři výjimky na certifikáty“? -
VM (neregistrovaný)
1) Já ji četl, co vy?
"Letos má přijít další krok: nové domény a subdomény v .GOV budou muset povinně zavést i HTTPS včetně HSTS. (...) Jakmile totiž bude nová doména registrována, GSA ji automaticky přidá na seznam domén v HSTS preloadu. "
Tohle říká celkem jednoznačně, že se přidá každý nový záznam pod GOV, a to opravdu nejsou 3 znaky.
Jinak úplně zrušit HTTP je nesmysl třeba u toho síťového HW. Něco HTTPS vůbec neumí, a i u toho zbytku nebude BFU instalovat certifikát telnetem, aby se vůbec dostal do webového nastavení. Nehledě na to že bez funkční sítě ten certifikát ani nezíská.
2) Telnet je workaround, není moc user-friendly, a některý HW ho ani neumí.
3) Ach jo.. třeba ten síťový HW výše, firemní servery pokud zrovna nemáme nainstalovanou jejich CA, vlastní web se self-signed certifikátem atd. -
Já jsem četl i zprávičku, i váš komentář. Vy jste napsal „teď se přidá jedna celá TLD“. Kdyby se přidala celá TLD gov, jsou to tři znaky. Jenže jak sám píšete, nebude se přidávat teď celá doména, ale budou se postupně přidávat nové domény. Chápete, že „postupně jen nové“ je něco úplně jiného, než „teď celá“?
Úplně zrušit HTTP není nesmysl, naopak k tomu dříve (doufejme) či později dojde. Dříve se ke konfiguraci takových zařízení používal třeba telnet, a dneska rozhodně není telnet klient v běžné výbavě každého uživatele. Zkrátka internetové protokoly také zastarávají a přestávají se používat. To, že dneska nějaké zařízení neumí HTTPS, neznamená, že taková zařízení budou i za deset let. Ostatně před deseti lety taková zařízení neuměla ani HTTP a konfigurovala se přes telnet nebo proprietárním nástrojem.
Bez funkční sítě se k tomu zařízení ani nepřipojíte, takže nepotřebujete řešit nějaký certifikát.
HTTP je také workaround a není moc user-friendly, některý HW ho také „neumí“ (rovnou vás přesměruje na HTTPS). Síťový HW, firemní servery, vlastní web – to vše může mít certifikát, kterému bude prohlížeč důvěřovat.
-
VM (neregistrovaný)
Jasně, koupím si domů router, ale nepůjde nastavit, dokud si pro něj nevyřídím certifikát pro danou IP adresu, což bez nastaveného routeru bude trochu komplikované. A nedej bože abych byl jako 95% lidí za NATem, protože na lokální rozsahy mi certifikát žádná CA nedá. A stávající HW co HTTPS neumí nemá nikdo co nastavovat, ne?
Tohle nemá cenu. -
Proč byste si pro něj vyřizoval certifikát vy? Uživatelsky přívětivé nastavení routeru rozhodně nevypadá tak, že uživatel bude někam zadávat nějakou IP adresu. Vypadá spíš tak, že uživatel klikne na odkaz v e-mailu, který dostal, nebo načte QR kód nebo přinejhorším opíše nějakou webovou adresu.
Certifikační autorita nevydává certifikáty na IP adresy, ale na jména.
Stávající HW, co HTTPS neumí, mohou lidé klidně nastavovat stávajícím prohlížečem, který umí HTTP. Ale není důvod, proč by to tak mělo být i za deset let. A pokud tou dobou někdo pořád bude mít zařízení, které se bude konfigurovat přes HTTP, není žádný důvod, aby ten protokol podporoval běžný webový prohlížeč určený pro práci na webu. Některá zařízení se i dnes konfigurují přes telnet, SSH nebo třeba přes sériový port, a neznamená to, že tohle všechno musí podporovat webový prohlížeč.
-
j (neregistrovaný)
To by me jirsak zajimalo, jak vydas certifikat (klidne na dns) kdyz netusis, kdo a kam to zarizeni pripoji ... celkem by me zajimalo, jak budes resolvovat 987hjasawd787.router.cisco.com na 192.168.4.79, protoze exaktne na to jmeno je vydanej cert ...
Mluvis predpokladam o tom stavajicim i budoucim HW (predevsim pak o IOT), ktery https umi, jen holt ho nekdo navrh pred 1/2 rokem, kdy jeste sha1 nikomu nevadilo ...
-
Varianta č. 1, pravděpodobnější: zařízení se připojí do domácí sítě a ohlásí se routeru, že je tu nové a přeje si býti nakonfigurováno. V rozhraní routeru (něco jako Amazon Echo, Google OnHub, Apple Home – můžete hádat, proč zrovna tyhle firmy najednou řeší domácí routery) uvidíte, že máte v síti nové zařízení, třeba „webkamera D-Link 999L“. Zadáte PIN ze štítku na kameře, čímž se autorizujete, povolíte zařízení přístup do sítě, pojmenujete ho, umístíte ho na plánku, a pak případně budete pokračovat jeho konfigurací. V okamžiku „povolíte přístup do sítě a pojmenujete ho“ ten router vytvoří certifikát pro to zařízení a pošle mu ho spolu s dalšími údaji o síťové konfiguraci. Certifikát router uloží do DANE, takže ani není potřeba řešit certifikační autoritu. A nebo ta komunikace může jít vždy přes router a autentizaci si zajistí router, a klidně pak ta komunikace se zařízením může jít přes SSLv2 a MD5 certifikát a router to přeloží do něčeho, co bude ochoten akceptovat uživatelův prohlížeč.
Varianta č. 2, kterou se budou snažit prosadit ti výrobci zařízení, kteří nebudou mít vlastní domácí routery: certifikát se vystaví na 987hjasawd787.router.cisco.com, buď přes ACME, nebo ho může vystavit intermediate certifikační autorita Cisca. Až se router někde připojí do internetu, oznámí svou interní IP adresu, která se nastaví do toho DNS záznamu, a stáhne si příslušný certifikát. Jediný „problém“, že podle RFC by IP adresy z privátních rozsahů neměly být ve veřejném DNS, ale Ciscu to nikdo vyčítat nebude, případně se to RFC změní na těch pár let, co ještě budou mít domácí zařízení běžně privátní IPv4 adresu. Nevím, zda už některý z poskytovatelů služeb dynamického DNS umožňuje ověřit pro ACME certifikát, pokud ano, můžete si to takhle udělat hned zítra.
Varianta č. 3, která se používá už dnes – k zařízení se připojujete přes nějaký portál myvyrobcezarizeni.com, hostname je pořád stejné, takže na něj má certifikát výrobce toho zařízení. Zařízení komunikuje s tím portálem nějakým interním protokolem, když chcete něco nastavit třeba na NASu, jde příkaz na cloud poskytovatele a zase zpět do vaší sítě. Je to padlé na hlavu, ale IPv6 je zlé ošklivé a NATy vládnou světu, takže máme, co jsme chtěli.
-
j (neregistrovaný)
Jo, tovizejo a vsichni vyrobci na planete se dohodnou na jednotnym zpusobu distribuce certifikatu, a vsechna zarizeni budou podporovat vsechny algoritmy ... pricemz ten router sam se nakonfiguruje telepaticky a bude se (sam) co tri mesice vymenovat jak HW tak SW za novej (a totez zaridi u vsech krabek v dosahu), to aby podporoval i vsechny budouci algoritmy a certifikaty ... lol
-
j (neregistrovaný)
Nevsim sem si, ze by se kameny tabulky vyradily z provozu behem 1/2 roku, stejne jako sem si nevsim, ze by sme je i po ticisich let neumeli precist (naprozdil od tech papyru, ktery davno shnily). Zato sem si vsim, ze data stari sotva 20 let uz precist neumime, protoze jednak neexistuje HW (a to je jeste ten mesi problem) druhak uz nikdo nezna format.
Mam tu 3 roky starou telku, asi bych ji mel zahodit ... https totiz jaksi neumi. Jo, ma i webovy rozhrani ... a tu novou (ktera https nebude umet taky) muzu rozslapat hned v krame ... jo aha, ono je mi uplne u rite jestli to https umi nebo ne, protoze kvuli tomu si to nekupuju, pouziju to mozna jednou pri nejaky konfiguraci.
-
j (neregistrovaný)
2Heron: treba takovy cisco ... ma bydefault hned dve moznosti ... seriovou linku, kde budes resit problem s tim, ze soudruzi seriovy porty zrusili a zadna usb redukce nefunguje jak ma (takze bezne nosis tak 3-4, a testujes, ktera se chytne tentokrat). nebo ... voiala ... telnet. Naprosto nesifrovanej textovej protokol ... katastrofa, je treba to hned vsechno nechat sesrotovat.
Nebo treba ... skladovy systemy. Nejmin polovina toho co sem kde videl pouziva ... taky telnet. Skladnik ma nejakej pomerne blbej terminal ... a ten ani HW nic jinyho neumi. Ovsem takovej terminalek vpohode stoji neco mezi ... 50 - 150k (ono se totiz ceka, ze v tom sklade neco vydrzi). Vyhodit, okamzite ... nesifruje to.
Nebo ... lol ... pred mesicem zprovozneny osvetleni ... komunikuje to bezdratove, v kazdy lampe je chip za 10Kc ... a ... pouziva to nejakou formu defakto sms - ciste text. Okamzite rozflakat ...
-
To už záleží na každém soudruhovi, jestli považuje za jednodušší zadat do prohlížeče
kamera-garážnebo3ffe:1900:4545:3:200:f8ff:fe21:67cf. A jestli mu připadá jednodušší hledat v nastavení routeru IP adresy připojených zařízení a hledat mezi nimi ten nový NAS, nebo jestli je jednodušší si prostě jen vybrat ze seznamu zařízení podle jejich výrobce a názvu.
ČLÁNKY DO MAILU