Zen je webový prohlížeč vycházející z Firefoxu. Vývoj probíhá na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 23 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Ve čtvrtek 3. října se v Red Hat Labu (místnost Q305) na FIT VUT v Brně uskuteční další Fedora Installfest. Od 10 do 16 budou v labu připravení odborníci na Fedoru ze společnosti Red Hat, kteří vám můžou pomoct nejen s instalací, ale taky pomoct s dalšími problémy a dotazy ohledně Fedory. Akce je primárně zaměřená na studenty FIT VUT, ale vítáni jsou i lidé, kteří tuto školu nenavštěvují.
Byla vydána nová verze 9.9 sady aplikací pro SSH komunikaci OpenSSH. Z novinek lze vypíchnout podporu hybridní post-kvantové výměny klíčů založené na FIPS 203 ML-KEM (Module-Lattice Key Enapsulation mechanism) v kombinaci s X25519 ECDH, tj. nový výchozí algoritmus "mlkem768x25519-sha256". Počátkem roku 2025 bude z OpenSSH odstraněna podpora DSA.
Interaktivní monitor zdrojů btop++, tj. C++ verze a pokračování monitorů bashtop a bpytop, byl vydán v nové verzi 1.4.0. Přináší podporu monitorování Intel GPU a NetBSD.
Byl vydán Nextcloud Hub 9. Představení novinek tohoto open source cloudového řešení také na YouTube.
Americký výrobce čipů Qualcomm se v minulých dnech obrátil s nabídkou na převzetí na konkurenční firmu Intel, která nyní prochází jednou ze svých největších krizí. Uvedl to list The Wall Street Journal s odvoláním na informované zdroje. Tržní hodnota Intelu se nyní pohybuje kolem 87 miliard amerických dolarů. Tržní hodnota firmy Qualcomm se pohybuje kolem 185 miliard dolarů.
Byla vydána beta verze Ubuntu 24.10 s kódovým názvem Oracular Oriole. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 24.10 mělo vyjít 10. října 2024.
Linux na 4bitovém mikroprocesoru Intel 4004 z roku 1971? Ale jistě: Linux/4004 (YouTube).
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.