Názory k článku Hardening webového serveru Apache: šifrování a certifikáty

Rozumim, Vy proste mate jiny nazor, a ten je nejlepsi. Sva tvrzeni nijak nedokladate, proste jsou platna a hotovo.
Muzete napriklad uvest nejaky podklad pro tvrzeni " Pokud se obáváte, že na serveru TLS_EMPTY_RENE­GOTIATION_INFO_SCSV vypnete ale knihovna to nebude respektovat a dál tu „šifru“ půjde používat, měl byste se úplně stejně být toho, že vypnete TLS 1.0 nebo SSLv3 ale knihovna to dál bude používat."
Tohle je totiz uplna hloupost a v mem textu nic podobneho neni. Vtip je v tom, ze TLS v1.0 umoznoval (za jistych okolnosti) downgrade na NULL cipher neboli TLS_EMPTY_RENE­GOTIATION.
U TLS v1.1 a v1.2 to prokazano neni.

Podobne je to i se zbytkem Vasich ostatnich tvrzeni.

Muj clanek je o hardeningu te casti Apache, ktera se tyka sifrovaneho provozu. Konkretne se jedna o to, aby server "vynutil" na klientech prechod na https, kde budeme pouzivat pouze vybrane sifrove sady v ramci TLS v1.2. A jako podklad pro tento "implementacni scenar" jsem zvolil dopourceni BSI Technical Guideline TR-02102–2, kde jsem navic ocitoval i nektera jejich oduvodneni, proc nepouzivat SSLv2, SSLv3, TLSv1.0 a TLS v1.1.

Mozna jste od clanku ocekaval neco jineho, ale to je jiz Vase zalezitost.

Michal Vymazal: Ne, nejde o názor. Vy jste v článku uvedl chybné a nesmyslné tvrzení, že v protokolech SSLv2, SSLv3 a TLS 1.0 budou uživatelská jména. Po dotazu jste se odkazoval na dokument BSI, kde ovšem žádné takové tvrzení není. To jsem doložil.

Proč je to tvrzení nesmyslné jsem nedoložil, ale když chcete… Je potřeba trochu znát, jak HTTP a TLS dohromady skládá HTTPS. TLS je univerzální šifrovaný tunel, kterým mohu procházet různé protokoly. HTTP (ve verzích 0.9 a 1.x) je textový protokol skládající se z hlaviček a těla. Uživatelská jména a hesla při přihlašování k webové stránce se přenášejí buď v hlavičkách (při použití HTTP autentizace) nebo (dnes u webů prakticky výhradně) v těle požadavku jako formulářová data. HTTPS je protokol HTTP tunelovaný skrze TLS spojení. To znamená, že TLS neví nic o tom, kde uvnitř je uživatelské jméno a heslo – to je záležitost HTTP protokolu. Pokud by tedy uvedené protokoly přenášely nešifrovaně uživatelské jméno a heslo, musely by přenášet nešifrovaně i vše okolo, nebo-li celý vnitřek komunikace. Jinými slovy, šifrovací protokoly SSLv2, SSLv3 a TLS 1.0 by od roku 1995 deset let vše přenášely nešifrovaně a nikdo by si toho nevšiml, až v roce 2006 by si toho konečně někdo všiml a malým updatem na TLS 1.1 by se najednou šifrování zprovoznilo. Ale nikomu by to nešifrování dál nevadilo a dalších víc než deset let by se v pohodě TLS 1.0 používalo.

Samozřejmě, kdokoli si to přečte, a ví trochu o co jde, musí se smíchy válet po zemi. Bohužel je to jen ale rozepsání důsledků vašeho tvrzení v článku.

Vtip je v tom, ze TLS v1.0 umoznoval (za jistych okolnosti) downgrade na NULL cipher neboli TLS_EMPTY_RENE­GOTIATION.
Už to z vás pomalu leze a začínáte chápat, proč je to tvrzení v článku nesmyslné. Za prvé píšete „za jistých okolností“. Ano, samozřejmě, za jistých okolností – což je úplně něco jiného, než (implicitní) „vždy“, které je v článku. Přičemž ty jisté okolnosti jsou mimo jiné to, že to server musí podporovat. Takže pro obranu před tímto útokem stačí vypnout podporu nulové šifry na serveru, a nemusíte vypínat TLS 1.0.

Dále nulová šifra samozřejmě znamená, že není šifrováno vůbec nic – takže by byla nešifrovaná celá komunikace, ne jen jméno a heslo.

Shrnuto a podtrženo – v článku tvrdíte, že budou vždy přenášeny přihlašovací údaje nešifrovaně, přičemž chybně jsou obě tvrzení. Nebude to vždy, ale jen pokud útočník na komunikaci zaútočí a server takový útok umožní. A pokud už útočník takový útok provede, nebude se to týkat jen uživatelských jmen a hesel, ale nešifrované bude celá komunikace.

Podobne je to i se zbytkem Vasich ostatnich tvrzeni.
Ano, jsou logická, pravdivá a nesnažím se tvrdit, že je něco napsaného v textu, kde to napsané není.

Muj clanek je o hardeningu te casti Apache, ktera se tyka sifrovaneho provozu.
To jsem psal v prvním komentáři, že by v článku měla být popsána jen konfigurace Apache a neměl byste se pouštět do obecných úvah „proč to nakonfigurovat právě takhle“, když tomu (bohužel) nerozumíte.

A jako podklad pro tento "implementacni scenar" jsem zvolil dopourceni BSI Technical Guideline TR-02102–2, kde jsem navic ocitoval i nektera jejich oduvodneni, proc nepouzivat SSLv2, SSLv3, TLSv1.0 a TLS v1.1.
Neocitoval, vy jste si je vymyslel. Pro vaši informaci, citace vypadá tak, že je napsaná v uvozovkách, je u ní uvedeno, odkud se cituje tak, abych dokázal citaci v původním dokumentu najít. A v tom původním dokumentu najdu buď přesný text citace, nebo třeba bude lehce upravený slovosled, abych vytvořil samostatnou větu z něčeho, co se v původním textu váže na okolní text. Případně tam bude to samé v jiném jazyce. Takže pokud by ten váš výmysl s přihlašovacím jménem a heslem byl citací, musel bych být schopen v původním dokumentu najít slovo „password“ – ono tam je, jednou a v úplně jiném kontextu. Nevím, jak ještě víc byste chtěl dokázat tvrzení, že si vymýšlíte – za mne jako důkaz bohatě stačí už to, že jste třikrát napsal, že citujete z dokumentu BSI, přitom jste ani jednou nepoužil citaci (nevložil jste sem konkrétní text BSI), ani jednou jste neodkázal na konkrétní kapitolu dokumentu (na rozdíl od mne – a tvrdíte, že já svá tvrzení nedokazuju), dokonce ani na konkrétní stránku jste nebyl schopen odkázat.

Důvod, proč nepoužívat TLS 1.0 a TLS 1.1 je ten, že jsou to z dnešního pohledu už slabé protokoly – mají známé díry, které je sice možné vhodnou konfigurací serveru a klienta zalepit, ale často si nemůžete být jistý, že druhá strana tu záplatu opravdu má. Což je zároveň důvod, proč už relativně dlouho platí, že se doporučuje tyhle protokoly opustit, ale k tomu, že přestanou být prohlížeči (ve výchozí konfiguraci) podporované dochází až letos. Jinými slovy platilo (a pořád platí), pokud máte dobrý důvod tyhle protokoly podporovat (např. musíte podporovat staré HTTPS klienty, kteří novější protokol neumí), nakonfigurujte je tak, aby byly bezpečné, a pak je můžete dál používat. Což je diametrálně odlišné od SSLv2 a SSLv3, které zabezpečit nejde – proto je k nim jednoznačný postoj „nepoužívat“, a pokud někde máte zařízení, které nic jiného neumí, je potřeba se k tomu chovat, jako by ten provoz byl nešifrovaný.

Mozna jste od clanku ocekaval neco jineho, ale to je jiz Vase zalezitost.
Očekával bych, že v článku nebudou zjevné nesmysly.

Skonceme to. Ja myslim, ze uz jste se vytrapil dost :-) Vtip je samozrejme v tom, ze TLS v1.0 je nachylny k tzv. "plain-text-attack". Jedna se o chybu v navrhu TLS v1.0 a tyka se modu s rezimem CBC. Plain-text-attack v BSI dokumentu zminen je a najdete jej nikoliv v textu, ale v tabulce.
Problem jsem nechtel rozvijet proto, ze patri do oblasti serialu Cryptosession, ktery mozna bude na ROOT.CZ tez vychazet. Tam se muzete podobnymi dotazy opravdu vyradit.

