Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Byla založena nadace Open Home Foundation zastřešující více než 240 projektů, standardů, ovladačů a knihoven (Home Assistant, ESPHome, Zigpy, Piper, Improv Wi-Fi, Wyoming, …) pro otevřenou chytrou domácnost s důrazem na soukromí, možnost výběru a udržitelnost.
Nešifrované HTTP
| by mělo zmizet |
|
4% (260) |
| je postačující, dokud nejsou přenášena důvěrná data |
|
96% (6819) |
Celkem 7079 hlasů
Vytvořeno: 23.4.2015 11:44
Tiskni
Sdílej:
23.4.2015 11:45
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
23.4.2015 23:39
Petr Tomášek | skóre: 39
| blog: Vejšplechty
jednocipy niesu taky problem, ARMy s linuxom uz vobec a ked pouzivas nieco ako ESP8266, tak si ho preproxujes a zasifrujes cez domaci router, aj tak vacsinou nema to male zariadenie ani verejnu IP...
9.5.2015 19:47
Petr Tomášek | skóre: 39
| blog: Vejšplechty
7.5.2015 23:04
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
23.4.2015 13:29
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
...jen nevím, ze kterého roku ty vánoce byly zamýšleny.
8.9.2015 09:34
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Chtělo by to checkboxy.
Zmizení nešifrovaného HTTP by bylo pěkné, ale zatím to není proveditelné, zejména z toho důvodu, že HTTPS není o moc bezpečnější. Problém je v tom, jakým certifikátem je možné komunikaci zabezpečit – v prohlížečích jsou i podivné CA a každá autorita může podepsat cokoliv.
Navíc většina browserů křičí při self-signed certifikátu a u některých (zrovna u Mozilly) není úplně jednoduché povolit spojení se serverem, kterému certifikát např. vypršel. Takže majitel webu musí solit a starat se.
7.5.2015 23:10
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Takže majitel webu musí solit a starat se.Majitelé webů, a to i těch hodně navštěvovaných, se často nestarají
Zmizet úplně nemusí, ale je třeba si uvědomit, že spousta informací, které samy o sobě důvěrné nejsou, v agregované podobě už nebezpečí představují – proto má smysl chránit i zdánlivé banality jako, o čem si člověk čte, co hledá na mapě, jaké si hledá spojení v jízdním řádu atd.
1.5.2015 01:18
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
To je pravda. V případě třeba nejaky-protistatni-blog.wordpress.com to hraje celkem velkou roli. Ale v případě Wikipedie, zpravodajských serverů nebo portálů se širším zaměřením se šmírák nic podstatného nedozví. Zatímco v případě nešifrovaného HTTP vidí, které konkrétní články si čteš a co zadáváš do vyhledávače.
7.5.2015 23:11
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
16.5.2015 22:33
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Hlavně by to chtělo změnit chování prohlížečů – zatímco samopodepsané HTTPS vypadá strašidelně a běžný uživatel se k takovému obsahu jen tak nedostane1, zatímco u nešifrovaného HTTP prohlížeč žádné varování nezobrazí2 a uživatel má pocit, že je všechno v pohodě – i když je to ve skutečnosti horší než to samopodepsané HTTPS, které odstaví alespoň pasivní3 odposlouchávače (třeba na WiFi nebo když si nějaký síťař pustí tcpdump, nachytaná data uloží a pak se povalují různě na discích nebo dále šíří),
[1] v horším případě si vytvoří návyk, že je potřeba kliknout tady a potom támhle, a bude to dělat kdykoli na něj ta hláška vyskočí – i třeba při přístupu do banky nebo k e-mailu
[2] kdysi se možná zobrazovalo varování při prvním odeslání formuláře přes HTTP, že data můžou být odposlechnuta
[3] nezasahují do komunikace a nedělají MITM
Hlavně by to chtělo změnit chování prohlížečů – zatímco samopodepsané HTTPS vypadá strašidelně a běžný uživatel se k takovému obsahu jen tak nedostane, zatímco u nešifrovaného HTTP prohlížeč žádné varování nezobrazíSes posral, ne? To by pak Mozilla nemohla inkasovat úplatky od důvěryhodných čínských soudruhů.
3.5.2015 10:06
Václav "Darm" Novák | skóre: 26
| blog: Darmovy_kecy
| Bechyně / Praha
4.5.2015 17:22
⧠ A = 0 | skóre: 10
| blog: Technokratovo_zrcadlo
| Helsinki
Přijatelná alternativa k heslům moc neexistuje.
Takže bych začal tím, že aplikace1, do které uživatel zadává heslo2, se k němu nebude distribuovat nezabezpečenou cestou3.
[1] u webů typicky JavaScript
[2] které se klidně na klientovi může zahashovat a server se ho za normálních okolností – pokud aplikaci cestou nikdo nepozmění – nedozví
[3] nešifrované/nedůvěryhodné HTTP
Přijatelná alternativa k heslům moc neexistuje.Challenge-response auth. Asymetrická kryptografie.
).[1] když už tu důvěryhodnost nedokáže posoudit uživatel, tak aspoň důvěryhodný z pohledu provozovatele služby/aplikace – který má přístup k datům uživatelů, a ti mu tudíž musí věřit tak jako tak
nebo můžou mít zase heslo, ze kterého se odvodí klíčPřesně tak. Rozdíl je v tom, že se to heslo neposílá na server - takže není možné aby nastal ten populární případ údivu „jé, já jsem serveru poslal své heslo a on ho teď zná, to je ale zlý server!“
Jak víš, že se to heslo neposílá na server nebo někam jinam, když ti ten JavaScript přišel po HTTP a kdykoli se ti mohla nainstalovat nová verze (takže i když jsi tu starou četl, je ti to celkem na nic)?
V čem je rozdíl jestli pošlu seed nebo hash?Záleží na tom jak ten seed/hash počítáš…
Replay tím stejně neodstraním a pokud tam je sůl nebo čas, tak už je to celkem běžná forma challenge/response.No vždyť o to mi jde.
protože nemáme uživatelsky příjemný a univerzální způsob jak pracovat s heslem chráněnýma čipovkamaI RSA/ECDSA odvozené z hesla je mnohem lepší než současný způsob.
Vzpomínám si, že jsem četl o protokolu na přihlášení přes nezabezpečený kanál, kde server nikdy nedostal heslo v čitelné formě (ani v db, ani při přihlášení), ale už si nevzpomínám jak se ten protokol jmenoval.SCRAM, ale ten mi přijde překomplikovaný. Jsou jednodušší cesty.
9.5.2015 20:07
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Vzpomínám si, že jsem četl o protokolu na přihlášení přes nezabezpečený kanál, kde server nikdy nedostal heslo v čitelné formě (ani v db, ani při přihlášení), ale už si nevzpomínám jak se ten protokol jmenoval.
Ono by úplně stačilo upravil HTML standard tak, aby se přidal nový typ formulářového pole který by heslo hashoval v prohlížeči, který by případně dostal za parametr "sůl" a na server by to posílalo jen čistý hash. Něco ve stylu:
<form> <input type="hashed-password" hash-method="sha512" hash-encoding="base64" salt="GxzoEm+ce3s8z2VLpQzz4CSh5awdC0xc07fJ0o/r"> <input type="submit"> </form>
To je pravda – součástí soli by měla být i doména serveru a jméno uživatele případně i název služby (na doméně jich může být víc).
10.5.2015 14:39
Petr Tomášek | skóre: 39
| blog: Vejšplechty
Co když si na svém ďábelském webu nastavím stejnou sůl jako mi vrátí AbcLinuxu a získaný hash prostě použiju?
V tom případě by Abclinuxu bylo opravdu debilní, kdyby si poslanou sůl nepoznamenalo do databáze (nejlíp s dalším identifikátorem, např. IP adresou klienta nebo tak něco) a nechalo si vnutit sůl jinou...
A taky to neřeší replay a přihlášení uloženým hashem z uniklé databáze.
Replay to řeší, pokud se zajistí pokaždé jiná sůl, viz výše.
V tom případě by Abclinuxu bylo opravdu debilní, kdyby si poslanou sůl nepoznamenalo do databáze (nejlíp s dalším identifikátorem, např. IP adresou klienta nebo tak něco) a nechalo si vnutit sůl jinou...Jak to pomůže?
Replay to řeší, pokud se zajistí pokaždé jiná sůl, viz výše.A jak pak budeš na serveru porovnávat jestli je to heslo správné? Při registraci dostaneš hash(mojeheslo+666), při dalším přihlášení hash(mojeheslo+999), úplně jiné hodnoty, neporovnatelné.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
7.5.2015 07:27
24.4.2015 13:15
6.5.2015 20:38
25.4.2015 00:06
25.4.2015 16:20
6.5.2015 15:02
"login:realm:heslo", takže server sice zná hash který by mohl zneužít k přihlášení jménem uživatele na jiný server, ale jen pokud ten server bude mít totožný realm.
Nejlepší na tom je, že webové prohlížeče i webové servery Digest podporují - stačí použít ne-basic .htpasswd autentizaci Apache - AuthType Digest.
viz podrobný (praktický) popis
.
Nešifrované HTTP by bylo svým způsobem OK, kdyby bylo aspoň kryptograficky podepisované, aby koncový uživatel mohl ověřit, že skutečně čte původní informace zveřejněné na nějakém webu. Dnešní nešifrované HTTP bohužel znamená, že se s informacemi může stát cestou cokoliv a koncový uživatel nemá možnost na to přijít.
17.7.2015 21:48
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
25.8.2015 12:28