Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Miroslav Šilhavý

Stran: 1 ... 90 91 [92] 93 94 ... 206
1366
Sítě / Re:Shorewall 5.x a alias veřejné IP
« kdy: 12. 03. 2019, 22:04:21 »
Druhá adresa, pokud je ze stejného subnetu, jako ta první, by se měla přidávat s maskou /32.

Řešení Vašeho problému je SNAT - musíte si nastavit pravidla, za jakou adresu se jaké spojení schová.
MASQUERADE vybere tu první (hlavní) adresu na interfacu.

1367
Sítě / Re:Zkušenosti se síťovými PowerLine adaptéry
« kdy: 11. 03. 2019, 08:00:59 »
Moje zkušenost je taky podobná. Někdy to jede svkěle, pak to zlobí a vypadává. Určitě to není řešení, na které se dá dokonale spoléhat. Tam, kde není jiná možnost, je to fajn.

Stejnou zkušenost mám s TP-Linkem i se Zyxelem.

Pokud je aspoň trochu reálná možnost natáhnout ethernet (a jen se Vám třeba nechce kvůli jendoduchosti), tak neváhejte, a natáhněte ethernet.

1368
Odkladiště / Re:Email a Článek 13
« kdy: 07. 03. 2019, 22:36:34 »
Takovéto obavy vznikají, když laik začne číst právní normy. Zejména je průšvih, když je čte někdo technicky zaměřený - protože takový člověk chce každou větu podrobovat výrazové logice :).

Každá právní norma se vykládá v kontextu účelu, pro který vznikla. Samozřejmě je nemyslitelné aby zmíněná odpovědnost platila pro e-maily, už jen protože podléhají listovnímu tajemství. Pokud jdou dva právní předpisy do kolize, poměřuje se, který zájem je hoden většího chránění. Naprosto bez pochyb není účelem zavádět cenzuru soukromé pošty a bez pochyby je soukromí pošty chráněnější zájem. Účelem zmíněného návrhu je, aby se poskytovatelé systematicky nezříkali odpovědnosti s odůvodněním, že obsah nahrál uživatel. Je spousta služeb, které toho vysloveně zneužívají - např. ulozto.cz. Po zavedení nové normy bude na poskytovateli, aby prokázal, že zavedl přiměřená opatření a že vynakládá očekavatelné úsilí na to, aby nešířil a zejména znovu nešířil nelegální obsah.

Pak je zde měřítko přiměřenosti. Pokud někdo zneužije blog Sboru dobrovolných hasičů v Horní dolní k šíření závadného obsahu, lze očekávat, že hasiči nebudou vůbec popotahováni, a kdyby ano, že to stejně soud smete ze stolu. Pokud ovšem bude docházet k opakovaným incidentům, a hasiči nepodniknou žádný krok k nápravě, mohli by být odpovědni. Proti tomu takový Facebook, Google, ... nese odpovědnost plnou, protože práce s uživatelským obsahem je alfa a omega jejich podnikání. V jejich případě lze naopal očekávat, že soudy budou nalézat vysokou míru odpovědnosti, protože kdo jiný by měl umět vynakládat požadované úsilí, než tyto firmy.

1369
Co chcete konkrétnějšího? StartSSL byl potrestán za porušení pravidel. Nikdo se ale nezabýval, že to porušení bylo ve skutečnosti dost okrajové.

Pravidla pro vydávání certifikátu = chráněný zájem.
Pravidla jsou dost volná (jak jste sám upozornil) = chráněný zájem není moc "chráněný".
Porušení StartSSL bylo víceméně formálního charakteru, protože ve faktické rovině do chráněného zájmu moc nezasáhlo.

Jinými slovy, StartSSL do té doby vydalo snad miliony certifikátů, včetně OV, ke kterým odváděli poměrně solidní práci (ověřovali totožnost, delegaci k úkonu, ...). Místo toho bylo ale (víceméně politicky) rozhodnuto, že mají zmizet. Zmizelé místo pak fakticky zaujal nejvíc Let's Ecnrypt, kterému, jako mnoha jiným, stačí k vydání DV certifikátu opravdu málo.

Tedy: mnohé certifikační autority sice formálně plní pravidla na 100 %, ale ve faktické rovině se snaží, aby urvaly co největší podíl trhu a laťku jen snižují.