A pro priste - pokud necemu nerozumite, pak staci se normalne (a zdvorile) zeptat. Autor rad normalne (a zdvorile) odpovi. Staci obvykle dotaz typu "co jste vlastne myslel vetou typu ....".

Jo, a dokumenty narodnich bezpecnostnich autorit pouzivame v branzi naprosto bezne. Ony totiz ty autority nejsou hloupe a dokazi zpracovat podnety od kohokoliv z verejnosti. Delaji to ve svem vlastnim zajmu a dokazi reagovat opravdu rychle - v radu hodin (kdyz uznaji za vhodne). Porovnejte s reakci spravcu ISO 27000 a mame jasno.

Kdybyste nepsal do článku nesmysly a pak se v diskusi nevymlouval, tolik bychom se netrápili.

O plain-text-attack psát nemusíte, ani o tom, že je zmíněný v dokumentu BSI. To všichni vědí. Co ale uniklo vám, je to, že to neznamená, že jsou přihlašovací jména a hesla protokoly SSLv2, SSLv3 a TLS 1.0 přenášena nešifrovaně. Resp. vám už to také došlo, akorát to nechcete naplno přiznat. Asi jste si uvědomil, že bych vám mohl předložit dump TLS 1.0 komunikace a chtít po vás, ať z něj ten login a heslo získáte – když je to podle vás nešifrované.

A pro priste - pokud necemu nerozumite, pak staci se normalne (a zdvorile) zeptat. Autor rad normalne (a zdvorile) odpovi. Staci obvykle dotaz typu "co jste vlastne myslel vetou typu ....".
Takže já se zde normálně a zdvořile zeptám: Proč píšete články o bezpečnosti, když na to nemáte? Sice znáte názvy jednotlivých protokolů, šifer nebo útoků, ale nedokážete to propojit dohromady.

Tady je hlavní problém v tom, že jste do článku napsal nesmyslnou zkratku, a místo abyste to přiznal a opravil to, jenom se do toho dál zamotáváte a vymýšlíte si, že citujete dokumenty BSI.

Můžete se jak chcete dál tvářit, že vy tomu rozumíte a já ne, bohužel jste ale před tím napsal nesmysl do článku, tady do diskuse jste několikrát napsal, že citujete BSI nebo že něco plyne z textu BSI, ale ani jednou jste z toho textu nic necitoval ani nic neodkázal. Každému soudnému člověku je už jenom z toho jasné, že si vymýšlíte – což byste neměl zapotřebí, pokud byste problematice alespoň trochu rozuměl. Já bezpečnosti moc nerozumím, bohužel se ukázalo, že vy jí rozumíte ještě méně.

Jo, a dokumenty narodnich bezpecnostnich autorit pouzivame v branzi naprosto bezne.
Tady mám také jeden normální a zdvořilý dotaz: Tohle je zbabělý pokus o argumentační faul, nebo opravdu stále nechápete, v čem je váš problém? Dokumenty BSI tu vůbec nikdo nezpochybňuje. Zpochybněna je vaše interpretace. Resp. kdokoli, kdo sleduje tuhle diskusi, kromě vás, už dávno ví, že byla vyvrácena – protože kdyby v těch dokumentech skutečně bylo to, co tvrdíte, už byste to dávno citoval nebo alespoň odkázal. Jenže tvrzení „přihlašovací jména a hesla jsou při použití protokolů SSLv2, SSLv3 nebo TLS 1.0 přenášena v otevřeném tvaru“ v těch dokumentech nikde není, a ani z těch dokumentů nijak neplyne. Je to čistě jen váš výmysl. Což je právě ten důvod, proč nemáte na to psát články o bezpečnosti.

Neustále se snažíte zaštiťovat BSI, jenže to, co já rozporuju, jsou vaše výroky. Argument, že jen citujete BSI, už jste sám vyvrátil tím, že jste ani v několikátém komentáři nebyl schopen odkázat nebo citovat cokoli od BSI, co by váš výrok potvrzovalo.

Rada „nepoužívejte interní CA“ je pochopitelně to nejlepší, co můžete udělat. Pokud ještě žádnou interní certifikační autoritu nemáte, tak už jí určitě nezakládejte. A pokud ji už máte, pomalu bych přemýšlel o její náhradě. Samozřejmě se to netýká velkých firem, kde na to mají tým lidí, který se tomu věnuje na plný úvazek – ale takoví lidé se na to nebudou ptát na rootu.

Jak by se asi obnovoval certifikat ze zabezpeceneho intranetu, ze?
Přesně tak, jak jsem popsal už včera. Klidně to zopakuju ještě jednou – pro ověření domény pro ACMEv2 stačí DNS, konkrétně je potřeba umět do DNS vložit správný TXT záznam. Nebo-li pro jména, která potřebujete ověřit, vystavíte na veřejném DNS serveru příslušné TXT záznamy – nemusíte tam zveřejňovat nic jiného, žádné A nebo AAAA záznamy. Tak se obnovují záznamy ze zabezpečeného intranetu.

Nepochopil jste otazku.
Mam na intranetu server bez pristupu k internetu. Jak si na nem automaticky obnovim certifikat, az vyprsi?
Nijak!

Na intranetu, který nemá vůbec žádný přístup do internetu, nemusíte řešit ani obnovu certifikátu – nezajímá vás totiž přístup z webového prohlížeče z běžné pracovní stanice.

Na intranetu, se kterým dokážete komunikovat alespoň z jednoho zařízení mimo intranet, použijete výše popsaný postup. Na zařízení vygenerujete žádost, vložíte z něj záznam do DNS, necháte provést validaci, stáhnete certifikát a pošlete ho do toho intranetu. Jediný přístup, který do intranetu potřebujete, je možnost nahrát tam obnovený certifikát.

Možná jste si neuvědomil, že obnovu certifikátu nemusí zajišťovat zařízení, které certifikát bude používat, ale může ho zajistit jakékoli jiné zařízení.

Pokud ještě žádnou interní certifikační autoritu nemáte, tak už jí určitě nezakládejte. A pokud ji už máte, pomalu bych přemýšlel o její náhradě. Samozřejmě se to netýká velkých firem, kde na to mají tým lidí, který se tomu věnuje na plný úvazek – ale takoví lidé se na to nebudou ptát na rootu.

Jde o to, jestli chcete používat lokální DNS názvy (např. .local). Tam má interní CA smysl. Přechod na veřejné názvy má taky smysl, ale zejména s IPv4 NAT je to složitější, o to víc práce je s nastavením a udržováním firewallu - to si nevyberete. Diskutujeme ale pod dotazem, který se týká právě situace s místním DNS názvem.

Interní CA je lehlá všude, kde mají Windows Server, tam je certificate enrollment docela snadný. Certifikát CA se pak instaluje na stanice automaticky při přihlášení, takže tým nebude vůbec řešit, jestli povolování certifikátu pro intranetový server.

Tam, kde je možnost přejít na veřejné názvy to je taky možné, ale zase se musí řešit buďto místní přebíjení DNS odpovědí (fuj praktika), nebo dvojitý nat, aby i zevnitř byly servery dostupné pod veřejnou IP adresou. Nebo v kombinaci s proxy serverem. To je podle mě větší pakárna a bezpečnostně složitější, než používat interní CA.

Jde o to, jestli chcete používat lokální DNS názvy (např. .local).
Ano, a moje odpověď je, že pokud byste interní názvy nebo autoritu teprve teď zaváděl, tak je používat nechcete.

Diskutujeme ale pod dotazem, který se týká právě situace s místním DNS názvem.
Ano, a moje doporučení je začít používat veřejný název. Spoustu věcí si tím dotyčný ulehčí.

Interní CA je lehlá všude, kde mají Windows Server, tam je certificate enrollment docela snadný.
Jasně, a snadné je tu autoritu správně nakonfigurovat, udržovat jí (některé tyhle interní autority dodnes nepoužívají SAN), v budoucnu jistě bude snadné dostat certifikáty vydávané touto autoritou na CT list. A stejně tak snadné je udržovat tu autoritu natolik bezpečnou, aby z ní nemohl nikdo vydat certifikát třeba pro google.com.

