HTTPS a NGINX - brutální nárůst zátěže

[M. N.]

Nazdar rooti.

Mám následující problém. Seshora od mgmnt přišel požadavek na překlopení webu na https. Jedná se o jeden poměrně čtený web. Začali jsme tedy polehoučku, nejdříve s webem, který servíruje statiku. Běží na soudobém HW HP/Intel, 18 GB paměti a v režimu http nemá nejmenší problém, vytížení 4 "jader" je okolo 10%, hlavně díky IO. Nastudoval jsem jak zkonfigurovat https na nginx sestavil velmi jednoduchý a přímočarý config s redirectem z 80 na 443. Rovnou jsem aktivoval http2 s představou, že takto bude méně spojení/ssl sessions.

V běžném provozu a s keepalive 2s obsluhujeme cca 30 req. paralelně s cca 900 otevřenými spojeními na keep alive.

Hlavní server, který servíruje obsah zůstal (prozatím  a navenek) http.

V okamžiku spuštění naběhla obrovsky zátěž, takřka ke 100% na každém z jader. do několika minut zátěž klesla k 60% per jádro (top) Nicméně bylo to odpoledne v času klidu. Večer jsem musel potupně přepnout zpět na http protože server začal kolabovat - vracel 500.

Nicméně, zřejmě kvůli hlavičce Strict-Transport-Security máme doteď problémy u některých obrázků browsery tvrdošíjně trvají na https

DOTAZ: Proč je tam ta pekelná zátěž, když *všichni* se dušují, že její nárůst bude minimální. Evidentně je to buď pověra, nebo mám chybu v konfiguraci... Vnitřně si to vysvětluju tak, že TLS handshake s celou parádou je výpočetně náročná operace a "prostě je to tak" - ale celkem se mi s tím těžko smiřuje.

... a mimochodem, počet otevřených spojení na keepalive samozřejmě vůbec neklesl, ba právě naopak, ale to asi kvůli zpomalení servírování.

Máte někdo vysvětlení?

Dík za váš případný čas ...


M.

--SSL config ---
    server {
        listen     443 ssl http2;
        server_name  *****.cz;
       
        ssl_certificate         ****.crt;
        ssl_certificate_key     ****.key;
   
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
        ssl_prefer_server_ciphers on;
   ssl_dhparam /path/to/dhparam.pem;
   
        ssl_session_cache shared:SSL:50m;
        ssl_session_timeout 1d;
        ssl_session_tickets off;
        add_header Strict-Transport-Security "max-age=0; includeSubDomains" always;

        root    /static/html;
    
        location / {
            index  index.html index.htm;
            add_header Access-Control-Allow-Origin "*";
        }

}
--- SSL -----

[Reklama]

[Lol Phirae]

Jedná se o jeden poměrně čtený web. Začali jsme tedy polehoučku, nejdříve s webem, který servíruje statiku. ...  Večer jsem musel potupně přepnout zpět na http ... Nicméně, zřejmě kvůli hlavičce Strict-Transport-Security máme doteď problémy u některých obrázků browsery tvrdošíjně trvají na https

Dej si ránu do hlavy a pak dej výpověď.

 

[Sten]

ChaCha šifry jsou hodně pomalé. Zkuste použít jen AES:

Kód: [Vybrat]

ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5

Máte předgenerované 2048-bitové DH? Ta cesta (/path/to/dhparam.pem) je editovaná nebo nenastavená?

[M. N.]

Máte předgenerované 2048-bitové DH? Ta cesta (/path/to/dhparam.pem) je editovaná nebo nenastavená?

... to je samozřejmě upraveno tady pro diskusi, DH je 2048b

[mmenphis]

Co vím, tak  šifry založené na DH jsou obecně pomalé. Pokud se jedná o hodně navštěvované stránky dal bych do konfigurace šifer jen:
ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;

To by mělo problém vyřešit.

[Reklama]

[M. N.]

Děkuju @sten a @mmenphis. Je to asi nakopnutí správným směrem. CPU na serveru má AES-NI, ale není to aktivní, takže to budu muset nechat přenastavit v BIOS a pak překontrolovat OpenSSL; podle toho odkazu od sten by tam měl být velmi výrazný rozdíl.
Napíšu sem jak to dopadlo.

M.

[abc123]

tvoj sef by mal hlavne pouvazovat nad testovacim servrom otestovat konfiguraciu a dat tam na skusku nejaky trafic s cca 30 spojeniami je celkom trivialny task. Clovek by sa tak vyhol tym 500vkam v produkcii

[Cx]

Osobně myslím, že je chyba někde jinde. Buď v konfiguraci, která tu není a nebo v backendu. Původní příspěvek bohužel neobsahuje výpis topu/htopu/ps ani kompletní konfiguraci, takže můžeme jen hádat. I při použití pomalejších šifer by zatížení nevyletělo na 100 % na takovém stroji při 30 spojeních za sekundu.

P.S. Ta Strict-Transport-Security hlavička je dobrá bota :-)

[M. N.]

Ještě jednou díky za pomoc. Bylo to opravdu těmi šiframi. Zátěž se na serveru pohybuje, v průměru, do 20% per jádro, jedno je trvale vyšší než ta ostaní.  Rezerva je ještě v AES-NI - ta přijde aktivovat později.

M.