Příspěvky

4276

Software / Re:Boj s kvalifikovaným certifikátem

« kdy: 15. 09. 2016, 21:17:57 »

Certifikační autorita může na přání zveřejňovat i certifikáty. Odkaz na CRL nebo OCSP je součástí certifikátu, takže pokud příjemce důvěřuje příslušné certifikační autoritě, je certifikát (automaticky) přiložený k podpisu to jediné, co potřebuje znát pro ověření podpisu.

4277

Software / Re:Jak ověřit podepsaný PDF soubor?

« kdy: 15. 09. 2016, 21:14:09 »

Podle mne nejjednodušší je použít Adobe Reader.

4278

Software / Re:Boj s kvalifikovaným certifikátem

« kdy: 14. 09. 2016, 08:13:13 »

Ad 1) Bylo by potřeba vidět konkrétní e-mail. Obvykle je podepsaný celý e-mail – i samotné tělo e-mailu může být v e-mailu vložené vícekrát (např. čistý text a HTML), stejným způsobem, jako přílohy. Ale formát e-mailu je hodně obecný, je možné je do sebe různě vnořovat, takže vždy dokážete vyrobit e-mail, kde bude část podepsaná a část nepodepsaná.

Pokud posíláte textové dokumenty, je podle mne nejlepší udělat z nich PDF a to podepsat. Například fakturu pak takhle příjemce snadno vloží do účetního systému, a když jí z něj za pět let otevře, pořád dokáže podpis ověřit. Když podepíšete e-mail, dokument z něj se brzy osamostatní, a kdo pak má pátrat, kde je ten původní podepsaný e-mail.

Ad 2) Certifikát nemusíte ručně přikládat jako přílohu, zvolte, že jej má e-mailový klient přikládat k podpisu. Pro ověření podpisu je certifikát potřeba, takže je nejlepší ho k podpisu vždy přikládat. Je možné, že příjemce e-mailu už váš certifikát má (v osobních kontaktech nebo v nějakém firemním adresáři), ale je lepší na to nespoléhat. I kdybyste u certifikační autority povolil jeho zveřejnění, tam ho klient nejspíš nenajde, protože nebude vědět, u které autority by ho měl hledat.

Ad 3) Certifikát je celý veřejný, jeho součástí je veřejný klíč. Privátní klíč nikdy nikam neposíláte, ten je tajný a nikdo ho nesmí znát. Nastavte si program, kterým podepisujete, aby certifikát přikládal rovnou k podpisu – ověřující program jej pak umí rovnou použít. Když ho přidáte vedle jako přílohu, musel by si ho adresát importovat ručně do svého adresáře.

4279

Software / Re:App Password od Google už nefunguje?

« kdy: 12. 09. 2016, 10:51:34 »

Ano, to jsem viděl. Že nejsou potřeba ale neznamená, že to vypnuli, nebo?

Nevím, čemu říkáte „vypnuli to“. Podle mne ten text znamená, že aplikace se přihlašuje pomocí hesla k uživatelskému účtu, takže když zadáte aplikační heslo, přihlášení neprojde.

A když se přihlásím dvoufaktorově, jak se to např. při strátě revokuje? U App Password to umím.

Pokud je potřeba se přihlásit pokaždé znovu, „revokuje“ se to jednoduše tak, že nezadáte číselný kód. Ale spíš to přihlášení funguje na principu OAuth, takže pak aplikaci najdete v Přidružené aplikace a weby, kde jí můžete přístup odebrat.

4280

Software / Re:App Password od Google už nefunguje?

« kdy: 11. 09. 2016, 22:05:42 »

V nápovědě píšou, že od iOS 8.3 nejsou App Passwords potřeba, nebo-li tam byste se měl přihlašovat klasicky heslem a jednorázovým kódem.

4281

Software / Re:App Password od Google už nefunguje?

« kdy: 11. 09. 2016, 13:21:13 »

V jaké aplikaci to přihlášení zkoušíte? Jakou chybu vám to vypíše? V jiné aplikaci to heslo aplikace funguje?

4282

Software / Re:App Password od Google už nefunguje?

« kdy: 10. 09. 2016, 21:16:15 »

Myslím,že dotaz nepotřebuje zjednodušit, ale zpřesnit. Možná existuje pro iOS jediná aplikace od Googlu a to, co popisujete, dává každému uživateli iOS smysl. Já iOS neznám a ve vašem dotazu se ztrácím.