1370
Psal jste, že vás nezajímá, jak by to mělo být, ale zajímá vás současná realita. Takže jistě máte odkaz na průběžně aktualizovaný seznam e-mailových schránek, které si firmy musí pohlídat. Podělíte se o ten odkaz?

To právě neexistuje. Proto je pro firmy (a např. vládu USA) daleko zajímavější spolupracovat s jednou certifikační autoritou, ať už s ní existuje dohoda či ne, a mít tuto cestu pohlídanou.

V minulosti jsem se dost podivoval, proč se rozjela honba proti StartSSL, které sice porušilo zvyklosti ve vystavování certifikátů, ale ve skutečnosti to mělo daleko menší dopad, než uvolnění kriterií pro DV certifikáty.

Dnes je v podstatě na certifikační autoritě, kterému e-mailu bude věřit, že je dostatečný pro autorizaci požadavku. Bohužel, v marasmu, který dnes platí, nedá se očekávat, že by někdo někomu sebral důvěryhodnost kvůli špatnému vydávání DV certifikátů.

1371
Já myslím, že jsem ve skutečnosti uváděl na pravou míru to, jak reálně certifikační autority validují vlastnictví domény. Nereálné představy, jak si teoreticky ohlídáte všechny e-maily, přes které je možné validovat doménu, jste tu psal vy.

No a jsme na začátku: DV certifikát je bezcenný: nic nezaručuje, jen si prostě "zašifrujeme" (co tedy "certifikuje", heh?). OV certifikát nedává smysl - není viditelný rozdíl od DV certifikátu, aspoň z pohledu koncového uživatele ne. EV certifikáty lidi taktéž nevnímají. Kdyby měla banka jeden den EV certifikát a druhý den jen DV, dovolím si tvrdit, že jen nepatrný zlomeček zákazníků by se obrátil na banku, jestli je to v pořádku.

Celý účel certifikátů, aby byly jen od toho že "jen budeme šifrovat" je uhozený. K tomu, abychom jen šifrovali, nepotřebujeme certifikovat. Pokud něco slovo "certifikace" znamená, tak to, že je někým ověřená nějaká skutečnost. U EV certifikátů je toho celý seznam, u OV certifikátů se ověřuje totožnost subjektu (a osoby, která jej zastupuje). U DV certifikátů je účelem ověřit, že se dostal do ruky toho, kdo má právo k doméně.

A jsme u toho, co to znamená "právo k doméně". Pokud to vyložíme extenzivně, můžeme dojít k tomu, že by se měl vystavit certifikát komukoliv kdo má na doméně e-mail.  ...Takže hledáme méně extenzivní způsob, jak ověřovat oprávněnost osoby a její spojitost s doménou.

Teď jde jen o to, jestli už dnes nejdeme moc vstříc tomu, aby DV certifikát získal kde kdo, třeba jen v důsledku chyby nějakého nastavení, nebo v důsledku toho, že už ve firmách nelze pohlídat přístup k e-mailům. Kdyby to nešlo uhlídat, jak píšete, lítaly by tu miliony certifikátů @seznam.cz, @gmail.com a dalších. Tyto firmy si naopak musí pohlídat všechny e-maily, přes které je možné certifikát získat.

1372
ACME je rozšiřitelný protokol, vy píšete jen o variantě ověřování http-01. Já tuhle metodu používám k ověření dvou certifikátů, u kterých nemám přístup do DNS. Ve všech ostatních případech používám dns-01. Nemyslím si, že by si měl web server nebo poštovní server sám zařizovat certifikát – jejich správce má vytvořit privátní klíč a vygenerovat žádost a na konci nanejvýš stáhnout nový certifikát. Ale samotné vystavení certifikátu má zařizovat někdo jiný.

Navazoval jsem na Vaši poznámku o lokaci .well-known, takže ano, mluvím jen o http-01.

V praxi právě o certifikáty žádají samotné servery. Touto cestou jde doba a toto usnadnění je nezakrývaným záměrem LE. Opět, v praxi, těžko tomu kdo platí (zákazník, management) vysvětlíte, proč chcete certifikát řešit se správcem a s jasnou hodinovou dotací, když má každý pocit, že to může být zadarmo a samo.

Myslím, že příliš mluvíte o tom, jak by to mělo být, ale málo vnímáte, jak to ve skutečnosti je.

1373
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.

