Příspěvky

2686

Odkladiště / Re:Proč Seznam.cz používá u některých domén Let's encrypt ?

« kdy: 06. 03. 2019, 15:38:31 »

V tom, že mi admin, s přístupem na proxy server nemůže nechat vygenerovat certifikát jen ověřením ACME.

Problém je v tom, že zaměňujete Let'S Encrypt, ACME a validaci držení domény přes HTTP.

V případě Let's Encrypt, GlobalSign a Buypass může admin s přístupem na proxy server nechat vygenerovat certifikát jen ověřením ACME.

U jmenovaných to bude muset být minimálně jedna z osob uvedených jako kontakt v registru domén (což už si opět dokážu jednodušeji pohlídat).

Spousta autorit vystavuje DV certifikáty na základě ověření přes HTTP – z těch levných to tak dělají snad všechny, protože je to jediný způsob, který se dá zautomatizovat. A i ten DigiCert validuje i pomocí jiných e-mailů, než těch uvedených v registru domén – např. validují i pomocí e-mailu webmaster.

Jednoduše si nepohlídáte vůbec nic, protože chybějící standardizace naopak znamená, že to každá autorita validuje jinak. Docela by mne zajímalo, jak to dělají třeba provozovatelé freemailů – jestli opravdu mají blacklist všech schránek, které mohou všechny existující certifikační autority používat pro validaci domén, a průběžně ho udržují. Já o tom pochybuju, protože to podle mne je nerealizovatelné.

To samé v bledě modrém je s validací přes HTTP – díky Bohu za .well-known adresář, konečně je jasné, k jaké cestě nemá mít přístup žádný CMS ani nic podobného a má být výhradně pod správou administrátora serveru. Teď ještě aby se všechny CA do tohoto adresáře co nejrychleji přesunuly.

2687

Odkladiště / Re:Proč Seznam.cz používá u některých domén Let's encrypt ?

« kdy: 06. 03. 2019, 12:47:15 »

Proto v současnsti není ze všech hledisek rovnocenné, jestli připustím použití LE certifikátů, nebo od jiné autority.

V čem přesně je rozdíl, jestli připustíte vystavení certifikátu od DigiCertu, Let's Encrypt, GlobalSign nebo Buypass?

2688

Odkladiště / Re:Proč Seznam.cz používá u některých domén Let's encrypt ?

« kdy: 06. 03. 2019, 12:02:43 »

Pomocí CAA lze omezit issue jen na jednu vybranou certifikační autoritu. S ní už si lze, při síle jakou má vláda USA, nebo i Seznam, smluvně domluvit odlišné podmínky pro vydávání certifikátů. Tedy např. lze sesmluvnit, že CA nevydá DV certifikát, a že ověřovací procedura firmy pro OV a EV je odlišná od běžných veřejných podmínek. Tím si zajistíte poměrně solidní kontrolu nad certifikáty a můžete ji zanést i do bezpečnostních procedur organizace.

Vláda USA možná. O tom, že by se DigiCert bavil se Seznamem, silně pochybuju.

Oproti tomu LE má nevýhodu v tom, že žádnou jinou metodu, než DV neumožňuje, a pokud připustíte issue od LE, tak v tu chvíli musíte mít plně pod kontrolou všechny cesty ověření ACME.

Pomocí přepínání CAA můžete omezit LE na krátké okno v měsíci (dobrodružné povahy to mohou omezit na okno jednou za tři měsíce), ve kterém všechny certifikáty obnovíte.

Zde chybí, jak už jsem napsal, mechanismus, jak vyblokovat vydávání DV certifikátů. Dnes, pokud nemám 100% důvěru ve své zaměstnance, nebo v nastavení bezpečnosti, mohu to maximálně ovlivnit  tím, že omezím CAA na autoritu, která ACME nepodporuje. A to ještě stále musím důvěřovat adminovi s přístupem do DNS a všem mechanismům dynamických změn v DNS (že nepropustí CAA záznam apod.). Přesto ale zůstanou, ať už přímo otevřené, nebo potenciálně existentní, další kanály DV ověření.

Mícháte dohromady věci, které spolu nesouvisí – ACME protokol je jedna věc, DV certifikáty jiná, klidně můžete protokolem ACME vydávat EV certifikáty.

