NajPresmerovanie z HTTP na HTTPS

Ktorý kód mám použiť na presmerovanie z HTTP na HTTPS (SSL), aby bolo čo najuniverzálnejšie a najbezpečnejšie??Samozrejme každému predchádza

RewriteEngine On

Hosting: Wedos

Server: Apache

CMS: WordPress

Takže ktorý?

RewriteCond %{HTTP:X-Forwarded-Proto} =http

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}

Alebo

RewriteCond %{HTTPS} !=on

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}

Alebo

RewriteCond %{HTTPS} off

RewriteCond %{HTTP:X-Forwarded-Proto} !https

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}

Alebo

RewriteCond %{HTTPS} !on

RewriteCond %{HTTP:X-Forwarded-Proto} !=https

RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI}

https://cs.wordpress.org/plugins/really-simple-ssl/

Napsal Oleg;1403004

https://cs.wordpress.org/plugins/really-simple-ssl/

Ďakujem.Vie niekto odpovedať na otázku, ktorá bola položená?

Řešíš blbiny, ptáš se tu samou věc snad na všech kanálech co znám...Pokud plánuješ použití reverzní proxy/balancer jako je CloudFlare (co řešíš zase jinde), musíš se zabývat X-Forwarded, nebo jinými hlavičkami dle dokumentace zvoleného řešení.Wedos ti sám říká, co je vhodné použít pro většinu případů: https://kb.wedos.com/cs/webhosting/https.htmlS CloudFlare máš možnosti:a) Flexible SSL- ve WP konfiguraci nic nenastavuješ necháš to na HTTP, musíš jen zpracovat hlavičku a dát vědět serveru, že to bylo na HTTPS:třeba do wp-config:if (isset($_SERVER) && $_SERVER == 'https') { $_SERVER='on'; }Nebo nainstaluješ CloudFlare Plugin - https://wordpress.org/plugins/cloudflare-flexible-ssl/- dále si nastavíš PageRule v CF, aby se všechny stánky přesměroval na HTTPS:http:///*

Always Use HTTPS – On

b) Full SSL

- na server musí běžet nějaké HTTPS, ale je mu jedno co tam je za certifikát, takže je možné použít wedosí self signed

- tady je třeba nastavit v administraci nové cesty s HTTPS a provést náhradu všech odkazů webu z http:// na https://

- k tomu lze použít nástroj https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

c) Full SSL (Strict)

- stejné jaké b), ale na serveru je nutné použít platný důvěryhodný certifikát, takže buď vlastní nebo Let's Encrypt

Osobně bych se Flexible SSL snažil vyvarovat, může způsobovat různé problémy a cesta z CF na web je nešifrovaná.

Pokud budeš používat Let's Encrypt sám, tak si musíš udělat výjimku z přesměrování pro složku /.well-known/, aby šlo certifikát prodlužovat. Hosting to bude mít pravděpodobně nějak vyřešeno, ale bylo by dobré to s nimi probrat jak to mají zařízení, aby CF nerozbil obnovování certifikátu - pak by nefungovalo c). Možná proto bude třeba udělat výjimku v CF.

Pokud potřebuješ vyřešit nějaké exotičtější problémy s přesměrováním, tak si nastuduj především https://httpd.apache.org/docs/current/rewrite/flags.html

Podoba řádku pro přesměrování v .htaccess s bezpečnostní nic neudělá. Pokud chceš řešit bezpečnost HTTPS, tak musíš zabrousit do HTTP hlaviček.

Chceš HSTS:

do .htaccess - ale musíš si nastudovat co přesně to dělá, jinak můžeš napáchat dost škody

Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

A následně se přihlásit do preload listu prohlížečů: https://hstspreload.org/

Další level je HPKP, ale tam už se dá pokazit opravdu hodně věcí a když to špatně nastavíš, tak web odstavíš na měsíce.

Bezpečnější šifrování HTTPS s hlavičkami HSTS a HPKP - Root.cz

Jak už jsem psal jinde, tak za nejuniverzálnější pouvažuji mé nastavení:

RewriteEngine onRewriteCond %{HTTPS} !onRewriteCond %{HTTP:X-Forwarded-Proto} !=httpsRewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}

X-Forwarded-Proto - pro případ, že před serverem je reverzní proxy a info o protokolu přijde touto hlavičkou

!=on místo off - protože některé verze Apache vrací v případě chybějícího HTTPS none a ne off

QSE - pro případ, kdyby se přesměrování změnilo na nějakou url s parametrem, tak aby původní zůstal zachovaný

NE - pro případ, kdy jsou v GET parametrech speciální znaky jako třeba ':'

regulár preferuji ^(.*)$, protože s adresou mohu následně pracovat v proměnné $1, ale pro tento případ je to úplně jedno, jen musí splnit podmínku, aby do něj padalo vše.

Url adresy pouze s HTTPS:RewriteCond %{HTTPS} offRewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} Funkční na Wedosu

