Počítačové hře Doom je dnes 30 let. Vydána byla 10. prosince 1993. Zahrát si ji lze také na Internet Archive.
V srpnu společnost HashiCorp přelicencovala "své produkty" Terraform, Packer, Vault, Boundary, Consul, Nomad a Waypoint z MPL a Vagrant z MIT na BSL (Business Source License). V září byl představen svobodný a otevřený fork Terraformu s názvem OpenTofu. Na konferenci Open Source Summit Japan 2023 byl představen (YouTube) svobodný a otevřený fork Vaultu s názvem OpenBao (GitHub).
Na dnes plánované vydání Debianu 12.3 bylo posunuto. V jádře 6.1.64-1 v souborovém systému ext4 je chyba #1057843 vedoucí k možnému poškození dat.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek i s náhledy aplikací v Týden v GNOME a Týden v KDE.
Tak od ledna linuxové terminály, výchozí pozadí i celé desktopy v barvě "broskvového chmýří", v barvě "jejíž všeobjímající duch obohacuje mysl, tělo i srdce". Barvou roku 2024 je PANTONE 13-1023 Peach Fuzz.
Byla vydána verze 10 linuxové distribuce Freespire (Wikipedie). Jedná se o bezplatnou linuxovou distribuci vyvíjenou společností PC/OpenSystems LLC stojící za komerční distribucí Linspire (Wikipedie), původně Lindows.
Binarly REsearch před týdnem informoval o kritických zranitelnostech UEFI souhrnně pojmenovaných LogoFAIL. Tento týden doplnil podrobnosti. Útočník může nahradit logo zobrazováno při bootování vlastním speciálně upraveným obrázkem, jehož "zobrazení" při bootování spustí připravený kód. Pětiminutové povídání o LogoFAIL a ukázka útoku na YouTube.
Byla vydána listopadová aktualizace aneb nová verze 1.85 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.85 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
git.kernel.org je nově oficiálně také v tmavém vzhledu.
Richard Hughes na svém blogu oznámil, že počet aktualizací firmwarů pomocí služby LVFS (Linux Vendor Firmware Service) přesáhl 100 milionů. Přehled podporovaných zařízení, nejnovějších firmwarů nebo zapojených výrobců na stránkách LVFS.
Naše soukromí by mělo být chráněno listovním tajemstvím, nicméně dnešní svět je plný všemožných slídilů a jiných záškodníků, takže kromě spoléhání se na psané právo je dobré používat i kryptografii. Ač to slovo zní hrozivě, šifrování je snadné a dostupné i běžnému uživateli.
OpenPGP a S/MIME jsou do jisté míry konkurenční technologie. Oboje slouží k šifrování a podepisování e-mailů, z bezpečnostního hlediska jsou srovnatelné – stojí na stejném šifrovacím algoritmu (RSA). V čem se ale liší, je způsob, jakým se ověřuje vlastník klíče.
OpenPGP funguje na síťovém principu – jednoduše si vytvoříte svůj klíč (resp. pár veřejného a soukromého klíče) a můžete šifrovat a podepisovat. Aby mohl někdo jiný váš podpis ověřit (věděl, že patří vám), musíte mu nejdřív předem sdělit otisk svého klíče, což je náročné – musíte to totiž provést nějakou důvěryhodnou cestou (např. předat na papíře při osobním setkání). Druhou možností je, že váš klíč podepíší vaši kamarádi a „zaručí“ se za vás. Adresát pak uvidí, kdo váš klíč podepsal, a pokud těm lidem věří, bude věřit i vašemu podpisu – nemusíte se tedy setkávat osobně.
S/MIME (a obecně PKI) oproti tomu funguje na hierarchickém principu. Existují zde tzv. certifikační autority (dále jen CA). Kořenové (nejvyšší) CA svým podpisem (certifikátem) ověřují podřízené CA a ty jednotlivé uživatele. Příjemce má ve svém e-mailovém klientovi nainstalované certifikáty autorit, kterým důvěřuje, což umožňuje bezpečnou komunikaci bez toho, aby bylo potřeba si předávat veřejné klíče osobně nebo se spoléhat na podpisy kamarádů.
S/MIME bývá někdy spojováno spíš se světem komerčního a uzavřeného softwaru, zatímco OpenPGP se považuje za víc „open“. V obou případech se ale jedná o otevřené standardy a v obou případech existují jak otevřené, tak uzavřené implementace: GnuPG (GPG), OpenSSL, GnuTLS, PGP… Tento článek se věnuje S/MIME, ale neznamená to, že by S/MIME byla jediná správná cesta – záleží na způsobu vaší práce, zda vám víc vyhovuje pavučina důvěry (WoT – Web of Trust) u PGP/GPG nebo hierarchický systém s certifikačními autoritami. A v neposlední řadě také záleží na tom, jakou technologii používají lidé, se kterými si budete dopisovat – výhodné je tak mít oboje.
Provozovat certifikační autoritu něco stojí, a tak se ani vydávání certifikátů neobejde bez placení (alespoň u těch CA, které jsou ve výchozí instalaci prohlížečů a e-mailových klientů). Vedle toho zde existují i CA, které ověří vaši „totožnost“, a vydají vám certifikát bezplatně.
Jako zástupce těchto certifikačních autorit jsem vybral CAcert.org a StartSSL. CAcert je zcela nekomerční a komunitní a její certifikáty používá např. poskytovatel IPv6 tunelů SixXS nebo nadace FSFe. U StartSSL si naopak časem můžete (ale nemusíte) přikoupit placený certifikát, který bude důvěryhodný ve většině e-mailových klientů a také nabízí další zajímavé služby (DNS, OpenID).
S/MIME stojí na asymetrické kryptografii – tedy šifrování s dvojicí klíčů, soukromým a veřejným. V prvním kroku si tedy tuto dvojici klíčů vytvoříme – použijeme k tomu software OpenSSL, který najdete ve své linuxové distribuci.
Nejprve si vyrobíme pomocný soubor s nastavením – šablonu – a pojmenujeme ho nastavení.txt
:
default_bits = 4096 distinguished_name = req_distinguished_name prompt = no [req_distinguished_name] commonName = franta@example.com
Zadejte samozřejmě svoji e-mailovou adresu. Více údajů (země, organizace…) není potřeba uvádět – stejně by se ve vydaném certifikátu neobjevily – ignorují se, protože je v našem případě nelze ověřit.
Následujícím příkazem si vygenerujeme soukromý klíč a požadavek:
openssl req -new -keyout klíč.pem -out požadavek.pem -nodes -config nastavení.txt
Soubor klíč.pem
teď musíme střežit jako oko v hlavě, je to náš soukromý klíč a díky volbě -nodes
není ani chráněný heslem. Takový soubor patří na šifrovaný disk bezpečného počítače. Také můžete volbu -nodes
vypustit – pak ale nezapomeňte heslo. Soubor požadavek.pem
je tzv. CSR, tedy požadavek na podepsání certifikátu. Obsahuje náš veřejný klíč a metadata (v našem případě jen e-mailovou adresu). Oba soubory jsou v textovém PEM formátu – snadno se kopírují třeba přes schránku a můžete si je zálohovat vytištěním na papír (jsou v Base64 kódování).
Soubor s CSR požadavkem vygenerovaný v předchozím kroku teď předáme certifikační autoritě a ta nám na základě něj vystaví certifikát. Před tím je potřeba ověřit, že jsme majiteli dané e-mailové adresy – jinak byste si mohli vyžádat certifikáty pro adresy cizích lidí, což by jistě nebylo dobré. Následující podpis se liší podle zvolené CA – kterou si vyberete, je na vás.
Po nezbytné registraci a přihlášení klikneme v nabídce na „Emailové účty“ a „Přidat“. Zadáme svoji e-mailovou adresu (stejnou jako v CSR) a odešleme. Vzápětí nám přijde ověřovací e-mail s odkazem – klikneme na něj a potvrdíme, že se skutečně jedná o náš e-mail.
Po ověření e-mailové adresy si můžeme požádat o certifikát – klikneme na „Klientské certifikáty“ a „Nový“. Zaškrtneme svoji e-mailovou adresu a volbu „Show advanced options“. Do textového pole vložíme obsah souboru požadavek.pem
a odešleme.
CAcert.org nám obratem vygeneruje certifikát:
Máme klientský certifikát. Uložíme si ho včetně hlaviček (-----BEGIN CERTIFICATE-----
a -----END CERTIFICATE-----
) do souboru certifikát-cacert.pem
.
Klíč a certifikát můžeme zabalit do jednoho souboru – k tomu slouží binární formát PKCS#12:
openssl pkcs12 -export -in certifikát-cacert.pem -inkey klíč.pem -out cacert.p12
Při vytváření tohoto „archivu“ budeme požádáni o heslo, kterým bude chráněn. Textové PEM soubory s klíčem a certifikátem můžeme smazat (dají se v případě potřeby z PKCS#12 zase obnovit).
Opět se zaregistrujeme a přihlásíme. Poté klikneme na „Validations Wizzard“ a vybereme „Email Address Validation“. Tentokrát nebudeme klikat na odkaz z e-mailu, ale opíšeme z něj kontrolní kód do webového formuláře. Ověření dané adresy je teď platné po dobu třiceti dnů – do té doby si musíme certifikát vyřídit, jinak je potřeba adresu znovu ověřit (na platnost certifikátu samozřejmě tato lhůta nemá vliv).
Po ověření e-mailové adresy si můžeme požádat o certifikát – klikneme na „Certificates Wizzard“ a zvolíme „S/MIME and Authentication Certificate“. V případě klientských (S/MIME) certifikátů bohužel nemůžeme použít vlastní CSR a soukromý klíč z předchozího kroku. Ke generování klíče totiž dochází ve webovém prohlížeči – jak praví jejich FAQ:
Otázka: Can I submit a certificate request (CSR) for client certificates (S/MIME)?
Odpověď: No. The client certificates (S/MIME) are created by using the capabilities of the browser. The private key and certificate request are generated by either using the <KEYGEN> tag (Firefox) or activeX control (Internet Explorer). This is the most convenient way for the majority of users. The installation of the certificate is seamless and doesn't require any special knowledge by the user. For the security minded it's important to note that the private key is generated in the browser and not at the server side!
Na jednu stranu je to pohodlnější způsob (nemusíme si klíč s požadavkem vytvářet ručně v příkazové řádce), na druhou stranu nemáme situaci tolik pod kontrolou (byť se klíč generuje v prohlížeči, a ne na serveru) a nemůžeme si zvolit dlouhý klíč 4096, ale „jen“ 2048 (případně 1024).
Pokud ale žádáme o serverový certifikát (pro doménu), můžeme vlastní CSR a vlastnoručně vytvořený klíč použít. U serverových certifikátů můžeme mít i délku 4096 bitů.
Klientský (S/MIME) certifikát je teď včetně klíče nainstalován v našem webovém prohlížeči. Odtud si ho vyexportujeme do souboru startssl.p12
– ve Firefoxu pomocí Úpravy / Předvolby / Rozšířené / Šifrování / Certifikáty / Zálohovat
. Zálohu jsme provedli ve formátu PKCS#12, což je binární formát a v souboru je uložený jak soukromý klíč, tak certifikát (veřejný klíč).
StartSSL nabízí vedle vydávání SSL certifikátů i jiné zajímavé služby. Můžete si zde zdarma aktivovat OpenID, které pak bude: https://vaše-jméno-či-přezdívka.startssl.com/
(pokud máte svoji doménu nebo stabilní webovou adresu, doporučuji používat jako OpenID adresu je a na StartSSL pouze delegovat – budete na nich nezávislí a můžete kdykoli svého OpenID poskytovatele změnit). Ověřování pak probíhá (stejně jako přihlašování k jiným službám StartSSL) přes klientský certifikát, takže při používání svého OpenID ani nebudete muset zadávat heslo. StartSSL dále poskytuje DNS servery (můžete je používat pro svoji doménu, zatím je to beta).
Bez ohledu na to, kterou CA jsme si vybrali, máme teď jak soukromý klíč, tak podepsaný certifikát v jednom souboru – buď cacert.p12
nebo startssl.p12
. Teď je potřeba nainstalovat si do e-mailového klienta (zejména na straně příjemce) kořenový certifikát dané CA (získáme na jejich webu) a importovat si svůj klíč a certifikát (PKCS#12) do e-mailového klienta, ze kterého budeme posílat podepsané e-maily a číst ty šifrované.
V Thunderbirdu si importujeme soubor *.p12
pomocí Úpravy / Předvolby / Rozšířené / Certifikáty / Importovat
. Budeme dotázání na heslo k *.p12
souboru a hlavní heslo k Thunderbirdu (pokud ho máme) – tím bude také náš certifikát a klíč chráněn. Podobným způsobem si importujeme i kořenový certifikát dané CA.
Takto potom vypadá podepsaná a zašifrovaná zpráva v Thunderbirdu:
Výhodou oproti OpenPGP/GPG zde je, že není potřeba doinstalovávat žádné rozšíření (Enigmail) – S/MIME je podporované ve výchozí instalaci Thunderbirdu.
KMail obsahuje ve výchozí instalaci modulu jak pro OpenPGP (GPG), tak pro S/MIME šifrování a podepisování. Ke správě klíčů a certifikátů v KDE slouží grafický nástroj Kleopatra, který je nadstavbou nad gpgsm
(GNU privacy guard – S/MIME version).
Svůj klíč a certifikát si importujeme pomocí příkazu:
gpgsm --import cacert.p12
Budeme dotázáni na heslo k PKCS#12 souboru a potom na heslo, kterým bude soukromý klíč chráněn v rámci GPG systému (stejně jako u GPG jsou tyto klíče uloženy v adresáři ~/.gnupg
)
Dále je potřeba importovat kořenový certifikát dané CA a označit ho za důvěryhodný:
# importujeme kořenový certifikát gpgsm --import root.crt # vypíšeme si veřejné klíče a zjistíme otisk toho daného kořenového certifikátu gpgsm -k # nepovinný komentář – pro pořádek echo "# CAcert" >> ~/.gnupg/trustlist.txt # otisk certifikátu + S (označíme danou CA jako důvěryhodnou) echo "13:5C:EC:36:F4:9C:B8:E9:3B:1A:B2:70:CD:80:88:46:76:CE:8F:33 S" >> ~/.gnupg/trustlist.txt # pošleme signál HUP gpg-agentovi, aby si načetl změny killall -SIGHUP gpg-agent
V KMailu (Kontactu) si potom nastavíme klíč pro danou identitu (e-mailovou adresu odesílatele) v: Nastavení / Nastavit KMail / Identity / Změnit / Šifrování
(na stejném místě se nastavují jak OpenPGP klíče, tak S/MIME).
Takto potom vypadá podepsaná a zašifrovaná zpráva v KMailu:
Na rozdíl od Thunderbirdu v KMailu nestačí zadat heslo ke „klíčence“ jen při spuštění e-mailového klienta, KMail používá gpg-agenta a na heslo se ptá častěji (záleží na vašem nastavení).
Tento článek se zabývá získáním certifikátu pro šifrování a podepisování e-mailů, ovšem služeb těchto CA můžete samozřejmě využít i pro získání serverového certifikátu. Ten vám poslouží k zabezpečení vašeho webového, poštovního, XMPP nebo jiného serveru. Kontrola, zda jste oprávněni získat certifikát pro danou doménu probíhá opět e-mailem – je potřeba mít přístup k adrese ve tvaru webmaster@vaše-doména.cz
.
Pokud identifikace užiatele spočívá jen v zaslání e-mailu a kliknutí na odkaz, lze samozřejmě namítat, že toto řešení není příliš bezpečné. Stejně tak prosté stahování kořenového certifikátu CA z jejího webu není optimální – cestou nám teoreticky mohl někdo podstrčit jiný certifikát a my to nemáme jak ověřit, protože neznáme otisky certifikátu. Certifikát CA byste si tak měli stáhnout aspoň na různých počítačích v různých sítí a zkontrolovat, zda je vždy stejný. V tomto případě má výhodu StartSSL, protože její komerční certifikáty jsou v běžných prohlížečích už nainstalované, a tak si její Class 1 certifikát můžete stáhnout po bezpečném HTTPS. Jestliže máte pocit, že vám tato úroveň zabezpečení nevyhovuje, stačí si pořídit certifikát od některé z komerčních CA. Nabídka je opravdu široká – stačí, když se podíváte do svého e-mailového klienta nebo webového prohlížeče, jaké autority v něm jsou nainstalované jako důvěryhodné. Osobně si myslím, že mít podepsaný certifikát od bezplatné CA je dobrou alternativou k samopodepsaným certifikátům – za nulové náklady přináší alespoň nějaké zvýšení důvěryhodnosti (jak velké, to nechám na vás).
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Oboje slouží k šifrování a podepisování e-mailů, z bezpečnostního hlediska jsou srovnatelné – stojí na stejném šifrovacím algoritmu (RSA).Já myslel, že dneska už skoro každý generuje nové páry klíčů jako DSA/ElGamal... :)
v Linuxu.
K tomu by sloužil daleko lépe DNSSEC než nějaké certifikační autority.Ale v tom ti přece DNSSEC nijak nepomůže, e-maily ti může někdo spoofnout, či odchytit i tak...
PGP/GPG ma trocha volnejsi pristup, avsak na pravne ukony je nepouzitelny.Teoreticky by to možné bylo… akorát se to nepoužívá v praxi. U běžného PKI (s CA) má každý certifikát právě jeden podpis (u podepsaných je podepsán sám sebou, ale jeden podpis má vždy). Kdežto u OpenPGP může mít veřejný klíč 0-n podpisů – je to vlastně mnohem variabilnější a i v prostředí GPG/PGP jde vytvořit prostředí s CA (určité klíče se budou považovat za CA a bude se jim věřit). Akorát jde o to, že v praxi umí e-mailoví klienti většinou S/MIME a u webových prohlížečů se tenhle typ certifikátů používá prakticky výhradně (schválně, kolik www prohlížečů používá GnuTLS, které umí i PGP klíče? Asi je to škoda, protože v nekomerčním světě by byly weby s GPG certifikátem zajímavou alternativou – k těm samopodepsaným a podepsaným neznámými CA – GPG certifikáty by mohlo podepsat víc lidí a dalo by se jim věřit možná víc než nějaké cizí CA…).
Akonahle by bol web podpisany certifikatom, ktory nie je doveryhodny tak to cele straca vyznam.Ne tak docela – když přijdu na stránku podepsanou třeba CAcertem, sice budu muset přidat výjimku, ale je celkem dobrá šance, že komunikuji se serverem majitele dané domény – kdežto v případě samopodepsaných certifikátů nemám jistotu vůbec žádnou (musel bych kontrolovat otisk certifikátu – což u podepsaného můžu dělat taky).
Otazne je, ci by dodavatelia browserov boli ochotni prehlasit nejakeho vydavatela (podpisovatela) PGP certifikatov za doveryhodnehoNejdřív by se to muselo vyřešit po technické stránce – dnešní prohlížeče umí pracovat s X509, ale ne s GPG/PGP certifikáty.
ak by za nim nestalo nieco velke (google?, mozilla?).Pravidla by byla asi stejná jako u klasických CA. Ale procpat do prohlížečů nový kořenový certifikát CA je téměř nemožné (už teď je jich tam hodně).
Na druhej strane, pre uzivatela by to nic neznamenalo, tak sa asi nepohrnu.Pokud by se mělo používat PGP stylem CA (některé klíče by byly považované za CA a byly nainstalované v prohlížečích), asi by to nic nepřineslo. Zajímavé by to bylo právě bez CA – např. bych věřil stránkám, které podepsalo X mých přátel. Což by bylo značně lepší, než samopodepsané certifikáty, které člověk často bez kontroly odklikne, protože mu nic jiného nezbývá – takový certifikát funguje jen jako kontrola, že komunikuji se stejným subjektem jako když jsem na tu stránku vlezl poprvé (jenže nevím, jestli to od samého začátku není útočník).
U StartSSL si naopak časem můžete (ale nemusíte) přikoupit placený certifikát, který bude důvěryhodný ve většině e-mailových klientů a také nabízí další zajímavé služby (DNS, OpenID).na certifikat duveryhodny v emailovych klientech si clovek priplacet nemusi, jedine co se tam plati je overeni osoby a firmy. takze pokud vam staci certifikat pro email nebo server bez jmena, tak nic neplatite zaroven jde i to overeni osoby udelat zadarmo pres notare (zatim nevytizeny, overoval jsem jen jednoho rakusana:) v ramci web of trust viz. startssl.org
Na jednu stranu je to pohodlnější způsob (nemusíme si klíč s požadavkem vytvářet ručně v příkazové řádce), na druhou stranu nemáme situaci tolik pod kontrolou (byť se klíč generuje v prohlížeči, a ne na serveru) a nemůžeme si zvolit dlouhý klíč 4096, ale „jen“ 2048 (případně 1024).certifikat o velikosti 1024 vam startssl odmitne jako moc malej a proc se nenabizi generovani delsiho klice (4096) nevim, je to delane pres html tag KEYGEN a tak asi zalezi na tom jak to ma naprogramovane prohlizec