Certifikát CA se pak instaluje na stanice automaticky při přihlášení, takže tým nebude vůbec řešit, jestli povolování certifikátu pro intranetový server.
Do té doby, než někdo zjistí, že existuje třeba prohlížeč Firefox. Nebo další programy, které mají svá vlastní úložiště certifikátů. Ono naklikat něco ve Windows ještě neznamená, že to umíte spravovat.

Tam, kde je možnost přejít na veřejné názvy to je taky možné, ale zase se musí řešit buďto místní přebíjení DNS odpovědí (fuj praktika), nebo dvojitý nat, aby i zevnitř byly servery dostupné pod veřejnou IP adresou. Nebo v kombinaci s proxy serverem. To je podle mě větší pakárna a bezpečnostně složitější, než používat interní CA.
DNS split horizon ani dvojitý NAT nemusíte řešit, když použijete IPv6. Bezpečnostně složitější je rozhodně správně provozovat certifikační autoritu.

Do té doby, než někdo zjistí, že existuje třeba prohlížeč Firefox. Nebo další programy, které mají svá vlastní úložiště certifikátů.

Však to je taky velká překážka, proč se FF nedostává do firem. Nezkoumal jsem, jaké důvody je k tomu vedly, ale je to dost podivné.

DNS split horizon ani dvojitý NAT nemusíte řešit, když použijete IPv6. Bezpečnostně složitější je rozhodně správně provozovat certifikační autoritu.

IPv6 je zatím utopie. I ty vyvíjené aplikace musíte testovat pro IPv4. To bohužel dnes není řešení.

Nezkoumal jsem, jaké důvody je k tomu vedly, ale je to dost podivné.
To je jednoduché. V době, kdy Firefox vznikal, bylo systémové úložiště certifikátů na Windows, ale v Linuxu si to každá distribuce a každá aplikace řešila sama. No a když už si to musel Firefox vyřešit sám pro Linux, bylo nejjednodušší tu samou implementaci použít i pro Windows.

IPv6 je zatím utopie. I ty vyvíjené aplikace musíte testovat pro IPv4. To bohužel dnes není řešení.
Nevidím důvod, proč by se třeba webové aplikace musely testovat pro IPv4.

Na tom je krásně vidět, jaké problémy nedostatek IPv4 adres přináší. Je jich málo, tak musíte používat NAT. Kvůli NATu zase musíte řešit DNS split horizon. To zase způsobuje problémy s vystavováním certifikátů. Jestli ono by nakonec nebylo jednodušší rozchodit v té síti IPv6… Na druhou stranu, takovéhle sítě už stejně split-horizon DNS mají, třeba jen proto, aby se zaměstnanci dostali na firemní web. Takže když už musíte v síti kvůli NATu páchat škody, snažil bych se je omezit na co nejmenší možnou oblast, tj. nejdál do DNS a dál už ne. Až pak konečně zprovozníte to IPv6, opravíte jen DNS a nemusíte sahat ještě na certifikáty a konfigurace a bůhvíco ještě.

Takže když už musíte v síti kvůli NATu páchat škody, snažil bych se je omezit na co nejmenší možnou oblast, tj. nejdál do DNS a dál už ne.

Interním CA právě žádnou škodu síti nezpůsobíte.

S tou IPv6 bych byl opatrný. Až se začne dostávat mezi širokou veřejnost, způsobí to ještě nejednu komplikaci. Za léta s IPv4 NAT si všichni zvykli, že zvenčí je interní zařízení neadresovatelné. Dnes se zase setkáváte často s IPv6 bastly, kde kdo Vám nepřidělí ani /56 prefix. Už jsem viděl i pokusy o spojovačky /126 apod. To myšlení se bude měnit, odhaduji, dalších 15 let.

Interním CA právě žádnou škodu síti nezpůsobíte.
Ale způsobíte. Naučíte uživatele, že mají bezmyšlenkovitě odklikávat varování o certifikátech. Vystavíte je nebezpečí vystavení falešných certifikátů pro nejrůznější adresy – státní instituce, banky, poskytovatele cloudových služeb… A zkomplikujete procesy tam, kde se někdo bude snažit dostat interní autoritu mezi důvěryhodné.

Za léta s IPv4 NAT si všichni zvykli, že zvenčí je interní zařízení neadresovatelné.
Vtipné je, že tuhle větu píšete po té, co jste psal o nejedné komplikaci. Jak se říká, člověk si zvykne i na šibenici, ale zrovna na tenhle zvyk – že musejí používat nejrůznější triky, aby se dostali ke svému zařízení – lidé zapomenou velice rychle. To je jako kdybyste argumentoval tím, že si lidé zvykli, že telefonní šňůra má maximálně metr a půl. Nezdá se, že by jim ten zvyk nějak bránil v adopci mobilních telefonů.

Naučíte uživatele, že mají bezmyšlenkovitě odklikávat varování o certifikátech.

Když si vytvoříte interní CA, naimportujete její kořenový certifikát a právě nic vyskakovat nebude. Na rozdíl od self signed certifikátů, tuto operaci provedete jednou na počítači, a ne pro každý interní web zvlášť. Ve Windows sítích CA máte automaticky, stačí si vyžádat certifikát (a ano, SAN to podporuje).

To už jsem vám vysvětloval dnes v 16:49. Od té doby se situace nezměnila.

@Filip Jirsák

Tak nevím, CA na Windows Serveru je asi šest kliknutí. Povolit SAN jsou asi dva příkazy. V 16:49 jste psal něco o správné konfiguraci a složitosti a nemožnosti SAN, ale to prostě není pravda.

V 16:49 jsem toho napsal mnohem víc. Za to jsem ale nepsal nic o nemožnosti SAN.

Ano, psal jste tam spoustu bludů, které podle mě vycházejí z toho, že vůbec nic nevíte Windows CA ve Windows doméně, o které jsem psal.

Bludy tady píšete akorát vy. Já jsem o možnostech Windows CA nepsal nic. Napovím vám – třeba Firefox není součástí Windows CA.

Pokud máte v místní síti firefox, docela jistě musíte řešit opičárnu i s dalšími CA.

Nemusím. Předinstalované seznamy důvěryhodných certifikačních autorit ve Firefoxu, v Linuxových distribucích, ve Windows, v Javě, v Docker obrazech i v dalších systémech jsou dostatečné, jediný problém dělají interní certifikační autority, jejichž certifikáty musíte na všechna tahle místa dostat/dostávat.

Předinstalované seznamy důvěryhodných certifikačních autorit ve ... jsou dostatečné, jediný problém dělají interní certifikační autority, jejichž certifikáty musíte na všechna tahle místa dostat/dostávat.

Nevím, přijdete mi odtržený od praxe. Seznamy důvěryhodných CA se mění, přibývají a odstraňují se. To, co píšete, platí v době instalace, případně u systému, který je aktualizován (aktualizovatelný). V praxi ale honíte odzkoušený docker, starou verzi Javy, často i starý Firefox, kvůli požadavkům prostředí. Takže se stejně práci s úložištěm nevyhnete.

To, co navrhujete, bych se asi snažil zavést v novém prostředí, ale v pravdě, nepotkal jsem za svoji praxi prostředí, kde by mohlo být vše ideální. Proto se volí kompromisy mezi bezpečností, aktualizacemi, testováním a během.

V praxi jsem u žádných aplikací, které jsem vyjmenoval, nenarazil na problém se seznamem důvěryhodných CA – s jedinou výjimkou, a tou byla právě interní CA. Doménové jméno, se kterým byly největší problémy, jsem nechal převést do veřejné domény, validujeme ho pomocí DNS a od té doby nebyl s certifikáty žádný problém. Teda občas v nevýchozím prohlížeči odklikám ta varování u interních webů, ale co, to jsou přece jenom systémy, které firma ani nechce vystavit do internetu, tak je potřeba jejich uživatele naučit, že bezpečnost nemají řešit a mají vše odkliknout… (Bazinga!)

Tolik příklad z praxe. Že to nesedí na vaši teorii, s tím nic neudělám.

To je asi věc názoru, jak se tyto situace mají řešit. Považuji za menší zlo vyřešit interní CA (kterou potřebuji obvykle na víc věcí, než jen na certifikát k intranetu!), než řešit DNS split horizon nebo dvojnat.

