Dotaz: HTTPS - Chyba zabezpečeného spojení

[Arny]

Ahoj, nainstaloval jsem Debian + Apache2, povolil konfigurační soubor 000-default a default-ssl, zapnul moduly rewrite, ssl, vhost_alias a headers. Restartoval Apache2.

pokud zadám adresu s https, dostanu zprávu:

Chyba zabezpečeného spojení
Spojení se serverem bylo v průběhu načítání stránky ukončeno.
Požadovanou stránku nelze zobrazit, protože nelze ověřit autenticitu přijatých dat.

V Error.log je:

[Sun Feb 25 04:00:26.328726 2018] [mpm_prefork:notice] [pid 32766] AH00169: caught SIGTERM, shutting down
[Sun Feb 25 04:00:26.407269 2018] [mpm_prefork:notice] [pid 333] AH00163: Apache/2.4.25 (Debian) OpenSSL/1.0.2l configured -- resuming normal operations
[Sun Feb 25 04:00:26.407306 2018] [core:notice] [pid 333] AH00094: Command line: '/usr/sbin/apache2'

Může někdo poradit? dÍK.

Odpovědi

[Filip Jirsák]

Asi nemáte na serveru důvěryhodný certifikát, třeba zdarma od Let's Encrypt. Zkuste:

openssl s_client -connect localhost:443

To vám vypíše detaily o SSL spojení.

[Josef Kufner]

Případně se k tomu dá doklikat v prohlížeči.

[Arny]