Mimochodem, ověření před vydáním DV certifikátů je velmi slabé, ovšem byl bych velmi opatrný v tom tvrdit, že ověření pro OV je silnější. Ověření zavoláním na vygooglený telefon jde možná hacknout snáz, než to ověření přes http-01.

Přidávat další omezení do CAA je hezká věc, já bych raději ta omezení sděloval spoléhající se straně, protože tím se ošetří i chyba certifikační autority.

2689

Odkladiště / Re:Proč Seznam.cz používá u některých domén Let's encrypt ?

« kdy: 06. 03. 2019, 08:36:47 »

Na takovýchto serverech je běžná i inspekce provozu ven, takže i vyžvanění ACME protokolu musí projít skrz spoustu mechanismů (firewally, proxy, ...), a bez pochyb to bude vyžadovat práci, bez které by to dřív či později přestalo fungovat.

Certifikát ACME protokolem nemusíte vůbec obnovovat ze zařízení, kde se pak bude používat. Proces, jakým se na cílovém zařízení dříve zacházelo s privátním klíčem a certifikátem, může zůstat úplně stejný.

Pokud přejdete na LE, dáváte reissue mechanismus do ruky každému adminovi, který má přístup k toku http požadavku na dané doméně.

To se netýká jen obnovy certifikátu, ale i jeho prvotního vydání. A netýká se to jen Let'S Encrypt, ale snad všech autorit vydávajících DV certifikáty – neznám autoritu, která by jako jeden ze způsobů ověření držení domény nepoužívala HTTP.

V případě tradičního certifkátu (kupovaného na delší období) omezíte issue pomocí CAA záznamu a interním mechanismem ověření vůči vybrané CA.

To samé přece můžete udělat u Let's Encrypt.

Osobně se mi vůbec nelíbí představa, že by všechny DV certifikáty byly od Let's Encrypt, zvlášť když dříve byl jediný, kdo podporoval ACME – a dnes už sice ACME podporují i další autority, ale pořád to není plnohodnotná náhrada za LE, že by je v případě problémů s LE dokázaly ze dne na den nahradit. Ale automatizaci a standardizaci vydávání certifikátů považuji za správnou a byl bych rád, kdyby na ACME přešly všechny autority (samozřejmě s přidáním dalších validačních metod,které jsou pro OV a EV potřeba, třeba fax…). To, že budete všechny autority žádat o validaci a o vydání certifikátu stejným způsobem, přece na bezpečnost nemá žádný negativní dopad.

2690

Server / Re:Obnova MariaDB přes SSH

« kdy: 05. 03. 2019, 17:58:58 »

Jak píše Ondřej Vaniš, použijte parametr --add-drop-database, příkaz pro smazání databáze se tak přidá na začátek obnovovacího skriptu.

Mimochodem, v tom zálohovacím příkazu máte zbytečný cat – cat se používá pro spojení více souborů do jednoho výstupu, pokud máte cat v koloně, je to snad vždy zbytečné. Stačí výstup toho ssh přesměrovat přímo do souboru.

Rozhodně bych nespouštěl obnovu nebo zálohování přímo přes SSH příkazy - vypadne ti spojení a budeš se divit, co se ti nahraje do databáze. 

V databázi bude poslední commitnutá transakce. Pokud by v průběhu obnovy databáze vypadlo spojení, neřešil bych, co se stihlo obnovit a co ne, to zavání průšvihem. Prostě bych tu obnovu spustil znova od začátku. Řešit výpadky spojení má smysl v případě, kdy ta obnova databáze bude trvat desítky minut a více a výpadek spojení by obnovu podstatně prodloužil.

Na výpadek spojení je náchylné spíš to zálohování databáze, protože tam asi není žádná kontrola, aby se záloha zopakovala, pokud se nepodaří. Takže pokud by výpadky spojení byl problém, je potřeba to vyřešit hlavně na té straně zálohování – nejspíš dostatečným prostorem na serveru, kam se záloha uloží, a pak už se jen přenese rsyncem jinam. Pak už je řešení obnovy snadné, postup se akorát otočí – rsyncem se přenese záloha na cílový server a tam se jen naimportuje.

