Společnost Anthropic vydala Claude 3.5 Sonnet, tj. novou verzi své umělé inteligence Claude (Wikipedie). Videoukázky na YouTube. S Claude 3, stejně jak s GPT-3.5, Llama 3 a Mixtral, si lze pokecat bez přihlašování na DuckDuckGo AI Chat.
Byla vydána nová stabilní verze 6.8 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 126. Přehled novinek i s náhledy v příspěvku na blogu a na YouTube. Vypíchnuta jsou vylepšení v integrovaném poštovním klientu.
Příspěvek Aukce domén – měsíc po spuštění na blogu CZ.NIC shrnuje první měsíc provozu Aukce domén .CZ. Aukcemi prošlo celkem 18 174 domén, z toho na 742 z nich byl učiněn alespoň 1 příhoz. Nejdražší aukcí byla na doménu virtualnisidlo.cz s cenou 95 001 Kč, která však nebyla včas uhrazena. Nejdražší aukcí, která byla vydražena i zaplacena je praguecityline.cz s cenovkou 55 600 Kč.
Před 40 lety, 19. června 1984, Bob Scheifler představil první verzi okenního systému X (X Window System). Vycházela z okenního systému W (W Window System).
Desktopové prostředí MATE bylo vydáno ve verzi 1.28. V gitových repozitářích je sice už od února, ale oznámení vydání se na webu objevilo s několikaměsíčním zpožděním (únorové datum zveřejnění je nepravdivé). Jde o první velké vydání od roku 2021. Uživatelsky nejvýznamnější pokrok je v podpoře Waylandu.
Laboratoře CZ.NIC vydaly novou verzi 4.24.0 aplikace Datovka, tj. svobodné multiplatformní desktopové aplikace pro přístup k datovým schránkám a k trvalému uchovávání datových zpráv v lokální databázi. Přidány byly nové parametry do rozhraní příkazové řádky „export-msg“, „export-msgs“, „import-msg“ a „import-msgs“, které dovolují číst/zapisovat zprávy z/do databází. Veliký panel nástrojů byl nahrazen více nastavitelnými
… více »Mapnik (Wikipedie), tj. open source toolkit pro vykreslování map a vývoj mapových aplikací, byl vydán ve verzi 4.0.0. Přehled změn na GitHubu.
Mozilla koupila firmu Anonym, tj. průkopníka v "digitální reklamě chránící soukromí".
Knihovna htmx (Wikipedie, GitHub), tj. knihovna rozšiřující HTML o nové atributy a umožňující vývoj dynamických webových aplikací, byla vydána ve verzi 2.0 (𝕏).
Společnosti DeepComputing a Framework Computer společně představily RISC-V základní desku pro modulární Framework Laptop 13.
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.