Jen pozor na to, že uvedená konfigurace pro Nginx způsobuje duplikaci GET parametrů při přesměrování z http na https a to může způsobit rozličné problémy. Viz https://lynt.cz/blog/nezvladnute-presmerovani
K návodu Mozilly mám jeden dotaz, proč mají ssl_prefer_server_ciphers off? Z více důvodů se obvykle doporučuje toto zapnout.
Měl k jejich návodu výhradu, že pro přesměrování http => https je vhodnější používat http status 307 Temporary Redirect nebo 308 Permanent Redirect, zejména ve variantě Modern (opravdu archaické prohlížeče ho nemusí podporovat, tam bych chápal 301/302). Statusy 307/308 jsou vhodnější kvůli správnému (bezpečnějšímu) předání parametrů.
Dále by return měl používat proměnnout $is_args, která dosadí do URL otazník pouze v případě, že existují parametry. V jejich příkladě (i v příkladě v blogu) je otazník dosazen na pevno a zbytečně se doplňuje. Tím pádem dochází (možná k nevýznamné, ale zbytečné) malformaci požadavku. (http://www.root.cz/ se změní na https://www.root.cz/?)
K návodu v blogu bych poznamenal, že v nginx se přesměrování neprovádí přes rewrite (to nesprávně používají ex-apache uživatelé). K přesměrování se v nginx používá return a kombinuje se do location {}, rewrite se používá okrajově (je komplikovanější, přináší např. problémy s parametry, jak se píše v blogu).
Takže nevhodně (špatně) je:
rewrite ^ https://www.root.cz$request_uri permanent;
ale i
rewrite ^ https://www.root.cz$request_uri? permanent;
return 301 https://$host$request_uri;
return 302 https://$host$request_uri;
Asi nejčistší variantou pro dočasné přesměrování http => https je:
if ($scheme != https) { return 307 https://$host$is_args$request_uri; }
Pro trvalé přesměrování:
if ($scheme != https) { return 308 https://$host$is_args$request_uri; }
Pokud je to vloženo do podmínky, může to být ve společné definici pro http i https virtuální server, tedy:
server {
listen 80 default_server;
listen [::]:80 default_server;
listen 443 ssl http2;
listen [::]:443 ssl http2;
if ($scheme != https) { return 308 https://$host$is_args$request_uri; }
# .... další konfigurace
}
"ssl_prefer_server_ciphers off" - ked mas povolene iba bezpecne ciphers, tak je jedno ktory cipher si klient vyberie. Takto davas klientovi volnost a on si pravdepodobne vyberie energeticky najefektivnesi cipher, ktory je dostupny na jeho platforme. Pokial mas vynutene serverove poradie, tak napr. mozes prinutit mobilne zariadenia pouzivat AES ciphers aj ked pre nich by bolo lepsie si vybrat CHACHA ciphers (pokial teda nemaju HW podporu pre AES instrukcie).
"ssl_prefer_server_ciphers on" - ma zmysel pokial je potrebne podporovat aj slabe ciphers, aby si ich klienti zbytocne nevyberali.
No a to je to, co mi právě jasné není. Konfigurátor dává do pořadí i některé slabší šifry - dokonce ten konfigurátor má tři úrovně nastavení (Modern, Intermediate a Old) a podle toho přidává slabší a slabší.
V takovém případě by mi právě dávalo smysl, aby pořadí cifer preferoval server a volil tu nejsilnější.
Podle mě se to týká i nejmodernějších prohlížečů, kde se (podle specifikace) musí nabízet AES128, zatímco by bylo asi prozíravější preferovat AES256.
Ano, to je pravda, že je lepší return. Já v článku řešil především opravu toho nepovedeného rewrite a snažil jsem se ukázat, kde ten problém vzniká. V něm ten otazník na konci nezpůsobí doplnění otazníku navíc, ale právě zajistí nepřidání původních parametrů (přidání žádných parametrů). Viz https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#taxing-rewrites
Každopádně jsem do něj doplnil nejlepší variantu s returnem, díky za postřeh.
Ono není ani moc potřeba lidi opravovat, to je v jazyce naprosto normální jev, že významy se přenášejí. Lezeme na web, přiotom už často otevíráme aplikace, které s webem mají společného jen to, že používají stejné protokoly, jako celosvětový (informační) web. Otevíráme je v prohlížeči, přestože už dekády neslouží jen k prohlížení ale úplné interakci uživatele se službou. V autě nám pomáhá ABS, přestože dnešní systémy se jmenují úplně jinak a funkci ABS značně překonávají. V elektře kupujeme místo televizoru celou televizi.
SSL a TLS má navíc ještě jednu významovou komplikaci. TLS se považuje za vývojového nástupce SSL, někdy jako preferovanou podmnožinu variant. To je patrné např. i z pojmenování direktiv - v Apache je to např. SSLProtocol. Můžete namítnout, že tato direktiva vznikla v době, kdy ještě TLS nebylo zavedeno. Ale co nginx a jeho direktivy, např. ssl_protocol? Ten už vznikal v době, kdy SSL bylo jednoznačně obsoletní.
Jak by se správně tedy tyto direktivy nazývat? TLS_SSL_Protocol, aby to bylo ("genderově") neutrální.
Kromě přísně technických dokumentů, kde je nutné opravdu odlišit SSL od TLS bych na rozlišení pojmů moc nebazíroval. A v těch přísně technických dokumentech se to na první pohled odlišuje přidáním verze - např. SSLv3, TLS1.2 apod. Čtenář nebo během hovoru by měl tedy každý umět rozlišit, že SSL a TLS jsou někdy synonyma a jindy zase strikně odlišené protokoly.
Zdroj?
https://cs.wikipedia.org/wiki/Identifika%C4%8Dn%C3%AD_%C4%8D%C3%ADslo_osoby
5. 7. 2019, 21:58 editováno autorem komentáře
Od počátku v tom byl trochu hokej. Jeden zákon zavedl pojem "identifikační číslo organizace", ale další navazující předpisy uváděly pouze pojem "identifikační číslo". Tento nesoulad vznikl už v počátku devadesátých let.
Pak ze zákona vypadlo i to slovo "organizace" a začal se používat univerzální pojem "identifikační číslo".
Pro zajímavost, od té doby ještě prošel naší legislativou i IČES (IČ ekonomického subjektu).
IČ je naprosto správně a bylo správně vždy - je to identifikační číslo, a koho identifikuje je zřejmé z povahy věci. Na faktuře pod hlavičkou firmy bude těžko identifikační číslo něčeho jiného, než té firmy samotné - a je už dost nepodstatné, jestli firmu zrovna zveme organizací, ekonomickým subjektem nebo (fyzickou / právnickou) osobou.
Vím, že jsou morkokostní byrokraté, kteří by se hádali nad platností dokladu kde je napsánjo IČ / IČO / IČES, ale ve skutečnosti žádný zákon nenařizuje mít identifikační číslo nadepsané jakkoliv. Uvedeno být musí, nadepsáno ne. To číslo může být klidně v závorzce za názvem firmy a bude to zcela platné. Před názvem firmy také nepíšeme "Název firmy:" ale prostě název napíšeme a je na minimální inteligenci těch dalších, aby to uměli pochopit.
Podobné hloupé bitky přišly s novým Občanským zákoníkem, kdy si lidé mysleli, že musí mandátní smlouvy přepodepsat s nadpisem "příkazní smlouva", vyměnit mandanta a mandatáře za příkazce a příkazníka. Vězte, že je to zcela jedno, jsou to synonyma.
IČ je tedy zkrátka "bezpečné" nadepsání rubriky už od devadesátých let, IČO je zcela vžité a použitelné, byť podle dnešních zákonů je IČO zkratka něčeho jiného než podle zákonů starších, ale v každém případě identifikuje stejné subjekty už od konce roku 1989.
5. 7. 2019, 22:22 editováno autorem komentáře
Ony jsou to ve skutečnosti protokoly SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 a TLS 1.3, přičemž překonané je vše až po TLS 1.1 včetně. Často se ale nepíše o konkrétní verzi protokolu, ale myslí se tím „některý z rodiny protokolů SSL/TLS“. V tomhle významu se dříve používalo označení „SSL“, a už to té rodině protokolů zůstalo, i když aktuálně už v ní žádná používaná verze SSL není. Žádný problém v tom ale nevidím, protože TLS 1.0 je přímý pokračovatel SSL 3.0. Ta změna SSL –> TLS byla jen kosmetická úprava názvu, protože se přišlo na to, že to pojmenování SSL je nepřesné z hlediska toho, jak dnes nazýváme jednotlivé části síťové komunikace. A bezpečáci ten název prostě museli mít správně :-)
5. 7. 2019, 11:49 editováno autorem komentáře
Menší korekce: SSLv1 fakticky neexistuje: https://security.stackexchange.com/a/41661/65904
Přesněji, nedošlo do finální fáze a vyšla rovnou dvojka. Pokud chceme uvádět SSLv1, pak bychom pro konzistenci měli uvádět asi i různé další nefinální verze, což tady asi nemá moc smysl.
Přejmenování – myslel jsem si, že k tomu došlo čistě v rámci přechodu a z rukou Netscape na neutrální půdu, poznámka o síťových vrstvách ale asi taky dává smysl. Asi hrálo roli obojí.