2691

Vývoj / Re:Jednoduchá evidence na webu

« kdy: 04. 03. 2019, 10:20:09 »

V GSuite máte Tabulky a Formuláře, které umí vyplněné údaje plnit do tabulky. To by se pro úplně základní evidenci použít dalo. Nad tabulkami je možné dělat i nějaké aplikace, otázka je, zda by to bylo nejlepší řešení.

Pokud byste chtěl GSuite (resp. účet u Googlu) použít jenom pro přihlášení do vlastní aplikace, to je také možné – Google pro přihlašování poskytuje rozhraní.

2692

Sítě / Re:DNS hosting

« kdy: 02. 03. 2019, 18:48:42 »

Prakticky každý registrátor nabízí v ceně i DNS hosting. Stejně, jako vy chcete domény spravovat z jednoho místa, já je chci i registrovat z jednoho místa, tím bych začal. A pokud vám nebude vyhovovat správa domén u příslušného registrátora, např. já používám ClouDNS.net, který asi bude levnější, než S3, určitý počet domén dokonce můžete hostovat zdarma. Poskytovatelů podobných služeb je samozřejmě víc.

Jeden vlastní server bych neprovozoval, je dobré mít alespoň dva DNS servery – a kdyby vám stačilo takhle málo, určitě je lepší využít alespoň těch základních služeb registrátora.

2693

Server / Re:Jak spustit příkaz jako jiný uživate sudo/su něco

« kdy: 28. 02. 2019, 19:19:57 »

Použít sudo nebo su v tom skriptu.

2694

Software / Re:translator slov v google chrome

« kdy: 25. 02. 2019, 14:13:17 »

Preco myslis ?
Ja nechcem preklad kazde slovo vo vete. Ja potrebujem obcas prelozit 1-2 slova. Ak sa v texte uplne stracam, tak prelozim celu stranku.

Jak jsem psal, Google Translate dnes neobsahuje slovník, je to neuronová síť natrénovaná na překladech textů. Když jí dáte přeložit jedno slovo, nemá kontext a je daleko pravděpodobnější, že udělá chybu. Když dáte jedno slovo přeložit lidskému překladateli, může ho také přeložit jinak, než jak by ho přeložil v kontextu (a to nemluvím třeba o frázových slovesech). A to lidský překladatel chápe významy slov, má jejich napojení na reálný svět. Neuronová síť tohle nemá, takže klidně může slova přiřazovat úplně nesmyslně.

Proto jsem doporučoval dát GT k dispozici při překladu celou větu, i když vás zajímá jedno slovo – bude tak znát kontext a může překládat lépe. Ostatně i lidský překladatel by se vás často zeptal na kontext, když se zeptáte na překlad jednoho slova.

2695

Software / Re:Software na prevod audio na text

« kdy: 24. 02. 2019, 19:53:10 »

Google Cloud Speech-to-text, Amazon Transcribe, NEWTON Dictate, Watson Speech to Text od IBM… Dost podstatné je pro jaký to chcete jazyk.

2696

Vývoj / Re:Dynamicka cenotvorba / pricing engine

« kdy: 24. 02. 2019, 19:48:32 »

Tazatel píše, že bude problém seřadit produkty podle individualizovaných cen, což je potřeba bez ohledu na to, kolik produktů nakonec na jedné stránce ukážu.

K čemu je to potřeba? Dejme tomu, že mám nějakou špatně roztříděnou kategorii, ve které mám 500 produktů. Uživateli jich na první stránce chci zobrazit 20 s nejnižší cenou – pak potřebuju mezi těmi 500 produkty najít 20 s nejnižší cenou pro uživatele a ty pak setřídit podle skutečné ceny. K tomu nepotřebuju spočítat individuální cenu pro všech 500 produktů, protože u velké části z nich nejspíš dokážu určit rovnou, že se na první stránku nevejdou. Ty individuální ceny se asi budou pohybovat v nějakém pásmu, nepředpokládám, že by jeden produkt stál pro jednoho uživatele 10 Kč a pro druhého milion.

2697

Software / Re:translator slov v google chrome

« kdy: 24. 02. 2019, 16:01:54 »