Aby to zde bylo úplnější - info z jiného komunikačního kanálu:Jak nastavit HPKP v Apache:- je třeba mít minimálně 2 piny, které nejsou součástí stejného chainu1) vyrobení otisku (pinu) hlavního certifikátu - výstupem je otisk1:openssl x509 -pubkey < /cesta/k/hlavnimu/certifikatu.pem | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base642) Vyrobení záložního klíče a certifikátu - výstupem je otisk2:openssl genrsa -out backup.key 4096openssl req -new -key backup.key -sha256 -out backup.csropenssl req -pubkey < backup.csr | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base643) privátní klíče a csr vytisknout a uložit do trezoru- při ztrátě původního klíče je možné z záložního CSR a klíče vygenerovat nový certifikát u libovolné autority4) úprava .htaccess:

Header append Public-Key-Pins 'pin-sha256="otisk1"; pin-sha256="otisk2"; max-age=300; includeSubdomains'

- po vyzkoušení funkčnosti zvedat max age (většinou dávám 2 týdny a pak finálně 6 měsíců - 15768000)Pinů je možné definovat větší množství, někdo do pinů dává mimo koncového certifikátu (leaf) i certifikát mezilehlý (intermediate) a CA - platné jsou pak všechny certifikáty od podepsané vybranou autoritou. Tyto piny je možné jednoduše vygenerovat na https://report-uri.io/home/pkp_hash. Osobně dávám piny pouze koncového certifikátu a záložních - nechci aby někdo cizí vygeneroval jiný certifikát od té samé autority. Běžný use case je pinovat místo koncového certifikátu intermediate pro ulehčení renew (pokud se při renew zachová CSR s veřejným klíčem, tak to není problém), což dává smysl především u Let's Encrypt, kdy se standardně při každém renew mění i privátní klíč, nicméně to už se podle mě trochu ztrácí smysl HPKP.Let's Encrypt lze nastavit nastavit pro používání již hotového csr a piny tak budou zachovány, ale nechá na vás více práce, než když obnovujete jednoduše příkazem renew.Snažit se měnit DNS po každém renew je špatný postup - propagace DNS trvá můžete si tak na celý den odstavit některé návštěvníky.HPKP + Cloudflare - nedoporučuji pokud nemáte Business plán s vlastním certifikátem, CF může kdykoliv změnit svou certifikační autoritu (už se to stalo - měl GlobalSign, nyní Comodo a koketuje s Let's Encrypt) - když to udělá, tak web nebude dostupný čas podle max-age.Potřebuji HPKP když už mám nastavený CAA a změně CA také bráním?CAA záznam je k něčemu jinému - slouží certifikačním autoritám, aby mohly zkontrolovat, že certifikát mohou vystavit, ne všechny jej však podporují. U HPKP dělá kontrolu uživatelův prohlížeč.HPKP je dost ošemetná věc a proto bych ji doporučoval používat pouze v případě, že máte svůj vlastní komerční certifikát, nebo že máte plnou kontrolu nad obnovovacím procesem LE a víte co děláte.

Ahojte.Tak HPKP by som mal mať nastavene.Môj kód v .htaccess:Header append Public-Key-Pins 'pin-sha256="**1**=";pin-sha256="**2**=";pin-sha256="**3**=";pin-sha256="**4**="; max-age=120; includeSubdomains; preload; report-uri="https://***.report-uri.io/r/default/hpkp/enforce"'# „*“ znamená cenzúru, celí kód je v jednom riadku)Podľa ssllabs.com/ssltest/analyze.html je HPKP aktívne.Problém je, že ho skúšam testovať a neviem získať požadovaný efekt zablokovania načítania webstránky prehliadačom.Pri testovaní postupujem nasledovne:01. v .htaccess nastavím:- HPKP 1x hash aktívneho kľúča- HPKP 3x hash záložných kľúčov- HPKP "max-age=120".02. Otvorím webstránku na prehliadači Chrome a zavriem.03. v dobe 120s od načítania stránky:- v .htaccess prepíšem všetky hashe kľúčov na totálne bludy (teda nepasuje ani jeden)- znova načítam webstránku v novom okne.05 Výsledok: webstránku načíta, report nepošle.Tak nejak nerozumiem prečo.Viete mi v tom poradiť prosím? Kde robím chybu?Dodatočné info pre ostatných.Report-uri.io má viacero šikovných nástrojov:HPKP URL Hash key generatorHPKP Hash GeneratorHPKP CRS Hash key generatorPublic Key Hash Generatora po prihlásení ma aj zachytávanie reportov z HPKP a CSP.Aké riešenie na reporty HPKP a CSP používate vy?

Pro kompletnost, přepis odpovědi z FB:Aby HPKP zafungovalo, tak je třeba aby se změnil důvěryhodný certifikát, ne aby se změnily piny. Prohlížeč spočítá hash (pin) aktuálního certifikátu a porovná ho s tím, co má uložené - pokud certifikát nesedí, tak zobrazí chybu. Pokud se změní piny v hlavičce, tak se jen při dalším obnovení neuloží do cache prohlížeče, protože tam se ukládá jen ten, co sedí s certifikátem.Aby se hláška zobrazila, tak je třeba například provést renew LE certifikátu (za předpokladu, že není zapinovná CA), nebo lze chromu vnutit jiný falešný PIN přes chrome://net-internals/#hsts.Reporting se dá poměrně jednoduše udělat vlastní (používám to především u našich vlastních projektů) - notifikace je popsána v https://tools.ietf.org/html/rfc7469?fref=gc#section-3Report-ui.io používám spíše u klientů a notifikace tam pak vypadá takto: