NSA proof SSL implementation

8.4.2014 18:24 | Jiné | poslední úprava: 9.4.2014 00:22

#ifndef JardikSSL_h_from_JardikuvNSAProofToolkit
#define JardikSSL_h_from_JardikuvNSAProofToolkit

enum JardikSSL_ERR
{
    JARDIK_SSL_ERR_OK,
    JARDIK_SSL_ERR_SSL_NOT_SECURE
};

enum JardikSSL_CTXTYPE
{
    JARDIK_SSL_CTX_CLIENT,
    JARDIK_SSL_CTX_SERVER
};

struct JardikSSL_CTX;
struct JardikSSL_CERT;

static inline enum JardikSSL_ERR
JardikSSL_CreateContext(struct JardikSSL_CTX **ctx_out,
                        enum JardikSSL_CTXTYPE ctx_type,
                        int socket_fd,
                        struct JardikSSL_CERT *cert)
{
    return JARDIK_SSL_ERR_SSL_NOT_SECURE;
}

#endif

       

Komentáře

[bind]

Máš to blbě.

[bind]

A navíc, ty a ještě ten Debňa jste největší blog-tapetáři zde na abc.

[Bedňa]

Máš tam tlačítko blokovať voe. ↑ ↑ ↑

[xkucf03]

Nejde to přeložit:

