Vlákno názorů k článku
Projekt OpenBSD čistí knihovnu OpenSSL
od Ondřej Caletka - To by mě zajímalo, jakým způsobem zvýší kvalitu...
-
Ondřej CaletkaZlatý podporovatelTo by mě zajímalo, jakým způsobem zvýší kvalitu OpenSSL odstranění heartbeatu. Heartbeat přece za nic nemůže. Když se za týden objeví zranitelnost v implementaci RSA, vyřeší to také odstraněním podpory pro RSA?
-
Ondřej CaletkaZlatý podporovatel
Stavové firewally a NATy běžně čistí spojení z tabulek po dvou minutách neaktivity. TCP keepalive chodí obvykle jednou za dvě hodiny. Z toho plyne, že TCP keepalive se hodí maximálně tak na detekci přerušeného spojení, ne na jeho udržování. SSL Heartbeat může v důsledku přinést například nižší spotřebu energie pro mobilní zařízení, třeba při čekání na došlou poštu; zpracování heartbeatu je jistě mnohem levnější než neustálé pingání IMAP příkazy.
Bez proměnlivé délky heartbeatů by nebylo možné provádět Path MTU discovery.
-
Někdo (neregistrovaný)
Tak tohle je ale hodně nepovedený příspěvek, protože:
1. TCP keepalive jde konfigurovat na mnohem častější komunikaci než jednou za dvě hodiny.
2. Pingat IMAP příkazy není nutno, viz RFC 2177. Navíc netuším odkud se bere tvrzení "zpracování heartbeatu je jistě mnohem levnější" - to zní spíš jako přání než jako realita.
3. K provádění Path MTU discovery máme ICMP. Reimplementovat to na aplikační úrovni vypadá jako velmi špatný nápad.Sečteno, podtrženo: opakovaně implementovat heartbeat na různých vrstvách není nutno, a to přesto že je to sice možné (například jako akademické cvičení), praktické to ovšem není.
-
Lol Phirae (neregistrovaný)
TCP keepalive jde konfigurovat na mnohem častější komunikaci než jednou za dvě hodiny.
Báječný nápad. Takže si zahltím router mraky absolutně nepotřebných konexí proto, že chci, aby mi nechcíplo SSH.
Sečteno, podtrženo: Tak tohle je ale hodně nepovedený příspěvek *facepalm*
-
Někdo (neregistrovaný)
Evidentně nevíte o čem je tu řeč, takže si to prosím nastudujte: http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/#setsockopt
-
Ondřej CaletkaZlatý podporovatel
1. Nevím, jaký je konkrétně problém s TCP keepalive, ale zřejmě tam nějaký bude, když si vyšší vrstvy budují vlastní keepalive mechanizmus (OpenSSH ho má již mnoho let). Nemůže to být třeba tak, že volba na nastavení periody není standardizována a byl by problém s portabilitou? Nevím to, jen se ptám.
2. Právě používání RFC 2177 je rizikové z toho pohledu, že nepřijde-li dlouho žádná pošta, spojení je zticha a může být z tabulek vyčištěno. A to je přesně to, čemu heartbeat zabrání. A nepochybuji o tom, že odeslat a přijmout heartbeat je levnější než odeslat a přijmout zprávu aplikačního protokolu, která musí být šifrovaná a její zpracování ve vyšší vrstvě nemusí být triviální.
3. V ideálním světě, kde si všichni věří, nikdo nic neblokuje a síťová neutralita není jen zbožným přáním, tam ano. Obecně se ale bohužel nedá spolehnout na funkčnost jiného protokolu/portu než toho, po kterém probíhá komunikace. Šíkovně implementovaný heartbeat umožní z linky vytěžit maximální výkon a spolehlivost i v případě, že po cestě sedí blbec co ICMP zprávy zahazuje.
-
Někdo (neregistrovaný)
1. U OpenSSH jde použít keepalive jak na úrovni TCP tak na aplikační úrovni, vypadá to na standardní paranoiu - viz man ssh_config, popis ServerAliveCountMax:
It is important to note that the use of server alive messages is very different from TCPKeepAlive (below). The server alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable.
Nevím o tom že by nastavování timeoutů TCP keepalive bylo standardizované, ale běžně používané platformy (Linux, Windows) to podporují - takže to vede na běžné použití #ifdef. V tomto je to to samé jako TLS heartbeat - všimněte si že v RFC 6520 taky není standardizované jak mají aplikace konfigurovat parametry heartbeatů, takže si asi autoři nejspíš představují že vrstva TLS se bude natvrdo prorůstat s aplikací, což považuji za vysloveně nevhodnou architekturu.
2. U IMAP IDLE jde o to použít jakýkoliv ping-pong mechanismus, nevidím důvod proč místo TCP keepalive vymýšlet cokoliv složitějšího - a i z pohledu výkonu je TCP keepalive to nejlevnější co jde použít, navíc funguje i bez TLS (tedy ne že by vždy bylo dobré IMAP bez TLS používat, ale je to možnost).
3. Když je rozbitá síť tak je ji třeba spravit a ne vymýšlet obezličky u kterých stejně není zaručené že opraví všechny možné rozbitosti sítě a jenom všechno komplikují a to dokonce i v případě že síť funguje správně.
-
Ivan (neregistrovaný)
TCP keepalive ma "divny" API. Uzivatel ho muze akorat povolit. Vsechna dalsi nestaveni(jako interval) jsou globalni pro vsechny procesy a vsechny sockety, a vyzaduji prava root-a.
Navic to vyzaduje podporu na strane serveru. Muze se stat, ze se na strane serveru vrati poll. A kdyz potom server zavola read, tak se vrati "0". Tzn. bylo precteno nula bajtu. Pokud to aplikace neocekava, tak to muze zpusobit problemy.
-
Někdo (neregistrovaný)
To že je nastavení intervalu TCP keepalive globální a nemůže ho měnit nikdo jiný než root není pravda, viz např. http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/#setsockopt nebo http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220(v=vs.85).aspx
Pokud na straně serveru je kód který je překvapený z toho že mu read vrátí nula bajtů tak je chybný a je ho třeba opravit - pokud čte z file descriptoru který je socket tak se to prostě může stávat a je třeba to mít správně ošetřené.
-
Lol Phirae (neregistrovaný)
viz např. http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/#setsockopt nebo http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220(v=vs.85).aspx
Ano, každý uživatel si to přeprogramuje a překompiluje. Juch! Ty máš asi v hlavě extrovně nasrána.