Já mám na Google účtu také zapnutou dvoufázovou autentizaci. To znamená, že když se někde nově přihlašuju ke Google účtu, zadám nejprve své heslo, a po té mne Google vyzve k zadání jednorázového hesla, což je šestimístné číslo, které mi vygeneruje aplikace v mobilu. To jednorázové heslo ale není App Password.

Některé aplikace ale nepodporují dvoufázové ověření, proto Google zavedl právě App Password. To je jedno dlouhé heslo přidělené konkrétní aplikaci, které se používá místo toho dvoufázového ověření. Když tedy nějaká aplikace umí pracovat jenom s jedním heslem (předpokládá tedy, že jí zadáváte přímo heslo k účtu a že nepoužíváte dvoufázové ověření), vygenerujete si pro ni takovéhle heslo (App Password) a použijete to. V nastavení účtu Google pak vidíte seznam těch App Password a můžete je např. smazat v případě, kdy by někdo to heslo získal nebo by se aplikace chovala špatně.

Doporučuju jít na web Google do Můj účet – Přihlášení a zabezpečení – https://myaccount.google.com/security Tam máte Hesla aplikací, kde máte seznam těch App Password. Zrušte stará hesla pro příslušnou aplikaci na iOS, vytvořte si nové heslo a to zadejte do aplikace na iOS (pokud ta aplikace nepodporuje dvoufaktorovu autentizaci). V takovém případě do té aplikace zadáte jenom tohle App Password, nezadáváte tam ani své heslo k účtu Google ani jednorázové  heslo (číselný kód).

4283

Software / Re:Overenie S/MIME certifikátu

« kdy: 05. 09. 2016, 21:45:18 »

V tomto případě bych si tipnul, že to není nějaký self-signed certifikát, ale že to bude certifikát vystavený některou z certifikačních autorit, které uznává slovenská legislativa. Takže bych ověřil certifikát té autority, a alespoň bych to měl vyřízené pro všechny další certifikáty vydané danou autoritou. Navíc těmhle certifikátům vydávaným podle evropské legislativy věřím mnohem víc, než drtivé většině tzv. "uznávaných autorit" - protože pro nás platí společné zákony a ta autorita má ze zákona vůči mně (zprostředkovaně) nějaké závazky.

4284

Server / Re:LDAP - jak zjistit, kdy si naposledy uživatel změnil heslo?

« kdy: 05. 09. 2016, 11:27:41 »

Zjistíte si, v jaké položce to máte v LDAPu uložené, a pak použijete libovolného LDAP klienta – třeba řádkový ldapsearch.

4285

Server / Re:Padajici dnsmasq

« kdy: 03. 09. 2016, 12:18:15 »

V tom logu nikde nevidím odpověď na dotaz na kořenové servery, který předpokládám pochází od Monitu. Otázka je, kde je problém - zda dnsmasq odpověď opravdu nedostane, nebo zda ji nepošle dál. To zjistíte asi jedině tcpdumpem.

4286

Server / Re:Padajici dnsmasq

« kdy: 03. 09. 2016, 11:15:24 »

Monit vás neinformuje o pád dnsmasq, ale o tom, že od něj nedostal odpověď. Je divné, že dnsmasq zaznamená požadavek v 9:12:23, a Monit už v 9:12:24 hlásí nedostupnost, když je tam limit 10 sekund. Důležité je pokračování v tom logu, zda dnsmasq odpověď od Google dostal a přeposlal jí dál. Pokud ano, je problém jen v monitoringu a ne v dnsmasq.

4287

Software / Re:BIND vs Unbound a caching DNS

« kdy: 02. 09. 2016, 14:37:22 »

Kešující DNS resolver použijete především v případě, kdy máte vlastní síť (firma, škola, ISP). Obyčejný klient (uživatelský desktop, mobil apod.) neprovádí překlad DNS sám od kořenových serverů, místo toho má nakonfigurovaný jeden nebo více DNS resolverů, které pro něj tuhle službu dělají. Klient se tedy DNS serveru zeptá rovnou „dej mi A záznam pro www.root.cz“, DNS resolver vyřídí to dotazování kořenového serveru, serveru pro doménu cz., pro doménu root.cz. a klientovi vrátí už hotový výsledek. Takovýhle DNS resolver obvykle poskytují svým klientům ISP, ale můžete ho mít i ve své síti. Případně existují veřejné, třeba 8.8.8.8 a 8.8.4.4 od Googlu nebo OpenDNS. No a kešující jsou ty DNS resolvery proto, že obvykle vyřizují velké množství opakujících se požadavků, takže se jim vyplatí odpovědi si nějakou dobu pamatovat (aby nemusel pořád dokola u serverů kořenové zóny zjišťovat, který že to server má na starosti doménu cz. apod.).

