Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
Lidé se často obávají úniku citlivých informací. Přitom svěřují takové informace technologii, která již z principu nemůže být bezpečná. Ochranu proti neoprávněnému narušení důvěrnosti komunikace sice zajišťuje trestní zákoník a jeho poměrně tvrdé tresty (v extrémním případě až 8 let vězení), nicméně ani toto nedokáže odradit zvědavce (například z řad zaměstnanců poskytovatelů internetového připojení), kteří se rádi podívají, jaká data kolem nich tečou a co zajímavého obsahují. V extrémním případě může dokonce někdo nějaká data podvrhnout.
Kvalitní ochranu zajistí jen takové šifrování, které pokrývá celou cestu od odesílatele k příjemci. Pro takové účely jsou vhodné různé metody asymetrického šifrování, při kterém příjemce zveřejní svůj veřejný klíč, takže mu kdokoliv může poslat zašifrovanou zprávu – dešifrovat ji však může jen oprávněný příjemce svým tajným klíčem.
Takové šifrování je velmi bezpečné, nicméně není úplně nejjednodušší na používání. Obě komunikující strany musí používat stejnou technologii (např. PGP), je potřeba nějak zajistit její použití v rámci odesílání a příjmu zprávy (buď ručně, nebo integrací do poštovního klienta – to zatím není tak úplně samozřejmost) a v neposlední řadě se musí šifrovací klíč dostat od příjemce k odesílateli (samozřejmě tak, aby bylo zaručeno, že patří skutečně onomu příjemci).
Proto se v praxi takovéto řešení používá zatím poměrně zřídka. Přesto se lze ale pokusům o získání obsahu zpráv poměrně úspěšně bránit šifrováním alespoň části přenosového řetězce – tedy komunikací mezi klienty a servery, též samozřejmě mezi servery navzájem. Pro tyto účely se obvykle používá standardizovaná technologie TLS (příp. starší technologie SSL).
Při tomto řešení je pochopitelně potřeba považovat tuto e-mailovou komunikaci stále za nešifrovanou, protože „ucho“ může číhat přímo na některém ze serverů nebo v úseku, kde šifrování není podporováno (třeba i jen od cílového serveru do klienta příjemce).
Technologie TLS (Transport Layer Security) slouží, jak už anglický název napovídá, k bezpečnému přenosu dat na úrovni transportní vrstvy. To znamená, že se pro vyšší komunikační vrstvy (například relační nebo aplikační, jak je definuje model OSI) jeví transparentní a komunikace může probíhat v zásadě stejně, jako kdyby se komunikovalo jen pomocí „holé“ transportní vrstvy, tedy u Internetu typicky protokolu TCP. SSL je starší verzí této komunikační technologie – dnes se využívá TLS 1.0, což je mírně upravená a hlavně standardizovaná (RFC 2246) verze staršího protokolu SSL 3.0. Pokud se dnes hovoří o TLS/SSL, bere se obvykle v úvahu jen TLS 1.0 a novější verze, přestože se servery někdy konfigurují tak, aby kvůli kompatibilitě se starými programy podporovaly i staré protokoly.
„V zásadě stejně“ (bohužel i bohudík) neznamená „úplně stejně“. Například komunikace, která vyžaduje analýzu nebo dokonce modifikaci přenášených dat, nebude přes TLS fungovat nebo bude vyžadovat jiné chování. Typickými případy jsou využití NAT v kombinaci s protokolem FTP v aktivním režimu nebo využití protokolu HTTP s virtuálními servery (hlavička Host
) – na tohle je potřeba si dát pozor.
TLS zajišťuje jednak samotné šifrování různými algoritmy (podle konfigurace a podle toho, co obě komunikující strany podporují), ale současně také ověření totožnosti jedné nebo obou stran – není totiž nic platné šifrování, když se komunikuje s podvodníkem, který se vydává za legitimní protistranu. Obvykle se používá jen ověření serveru, protože totožnost klienta není potřeba ověřovat (anonymní přístup k webu apod.) nebo je ověřována jiným způsobem (většinou jméno a heslo), nicméně možnost ověření klienta je v řadě případů užitečná.
Pro kontrolu totožnosti se používají certifikáty podle standardu X.509. Lze používat „samopodepsané“ certifikáty – s tím, že budou na protistraně certifikát nebo kořenový certifikát vlastní certifikační autority nainstalovány. Pro veřejné použití jsou ale vhodnější certifikáty podepsané certifikační autoritou, jejíž kořenový certifikát je poskytován v rámci používaných programů (používá se označení „důvěryhodné autority“, i když v některých případech to s tou důvěrou není až tak horké), protože pak není relativně bezpečná komunikace omezena na malou množinu komunikujících stran.
V rámci poštovní komunikace lze TLS použít pro všechny komunikační protokoly, tedy SMTP, IMAP i POP3. Předpokladem je, aby komunikaci podporovaly příslušné programy (i když to úplně striktní podmínka není – existují řešení jako stunnel
, která poskytnou TLS i programům bez podpory této technologie). Také je samozřejmě potřeba si připravit potřebný certifikát nebo více certifikátů.
Další důležitou věcí je, že TLS lze využívat ve dvou režimech – implicitně a explicitně. Implicitní režim znamená, že komunikace probíhá od počátku šifrovaně, resp. ihned po sestavení komunikačního kanálu proběhne sestavení TLS komunikace a jinak komunikovat nelze. Explicitní režim se naopak zapíná z nešifrovaně probíhající komunikace. Implicitní režim vyžaduje samostatný port (na kterém server naslouchá jen pro účely této komunikace), kdežto režim explicitní probíhá na běžném portu určeném původně pro nešifrovanou komunikaci.
Výhodou explicitního režimu (realizovaného pomocí rozšíření STARTTLS) je, že není třeba mít otevřen samostatný port. Po připojení klienta server deklaruje, že podporuje STARTTLS, načež klient může – pokud je tak nastaven – následně odeslat příkaz STARTTLS (nebo jeho jinou konkrétní reprezentaci) a zahájit tak sestavování šifrované komunikace. Nevýhodou je naopak nutnost podpory přímo v rámci příslušného aplikačního protokolu a také nemožnost tento režim používat s klienty bez podpory TLS (u kterých se u implicitního režimu použije stunnel).
Pro používání TLS na e-mailovém serveru je nejprve potřeba splnit několik předpokladů. Především musí být programy zkompilovány a nainstalovány s podporou této technologie (např. přes knihovnu OpenSSL, případně GNU TLS), což může u některých distribucí znamenat instalaci dodatečných balíčků. Obecně ale jak Postfix, tak Dovecot bývají připraveny k takovému nasazení, takže víc než doinstalace příslušné komponenty nebývá potřeba.
Dalším předpokladem je příprava certifikátů. Pokud se bude certifikát používat jen pro ověřování totožnosti serveru, stačí mít pro daný stroj jediný certifikát. Ten si lze připravit například pomocí nástroje openssl (návodů, jak to udělat, je na Internetu plno, například přímo na webu OpenSSL). Pokud bude certifikát samopodepsaný, lze si všechno udělat přímo na serveru – má-li být ale certifikát podepsán důvěryhodnou autoritou, nezbývá, než si vygenerovat požadavek (CSR, Certificate Signing Request) a ten předat zvolené autoritě, která ho za určitý finanční obnos podepíše.
Pokud se nechává certifikát podepisovat důvěryhodnou autoritou, je třeba splnit požadavky autority, typicky například na dobu platnosti. Standardní doba platnosti je 1 rok, nicméně v některých případech může být tato doba jiná. U samopodepisovaných certifikátů je režim mnohem volnější.
Certifikát se na server nainstaluje tak, aby k němu měly přístup programy, které ho používají. Často se dává například do /etc/ssl/certs
, kde bývají nainstalovány také kořenové certifikáty certifikačních autorit. Tajný klíč, který k certifikátu přísluší, se umísťuje na bezpečné místo (např. /etc/ssl/private
), kam má přístup jen root. Tyto cesty se pak použijí v konfiguraci programů.
Certifikát musí být ve formátu PEM, klíč musí být nezašifrovaný (bez hesla). Lze použít klíč a certifikát RSA nebo DSA (u Postfixu 2.6 společně s OpenSSL 0.9.9 také ECDSA). Následující popis je určen pro RSA, nicméně přizpůsobení pro klíče a certifikáty s jinými algoritmy je snadné (v podstatě se jen v názvech parametrů _key_
, resp. _cert_
nahradí _dkey_
, či _eckey_
atd.). Certifikát a příslušný klíč mohou být každý ve svém souboru, jak je uvedeno výše, ale funguje i varianta ve společném souboru – pak ovšem musí být na tento soubor uplatněna přístupová práva jako pro klíč.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Zajímalo by mě, jestli Postfix umí vystupovat jako implicitní TLS klient.Pokud vím, tak neumí.
Vzhledem k tomu, že legislativa donutila úřady pořídit šifrovací zařízení, chtěl bych, aby je naši úředníci mohli použít pro přístup do poštovních schránek přes IMAP.
Díval jsem se do dokumentace Dovecotu, a nikde jsem nenašel, jak spárovat klientský certifikát a přihlašovací jméno uživatele. Vzpomínám si na hádání loginu z položek DN nebo SAN certifikátu, ale to obecně nefunguje.
I z toho, co jste napsal, mi vyšlo, že sice dokážu ověřit, že klient disponuje certifikátem vydaným autorizovaným vydavatelem (v našem státě to znamená, že byl vydán existující a správné osobě), ale už nezjistím, kdo se mi to přihlašuje.
Tudíž potřebuji namapovat otisk certifikátu na konkrétního uživatele.
Protože mám fyzické (nevirtuální) uživatele a používám PAM, napadlo mě použít některý z pokusných modulů, které autentizaci řeší porovnáním certifikátu (respektive ověřením podpisu nesmyslu) s certifikátem uloženým v domovském adresáři uživatele.
Jenže jsem nezjistil, jak a jestli umí Dovecot poskytnout certifikát klienta z TLS relace PAMu. Navíc dotyčné moduly často operují lokálním šifrovacím zařízením, nikoliv s certifikátem ze sítě. (Je celkem možné, že PAM na tohle nemá standardizované rozhraní.)
Zkoušel někdo něco takového?
Jenže stejně nepoužitelné mohou být i ostatní hodnoty. Proto rozumné systémy se orientují podle otisku certifikátu. Navíc, když si certifikáty nevydáváte sám, tak se může stát, že přijde někdo, kdo bude mít zrovna v položce, kterou jsem si vybral kolizní hodnotu.
Ještě mám jeden nápad:
Klient použije certifikát v TLS a do přihlašovacího dialogu vyplní uživatelské jméno.
PAM by vzal název účtu z přihlašovacího jména a nejprve jako heslo by použil certifikát. Vzor certifikátu by byl v domovském adresáři nebo v LDAPu. Teprve v druhém kole by jako heslo použil heslo z přihlašovacího dialogu.
Ale nevím, jak moc to znásilňuje PAM a otravuje uživatele.