Podívejte se, jak vypadají ACME klienti v praxi. Velká část z nich definuje .well-known jako globální alias na webserveru a pro všechny virtualweby do stejného místa. Bohužel, lidská lenost je nekonečná a i možná dobře zamýšlený záměr dostane vždy v praxi přes kalhoty.

Druhým případem, kdy naopak .well-known nedostačuje je situace, kdy HTTPS provoz ochytává perverzní proxy, ale ostatní porty předává dál - např. mailserveru. Pak musíte řešit buďto distribuci certifikátu na jiný stroj, nebo nějakými (dost nesymslnými a nesystematickými) pravidly umožnit, aby .well-known byl nastaven jen jako "try", a v případě neúspěchu naopak předán dál na další stroj (aby i on si mohl získat certifikát).

ACME zdaleka není tak růžové. Má i svá proti.

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

V tom, že mi admin, s přístupem na proxy server nemůže 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).

1375
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.

Já zde hovořím o praxi, o současné situaci a o tom, jak firmy (i vlády) na ni musí reagovat. Proto v současnsti není ze všech hledisek rovnocenné, jestli připustím použití LE certifikátů, nebo od jiné autority. Každá z cest má jinak vysoký práh a jiné překážky, u kterých je potřeba vždy počítat, že je bude možné nějak překonat. Přesto budu volit to, co je "tady a dnes" z mého pohledu nejbezpečnější.

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.

Z mého pohledu je to naivní představa. Stejně jako vysvětlovat seniorům, že na zájezd zdarma, nebo na "krátkou předváděcí akci s dlouhou neomezenou konzumací" je nikdo ve skutečnosti nepozve.

Obdobou jsou banky: sice si máte hlídat svoji kartu, údaje k ní a PIN, limity si můžete nastavovat podle potřeby on-line v bankovnictví. Přesto banky zaváděj stále složitější procesy pro ochranu zákazníka - 3D secure, dnes se chystá další velmi silné rozšíření. Taky by mohli říct, že by se o to měl starat držitel karty.

Stejně jako banky musí chránit karty svých zákazníků, i poskytovatelé obsahu mají daleko větší možnosti, jak z jednoho místa bezpečnost zvýšit. Souhlasím s tím, že lepší možnost má příjemce sám (stejně jako držitel karty). Tyto dvě cesty se ale nutně nevylučují.

1376
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ý.

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.

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.

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. To může být složitější mimo jiné i díky tomu, že vůči vlastnímu zaměstnanci (v ČR) nemůžete uplatnit příliš vysokou míru odpovědnosti. Zaměstnanec udělá "chybu", která může stát hodně peněz, ale pokud tam není jasný úmysl (který se prokazuje opravdu složitě), tak ho v nejlepším případě na hodinu propustíte a budete se soudit o něco-málo-násobek jeho průměrné mzdy. Se sesmluvněnou CA, která poruší podmínky ve smlouvě, se můžete soudit neomezeně, nehledě na to, že CA bývají pojištěny.

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.

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í.

U CAA záznamu, nebo v registru domén by možná jen stačilo mít možnost nastavit, jestli chci povolit pro své domény vydávání DV certifikátů, a celý problém, o kterém píšu, by odpadl.

1377
Proč by neměla? Let's Encrypt má velkou výhodu v automatizaci svých služeb, takže není potřeba se o obnovení starat. Že to může být problém ukázal nedávný problém ve Spojených státech, kde přestali chodit úředníci na chvíli do práce a některé služby přestaly být dostupné, protože v kanceláři neseděla lidská síla, která je zodpovědná za hlídání platnosti certifkátů a jejich včasné ruční obnovování. Tohle je lepší nechat na stroji.

S tím bych s dovolením nesouhlasil. 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. Jaké je v takovém případě riziko, že přestane fungovat obnova jednou za cca dva měsíce vs. ruční obnova jednou za dva roky, bych si nedovolil bez podkladů posuzovat.