Já bych řekl, že si nejprve musíte ujasnit, co vlastně chcete. DNS split horizon nebo dvojitý NAT potřebujete tehdy, pokud má být daná adresa dostupná jak z internetu, tak z intranetu. Jenže aby byla dostupná z internetu, musí mít veřejný DNS záznam. Pak ale zase nemáte problém na něj vystavit certifikát třeba od Let's Encrypt. A nebo ta adresa v současné chvíli je z nějaké lokální domény (což byl původní dotaz na začátku vlákna), pak je logicky dostupná jen z intranetu. Tudíž když ji změníte na veřejné DNS jméno, abyste na ni mohl vystavit uznávaný certifikát, nemusíte řešit žádný DNS split horizon nebo dvojitý NAT, protože vám pořád stačí, aby se ta adresa byla dostupná z intranetu. Do internetu stačí vystrčit jenom ten jeden validační TXT záznam (který vám ovšem v intranetu nijak nepřekáží). Takže jediný obrovský problém, který musíte vyřešit, je za 1) vystavíte A záznam pro tu doménu do internetu, takže kdo bude to jméno znát a přeloží si ho, dostane IP adresu z privátního rozsahu, z čehož by se někdo třeba mohl opupínkovat. Nebo za 2) ten A záznam vystavíte jen do intranetu, na internetu se překládat nebude, tj. DNS server bude vracet NXDOMAIN. Technicky je to sice split horizon, ale možné škody jsou minimální. A nebo můžete zvolit variantu 3), která je sice na palici (protože ke každému hloupému pravidlu existuje způsob, jak ho obejít se zachováním všech pravidel a napácháním mnohem větších škod), ale nejspíš neporušuje žádné RFC – do veřejného DNS dáte pro to jméno CNAME na vaši lokální doménu, která se vám v intranetu bude překládat správně, v internetu se nepřeloží vůbec a v jiných intranetech se třeba také na něco přeloží, o to větší zábava to bude.

A záznam vystavíte jen do intranetu, na internetu se překládat nebude, tj. DNS server bude vracet NXDOMAIN. Technicky je to sice split horizon, ale možné škody jsou minimální.

Ano, já Vám rozumím od začátku, ale myslím si, že ty škody právě tak minimální nejsou. Jako příklady můžu uvést (budu se opakovat):

1. cesťáci s notebooky; do firmy se připojují jen přes VPN - pak musíte pohlídat, že si budou žádat o DNS z VPN, nikoliv z internetu; dá se to řešit default gw do VPN, ale to má taky spoustu nevýhod
2. ladění jakýchkoliv aplikací a problémů: programátoři i oprašovači IT si DNS split horizon nedokáží představit, takže při hledání problémů naleznou příčinu až strašně pozdě (zažil jsem několikrát)

Proti tomu distribuce důvěryhodných kořenových certifikátů je snazší záležitost. Je to i přímočařejší řešení, podmíněné jedním jediným předpokladem: dostat certifikát CA do úložiště. Vaše řešení vyžaduje nastavení DNS, nastavení ACME DNS challenge (+proxy, pokud chcete filtrovat i provoz ven, protože LE ověřovací servery nemají pevně dané IP adresy). Když k tomu přičtete, že často interní CA potřebujete i pro jiné účely než jen pro intranet (např. klientské certifikáty) tak z toho vychází prostě lépe.

Kdybych chtěl naopak využívat možnosti, jaké jsou, a jak by to mělo být, pak bych asi opravdu intranetu dal veřejné jméno, veřejnou adresu (klidně i IPv4 - sehnat se dají, IPv6 ještě snáz) a provoz zvenčí bych utnul na firewallu a v ACL na webserveru. Bohužel, dnes už většina adminu bere NAT a privátní rozsahy jako standard a ne jako my, co ji považujeme za obezličku (a asi oba pamatujeme, kdy bylo běžné mít veřejný IPv4 rozsah ve firmě).

Miroslav Šilhavý: Pořád melete a melete, fakta vás nezajímají, komentáře ostatních ignorujete. Cesťáci s notebooky se snad k vaší intranetové doméně připojí i bez VPN? Nepřipojí. Prostě jen blábolíte.

Cesťáci s notebooky se snad k vaší intranetové doméně připojí i bez VPN? Nepřipojí.

Nevynutíte, aby pro veřejnou doménu zasílali DNS požadavky na DNS ve VPN. Pokud se jedná o lokální doménu, tak do VPN požadavek spadne. Pokud o veřejnou, není to zajistitelné spolehlivě bez GW do VPN.

Miroslav Šilhavý: Jasně, lokální router se dívá do paketu, zjistí, že je to DNS dotaz na lokální doménu, tak nahodí VPN, paket zaNATuje a pošle do VPN. Vidím, že už jste se rozhodl na seriózní diskusi rezignovat a jenom se bavíte tím, zda vymyslíte ještě větší nesmysl, než před tím.

Mal by som k tomu par postrehov:

Co sa tyka moznosti internou CA vygenerovat crt trebars pre google.com, na to je jednoduche riesenie. Staci aby ten CA certifikat obsahoval name contraint obmedzene na .local. Podpora klientov sice nie je sie zatupena na 100%, ale vacsina modernych prehladacov v tomto smere funguje tak ako ma. Teda az na safari, ale kto normalny to pouziva...

Co sa tyka VPN, je idealne ak ma klient svoj certifikat, v tomto smere je interna CA neocenitelna. Co sa tyka sietovania okolo VPN je to na obsiahlu diskusiu, ale pre cloveka ktory vie ako to ma fungovat je nastavenie laptopu pre cestaka skor rutina.

Co sa tyka verejnych nazvov... zvolime aj pre kazde zariadenie verejnu ip alebo budeme do verejnych DNS pchat ip adresy z lokalnych rozsahov? Odpoved je myslim jasna.

Co sa tyka verejnych nazvov... zvolime aj pre kazde zariadenie verejnu ip alebo budeme do verejnych DNS pchat ip adresy z lokalnych rozsahov? Odpoved je myslim jasna.
Odpověď byla hned v prvním komentáři, ale podrobněji jsem pak pro pana Šilhavého možnosti rozepsal včera v 19:14. Nemám problém ani s DNS split horizon, ani s privátními IP adresami, ani jedno ničemu neublíží. Druhá varianta je sice v rozporu s RFC, ale holt IPv4 adresy už dávno došly, takže se hledají způsoby, jak to obejít – běžně se používá NAT, což je mnohem větší zlo, než privátní IP adresy ve veřejném DNS.

@Filip Jirsák

Vymýšlíte složité ptákoviny s různými nedomyšlenými dopady, navrhujete zasahovat do nastavení sítě - a to vše jen kvůli kvaziproblému s importem CA do úložiště. Fungovat to bude, ale je to prostě fuj řešení.

Miroslav Šilhavý: Zase špatně, zase si vymýšlíte. O zasahování do nastavení sítě jsme nic nepsal. Nedomyšlené jsou vaše nápady, když si vymýšlíte ptákoviny, že se lokální DNS resolver vzdáleného uživatele bude rozhodovat na základě toho, jakou doménu má překládat, který server použije.

Pokud máte jen pracovní stanice s Windows, kde se používá jen Edge nebo MSIE, problém s instalací CA opravdu není. Jenže v některých sítích se toho vyskytuje víc – mobilní telefony, linuxové a unixové servery, počítače a telefony hostů, různé serverové aplikace…

běžně se používá NAT, což je mnohem větší zlo, než privátní IP adresy ve veřejném DNS

Nat je naopak vynikajuca vec ak s tym vie clovek spravne pracovat. Preto mame aj lokalne rozsahy ip, ci uz je to 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 alebo fe80::/10.

Lokalne adresy vo verejnom DNS. Hm, naco reverzne zaznamy, vsak. Pretoze pochybujem ze by sa niekomu z vonka podarilo zapisat do reverznej zony pre lokalne rozsahy...

Je stastie ze rfc k tymto veciam pisu ludia ktory nie su zatazeny bludmi ;)

Nat je naopak vynikajuca vec ak s tym vie clovek spravne pracovat.
Sádra na ruce je taky vynikající věc, ale ještě lepší je nemít ruku vůbec zlomenou. NAT je totiž hlavně zbytečná věc – používá se v drtivé většině případů jenom jako způsob, jak obejít to, že je nedostatek IPv4 adres. Kdyby bylo dost IPv4 adres a NAT vůbec neexistoval, nic by se nestalo.

Preto mame aj lokalne rozsahy ip, ci uz je to 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 alebo fe80::/10.
Zaměňujete příčinu a následek. Nejprve tu byly privátní rozsahy, a teprve pak se (díky jejich existenci a kvůli nedostatku IPv4 adres) začal používat NAT. Účel privátních rozsahů byl původně úplně jiný.