Zajímavé je, že to nejde pouze ve Firefoxu a všude jinde jo :(

Jinak je to jen na localhostu, tak že na Let's Encrypt nedosáhnu.

[Filip Jirsák]

Nedůvěryhodný certifikát se dá ve Firefoxu přeskočit. Ale zatím vůbec nevíme, kde přesně je chyba – teď už aspoň víme, že ten text uvedený v dotazu, pravděpodobně zobrazuje Firefox. Jenže Firefox v takovýchhle případech zobrazuje víc informací, odkazy na detaily apod. Takže by bylo dobré se alespoň vložit screenshot místo vykopírování části textu. A ten výstup z OpenSSL klienta by byl také vhodný, protože v něm bude vidět certifikát a parametry SSL spojení. Certifikát může být expirovaný, může být podepsaný slabým hashem, může být zvolen slabý šifrovací protokol… Bez dalších informací můžeme jenom hádat.

Jinak používat HTTPS na localhostu kvůli šifrování moc nedává smysl. A pokud je to kvůli testování, zase nedává moc smysl to testovat s nedůvěryhodným certifikátem. Pokud chcete něco testovat, je lepší si nechat vystavit důvěryhodný certifikát od Let's Encrypt a adresu si nasměrovat třeba na localhost.

[Arny]

Tak vyřešeno, problém byl v tom, že Firefox měl zapnutou proxy (zapomněl jsem ji vypnout) na ten můj virtuální server, tudíž ho nezajímalo nastavení v systému, proto se to chovalo jinak než u jiného prohlížeče. Díky za nakopnutí.

Můj problém proč potřebuji https na lokále

Mám jeden ostrý server a jeden server co mi běží virtuálně. Pak mám dva prohlížeče kdy z jednoho se po zadání www.example.com (http i https) potřebuji dostat na ostrý server a z druhého prohlížeče se po zadání té stejné domény www.example.com (http i https) potřebuji dostat na virtuální server. V systému to nastavit nejde, to je jasný, musím použít tedy asi proxy, zase ale neznám rozšíření pro prohlížeč, který umí současně http a https. Nějaký nápad, tip? Díky

[Filip Jirsák]

Tohle přepínání dvou prostředí pod stejným jménem je to nejhorší možné řešení – koledujete si o průšvih, až si to někdy popletete. Ale pokud máte privátní klíč k certifikátu pro ten ostrý server, můžete ho použít i pro ten testovací.

Nerozumím, na co potřebujete rozšíření pro prohlížeč. Prostě si v prohlížeči nakonfigurujte vlastní proxy server, a na něm veškerý provoz na tu adresu směřujte na virtuální server. Dokonce existují i rozšíření do prohlížeče, která umožňují proxy přepínat jedním kliknutím – ale to bych nedoporučoval, protože pak budete mít v prohlížeči nacachované věci z jednoho prostředí a půjdete na druhé a bude se to chovat divně.

[Arny]

Prostě si v prohlížeči nakonfigurujte vlastní proxy server, a na něm veškerý provoz na tu adresu směřujte na virtuální server.

No to právě nefunguje, pokud to nastavím v souboru hosts (čili pro všechny) tak to funguje parádně, to se ale zase nedostanu na ostrý server. :(

Takto to mám nastavené. Je to správně?

[Filip Jirsák]

V souboru hosts nenastavujete proxy server. Proxy server nastavujete v prohlížeči v tom dialogovém okně, ze kterého máte screenshot – a nastavujete tam adresu a port toho proxy serveru (ne cílového serveru). Pochybuju, že máte spuštěné dva proxy servery na různých portech, nevidím v tom žádný smysl. Zadejte adresu proxy serveru do té položky HTTP proxy a zaškrtněte „Pro všechny protokoly používat tento proxy server“. I kdyby ten proxy server neuměl FTP, asi v tom prohlížeči pro testování nebudete používat FTP. Proxy server se málokdy umisťuje na port 80 nebo 443, např. Squid obvykle používá port 3128, ve světě Windows bývá obvyklé dávat HTTP proxy na port 8080.

[Filip Jirsák]

Jinak s proxy serverem se komunikuje protokolem HTTP, takže pokud jste jako proxy server uvedl ten cílový server a port 443, prohlížeč se pokusil navázat spojení přes proxy server protokolem HTTP metodou CONNECT, jenže to přišlo na cílový server, který očekával SSL, tomu nešifrovanému spojení nerozuměl, takže ho ukončil.

[Arny]

Tak že jestli to dobře chápu, přes proxy se na https nepřipojím? Zkoušel jsem to nastavit jak jste radil ale..

Proxy server odmítl spojení
Firefox je nastaven, aby používal proxy server, který odmítá spojení.

[Filip Jirsák]

Přes proxy se na HTTPS připojíte.

Když prohlížeč hlásí tuhle chybu, proxy server buď neběží, nebo tam zadáváte špatnou adresu nebo port. Jaký proxy server používáte a kde vám běží?

[Arny]

Nemám žádný proxy server, zadal jsem tam IP adresu toho mého virtuálního webserveru.

[Filip Jirsák]

To samozřejmě nemůže fungovat. Když chcete používat proxy server, musíte nějaký mít.

[Arny]

Aha, tak že jak to udělat? Sám jste psal, že existuje rozšíření pro prohlížeč, který umí přepnout proxy. Jaké mám tedy hledat rozšíření?

[Filip Jirsák]

To rozšíření ale umí jen rychle přepínat různé proxy servery. Ale když chcete používat proxy server, pořád nějaký musíte mít.

Pokud to ale máte pro to, abyste měl vývojovou nebo testovací instanci aplikace, je to s proxy serverem podle mne zbytečně komplikované řešení (zvláště když žádný nemáte a musel byste ho zprovoznit). Podstatně jednodušší je ten virtuální server mít na jiné adrese.

[Arny]

A to je právě hlavní kámen úrazu, jelikož bych musel před uploadem vždy přepsat spousto odkazů.

[Filip Jirsák]

Proč tam nemáte odkazy relativní k doméně?

[Arny]

Jedná se o backend a prý je to druh zabezpečení (nejsem autorem).

[OldFrog {Ondra Nemecek}]

Taky doporučuju mít vývojový server pod jiným jménem než ostrý. Máte pak přístupné oba servery bez jakéhokoli zvláštního nastavení a to nejen v prohlížeči ale globálně v celém systému (což se hodí pro testování).

Https pořešíte tak, že si vyrobíte self-signed certifikát (jeden až dva příkazy v konzoli) a v prohlížeči mu dáte vyjímku. To je nejsnadnější postup.

[Josef Kufner]

Pro lokální testování si vyrob vlastní certifikační autoritu a naimportuj si ji do svého prohlížeče. Webu pak touto autoritou podepiš certifikát a bude ti to lokálně fungovat s hezky zeleným "https" v prohlížeči. Já takto mám skript, který mi automaticky přegeneruje certifikát pro všechny virtuální hosty, které u sebe na notebooku mám. Návodů je na to všude spousta.

[Arny]

To by bylo hodně dobrý ;) Možná, že bych zabil dva Alfonse jednou ranou. A nějaký odkaz nejlépe česky dáš?

[Filip Jirsák]

To ale pro testování není úplně vhodné, protože ta vlastní certifikační autorita se nebude chovat stejně, jako ty důvěryhodné – nebude publikovat certifikáty v Certificate Transparency, asi nebude mít CRL, v budoucnosti tam nebudete mít DANE a DNSSEC. Pokud už to tak máte, asi není důvod to teď měnit, ale pokud si někdo teď vytváří testovací prostředí, měl by použít skutečné domény a důvěryhodné certifikáty – jiné řešení je zastaralé a dříve či později s ním budou problémy.

[Josef Kufner]

To vůbec není potřeba. Pokud vyvíjím webové aplikace, potřebuju, aby prohlížeč neotravoval a aplikace mohla řešit, zda běží na HTTP nebo HTTPS. Certifikát podepsaný mojí lokální certifikační autoritou je pro mne a můj prohlížeč důvěryhodný. Domén to stejně musí umět víc, neboť aplikace poběží v několika instancích – vedle lokální vývojové ještě na testovací a produkční.

[Filip Jirsák]

Stejně, jako dnes prohlížeč rozlišuje HTTP a HTTPS, bude v budoucnosti nejspíš rozlišovat další úrovně zabezpečení. To, že jsou všechny certifikáty stejně důvěryhodné, stačí přidat autoritu do prohlížeče, je mýlka – vzpomeňte třeba SHA-1 certifikáty.

[Josef Kufner]

Ne. Opravdu to stačí. Jak ten certifikát vypadá je zcela irelevantní, beztak šifrování pořeší web server a k aplikaci se to ani nedostane. A až se někdy objeví nějaké relevantní další zabezpečení, tak se to prostě nastaví, nebo se to otestuje jinde. Je ptákovina se tím zabývat teď.

[Filip Jirsák]

Prohlížeč neeviduje, že jste si danou certifikační autoritu nahrál mezi důvěryhodné vy sám, takže nemá možnost se k ní chovat speciálním způsobem. Certifikát s šifrováním přímo nesouvisí, slouží k tomu, abyste věděl, že komunikujete skutečně se správnou protistranou. Certifikát se k webovému prohlížeči samozřejmě dostane a prohlížeč samozřejmě neakceptuje libovolný certifikát, má na něj spoustu podmínek – musí být vydaný důvěryhodnou autoritou, musí být platný, musí být vydaný na jméno, které klient požaduje, musí být podepsaný bezpečným algoritmem. Ta další relevantní zabezpečení existují už teď, některá jsem jmenoval.

Nesmysl je naopak teď nově vytvářet zastaralé testovací prostředí, o kterém už teď víte, že se zbytečně liší od produkčního prostředí.

[Josef Kufner]

Prohlížeč neeviduje, že jste si danou certifikační autoritu nahrál mezi důvěryhodné vy sám, takže nemá možnost se k ní chovat speciálním způsobem.

Takže je vše v pořádku a můžeme se věnovat vývoji.

[Filip Jirsák]

Hodně štěstí, až budete chtít při tom vývoji otestovat třeba HPKP nebo HSTS preload list.

[alkoholik]

RIP HPKP. HSTS i HPKP samozrejme funguji s vlastni autoritou naprosto v klidu.

[Filip Jirsák]

HTTP Public Key Pinning (HPKP) na MDN:

Firefox and Chrome disable pin validation for pinned hosts whose validated certificate chain terminates at a user-defined trust anchor (rather than a built-in trust anchor). This means that for users who imported custom root certificates all pinning violations are ignored.

[Josef Kufner]

V defaultní konfiguraci je vygenerován self-signed certifikát (soubor snakeoil.pem tuším). Ten tam je jen aby to tak nějak fungovalo, ale pro praktické použití ho musíš nahradit něčím důvěryhodným. Třeba tím od Let's Encrypt – viz balíček certbot.

[karlik]

To by mě taky zajímalo, ten Let's Encrypt jde použít na intranetu, pokud nemám přístup k internetu?

Například pokud si nainstaluji Webmin a chci s ním pracovat přes webové rozhraní. Vlastní doménu zakoupenou nemám.

[Josef Kufner]

Ne.

Doména musí být dosažitelná z Internetu. Pro ověření musí být dosažitelný i kousek serveru. Pokud bys měl doménu, tak z vnějšku necháš subdoménu přes wildcard záznam (nebo CNAME) nasměrovat na nějaký vnější server, přes který se ověří certifikát (tedy přesněji kontrola nad serverem). Samotná webová služba může být schovaná jen pro intranet (zevnitř bude jinak nastavený DNS záznam).

[Filip Jirsák]

Pro Let's Encrypt se dají domény ověřit i čistě jen přes DNS, takže kromě DNS nic jiného z internetu dosažitelné být nemusí.

[Josef Kufner]

Teoreticky ano. Prakticky však bude chtít automatické obnovování certifikátu a u ověření přes DNS nejspíš narazí na nutnost manuálního nastavování záznamů na DNS serveru (neboť moc registrátorů nemá potřebné API a nebo tomu nebude LE klient rozumět).

Oproti tomu může vystavit adresář .well-known a mít klid.

[Filip Jirsák]

Jedině v případě, kdy má ten webový server dostupný z internetu. Já jsem psal o případu, kdy se jedná o nějaký interní server. Pak je potřeba stejně řešit, jak dostat vystavený certifikát na ten interní server. Může to být jednoduchý HTTP GET, ale stejně tak se možná dá jedním HTTP požadavkem vystavit ten ověřovací klíč do DNS.

[Josef Kufner]

Obnovení certifikátu může pořešit zvnějšku viditelný server a napsat jedno scp do renew-hoooku je to nejmenší.

[Filip Jirsák]

Což ovšem znamená ten zvnějšku viditelný server mít nebo rozchodit a nasměrovat na něj tu doménu. Navíc na ten cílový server nedostupný z internetu se těžko dostanete z internetu přes scp. To vaše řešení je taky funkční, akorát toho k němu potřebujete mnohem víc, než k řešení s DNS. Ale pokud už to všechno máte (externí web server, přístup z něj na interní webserver, doménové jméno nasměrované zevnitř na ten vnitřní web server a z venku na ten vnější), může to být jednodušší. Pokud to ale nemáte, bude asi jednodušší vyřešit to vkládání DNS záznamu skriptem.

[Josef Kufner]

Nebo se nechá na routeru přeposlat port, když není veřejný server.