Zadejte hledaný výraz...

NajPresmerovanie z HTTP na HTTPS

Ogi22
verified
rating uzivatele
6. 8. 2017 11:59:43
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}
6. 8. 2017 11:59:43
https://webtrh.cz/diskuse/najpresmerovanie-z-http-na-https/#reply1293756
Oleg
verified
rating uzivatele
(53 hodnocení)
6. 8. 2017 14:39:04
https://cs.wordpress.org/plugins/really-simple-ssl/
6. 8. 2017 14:39:04
https://webtrh.cz/diskuse/najpresmerovanie-z-http-na-https/#reply1293755
Ogi22
verified
rating uzivatele
6. 8. 2017 14:44:48
Napsal Oleg;1403004
https://cs.wordpress.org/plugins/really-simple-ssl/
Ďakujem.
Vie niekto odpovedať na otázku, ktorá bola položená?
6. 8. 2017 14:44:48
https://webtrh.cz/diskuse/najpresmerovanie-z-http-na-https/#reply1293754
Ř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.html
S 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:
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í:
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.
6. 8. 2017 18:05:55
https://webtrh.cz/diskuse/najpresmerovanie-z-http-na-https/#reply1293753
Pomeranc
verified
rating uzivatele
6. 8. 2017 18:18:30
Url adresy pouze s HTTPS:
Funkční na Wedosu
6. 8. 2017 18:18:30
https://webtrh.cz/diskuse/najpresmerovanie-z-http-na-https/#reply1293752
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 chainu
1) 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 | base64
2) Vyrobení záložního klíče a certifikátu - výstupem je otisk2:
openssl genrsa -out backup.key 4096
openssl req -new -key backup.key -sha256 -out backup.csr
openssl req -pubkey < backup.csr | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64
3) 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é autority
4) ú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.
10. 8. 2017 09:34:25
https://webtrh.cz/diskuse/najpresmerovanie-z-http-na-https/#reply1293751
Ogi22
verified
rating uzivatele
15. 8. 2017 13:54:56
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 generator
HPKP Hash Generator
HPKP CRS Hash key generator
Public Key Hash Generator
a po prihlásení ma aj zachytávanie reportov z HPKP a CSP.
Aké riešenie na reporty HPKP a CSP používate vy?
15. 8. 2017 13:54:56
https://webtrh.cz/diskuse/najpresmerovanie-z-http-na-https/#reply1293750
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-3
Report-ui.io používám spíše u klientů a notifikace tam pak vypadá takto:
17. 8. 2017 09:30:35
https://webtrh.cz/diskuse/najpresmerovanie-z-http-na-https/#reply1293749
Pro odpověď se přihlašte.
Přihlásit