Lokalne adresy vo verejnom DNS. Hm, naco reverzne zaznamy, vsak.
Já si myslím, že prohlížeč pro přístup k webu žádné reverzní DNS záznamy nepotřebuje. Ale vy asi znáte nějaký důvod, proč jsou u intranetového webu reverzní záznamy potřeba.

Je stastie ze rfc k tymto veciam pisu ludia ktory nie su zatazeny bludmi ;)
Je smutné, že dnešní správci sítí už ani nevědí, jak vypadá Internet. Fakt se toho nemusíte bát – to, že je každé zařízení připojené k Internetu routovatelné z libovolného jiného zařízení připojeného k Internetu, není nic nenormálního, nemusíte se bát o tom byť jen přemýšlet. Fungovalo to tak dříve a zase to tak fungovat bude, protože je to krásně jednoduché.

NAT je totiž hlavně zbytečná věc
Taci si precitat 2 odstavec z rfc1918 - motivation. Mimo ine je tam aj to ze pri niektorych sietach je ziaduce aby neboli pristupne z internetu. Ale kedze sem tam treba updatovat servre tak je naopak potreba aby s tejto siete do internetu pristup bol. Napada vas iny sposob ako dnat? Rad sa necham poucit. A nejake to podupavanie hysterickeho decka, ktore musi mat za kazdu cenu pravdu ma moc nezaujima.

Nejprve tu byly privátní rozsahy, a teprve pak se (díky jejich existenci a kvůli nedostatku IPv4 adres) začal používat NAT
Tym som si nie tak celkom isty. Aspom podla datumov vydania rfc1918 a rfc1631... podla toho to vyzera ze nat je cca o 2 roky starsi ako privatne rozsahy.

Já si myslím, že prohlížeč pro přístup k webu žádné reverzní DNS záznamy nepotřebuje.
Ak je vas jediny nastroj prehliadac, tak to by mnoho vasich domienok vysvetlovalo.

Je smutné, že dnešní správci sítí už ani nevědí, jak vypadá Internet.
Ja pamatam este BBSky. A prva klavesnica za ktorou som sedel bola terminal od PDP11 ;)

17. 2. 2020, 18:52 editováno autorem komentáře

Musim sa opravit: rfc1918 nahradzuje rfc1597, ktore ma rovnaky datum ako rfc1631... teda privatne rozsahy a nat su rovnako stare. Moja chyba. Ale to stale neznamena ze nat je zbytocny - umoznuje korektny pristup z privatneho rozsahu do rozsahu s unikatnimi IP.

Je smutné, že dnešní správci sítí už ani nevědí, jak vypadá Internet.

Mimo ine je tam aj to ze pri niektorych sietach je ziaduce aby neboli pristupne z internetu. Ale kedze sem tam treba updatovat servre tak je naopak potreba aby s tejto siete do internetu pristup bol. Napada vas iny sposob ako dnat? Rad sa necham poucit
To, aby nebyly přístupné z internetu, řeší firewall, nikoli NAT. Privátní rozsahy jsou určené pro zařízení, která nepotřebují komunikovat přes internet, nebo kterým stačí vybrané služby. Máte to vtom RFC 1918 v sekci Motivation napsané – když už jste ji zmínil, mohl jste si ji přečíst. A způsob, jak to zajistit pro ta zařízení, která některé služby potřebují? Třeba tu aktualizaci? Proxy server. Opět je to napsané v tom RFC (akorát tam to nazývají application layer gateway). Žádný NAT k tomu nepotřebujete.

Ak je vas jediny nastroj prehliadac, tak to by mnoho vasich domienok vysvetlovalo.
Pokud si neumíte přečíst vlákno, ve kterém reagujete, vysvětluje to, proč je váš komentář tak hloupý.

Ja pamatam este BBSky. A prva klavesnica za ktorou som sedel bola terminal od PDP11 ;)
Škoda, že si nepamatujete také to, jak vypadal internet bez NATů a jaké se používaly technologie.

Ale to stale neznamena ze nat je zbytocny - umoznuje korektny pristup z privatneho rozsahu do rozsahu s unikatnimi IP.
Což je přesně to, k čemu původně privátní rozsahy nebyly určené.

Navíc já jsem nepsal, že NAT je zbytečný sám o sobě, polemizoval jsem s tím, že NAT je skvělá věc. Napsal jsem, že prakticky jediná jeho funkce je obcházet problém – nedostatek IPv4 adres. Když nebude problém, nebude ani potřeba NATu. Jako s tou sádrou na ruce – když máte zlomenou ruku, je sádra dobrá věc, ale lepší je nemít ruku zlomenou.

Proxy server.
Proxy - to ale predpoklada ze obe strany ktore proxy obsluhuje maju implementovane SOCKS. Naproti tomu NAT funguje na transportnej vrstve. Viacmenej ak budete potrebovat pouzit aplikaciu alebo zariadenie ktore socks nepodporuju tak sa natu nevyhnete. Je nejaka vyhoda proxy oproti natu? Preco mat nieco co bezi na aplikacnej vrstve a nie na transpornej vrstve. Ostatne aj to je dovod preco nemaju routery proxy ale maju maskaradu vo firewalli.

Pokud si neumíte přečíst vlákno, ve kterém reagujete, vysvětluje to, proč je váš komentář tak hloupý.
Myslim ze postaci ak odcitujem to na co som reagoval: Já si myslím, že prohlížeč pro přístup k webu žádné reverzní DNS záznamy nepotřebuje. Ale vy asi znáte nějaký důvod, proč jsou u intranetového webu reverzní záznamy potřeba. Ak si vytvorite lokalny kontex, tak by bolo tak nejako divne aby som v nom zohladnoval globalne cele vlakno. Alebo mi nieco uslo a vo vlakne sa cely cas pisalo len o webe. Asi si ho precitam cele este raz, aby som sa uistil ci sa nemylim. Vam by som to odporucal rovnako, teda ak ste ochotny sa presvedcit ci sa memylite a uznat si to.

Škoda, že si nepamatujete také to, jak vypadal internet bez NATů a jaké se používaly technologie.
Vzdy ma potesi ak stretnem niekoho kto o mne vie viac nez ja sam :) Ja mam psychologiu ale len ako konicek, prax necham radsej odbornikom, i v pripade ze sa jedna o diskusiu.

Což je přesně to, k čemu původně privátní rozsahy nebyly určené.
Ano, povodne boli privatne rozsahy urcene pre privatne siete, ale ako si sa ukazalo ze aj tieto casto potrebuju pristup do globalnej siete.

Napsal jsem, že prakticky jediná jeho funkce je obcházet problém – nedostatek IPv4 adres
To iste by sa dalo tvrdit o proxy, tiez mu staci jedna verejna adresa, akurat ma nevyhodu ze nefunguje s hociakou aplikaciou.

když máte zlomenou ruku, je sádra dobrá věc, ale lepší je nemít ruku zlomenou
Ja pouzijem zavedenejsie prirovnanie: Zbytocne strielate kanonom na vrabce.

Proxy - to ale predpoklada ze obe strany ktore proxy obsluhuje maju implementovane SOCKS.
Nikoli. Předpokládá to, že klient umí nějakým způsobem komunikovat s proxy serverem. Vy jste psal o aktualizacích systému, ty se dnes obvykle stahují přes HTTPS, dříve případně přes FTP. Snad všichni HTTP i FTP klienti umějí komunikovat přes HTTP proxy.

Naproti tomu NAT funguje na transportnej vrstve.
Což nic neznamená. Některé protokoly například přenášejí v aplikačních datech IP adresu. V případě NATu se to musí nějak obcházet – použít variantu protokolu, která to nedělá, na NATu měnit až na úrovni aplikačního protokolu i tu přenášenou IP adresu apod. Pro vaši informaci, tu IP adresu přenáší i protokol FTP ve svém původně nejpoužívanějším aktivním módu. A protokol FTP se hojně používal mimo jiné právě pro stahování distribučních balíků. Samozřejmě, že stejný problém budete mít i s proxy serverem, jenom poukazuju na to, že NAT není bezproblémové řešení.

Viacmenej ak budete potrebovat pouzit aplikaciu alebo zariadenie ktore socks nepodporuju tak sa natu nevyhnete.
Vzhledem k tomu, že neznáte fakta, neměl byste se pouštět do unáhlených závěrů.

