Vlákno názorů k článku
Mozilla představila nový SSL Configuration Generator od Vláďa Smitka - Jen pozor na to, že uvedená konfigurace pro...

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_ser­ver_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$re­quest_uri;
return 302 https://$host$re­quest_uri;

Asi nejčistší variantou pro dočasné přesměrování http => https je:
if ($scheme != https) { return 307 https://$host$is_ar­gs$request_uri; }

Pro trvalé přesměrování:
if ($scheme != https) { return 308 https://$host$is_ar­gs$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_ar­gs$request_uri; }
# .... další konfigurace
}

Ehm, nemá to být spíše

https://$host$uri$is_args$args

?

Má, díky za opravu.

"ssl_prefer_ser­ver_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_ser­ver_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.