$ gcc JardikSSL.c 
JardikSSL.c:16:1: error: expected ‘;’, identifier or ‘(’ before ‘struct’
 struct JardikSSL_CTX;

^

$ g++ JardikSSL.cpp 
JardikSSL.c:16:8: error: multiple types in one declaration
 struct JardikSSL_CTX;

$ javac JardikSSL.java 
JardikSSL.java:1: error: illegal character: \35
#ifndef JardikSSL_h_from_JardikuvNSAProofToolkit
^
JardikSSL.java:2: error: illegal character: \35
#define JardikSSL_h_from_JardikuvNSAProofToolkit
^
JardikSSL.java:16: error: class, interface, or enum expected
struct JardikSSL_CTX;
^
JardikSSL.java:17: error: class, interface, or enum expected
struct JardikSSL_CERT;
^
JardikSSL.java:19: error: class, interface, or enum expected
static inline enum JardikSSL_ERR
       ^
JardikSSL.java:19: error: '{' expected
static inline enum JardikSSL_ERR
                                ^
JardikSSL.java:20: error: ')' expected
    JardikSSL_CreateContext(struct JardikSSL_CTX **ctx_out,
                                  ^
JardikSSL.java:20: error: ',', '}', or ';' expected
    JardikSSL_CreateContext(struct JardikSSL_CTX **ctx_out,
                                   ^
JardikSSL.java:20: error: '}' expected
    JardikSSL_CreateContext(struct JardikSSL_CTX **ctx_out,
                                                  ^
JardikSSL.java:21: error: '{' expected
                            enum JardikSSL_CTXTYPE ctx_type,
                                                  ^
JardikSSL.java:21: error: <identifier> expected
                            enum JardikSSL_CTXTYPE ctx_type,                                                                                                                                                       
                                                            ^                                                                                                                                                      
JardikSSL.java:22: error: ',', '}', or ';' expected                                                                                                                                                                
                            int socket_fd,                                                                                                                                                                         
                            ^                                                                                                                                                                                      
JardikSSL.java:22: error: '}' expected                                                                                                                                                                             
                            int socket_fd,                                                                                                                                                                         
                                         ^                                                                                                                                                                         
JardikSSL.java:26: error: class, interface, or enum expected                                                                                                                                                       
}                                                                                                                                                                                                                  
^                                                                                                                                                                                                                  
JardikSSL.java:28: error: illegal character: \35                                                                                                                                                                   
#endif                                                                                                                                                                                                             
^                                                                                                                                                                                                                  
15 errors

[Jardík]

Jó, jó, někdo snědl středník za druhým enumem. NSA to prostě modifikuje během posílání, za to nemůžu ...

[pta]

Jj, Jardik si dela prcu a malem by mu to jeden sezral ;)

[Jendа]

Existuje nějaký protokol, který je bezpečný? V čem se od SSL liší?

[Jardík]

protokol jardik je bezpečný. Každý požadavek je zašifrován funkcí f(x) = 1 xor tmp. Počáteční hodnota tmp je 1. Takový obsah je pak nemožné při cestě rozšifrovat ani nejmodernějšími technologiemi NSA, odolný vůči standardním* MITM útokům a odolný dokonce i vůči hloupému příjemci zprávy. Ten ji může rozšifrovat jen se znalostí původní zprávy!

[Jardík]

* Bohužel je náchylná k MITM útoku, kdy se někdo napíchne na vaší RAMku.

[Bill Gates]

No jako pozor .. ono je to ale vazne pro NSA nerozsifrovatelne, protoze oni v tom budou hledat AES, DES3, SHA, RSA... KdoViCo .. Napadlo by nekoho ze to bude tak tivialni ? :D

Zkratka jit na ne z te strany, odkud by to vubec necekali :D

[xkucf03]

Tohle nebyla chyba protokolu.

Může pomoci použít dvouúrovňové zabezpečení založené na dvou různých protokolech a dvou různých šifrách. Třeba SSL + SSH. Buď tunel, VPN, IPSEC… a nad tím ještě šifrování v aplikaci (ve které ideálně přenášíš zprávy šifrované end-to-end zase jinou technologií – např. GnuPG).

Případně ta jedna úroveň nemusí být šifrování, ale aspoň něco jako port-knocking nebo SCRAM, ke kterému musíš znát heslo, abys měl vůbec šanci se připojit k tomu SSL/SSH. A taky nějaký IDS/IPS systém.

[Jendа]

Tohle nebyla chyba protokolu.

Vím. A myslím, že Jardík má hlavně problém s tím, že existují CA - ale to se SSL nemá nic společného.

[Jardík]

Jardík má hlavně problém s tím, že existují CA

Ano, to je pravda. Viz níže Taky mám problém s tím, že na domény má mít monopol jakási americká společnost. V tom, mít vlastní DNS a rozdávat zdarma domény, mi brání různé korporace, které nechcou uznávát mnou darované domény.

[Jardík]

Chyba je hlavně v tom, že některé prohlížeče či jiné balíčky, či operační systémy, s sebou tahají jakýsi "důvěryhodný seznam" certifikačních autorit, jímž je ve výchozím nastavení důvěřováno. Tato volba důvěry by měla zůstat na uživateli. Pokud už s sebou ten seznam tahají, měli by být všechny nastaveny jako nedůvěryhodné, dokud uživatel neurčí jinak. Např. se ho při prvním spuštění zeptat. A pokud tomu uživatel nerozumí, mělo by se doporučovat "nechat nastaveny jako nedůvěryhodné", aby hloupý uživatel slepě nedůvěřoval jakési ikonce vedle adresy. Další slabina je vůbec existence těchto autorit. Pokud chci mít zabezpečené připojení a záleží mi opravdu na těch datech, měl bych dostat veřejný certifikát nějakým "extra" způsobem (třeba osobně) a následně ho porovnat s tím, co mi vnucuje server při připojení. Slepě důvěřovat jakémusi podpisu bez 1:1 kontroly certifikátu, to je naprostá ignorance.

[xkucf03]

Chyba je hlavně v tom, že některé prohlížeče či jiné balíčky, či operační systémy, s sebou tahají jakýsi "důvěryhodný seznam" certifikačních autorit, jímž je ve výchozím nastavení důvěřováno. Tato volba důvěry by měla zůstat na uživateli. Pokud už s sebou ten seznam tahají, měli by být všechny nastaveny jako nedůvěryhodné, dokud uživatel neurčí jinak.

To je sice hezké, ale uživatelé toho většinou nejsou schopní, takže jak to pak dopadne? Všechno bude nedůvěryhodné. Ale uživatel se k těm službám potřebuje připojit, takže to odklikne cokoli, jen aby se dostal na svůj Facebook, do své banky, na e-mail atd.

Bezpečné spojení pak pro BFU bude vypadat úplně stejně, jako spojení, na které dělá MITM jeho zlomyslný soused, správce sítě, ISP, tajná služba atd. Proto tu jsou výchozí CA, které umožňují alespoň části těchto útoků předejít.

Samozřejmě jim nelze slepě věřit a je vhodné to doplnit o další úroveň zabezpečení – např. by mohly být CA důvěryhodné systémově a pak důvěryhodnější ty. které si označil uživatel (zobrazovala by se jiná ikonka). Navíc by se měla kontrolovat změna certifikátu/klíče oproti minulému spojení a uživatel by měl být varován (to umí některé doplňky do prohlížečů). Případně to lze všechno podepsat ještě jinou CA – tím myslím DNSSEC/TLSA, což je sice špatné v tom, že je to monopolní systém, ale pro kontrolu to použít lze (jako pojistka, dvojitá kontrola). Také by šlo kontrolovat z více míst v Internetu, z různých sítí, zda server používá stejný certifikát – na to jsou opět doplňky do prohlížečů. Dále lze použít WOT a nechat uživatele podepisovat certifikáty jako je tomu v PGP.

Nakonec to vede na celou škálu úrovní důvěryhodnosti spojení, nikoli jen binární informaci důvěryhodný/nedůvěryhodný.

[Jardík]

Navíc by se měla kontrolovat změna certifikátu/klíče oproti minulému spojení a uživatel by měl být varován (to umí některé doplňky do prohlížečů)

Jaké? Nedávno mi někdo doporučoval CA Patrol, jenže ten nefunguje "správně", protože nezabrání spojení a odeslání dat, pouze mi vykydne varování, ale to už je pozdě. viz tu.

[xkucf03]

jj, to mi taky vadí, že sice zařve, ale kdyby se v tu chvíli odesílala nějaká důvěrná data¹, tak je už pozdě.

Tyhle chyby se dají řešit, ale bez toho předschváleného seznamu důvěryhodných CA se BFU stejně asi neobejde – jak jsem psal, jsou různé kategorie útoků a je dobré ochránit uživatele alespoň před některými z nich, než to hodit všechno do jednoho pytle i s důvěryhodnými spojeními a tvářit se, že je všechno nedůvěryhodné, dokud si uživatel ručně nezkontroluje otisk klíče (protože většina uživatelů se na to bohužel vykašle).

_{[1] POST, HTTP autentizace nebo vlastně i cookies}

[xm]

Ale jistě že existují jiné možnosti než CA. Např. systém distribuovaných notary serverů, které sledují síťovou perspektivu (prostě jaké certifikáty vidí pro danou doménu notářské servery z různých částí Internetu - klient se jich dotáže a pokud všechny nevidí stejný certifikát, nahlásí problém). Notary servery také udržují historii toho jaké certifikáty viděly u daných domén v průběhu času.

Viz projekty Perpectives a Convergence.

Problém v dnešní době ovšem je, že servery Facebooku a Googlu (a možná další velké stránky) klientům posílají _jiné_ certifikáty v závislosti odkud klient přišel a tudíž z pohledu síťové perspektivy se jeví, jako kdyby někdo dělal MITM. Prostě tento nadějný princip úspěšně sabotují :-/

[xm]

Jinak Perspectives je zdá se (narozdíl od Convergence) stále aktivně vyvíjené. Nová verze vyšla nedávno (kdežto u Convergence je poslední změna před 2 roky).

[xkucf03]

Vždyť o tom píšu:

Také by šlo kontrolovat z více míst v Internetu, z různých sítí, zda server používá stejný certifikát – na to jsou opět doplňky do prohlížečů.

Jenže zkus se nad tím zamyslet. Znamená to, že pak věříš notářským serverům provozovaných nějakou jednou organizací nebo v rámci nějaké jedné infrastruktury. Tudíž vlastně jedné CA. A jak se do prohlížeče dostane seznam důvěryhodných notářských serverů? A jak zajistíš bezpečnou komunikaci s nimi? Asi by to chtělo šifrovat a podepisovat ten kanál, po kterém se ty informace posílají. Jak to budeš šifrovat? Kde na klientovi vezmeš certifikáty či veřejné klíče druhé strany (notáře), abys ji ověřil? Co budeš dělat, až dojde k vypršení nebo kompromitaci nějakého klíče notářského serveru a bude potřeba ho revokovat a vydat nový? Jak tuhle informaci dostaneš na klienty? Je to podobná situace jako u DNSSEC/TLSA – stále řešíš tu samou otázku (jak dostat nějaké veřejné klíče bezpečně na klienty) a navíc je to centralizovaný systém, nad kterým bdí jedna autorita (buď hierarchie DNS s jedním kořenem nebo nějací provozovatelé sítě notářských serverů). Navíc u těch notářských serverů je problém v tom, když se záškodník dohodne s datacentrem, kde je server, nebo jeho ISP a budou dělat MITM tam – pak všichni, včetně všech notářských serverů, uvidí stejný certifikát.

Řešení vidím v kombinaci více prostředků, několikanásobné ochraně a kontrole. Což tedy vede na nebinární hodnocení důvěryhodnosti (ne jen ano/ne, ale celá škála), se kterým se uživatel musí nějak vyrovnat a nějak ho vyhodnotit… což se asi uživatelé budou muset naučit nebo tu bude muset být nějaké rozumné výchozí nastavení. Ale každopádně plnohodnotná náhrada k systému PKI/CA v současnosti neexistuje.