Je nejaka vyhoda proxy oproti natu?
Například ta, že na proxy serveru můžete mnohem lépe řídit provoz. Přístup přes proxy server může být autentizovaný, můžete na něm povolit přístup jen k určitému doménovému jménu. Třeba pro ty servery povolíte na proxy serveru jenom přístup k serverům s distribučními balíčky a nikam jinam. To s NATem neuděláte – NAT nevidí DNS názvy, jen IP adresy.

Alebo mi nieco uslo a vo vlakne sa cely cas pisalo len o webe.
Ono se celou dobu píše jenom o webu nejenom v tomto vlákně, ale v celé diskusi. Řekl bych, že to bude mít něco společného se slovy „webový server“, která jsou v nadpisu článku.

Asi si ho precitam cele este raz, aby som sa uistil ci sa nemylim.
Ano, to vám doporučuju. Ve zkratce – původní dotaz na začátku vlákna byl: „Mám server v intranetu, který nemá veřejné doménové jméno. Je možné pro něj nějak vystavit důvěryhodný certifikát?“ Mnou navržené řešení s reverzními DNS záznamy nijak nemanipuluje, tj. pokud měl ten server původně nastavený reverzní DNS záznam, bude úplně stejně fungovat i nadále. Jediná věc je ke zvážení – pro server nemusíte zachovávat původní intranetový název, můžete server na veřejný název přejmenovat (místo vytvoření přezdívky). V takovém případě je potřeba změnit i ten název, na který ukazuje reverzní DNS záznam. Záznam ale pořád zůstane v intranetové reverzní zóně.

Ano, povodne boli privatne rozsahy urcene pre privatne siete, ale ako si sa ukazalo ze aj tieto casto potrebuju pristup do globalnej siete.
Tak příště neargumentujte RFC, kde se píše to, co tvrdím já.

To iste by sa dalo tvrdit o proxy
Tvrdit by se to dalo, třeba vy byste to tvrdit mohl, ale není to pravda. Proxy servery se používaly a používají i tam, kde jsou jen veřejné IP adresy. Dají se použít např. pro řízení přístupu. Nebo můžete pomocí proxy serveru bezpečně zpřístupnit pomocí aktuálních verzí protokolu HTTPS nějaké bláznivé zařízení, které umí jen HTTP nebo HTTPS se SSLv3. A tak dále.

akurat ma nevyhodu ze nefunguje s hociakou aplikaciou
Vzhledem k tomu, jak se postupně víc a víc blížíme k Internet-over-HTTPS (mimo jiné a kvůli NATům), těch aplikací nepodporujících proxy servery je čím dál méně.

Ja pouzijem zavedenejsie prirovnanie: Zbytocne strielate kanonom na vrabce.
Myslíte, že nedostatek IPv4 adres je vrabec a NAT je kanón? Bylo by fajn, kdyby to tak bylo, a kdyby zavedení IPv6 bylo mnohem jednodušší řešení, než používat NAT. Bohužel si to ale spousta správců nemyslí.

Ono se celou dobu píše jenom o webu nejenom v tomto vlákně, ale v celé diskusi. Řekl bych, že to bude mít něco společného se slovy „webový server“, která jsou v nadpisu článku.
httpd server(laicky apache, pod touto hlavickou existuje mnoho dalsieho software) sice primarne komunikuje cez http protokol v1, ktory pouzival prvy browser vobez nazvany worldwideweb, skratene web, ale myslim ze my sme sa skor bavili v suvislosti s tls protokolom (certifikaty od le nemusi vyuzivat len http serrver ale mozete ich napr pouzit aj pre postfix). Naviac openssl pomocou ktoreho si ziskate certifikat serveru s httpd asi nebude komunikovat cez webovy protokol, ale je mozne ze sa len zase mylim...

Vy jste psal o aktualizacích systému, ty se dnes obvykle stahují přes HTTPS, dříve případně přes FTP.
Ak by bolo vsetko v rpm repozitari, a memusel pouzivat aj ine sluzby tak by bol moj pohlad rovnako ruzovy. Mne vsak nestaci holy server ktory je aktualny, rovnako potrebujem aj aktualne aplikacie ktore na tom servri bezia.

Mnou navržené řešení s reverzními DNS záznamy nijak nemanipuluje, tj. pokud měl ten server původně nastavený reverzní DNS záznam, bude úplně stejně fungovat i nadále.
Uz vidim ako napriklad automobilka aktualizuje klientov u vsetkych autorizovanych servisov tak aby boli vo formate ktory by sa pacil prave Vam. Pripadne napada vas nejaky jednoduchy sposob ako hromadne aktualizovat konfigy s domenovymi menani v rozsiahlej intranetovej sieti tak aby nebol naruseny chod celeho systemu?
Naviac, mudrujete tu zbytocne o kope veci ale k jednej s namietok ste sa nevyjadril. Ak potrebujem aby klient bol voci serveru overeny certifikatom a nie len server oproti klientovi, tak bud si zaplatite drahy certifikat ktory vam umozni podpisovat klientske certifikaty alebo pouzijete privatnu CA.

Myslíte, že nedostatek IPv4 adres je vrabec a NAT je kanón? Bylo by fajn, kdyby to tak bylo, a kdyby zavedení IPv6 bylo mnohem jednodušší řešení, než používat NAT. Bohužel si to ale spousta správců nemyslí.
Verim ze mi nevkladate slova ktore som nepovatl do ust zamerne, dost by ma to rozladilo ;) Kedze ale predpokladam ze ste to len nepochopil tak vysvetlim: Tym kanonom na vrabce je pouzitie proxy tam kde proste staci nat.

Vzhledem k tomu, jak se postupně víc a víc blížíme k Internet-over-HTTPS (mimo jiné a kvůli NATům), těch aplikací nepodporujících proxy servery je čím dál méně.
Je zrejme ze NAT zatracujete koli tomu ze vobec nechapte ako funguje, NAT samotny vam neodoprie sa pripojit na akykolvek port serveru ktori lezi vonku, toto uzivatelom zakazete len pomocou firewallu alebo pomocou prave proxy. Cize internetu over https skor mozete podakovat spravcom, ktory to dalej ako na spravcu nedotiahli a maju z dovodu komplexu menejcennosti potrebu nastavovat nezmyselne pravidla na proxy. Nat je v tom uplne nevinne...

Tak příště neargumentujte RFC, kde se píše to, co tvrdím já.
Tak si to rfc skuste precitat este raz, je v nom konstatovane ze niektore velke firmy pouzivaju brany na aplikacnej vrstve a nasleduje doporucenie k tomuto prikladu. Pripadne mozete mi poslat link? Myslim ze napisat fragment url adresy nebude pre vas problem napisat tak aby odkazoval na odstavec kde je vymedzeny vyhradne sposob komunikacie internej a externej siete na proxy a kde je odmitane ine riesenie, napr nat.

Vzhledem k tomu, že neznáte fakta, neměl byste se pouštět do unáhlených závěrů.
To ste adresoval sebe? Pretoze asi tazko poznate fakt ci niekto potrebuje pouzivat aplikaciu ktora nepodporuje socks. Inak by ste s tymto zaverom pockal az bude zrejme ze nikto taku aplikaciu nepotrebuje.

httpd server(laicky apache, pod touto hlavickou existuje mnoho dalsieho software) sice primarne komunikuje cez http protokol v1, ktory pouzival prvy browser vobez nazvany worldwideweb, skratene web, ale myslim ze my sme sa skor bavili v suvislosti s tls protokolom (certifikaty od le nemusi vyuzivat len http serrver ale mozete ich napr pouzit aj pre postfix). Naviac openssl pomocou ktoreho si ziskate certifikat serveru s httpd asi nebude komunikovat cez webovy protokol, ale je mozne ze sa len zase mylim...
No, mýlíte se skoro ve všem, co jste v tomto odstavci napsal. Oficiální název toho serveru, pokud na něm trváte, je Apache HTTP Server. „Apache“ není žádný laický název, je to původní název toho serveru – původně existoval patch (tedy „a patch“) na předchozí webový server (jeho jméno z hlavy nevím, můžete si to vygooglit), proto byl následně server pojmenován Apache. To „mnoho dalšího software“ pod hlavičku Apache přibylo až mnohem později. Apache komunikuje protokoly HTTP 1.0 (myslím, že stále ještě zvládne i 0.9), HTTP 1.1 a HTTP 2.0, všechny verze umí v šifrované i nešifrované variantě (tedy HTTPS i HTTP). Protokoly HTTP a HTTPS podporují všechny webové prohlížeče a mnoho dalších nástrojů a programů. World Wide Web byl a je název sítě internetových stránek, první prohlížeč byl „pojmenován“ podle této sítě. Nebavili jsme se v souvislosti s TLS obecně – ještě jednou si přečtěte nadpis článku, případně celý článek – je jenom o HTTPS. Pro získání certifikátu z HTTPS serveru opravdu nepotřebujete OpenSSL. Dokonce žádný z běžně používaných prohlížečů OpenSSL nepoužívá, Firefox má vlastní SSL knihovnu, Google pro Chrome používá fork BoringSSL a Microsoft má také vlastní implementaci. Certifikát se nezískává žádným zvláštním protokolem – certifikát se přenáší na začátku TLS spojení. Takže když se bavíme o protokolu HTTPS, certifikát se přenese na začátku, když se ustavuje šifrovaný kanál (TLS) – konkrétně v TLS zprávě „server hello“, což je první zpráva, kterou posílá server (jako odpověď na „client hello“, kterou začíná TLS spojení).