Co se týče případu USA, z hlediska bezpečnosti bylo vyústění naprosto v pořádku. Procesy byly nastaveny na to, že vyžadují lidskou kontrolu. Opět nelze bez podkladů (mj. bez bezpečnostního protokolu daného úřadu) od stolu vystřelit, že by bývalo bylo lepší používat LE. Ano, bylo by to lepší pro nepřetržitý běh webu. Ale bylo by to opravdu lepší ve všech ohledech, které administrativa řeší? Není např. proces obnovy certifikátu pevně svázán s nějakými bezpečnostními procedurami? Není např. před výročním datem vyhodnocováno, jaký typ certifikátu a issuer nejlépe odpovídá bezpečnostním ohledům úřadu? Zkuste si např. představit, že se přijde na nějakou bezpečnostní chybu v LE. Bude úřad schopný reagovat tak rychle, jak je požadováno? Nebo je vhodnější podepsat velkou smlouvu s externím partnerem, který ručí za hlídání některých oblastí bezpečnosti, mj. za reissue, pokud by to bylo potřeba? Nemají přístup k LE mechanismům i osoby, které jsou potenciálně nebezpečné pro USA? Pokud ano, bylo by nutné zvážit HPKP - v případě ohrožení USA potřebujete mít kontrolu jak i lidi od informací odříznout, tak i jak jim zaručené informace předat. Pokud se použije HPKP, jak často se bude měnit klíč? Pokud se bude měnit klíč, jak moc to bude (opět) závislé na zaměstnancích? (a jsme na začátku...?)

Nemám opravdu rád, když se bez bližších znalostí vypalují soudy typu: "vidíš, s LE by se to nestalo". To si možná může dovolit laik v diskusi, ale profesionál by měl vědět, že je potřeba aspoň nakouknout i za roh. Bezpečnost není téma jen o černém zámečku v prohlížeči.

V Seznamu očividně vyhodnotili, že pro jejich potřeby stačí LE, že nevyžadují ani OV, ani EV certifikát. To není jen politické rozhodnutí, ale i bezpečnostní. 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 musíte pečlivě zvážit, jestli je dobrý nápad. Nebo, pokud chcete issue omezit, pak ACME zatrhnete na vstupní proxy a dál si musíte být jist, že se požadavek nepředá (co když tento filtr selže?). 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. Oba mechanismy mají administrativně svá pro i proti, oba mechanismy mohou být zneužity jinak a oba mají jiné silné stránky.

Technický ohled je až to poslední, co se v těchto případech zvažuje. Technicky je totiž (pokud vláda USA neví něco víc :)) šum a fuk, jestli je certifikát vystaven od LE, nebo od někoho jiného. LE už dávno nemá nálepku low cost řešení.

1378
Běžně potřebujete mít tři prostředí:
1. Produkční.
2. Vývojové - tady programátoři dělají změny v databázi a testují je.

3. Předprodukční - obvykle se jedná o pravidelnou (třeba noční) kopii produkčního prostředí. Na ní se testují patche z vývojového prostředí a dá se otestovat i výkon na reálných datech. Máto to ale i svá úskalí. Např. v předprodukčním prostředí máte kopii ostré uživatelské databáze. Takže existuje riziko, že třeba odejdou e-maily registrovaným uživatelům. Proto se předprodukční prostředí řeši ještě navíc tak, že běží v kontextu jiného systémového uživatele, který nemá právo odesílat e-maily (vč. pravidla na firewallu). Obdobně musí být vyblokované funkce volání vzdálených API (např. platební brány, SMS brány, ...).

1379
@Miroslav Šilhavý: To už mi zase přijde jako složité řešení, navíc, myslel jsem, že jste propagoval, aby se takové věci nedělaly uživatelem postgres na tož rootem.

To propaguji dál, ale vy jste položil jako podmínku, že script je rootem spuštěný. Tj. vyšší oprávnění už nejdou získat.

1380
Mám na CentOS skript, který potřebuji spouštět rootem, ale zároveň tam jsou části skriptu, které potřebuji spouštět jiným uživatelem, ale navzájem ty části kódu na sebe musí vidět a umět spolu spolupracovat. Jedná se například o příkazy psql a pg_dump, se kterými root neumí pracovat a zároveň ho nechci vytvářet jako roli v postgresql databázi. příkazy bych raději spouštěl uživatelem, který je pro tento účel vytvořen.

Zde by mi přišlo asi nejjednodušší pouštět psql i pg_dump pod rootem. Na to nepotřebujete rootovi dávat roli do databáze. Stačí psql i pg_dump spustit s příkazem -U a uvést, pod jakou rolí se chcete přihlásit. Pak už je potřeba jen nastavit do pg_hba buďto trust, nebo lépe, zadat heslo do .pgpass.

Přehazovat to pomocí su / sudo je podle mě zbytečné, nepřinese to ani zblo bezpečí navíc.

Stran: 1 ... 90 91 [92] 93 94 ... 206