Názory k článku OpenSSL: švýcarský nůž nejen k šifrování

Dokumentace zmiňuje, že parametr -salt je implicitní volba, takže není asi třeba jej explicitně uvádět, jestli to dobře chápu.

Také bych trochu rozvinul tvrzení, že solení hesel komplikuje útok hrubou silou ... pokud se nepletu, tak reálně pouze znemožňuje použití předpočítaných hodnot klíčů/hashů. Pokud by se někdo snažil hrubou silou prolomit zašifrovaný soubor, tak pravděpodobně bude napodobovat chování uživatele a zkoušet zadávání hesel, kde solení není žádnou překážkou.

Jinak děkuji za pěkný článek a co se pokračování týče, tak o vytvoření vlastní jednoduché CA tu už něco kdysi bylo, ale hlasoval bych pro téma "ručních" operací s certifikáty jako jsou třeba podpisy dokumentů/mailů a jejich ověřování

ale přeci při dekódování (= ověřování hesla, když to tak řeknu) je sůl známá, takže ji útočník může vesele použít, ne?

komplikuje to útoky, kdy přijde člověk a má několik GB spočítaných hashů a jenom vyhledává shody, aniž by je přímo počítal ... tuším, že na tomhle principu jsou založené Rainbow Tables k prolamování WinXP (ale nevím jestli je to aktuální)

Zrovna včera jsem openssl použil pro volání ocsp serveru a mám k tomu jednu nejasnost: pokud je k přístupu na ocsp server třeba basic authentication, kam jméno a heslo zadat? Obdobně s autentizací pomocí klientského certifikátu.

V případě basic authentication se údaje předávají v hlavičce Authorization.

Authorization: Basic username:password

Přičemž username:password musí být zakódováno pomocí base64.

Klientský certifikát zadáte jako parametry -cert resp. -key. Ale openssl je v případě HTTPS vhodné asi jen na ladění SSL, jinak je jednodušší použít wget nebo curl.

Díky, ale nepochopil jsem to. Předpokládejme volání příkazu
openssl ocsp -issuer issuerCert.pem -cert myCert.pem -text -url http:/www.neja­kaadresa.cz/ces­ta
Nemám kam dát hlavičku s Authorization. Tuto lze přidat leda do zmíněného příkazu curl.
Klientský certifikát jsem myslel pro ověření klienta pro přístup k serveru (namísto basic authentication). Nikoli jako předmět o němž se snažím získat status.

Myslel jsem, že zkoušíte variantu s_client a telnetem. V případě ocsp asi nemůžete parametry protokolu HTTP ovlivnit. Asi jediná možnost je pomocí openssl si vygenerovat požadavek, ten pak pomocí wget/curl poslat a pak zase pomocí openssl zpracovat výsledek.

Používáte někdo OpenSSL ve Windows? Jakou binárku?
Potřebuji si předávat šifrované soubory mezi Linuxem a Windows.

Přímo na webu OpenSSL je jedna Win varianta linkovaná. Zkušenosti ovšem nemám.

Dost užitečný option u s_client je -servername, který zapíná Server Name Indication. Je už celkem dost serverů, které na stejné IP sdílejí různé FQDN.

Zobrazení celého certificate chainu v PEM kódovaní:

openssl s_client -connect www.google.com:443 -servername www.google.com -tls1 -verify 5 -showcerts < /dev/null

Rozparsování serverového certifikátu se SHA256 fingerprintem:

openssl s_client -connect www.google.com:443 -servername www.google.com -tls1 < /dev/null | openssl x509 -noout -text -fingerprint -sha256

Dále, různě zvolené ciphersuites v optionu -cipher můžou servery teoreticky vrátit jiné certifikáty - jiný pro RSA, DSA a ECDSA.

Spíš scháním nějakou jednoúčelovou knihovnu (C/C++) na digitální podpis,je mi jedno, podle jaké normy, a jak se generují klíče, ale hrozně rád bych ocenil, aby to fungovalo jak má, tedy podepsat soukromým klíčem a ověřit veřejným klíčem. A opět, nechci kolos, který umí deset norem a dvacet hashovacích funkcí a zvedne velikost výsledné binárky z 1MB na 20MB.