Ale i kdybychom se bavili o TLS obecně – SMTP server v intranetu asi nebude potřebovat vybavit důvěryhodným certifikátem. Nicméně i kdybyste měl v intranetu server, jiný než HTTPS a zároveň byste ho potřeboval vybavit důvěryhodným certifikátem – popisoval jsem několik variant, v jedné tomu serveru dáte veřejnou IPv4 adresu a pak normálně nastavíte reverzní záznam pro tuhle veřejnou IPv4 adresu, v jiných variantách zůstane serveru IPv4 adresa z privátního rozsahu, takže s reverzním DNS záznamem nemusíte dělat nic, pořád to bude fungovat stejně, jako předtím.

Mne vsak nestaci holy server ktory je aktualny, rovnako potrebujem aj aktualne aplikacie ktore na tom servri bezia.
Asi vás to překvapí, ale v distribučních repozitářích najdete spoustu aplikací. A i pokud tam tu vaši aplikaci nenajdete – můžu se zeptat, jakým protokolem ty jiné aplikace na váš server stahujete? Přes Gopher? (Pokud je tam nahráváte přes SFTP, není to komunikace navazovaná ze serverů ven, ale naopak na ty servery. A asi tam ten software nepotřebujete nahrávat přes internet, bude vám stačit přístup z intranetu.)

Pripadne napada vas nejaky jednoduchy sposob ako hromadne aktualizovat konfigy s domenovymi menani v rozsiahlej intranetovej sieti tak aby nebol naruseny chod celeho systemu?
Ano, napadá mne jeden způsob, jak nemuset distribuovat doménová jména pomocí konfiguračních souborů. Přesně z tohohle důvodu byl vymyšlen protokol DNS. Už je to nějaký ten pátek, co tenhle protokol existuje, docela se osvědčil a používá se dost často.

Naviac, mudrujete tu zbytocne o kope veci ale k jednej s namietok ste sa nevyjadril.
Ale kdepak, k námitkám jsem se vyjádřil. A pak jsem vám vysvětlil spoustu věcí, ve kterých plavete.

Ak potrebujem aby klient bol voci serveru overeny certifikatom a nie len server oproti klientovi, tak bud si zaplatite drahy certifikat ktory vam umozni podpisovat klientske certifikaty alebo pouzijete privatnu CA.
Klientskou autentizaci certifikátem jste sem teď poprvé zavlekl vy. Mimochodem, reálně se tahle autentizace používá čím dál méně, protože podpora v prohlížečích (zejména UX) není moc dobrá. Ale když ji budete chtít použít, nic vám v tom nebrání – narazili jsme tu totiž na další vaši neznalost, a totiž tu, že klientský autentizační certifikát nijak nesouvisí s tím serverovým. Takže serverový certifikát klidně můžete být důvěryhodný od Let's Encrypt, a klientské certifikáty použijete od vlastní certifikační autority.

Je zrejme ze NAT zatracujete koli tomu ze vobec nechapte ako funguje
To je od vás velmi odvážné tvrzení.

Uz vidim ako napriklad automobilka aktualizuje klientov u vsetkych autorizovanych servisov tak aby boli vo formate ktory by sa pacil prave Vam.
Vidím, že jste konečně pochopil, že píšete nesmysly, a raději jste se přiklonil na mou stranu. Ano, právě proto aby ta automobilka nemusela všem autorizovaným servisům nutit svou certifikační autoritu, použije raději důvěryhodný certifikát.

NAT samotny vam neodoprie sa pripojit na akykolvek port serveru ktori lezi vonku
Je vidět, že vaše představa i Internetu už je velmi omezená, deformovaná NATem. Víte, ona komunikace nemusí být navazovaná jenom z vnitřní sítě ven, ale i opačným směrem. A tam už je NAT docela překážkou. Samozřejmě, že když omezíte komunikaci jen na TCP/IP spojení navazované z vnitřní sítě do internetu na jednom standardním portu, vzniká otázka, proč používat různé protokoly – a tak právě vzniká ten Internet-over-HTTP.

Tak si to rfc skuste precitat este raz, je v nom konstatovane ze niektore velke firmy pouzivaju brany na aplikacnej vrstve
Ano, některé firmy používají proxy servery – což jsem tu já psal a vás to hrozně překvapilo. Opět jste potvrdil, že v RFC je psáno to samé, co tu tvrdím.

Myslim ze napisat fragment url adresy nebude pre vas problem napisat tak aby odkazoval na odstavec kde je vymedzeny vyhradne sposob komunikacie internej a externej siete na proxy a kde je odmitane ine riesenie, napr nat.
Teď jste tu část sám parafrázoval. A RFC 1918 jste jako první odkazoval vy – neměl jste si nejprve přečíst to, co jste odkazoval? NAT v tom RFC vysloveně odmítnutý není, ale ani se o něm nepíše. A je v rozporu s tím, co je popsané v motivaci. Konkrétně si přečtěte v kapitole 2 Motivace rozdělení do tří kategorií. První kategorie jsou sítě, ve kterých zařízení vůbec nepotřebují komunikovat s okolním světem. Druhá kategorie jsou sítě, kde zařízení potřebují komunikovat s omezeným množstvím služeb, a to lze zařídit (při použití privátních rozsahů IPv4 adres) pomocí proxy serverů, které ty vnější služby zpřístupní. A třetí kategorie jsou zařízení, která potřebují plný přístup do internetu – tato zařízení potřebují IP adresy, které jsou globálně nezaměnitelné. Tudíž nemohou používat IP adresy z privátních rozsahů, o kterých pojednává RFC 1918. Celé RFC je o tom, jak zařízení z různých kategorií zkombinovat do jedné sítě a jak tyto privátní IPv4 adresy používat. Všimněte si, že tam nikde není zmínka o NATu, a že se v celém RFC předpokládá to, že když máte zařízení z kategorie 3, přidělíte mu veřejnou IPv4 adresu, ne privátní. Takže žádný NAT nepotřebujete. Nebo-li je to přesně tak, jak jsem psal prve – NAT pro přístup z privátních IPv4 adres do internetu je zneužití těchto adres, je to v rozporu s RFC 1918, protože to předpokládá pro zařízení z kategorie 3 veřejné IPv4 adresy. Samozřejmě dnes je jiná doba a nezbývá, než tohle RFC porušovat. Ale je dobré si uvědomovat, že děláme něco špatně, a že je to jen méně špatné řešení – a ne z toho dělat bůhvíco dobrého, jak to děláte vy.

To ste adresoval sebe?
Ne, vám. Když porovnám vaše a svoje komentáře, ty vaše jsou znalostmi sítí někde tak na úrovni první třídy ZŠ, moje někde na úrovni maturanta. Chápu, že s vašimi znalostmi je obtížné to rozpoznat.

Pretoze asi tazko poznate fakt ci niekto potrebuje pouzivat aplikaciu ktora nepodporuje socks
Je hezké, že jste se v první třídě dozvěděl o protokolu SOCKS. Nicméně já už jsem vám vysvětloval, že existují i jiné a používanější protokoly pro komunikaci s proxy serverem. Vraťte se k mým předchozím komentářům a dostudujte si to. Ať postoupíte alespoň do druhé třídy.

Mimochodem, protokol SOCKS nemusí být podporován přímo aplikací, může ho implementovat i socket knihovna. Dříve takové řešení nebylo úplně výjimečné. Ostatně proto se ten protokol jmenuje SOCKS, je to proxy pro sockety… Dalo by se to udělat i s HTTP proxy (která má omezenější možnosti, ale pro spoustu aplikací by to stačilo), ale to se nepoužívalo, alespoň ne tak často.

