Vlákno názorů k článku Vlády přesměrovávají uživatele na software doplněný o malware od Vít Šesták - Jsme na technickém webu, takže věta „Šifrování problémům...
-
Jsme na technickém webu, takže věta „Šifrování problémům zabrání“ mi přijde zavádějící, podobně jako „hesla se šifrují“ (ačkoli se obvykle spíše hashují).
Cílem šifrování není zabránit modifikaci obsahu (vizte malleability), ale skrýt obsah. Navíc z principu to není dokonalé, třeba délka obsahu s větším či menším (někdy i s nulovým) šumem unikne a při připojení na známý server s veřejným obsahem někdy není až tak těžké odhadovat, co si člověk stahuje.
Zabrání tomu správná autentizace obsahu, kterou nabízí (za jistých podmínek) například HTTPS, protože to není pouze o šifrování. Takže nadpis by mohl znít třeba „HTTPS problémům zabrání“, případně – chceme-li být přesnější „HTTPS prohlémům může/dokáže zabránit“. Je to samozřejmě za podmínkek, jako že HTTPS je skutečně použito (útočník může zkoušet sslstrip, obránce může použít HSTS+preload) a že platí všechny jeho prerekvizity (privátní klíč je v bezpečí, implementace jsou korektní, CA fungují správně, …).
(BTW, i pokud některá z prerekvizit neplatí, pro útočníka to často znamená více práce, více nákladů a větší pravděpodobnost, že se mu to nevyplatí.)
Když budeme říkat, že HTTPS je o šifrování, najde se pak spousta lidí, kteří zdánlivě správně namítnou „vždyť tento obsah je veřejný a není ho potřeba šifrovat“. Jenže HTTPS není jen o šifrování. Stejně tak jako uložená hesla se (ideálně) nešifrují, ale hashují.
-
Jan S (neregistrovaný)
Omlouvam se za asi hloupy dotaz trochu jinam, ale to to me zaujalo:
<i>Navíc z principu to není dokonalé, třeba délka obsahu s větším či menším (někdy i s nulovým) šumem unikne...</i>
Je tim mysleno, ze kdyz necham PHP do stranky vygenerovat nejaky neviditelny retezec (napr. komentar?) s nahodnou delkou, znesnadni to tipovani komunikace po HTTPS pomoci znalosti delky zpravy? -
Je tim mysleno, ze kdyz necham PHP do stranky vygenerovat nejaky neviditelny retezec (napr. komentar?) s nahodnou delkou, znesnadni to tipovani komunikace po HTTPS pomoci znalosti delky zpravy
Ano, dokonce některé typy dřívějších útoků se tak mitigovaly. Na druhou stranu, znesnadňuje to cachování obsahu a žere výkon.
Přidání "ocásku" lze řešit i nastavením na web serveru, bez nutnosti upravovat každý PHP script.
Není to ale obecně doporučovaná metoda, pro svoje nevýhody.
-
> Je tim mysleno, ze kdyz necham PHP do stranky vygenerovat nejaky neviditelny retezec (napr. komentar?) s nahodnou delkou, znesnadni to tipovani komunikace po HTTPS pomoci znalosti delky zpravy?
To sice znesnadní (i když, v některých scénářích jako CRIME/BREACH prostě útočník provede více měření), ale není to to, co jsem měl namysli. Moderní symetrické blokové šifry používají délku bloku typicky 128b (16B). V některých módech, například CBC, útočník vidí pouze délku zarovnanou na délku bloku, takže při přenesení 16358 bytů plaintextu útočník dovede určit, že se přeneslo 16353–16368 bytů plaintextu (snad jsem to spočítal dobře), neví ale úplně přesné číslo.
Nejspíš to ale většinou nebude velká překážka, navíc se třeba v TLS od těchto módů upouští ve prospěch AEAD, které – co jsem zatím viděl – byly vždy proudové, a tedy prozradí přesnou délku.
-
O tom jsem nečetl, máte k tomu nějaký zdroj? Já našel jen nějaký expirovaný draft z roku 2013 pro TLS extension, které mělo něco takového dělat.
A ani si nedovedu představit, jak by mo mohlo sloužit oběma zmíněným účelům. Pokud to bude per TLS record, tak tam truncation attack nehrozí – jakákoli modifikace recordu by měla způsobit neplatnou MAC. Pokud by útočník ustřihl TLS spojení jako celek, pak něco takového teoreticky smysl má na úrovni celého spojení (hmm, ale na HTTP to není potřeba – máme content-length nebo chunked encoding), ale pak to moc nezakryje délku přenášených dat.
-
Padding se na konec přidává u AES v CBC, funguje to podobně jako u PKCS#7, jen obsah je konstanta. Více informací se můžeš dozvědět např. pro TLS 1.0 v RFC 2246 v sekci 6.2.3.2.
CBC je zranitelný na Padding oracle attack právě kvůli paddingu, google ti řekne víc. Před rokem jsme tady třeba řešili BEAST, což je právě variance na padding attack u TLS.
Nejlepší je asi když tady rovnou vycituji dané paragrafy:
padding
Padding that is added to force the length of the plaintext to be
an integral multiple of the block cipher's block length. The
padding may be any length up to 255 bytes long, as long as it
results in the TLSCiphertext.length being an integral multiple of
the block length. Lengths longer than necessary might be
desirable to frustrate attacks on a protocol based on analysis of
the lengths of exchanged messages. Each uint8 in the padding data
vector must be filled with the padding length value.
padding_length
The padding length should be such that the total size of the
GenericBlockCipher structure is a multiple of the cipher's block
length. Legal values range from zero to 255, inclusive. This
length specifies the length of the padding field exclusive of the
padding_length field itself. -
Díky za odkaz na specifikaci. Aha, takže to je v rámci TLS recordu, prostě prodloužený klasický padding. OK, z hlediska šumu v délce zpráv to může mít smysl, z hlediska truncation attacku (jak zmiňoval Sten) těžko.
Používá se to někde reálně?
Padding oracle znám, ale problém není až tak v samotném CBC, jako v kombinaci CBC s druhem paddingu a mac-then-encrypt, případně v implementačních chybách, které ale těžko mohou nastat u encrypt-then-mac.
Ad BEAST: Ten AFAIK souvisel s IV a ne až tak s paddingem, natož s padding oracle.
