Šifrování. Ověřování pravosti a ověřování certifikátů certifikační autoritou

V posledních verzích byly výrazně rozšířeny možnosti zabezpečení systému 4D, zejména v oblasti certifikátů. Patří sem automaticky generované certifikáty pro komunikaci mezi klientem a serverem, podpora certifikátů ECDSA a ve verzi 4D 20 R7 také ověřování platnosti autority certifikátu pro komunikaci mezi klientem a serverem u enginových aplikací. Někteří zákazníci vyžadují nejvyšší úroveň zabezpečení, což podtrhuje důležitost těchto funkcí.

Zabezpečení však může být složité a objevily se požadavky na vysvětlení fungování spojení TLS/SSL a úlohy certifikátů. Proto je užitečné, než se pustíme do nových funkcí, nejprve rozebrat základní pojmy zabezpečení a jejich vzájemné vztahy.

Šifrování, ověřování a certifikáty

Základem zabezpečení jsou dva klíčové pojmy: šifrování a ověřování. Šifrování chrání data tím, že je zakóduje a zabrání tak neoprávněnému přístupu mezi serverem a klientem, zatímco ověřování zajišťuje, že klient i server jsou ti, za které se vydávají. Certifikáty pokrývají oba tyto koncepty, protože se skládají ze dvou prvků (a tedy ze dvou souborů): klíče, který je uchováván jako soukromý a bude použit k šifrování komunikace, a veřejného certifikátu, který se používá k ověření.

symetrické šifrování

Nejjednodušší formou šifrování je symetrické šifrování, kdy klient a server sdílejí stejný klíč k šifrování své komunikace. Symetrické šifrování je výhodné, protože zajišťuje šifrování i autentizaci: server je platný, protože používá správný klíč, a klient je platný ze stejného důvodu. Hlavní nevýhodou symetrického šifrování je nutnost kopírování klíče na serveru i u klienta, což vyžaduje samostatný zabezpečený komunikační kanál.

Asymetrické šifrování

Asymetrické šifrování se široce používá v internetu a funguje na jednoduchém principu: klient i server mají veřejný a soukromý klíč. Veřejný klíč šifruje komunikaci, zatímco soukromý klíč ji dešifruje. Server i klient mohou své veřejné klíče volně šířit bez obav z možného odposlechu, protože veřejný klíč umožňuje pouze šifrování. Bez soukromého klíče není dešifrování komunikace možné.

Ve 4D se asymetrické šifrování používá pro server HTTP, klienta HTTP a komunikaci mezi 4D Serverem a 4D Remote. V případě serveru HTTP musí být certifikát a příslušný klíč umístěn ve složce projektu. Pro komunikaci mezi 4D Serverem a 4D Remote mohou být certifikát a klíč buď uloženy ve složce Resource (Zdroje) 4D Serveru, nebo může 4D Server svůj certifikát vygenerovat automaticky. Klient HTTP a 4D Remote generují své certifikáty automaticky.

Na rozdíl od symetrického šifrování zajišťuje asymetrické šifrování šifrování, nikoli však ověřování. To znamená, že nemůže zaručit, že server, se kterým se komunikuje, je zamýšlený server. Tato zranitelnost může vést k vydávání se za server a k útokům MITM (man-in-the-middle) (kdy útočník zachytí komunikaci mezi klientem a serverem).

Zabránění vydávání se za server a útokům MITM: Ověření platnosti certifikátu autority

Aby se zabránilo útokům typu man-in-the-middle, musí klient a server používat způsob, jak se vzájemně ověřit. V případě klienta se obvykle používá klasický dialog přihlašovacího jména a hesla, protože více než stroj, kterým chcete uživatele ověřit.

Jednou z nejběžnějších metod ověřování serverů je použití certifikátu vydaného důvěryhodnou certifikační autoritou. Certifikační autority jsou celosvětově uznávané subjekty, jejichž podpisy jsou vloženy do aplikací, jako jsou webové prohlížeče. Když server předloží certifikát vydaný certifikační autoritou, klient může ověřit jeho pravost porovnáním uloženého podpisu certifikační autority s podpisem v certifikátu.

Představení ověřování certifikační autority v aplikaci 4D 20 R7

Nyní se podíváme na novou funkci v produktu 4D 20 R7: ověřování platnosti certifikátových autorit pro enginové aplikace. Tato aktualizace umožňuje klientům 4D ověřit certifikát, který obdrží od serveru 4D, čímž je zajištěna identita serveru a ochrana proti útokům typu MITM (man-in-the-middle).

Pro implementaci této funkce je třeba při sestavování klientské aplikace přidat do souboru buildApp.4DSettings dvě hodnoty: umístění souboru obsahujícího podpisy důvěryhodných certifikačních autorit, které budou v klientské aplikaci zkopírovány, a název domény certifikátu serveru. Pomocí těchto informací může klientská aplikace ověřit, zda je certifikát zaslaný serverem vydán platnou certifikační autoritou a zda název domény odpovídá očekávanému. V případě nesrovnalostí bude připojení odmítnuto.

V případech, kdy se jedná o více klientů, může být vytvoření samostatné aplikace pro každého klienta náročné. Pro řešení tohoto problému lze poskytnout seznam platných doménových jmen. Tento přístup je sice méně bezpečný než zadání jediného doménového jména, ale stále vyžaduje, aby případný „muž uprostřed“ vlastnil certifikát jednoho z klientů, což není snadno dosažitelné. Případně lze pole pro název domény ponechat prázdné a v takovém případě bude 4D kontrolovat pouze to, zda certifikát pochází od platné certifikační autority.

Pro aplikace, které komunikují přes internet nebo jiné nedůvěryhodné sítě, nabízí tato funkce základní vrstvu ochrany komunikace mezi klientem a serverem.

Pomoc je vždy k dispozici – neváhejte a napište jakýkoli dotaz do fóra 4D.