No, mýlíte se skoro ve všem, co jste v tomto odstavci napsal. Oficiální název toho serveru, pokud na něm trváte, je Apache HTTP Server.
httpd sa ten server nazyval aj pred tym ako vznikla nadacia apache.
Ako funguje ssl handchaking mi vysvetlovat nemusite, zopar(teda skor vcelku dost) aplikacii s pouzitim socketov som uz programoval.
Openssl mozete pouzit ak chcete ziskat certifikat serveru. Bez toho aby ste musel spustit browser.

(Pokud je tam nahráváte přes SFTP, není to komunikace navazovaná ze serverů ven, ale naopak na ty servery. A asi tam ten software nepotřebujete nahrávat přes internet, bude vám stačit přístup z intranetu.
Asi ste myslel SCP. SFTP a SCP su diametralne odlisne zalezitorti ;) Mozno viete ze ssh vam po prihlaseni nemusi spustit len shell, odporucal by som si prestudovat moznosti authorized_keys... napr. git proti gitolite na servri...

Vidím, že jste konečně pochopil, že píšete nesmysly, a raději jste se přiklonil na mou stranu. Ano, právě proto aby ta automobilka nemusela všem autorizovaným servisům nutit svou certifikační autoritu, použije raději důvěryhodný certifikát.
Preco by som sa v tejto oblasti ktora mi je znama z praxe mal priklanat k teoretikovi z iluzorneho vesmiru.

Je vidět, že vaše představa i Internetu už je velmi omezená, deformovaná NATem. Víte, ona komunikace nemusí být navazovaná jenom z vnitřní sítě ven, ale i opačným směrem. A tam už je NAT docela překážkou. Samozřejmě, že když omezíte komunikaci jen na TCP/IP spojení navazované z vnitřní sítě do internetu na jednom standardním portu, vzniká otázka, proč používat různé protokoly – a tak právě vzniká ten Internet-over-HTTP.
Dalsi dovod si mysliet ze danej problematike vobec nerozumiete. V pripade natu existuje okrem DNATu (maskarady) aj SNAT ktory Vam umozni namapovat vonkajsie porty do internej siete. Ale vcelku mi unika dovod preco by niekto umiestnoval server ktory ma byt pristupny verejne do intranetu. Asi zpackana aplikacia na ktoru je lepsie nesiahat na aktualnom servri, nie to ju sprevadzkovat na inom servri.

Ne, vám. Když porovnám vaše a svoje komentáře, ty vaše jsou znalostmi sítí někde tak na úrovni první třídy ZŠ, moje někde na úrovni maturanta. Chápu, že s vašimi znalostmi je obtížné to rozpoznat.
Nemlati Vase ego hlavou o veraje dveri ked sa nimi snazite prejst? ;)

Je hezké, že jste se v první třídě dozvěděl o protokolu SOCKS. Nicméně já už jsem vám vysvětloval, že existují i jiné a používanější protokoly pro komunikaci s proxy serverem.
A aky protokol chcete pouzit v pripade HTTPS ak nechcete podvrhovat certifikat? Ak nepouzivate ssl bump tak sa vam ta proxy prepne na transportnu vrstvu.

21. 2. 2020, 19:12 editováno autorem komentáře

Vy jste si dal svazácký závazek, že do každého svého komentáře propašujete alespoň pět nesmyslů?

Apache se nikdy nenazýval „httpd“, od začátku se jmenuje Apache. httpd je jenom název binárky, protože se tak jmenoval i ten předchozí HTTP server, který Apache nahradil. Ve studiu pokračujte zde.

Když jsem napsal SFTP, myslel jsem tím SFTP – a vy při vašich neznalostech máte předpokládat, že je to správně, a vygooglit si to. Tak byste se dozvěděl, že SFTP je protokol pro přenos souborů, který jako rozšíření protokolu SSH 2 nahradil starší protokol SCP. SCP má omezené možnosti a proto se dnes už doporučuje ho nepoužívat, místo něj se používá právě modernější SFTP. Samozřejmě je možné, že někteří „praktici“, kteří nejsou moc v obraze, ale myslí si o sobě bůhvíco, dál používají SCP. Ve studiu pokračujte zde.

Už jsem vám několikrát psal, že vedle protokolu SOCKS existují i jiné protokoly pro komunikace s proxy serverem, například protokol HTTP. Ve studiu pokračujte zde.

Ty hloupé pokusy o poučování si nechte, nemáte na to. Pokaždé, když se mě pokusíte opravit, napíšete jen další nesmysl. Ve studiu pokračujte zde.

21. 2. 2020, 20:10 editováno autorem komentáře

Apache se nikdy nenazýval „httpd“, od začátku se jmenuje Apache. httpd je jenom název binárky, protože se tak jmenoval i ten předchozí HTTP server, který Apache nahradil.
httpd (http daemon) od apchahe neznamena ze sa ten server vola Apache, rovnako ako sa sqlserver nevola microsoft, i ked zvedsa najdete na webe spojenie microsoft sqlserver. Vsimnite si nazvy balickov http://mirror.hosting90.cz/apache/httpd/#binaries

Když jsem napsal SFTP, myslel jsem tím SFTP
V rychlosti som miesto SFTP cital FTPS. Moja chyba. Ale potesilo ze ste si uznal ze balicky nemusia byt distribuovane len cez http alebo ftp. I ked nepriamo, nie kazdy ma na to priznat chybu otvorene.

Už jsem vám několikrát psal, že vedle protokolu SOCKS existují i jiné protokoly pro komunikace s proxy serverem, například protokol HTTP.
To je sice pekne ale ako cez neho pretlacite dalsie protokoly, Pri https sice mozete podvrhovat certifikat, ale fizlovat uzivatelov v dnesnej dobe je dost negativna prax.

Ty hloupé pokusy o poučování si nechte, nemáte na to. Pokaždé, když se mě pokusíte opravit, napíšete jen další nesmysl.
Dunning - krugerov efekt poznam, mozno by ste mohol zacat tym ze by ste si na roote mohol najs aspom 10 prispevkov v ktorych uznavate ze sa mylite. Ak sa vam to nepodari tak by ste si mohol skusit odkazovany clanok precitat z trocha ineho uhla pohladu ;)

Ten server se jmenuje Apache HTTP Server, dříve se nazýval jen Apache server nebo Apache. To HTTP se do názvu přidalo později, když pod Apache Software Foundation začal přibývat další software. Odkaz jsem vám dával. Že neumíte používat Google, to už jsem pochopil. Že pro vás bude problém i kliknout na odkaz, to jsem nečekal.

S SFTP jste vyrobil další botu. Já jsem nikdy nepsal, že balíčky mohou být distribuované jen přes HTTP nebo FTP. Vy jste ovšem psal o stahování balíčků z internetu. Jenže protokolem SFTP nebudete balíčky stahovat (download) z internetu, ale budete je nahrávat (upload) z intranetu. Tím pádem nepotřebujete přístup toho serveru do internetu, což byl ten důvod, proč jste o tom začal psát. Takže svou chybu jsem neuznal, protože jsem žádnou chybu neudělal – popletl jste to opět vy.

Jak skrze HTTP proxy protlačíte další protokoly byste snad i vy pochopil, kdybyste si rozklikl ten odkaz, který jsem vám dával. Když takhle budete tunelovat HTTPS, žádné podvrhování certifikátů se nekoná – to je zase jen váš další nesmysl. A můžete takhle samozřejmě tunelovat i jiné protokoly postavené nad TCP/IP, jinak bych vám nepsal, že je to univerzálně použitelný protokol pro aplikační proxy. Např. můžete HTTP proxy použít pro SSH protokol – HTTP proxy lze použít s OpenSSH klientem (s pomocí např. nc/ netcat a volby ProxyCommand), pod Windows to umí Putty i WinSCP.

Pokud se mýlím, tak to uznám. Ale hlavně nepíšu o věcech, o kterých nic nevím – tím se docela eliminuje to, že bych psal nesmysly. Z čehož následně plyne, že těch omluv nemusí být mnoho. Nicméně tady jde o to, že snad všechny vaše komentáře v této diskusi obsahují nějaký nesmysl. Nějak jsem si nevšiml, že byste se za všechny ty nesmysly omluvil. Místo toho navršíte další nesmysly. Já jsem v této diskusi nenapsal nic, co by bylo špatně.

21. 2. 2020, 21:52 editováno autorem komentáře