Překládat takhle slova ale není dobrý nápad. Google Translate neobsahuje slovník, je určený pro překládání celých textů. Naučil se překládat porovnáním spousty vícejazyčných textů. Překládat s ním jednotlivá slova je tedy přesně to samé, akorát s opačným znaménkem, jako kdybyste texty překládal tak, že s pomocí slovníku přeložíte jednotlivá slova. Jinými slovy, občas z toho může vypadnout úplný nesmysl.

Takže když chcete použít Google Translate, je lepší nechat si přeložit celou větu, i když jí z větší části rozumíte a neznáte jen jedno slovíčko.

2698

Vývoj / Re:Dynamicka cenotvorba / pricing engine

« kdy: 22. 02. 2019, 19:41:14 »

O takhle obecném zadání se dá napsat jediné – ano, obecně to možné je. Napište alespoň, v jakých se pohybujete řádech – co je počet produktů ve vysokých číslech? Je to 100 nebo 100 milionů? Jak jsou definované ty podmínky, na základě kterých se cena počítá? Kolik je současně pracujících uživatelů? Jak přesně by podle vás vypadalo to filtrování nebo řazení podle ceny? Nějak mi to nejde dohromady s tím vysokým počtem produktů – přece nechcete uživateli zobrazovat 100 milionů produktů seřazených podle ceny. Nedává smysl ukazovat uživateli víc než malé desítky položek najednou, ve větším množství nebude uživatel nic hledat ručně, ale musí mít nástroj na zpřesnění filtru.

2699

Server / Re:Nelze vytvořit adresář v /srv běžným uživatelem

« kdy: 20. 02. 2019, 19:27:53 »

tedy nejspíš i šifruje

V tom případě je důležité jenom to, jestli na to od nich máte papír. :-) Aby kdyby ta data ze záloh unikla, nebylo to na vás…

Ale já z toho o čem se bavíte furt nechápu jestli se mám tedy pokoušet vytvářet pgmaint odděleného uživatele pro tvoření pgdumpů, či to stačí tak jednoduše, jak jsem udělal.

Já bych začal tímhle jednoduchým řešením. Podle toho, co píšete, ten skript ani nic nemaže, jenom spouští psql a pg_dump. Oprávnění nastavená tak, aby vám ten skript nemohl jen tak někdo přepsat, předpokládám máte. Takže pravděpodobnost, že ten skript napáchá nějaké škody, je velmi nízká. Vylepšovat to, aby ten skript běžel pod jiným uživatelem, můžete později, až vám ten současný systém bude bezpečně fungovat a budete vědět, že poznáte, když se záloha nevytvořila nebo není kompletní nebo když se tím enterprise řešením neodzálohovala pryč. To jsou mnohem větší rizika.

2700

Sítě / Re:Routování klientů připojených přes Wi-Fi na konkrétní IP

« kdy: 20. 02. 2019, 17:52:47 »

Tím si akorát zaděláváte na problémy. Použijte nějakou krátkou adresu, kterou uživatel do prohlížeče zadá, případně ji můžete někde mít i jako QR kód (pokud tím klientem mohou být mobily nebo tablety), a budete to mít mnohem spolehlivější, než když se budete pokoušet unášet spojení. Můžete tam pak i použít HTTPS (pokud si tu doménu opravdu zaregistrujete) a nebudete muset řešit problémy s nezabezpečeným připojením v prohlížeči. Už dnes některá API v prohlížeči nejsou na stránkách otevřených přes HTTP dostupná, a postupně bude ještě lépe, nezabezpečené HTTP už konečně začíná vyklízet pole.

Pokud to trváte na tom, aby to bylo bezobslužné, použijte to, co používají captive portály. Dnes už myslím existuje standard nebo de-facto standard, jak je možné dát tou zařízení vědět, že v síti je captive portál a jakou má adresu. Takže na tu vaší adresu můžete uživatele přesměrovat tímhle způsobem. Třeba na Androidu se při připojení do takové sítě zobrazí dotaz ve smyslu, že pro připojení k síti je potřeba se přihlásit a zda to chce uživatel udělat, a pokud to odsouhlasí, otevře se mu internetový prohlížeč právě s tím captive portálem.