S nástupem DNSSEC je snaha dostat ten DNS resolver až na zařízení uživatele (buď přímo koncové zařízení, nebo třeba domácí router), protože DNS resolver je ta služba, která také provádí validaci DNSSEC (a když vám DNS resolver ISP odpoví „IP adresa je 91.213.160.118 a DNSSEC jsem zvalidoval“, tak mu to věřit můžete, ale taky nemusíte).

Jinak BIND může fungovat i jako kešující DNS resolver, dříve se často provozoval na jednom serveru spolu s autoritativním serverem, ale takové použití se silně nedoporučuje, protože je velice snadné udělat to špatně. A BIND také není zdaleka jediný autoritativní DNS server, zajímavý je třeba český KnotDNS, dále třeba PowerDNS nebo NSD. A vedle Unboundu existují i další kešující DNS resolvery, třeba mladší bráška KnotDNS Resolver nebo dnsmasq.

4288

Software / Re:Proč po delší době narůstá použitá paměť u prohlížečů?

« kdy: 02. 09. 2016, 06:45:51 »

Cílem tohoto "efektivního využití dostupné paměti" by přece mělo být zrychlení aplikace. Nebo se snad pletu?

Nevím, co "zrychlení aplikace" znamená. Já bych spíš řekl, že cílem by mělo být "komfortnější používání" nebo "lepší zážitek uživatele" nebo něco takového.

4289

Software / Re:Proč po delší době narůstá použitá paměť u prohlížečů?

« kdy: 01. 09. 2016, 23:53:19 »

Mně se to děje taky, a na každém počítači s Windows, ke kterému si sednu, a v každém prohlížeči, který tam spustím, IE, FF, Chrome. Chyba bude tedy asi v mně. I když teď si vzpomínám, že někdy před 8 lety, když jsem měl otevřeno více jak 10 tabů, tedy stejně jako dnes, tak to v paměti zabíralo podstatně méně místa a ani to nezpomalovalo celý počítač. Takže buď se zhoršil OS a prohlížeče nebo ty stránky jsou více nenažrané. Anebo oboje.

Někteří lidé tu opakovaně píšou, že mají s prohlížečem problém, že jim zpomaluje počítač a musí ho často restartovat. A jiní zase píšou, že žádný takový problém nemají a prohlížeč jim běží klidně několik dní v kuse. Buď můžete tvrdit, že je chyba obecně v prohlížeči nebo ve webových stránkách, přestože jiní takový problém v prohlížeči ani stránkách nemají. A nebo můžete přestat pronášet rychle soudy, kdo za to určitě může, a místo toho se můžete pokusit zjistit, co je skutečnou příčinou těch problémů, které pozorujete. K vyřešení vašeho problému vede jenom jedna cesta, a ta první to není.

Mimochodem, to, že prohlížeč dříve zabíral méně místa v paměti, se tu také objevilo opakovaně, a pořád je to stejný nesmysl. Pochopit to na příkladu paměti je asi náročné, tak to zkusím s procesorem. Na Rootu je v současné chvíli zprávička o novém kompresním a dekompresním algoritmu, a v diskusi je také zmíněna paralelní implementace gzipu. Dalo by se to popsat stejným způsobem, jako popisujete tu paměť. Dříve gzipu stačilo na komprimaci a dekomprimaci jedno vlákno procesoru. Dnes paralelní pigz zabere klidně osm vláken procesoru. Jistě se na to dá pohlížet i takhle, ale většina lidí se na to dívá spíš tak, že pigz dokáže využít všechna vlákna procesoru a je díky tomu rychlejší, než gzip, který "šetří procesor".  Úplně stejně je to i s tou pamětí. To, co jeden může nazývat "zabíráním paměti", někdo jiný může nazvat "efektivním využitím dostupné paměti".

4290

Software / Re:Proč po delší době narůstá použitá paměť u prohlížečů?

« kdy: 01. 09. 2016, 15:19:17 »

Deje se to asi vsem.

Ne, neděje se to všem. Mně se to neděje na počítači ani notebooku s 8 GB RAM, nedělo se mi to na počítači se 4 GB RAM. A to mívám vedle prohlížeče spuštěné aplikace, které jsou na paměť opravdu náročné.