Bezpečnost a bezpečné programování

Bezpečnost a bezpečné programování 11. Bezpečnost soketů Ing. Tomáš Zahradnický, EUR ING, Ph.D. České vysoké učení technické v Praze Fakulta informačních technologií Katedra počítačových systémů Příprava studijních programů Informatika pro novou fakultu ČVUT je spolufinancována Evropským sociálním fondem a rozpočtem Hlavního města Prahy v rámci Operačního programu Praha adaptabilita (OPPA) projektem CZ.2.17/3.1.00/31952 Příprava a zavedení nových studijních programů Informatika na ČVUT v Praze. Praha & EU: Investujeme do vaší budoucnosti T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 1 / 23

Úvod V říkali jsme, že je třeba komunikaci pro TCP/IP šifrovat nejlépe na úrovni transportní vrstvy. Nyní si ukážeme jak. Historie TLS/SSL Popis TLS/SSL Proces navázání spojení Proces ustanovení šifrovacího klíče Volba šifrování v TLS Jak se vytváření certifikáty pro TLS? T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 2 / 23

Historie SSL/TLS TLS Transport Layer Security (TLS) a jedná se o množinu kryptografických protokolů, které poskytují bezpečnou komunikaci po internetu. SSL Secure Socket Layer (SSL) je předchůdce TLS. 199? SSL 1.0 neveřejné 1995 SSL 2.0 1996 SSL 3.0 1999 TLS 1.0 (= SSL 3.1) 2006 TLS 1.1 (= SSL 3.2) 2008 TLS 1.2 (= SSL 3.3) T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 3 / 23

TLS verze 1.2 (SSL verze 3.3) Definováno RFC 5246 [3]. Základním účelem protokolu TLS je zařídit soukromí a integritu dat mezi dvěmi komunikujícími aplikacemi. Protokol TLS má 2 vrstvy: 1 nišží na té běží TLS Record Protocol 2 vyšší na té běží 4 protokoly: TLS Handshake Protocol, Alert Protocol, Change Cipher Spec Protocol, Application Data Protocol Nad protokolem transportní vrstvy, typicky napříkad TCP, nebo UDP je nízkoúrovňový TLS Record Procotol a nad ním jsou TLS protokoly vyšší úrovně. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 4 / 23

TLS Record Protocol (RP) Nízkoúrovňový protokolol, který má na starosti rozklad a skládání paketů vyšší úrovně do rámců, volitelně také poskytuje: kompresi/dekompresi dat, šifrování/dešifrování a zabezpečení/kontrolu pomocí MAC. šifrování volitelně šifruje data symetrickou šifrou jejíž klíč je unikátní pro každou session a zřizuje se TLS Handshake Protokolem. komprese volitelně provádí kompresi rámců. integrita volitelně počítá MAC s klíčovaným hashem. Je využíván čtyřmi základními protokoly vyšší vrstvy: TLS Handshake Protocol (HP) Alert Protocol (AP) Change Cipher Spec Protocol (CCSP) Application Data Protocol (ADP) Je možné vytvořit i vlastní protokol běžící nad RP. Maximální velikost rámce 2 14 B. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 5 / 23

TLS Record Protocol Komprese dat v RP Stav session definuje, jaký kompresní algoritmus je použit pro kompresi všech rámců RP. Kompresní algoritmy použitelné v RP jsou popsány v RFC 3749: null metoda komprese, která neprovádí žádnou kompresi. Deflate metoda komprese, kterou provádí libz. Požadavky na kompresní algoritmy: Komprese musí být bezeztrátová Komprese nesmí rámec rozšířit o více než 1024 B. Pokud dekomprese zjistí rámec, který by překročil 2 14 B, musí ohlásit fátální chybu dekomprese. Výstupem kompresní fáze je struktura TLSCompressed. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 6 / 23

TLS Record Protocol I Šifrování/Integrita v RP Struktura TLSCompressed se použije jako vstup pro šifrování a pro MAC. Šifrovat lze těmito šiframi: Proudové null metoda šifrování, která neprovádí šifrování Standard Stream Cipher RC4 Z celé struktury TLSCompressed, čísla rámce a klíče pro hash se spočítá MAC domluveným algoritmem. Dále se struktura TLSCompressed zašifruje domluveným algoritmem a výstupem obou kroků je struktura osahující zašifrovaná data a MAC. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 7 / 23

TLS Record Protocol II Šifrování/Integrita v RP Blokové Např. 3DES, AES,... Blokové šifry používají inicializační vektor (IV) a pracují se zarovnanými daty. IV je má být zvolen náhodně a má být nepredikovatelný. Používá se operační mód CBC (Cipher Block Chaining). Výstupem je struktura, ve které jsou šifrovaná data, MAC, výplň pro zarovnání a počet bytů zarovnání. AEAD (Authenticaed Encryption with Associated Data) Např. CCM, CGM. Více informací viz RFC 5116. Šifry AEAD používají jako vstup klíč, nonce, data a další data, která se používají při autentizačním testu. Výstupem je struktura ve které je pouze šifrovaný blok dat. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 8 / 23

TLS Handshake Protocoly Change Cipher Spec Protocol Slouží k tomu, aby bylo možné signalizovat změnu v šifrování. Má jen jediný typ zprávy, která je šifrována a komprimována současným nastavením. Zpráva je poslána jak klientem, tak i serverem, aby potvrdili že další rámce budou šifrovány novou šifrou. Zpráva je posílána během připojování po domluvě na bezpečnostních parametrech session. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 9 / 23

TLS Handshake Protocoly Alert Protocol Slouží k posílání informacích o chybách a varováních v session. Každá zpráva se skládá z úrovně chyby fatální varování a čísla chyby. Pokud dojde k nějaké chybě/varování (RFC 5246 definuje 25 druhů) je odeslána protistraně zpráva a v případě: fatální chyby obě strany uzavřou spojení a zapomenou identifikátor session, klíče a tajemství. Tato session již nemůže být obnovena. varování může session pokračovat dál. Pokud si to ale příjemce zprávy nepřeje, musí protistraně odeslat fatální chybu, která povede k ukončení session. toto chování se v praxi často nedodržuje, protože nevíme, jak protistrana zareaguje. Z toho důvodu například klient, který zjistí, že certifikát serveru je podepsaný nedůvěryhodnou CA, se nejdřív zeptá uživatele, a teprve potom raději neodešle varování. AP se posílá i informace o ukončení session, kterou musí protistrana potvrdit, pokud nejdojde k jiné fatální chybě. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 10 / 23

TLS Handshake Protocoly I Handshake Protocol (HP) HP slouží ke zřízení session, která zahrnuje následující parametry: identifikátor session používá se pro identifikaci stavu aktivní anebo obnovitelné session. X509v3 (PKIX) certifikát protistrany, může být null. kompresní algoritmus speficikaci šifry zahrnuje výběr funkce pro generování pseudonáhodných čísel, typ šifry, hashovací funkce a typ MAC. master secret sdílené mezi klientem a serverem. resumable flag příznak určující jestli lze použít session pro nová připojení Výše uvedené parametry se použijí pro vytvoření bezpečnostních parametrů používaných RP. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 11 / 23

TLS Handshake Protocoly II Handshake Protocol (HP) Klient Server ClientHello ServerHello Certificate ServerKeyExchange CertificateRequest ServerHelloDone Certificate ClientKeyExchange CertificateVerify [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished Data Data T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 12 / 23

TLS Handshake Protocoly III Handshake Protocol (HP) ClientHello první zpráva, kterou posílá klient serveru a spouští s ní proces domluvy na parametrech spojení. Součástí zprávy ClientHello je: verze protokolu klienta (např. 3.3), 32 B náhodných dat, z nichž 4 jsou datum a čas v GMT v sekundách od roku 1970, identifikátor session, seznam kryptografických možností klienta, seznam kompresních metod klienta, seznam rozšíření. ServerHello první zpráva odesílaná serverem jako reakce na zprávu ClientHello. Server projde klientovy seznamy a zvolí příslušné metody, jinak pošle chybu typu handshake failure. Zpráva obsahuje jinak položky, jako zpráva ClientHello. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 13 / 23

TLS Handshake Protocoly IV Handshake Protocol (HP) Hello Extensions RFC 5246 definuje rozšíření pro domluvu na algoritmech používaných pro digitální podepisování, tedy hashovací funkci (MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) a algoritmu digitálního podpisu (RSA, DSA, ECDSA). Další rozšíření např. v RFC 6066. Server Certificate server musí poslat tuto zprávu, pokud dohodnutá metoda autentizace používá certifikáty. Zpráva obsahuje celý certifikační řetěz a certifikáty musí být ve formě X.509v3, pokud není domluveno jinak. Server Key Exchange je poslána pokud zpráva Server Certificate (pokud je poslána) neobsahuje dostatek dat ke zřízení premaster secret. Součástí zprávy je výběr algoritmu a dodatečná informace, která je využita buď ke zřízení přemaster secretu pomocí algoritmů na bázi Diffie-Hellman, anebo je veřejným klíčem pro jiné algoritmy. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 14 / 23

TLS Handshake Protocoly V Handshake Protocol (HP) Certificate Request neanonymní server může požadovat certifikát od klienta, pokud to vyžaduje dohodnutá šifra. Server Hello Done posíláno serverem k indikaci dokončení všech hello zpráv. Po odeslání této zprávy bude server čekat na odpověď klienta. Client Certificate zpráva odesílaná klientem serveru po příjmu ServerHelloDone a to jen v případě, že neanonymní server o certifikát požádal. Zpráva obsahuje celý certifikační řetězs, anebo je prázdná, pokud klient žádný certifikát nemá. Certifikáty musí být ve formě X.509v3, pokud není domluveno jinak. Client Key Exchange povinná zpráva klienta, kterou nastavujeme premaster secret, a to buď jeho přímým přenosem zašifrovaným RSA, anebo přenosem parametrů pro výměnu klíčů pomocí Diffie-Hellman. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 15 / 23

TLS Handshake Protocoly VI Handshake Protocol (HP) Certificate Verify zpráva se používá k explicitnímu ověření klientského certifikátu a je posílána pouze pokud je klientský certifikát určen k podepisování. ChangeCipherSpec tato zpráva je poslána asynchronně, jiným druhem handshake protokolu a její popis viz dříve. Finished zpráva Finished je poslána po odeslání zprávy ChangeCipherSpec k ověření, že zřízení klíče a autentizace byly úspěšně dokončeny. Tato zpráva je první zprávou, která je již chráněna dohodnotými algoritmy. Příjemce musí ověřit, že obsah zprávy je správně a musí ho potvrdit také zprávou Finished. Po tom, co obě komunikující strany dostanou a ověří zprávu Finished je session úspěšně vytvořena a handshake končí. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 16 / 23

SSL/TLS na webu [4] Typický scénář na webu: server, která má serverový certifikát klient, který je anonymní Serverový certifikát může být buď: self-signed, případně podepsán self-signed CA; v tomto případě bude webový prohlížeč uživatele upozorňovat na to, že certifikát je podepsán nedůvěryhodnou CA, a že nedoporučuje stránku otevřít, protože nevíte, s kým máte tu čest. + levné + poskytuje šifrování, ale ne ověřování + vhodné i pro firmy, které si mohou nainstalovat kořenový certifikát uživatel nemající váš kořenový certifikát bude (neustále) upozorňován prohlížečem. Po čase si uživatelé na toto upozornění zvyknou a otupí a budou snadnou kořistí pro podvržený certifikát. vystaven důvěryhodnou CA: drahé + nezbytné pro webové servery, kde máte autentizaci a chcete šifrovat + kořenový certifikát je již v počítači nainstalován přímo výrobcem OS T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 17 / 23

Self-signed certifikát I Termín je nesprávný, protože certifikát se nepodepíše sám, ale je podepsán vaší CA, ke které máte privátní klíč. CA a certifikát vytvoříme v těchto 5 krocích: 1 Nejdříve je nutné vytvořit pár RSA klíčů CA, zvolili jsme modul 4096 b: tomas$ openssl genrsa -out CA.key 4096 Generating RSA private key, 4096 bit long modulus...++...++ e is 65537 (0x10001) 2 Dále je nutné vytvořit (kořenový) certifikát CA, platnost 10 let: tomas$ openssl req -new -x509 -days 3650 -key CA.key -out CA.crt You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter., the field will be left blank. ----- Country Name (2 letter code) [AU]:CZ State or Province Name (full name) [Some-State]:. Locality Name (eg, city) []:Praha Organization Name (eg, company) [Internet Widgits Pty Ltd]:Ceske vysoke uceni technicke v Praze Organizational Unit Name (eg, section) []:Fakulta informacich technologii Common Name (eg, YOUR name) []:FIT CVUT, K18104 CA Email Address []:zahradt@fit.cvut.cz T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 18 / 23

Self-signed certifikát II 3 Nyní vytvořme pár RSA klíčů pro náš certifikát, modul 2048 b: tomas$ openssl genrsa -out server.key 2048 Generating RSA private key, 2048 bit long modulus...+++...+++ e is 65537 (0x10001) 4 Dále je nutné vytvořit požadavek na podpis certifikátu CA: tomas$ openssl req -new -key server.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter., the field will be left blank. ----- Country Name (2 letter code) [AU]:CZ State or Province Name (full name) [Some-State]:. Locality Name (eg, city) []:. Organization Name (eg, company) [Internet Widgits Pty Ltd]:Ceske vysoke uceni technicke v Praze Organizational Unit Name (eg, section) []:. Common Name (eg, YOUR name) []:server.kps.fit.cvut.cz Email Address []:. Please enter the following extra attributes to be sent with your certificate request A challenge password []: An optional company name []:. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 19 / 23

Self-signed certifikát III 5 Posledním krokem je podpis požadavku na certifikát certifikátem CA: tomas$ openssl x509 -req -days 1440 -CA CA.crt -CAkey CA.key -set_serial 01 \ > -in server.csr -out server.crt Signature ok subject=/c=cz/o=ceske vysoke uceni technicke v Praze/CN=server.kps.fit.cvut.cz Getting CA Private Key Soubory certifikátů lze vypsat pomocí: tomas$ openssl x509 -in server.crt -noout -text Certificate: Data: Version: 1 (0x0) Serial Number: 1 (0x1) Signature Algorithm: sha1withrsaencryption Issuer: C=CZ, L=Praha, O=Ceske vysoke uceni technicke v Praze, OU=Fakulta informacnich technolo gii, CN=FIT CVUT, K18104 CA/emailAddress=zahradt@fit.cvut.cz Validity Not Before: May 14 12:31:56 2011 GMT Not After : Apr 23 12:31:56 2015 GMT Subject: C=CZ, O=Ceske vysoke uceni technicke v Praze, CN=server.kps.fit.cvut.cz Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:a9:8f:4f:82:27:cd:4e:4b:63:28:ca:74:b4:18: <<odstraněno>> T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 20 / 23

Instalace certifikátu Apache V konfiguračním souboru /etc/httpd/conf.d/ssl.conf je nutno nastavit cesty k serverovém certifikátu, a to v proměnných: SSLCertificateFile umístění certifikátu, tedy.crt souboru. SSLCertificateKeyFile umístění soukromého klíče, tedy.key souboru. SSLCertificateChainFile umístění řetězu certifikátů (všechny CA, které certifikovaly náš certifikát ve formátu PEM) anebo přímo náš certifikát. Microsoft Windows 7 Server Start > Administrative Tools > Internet Information Services (IIS) Manager. Connections > Sites > vybrat server, poklepat na Server Certificates. Actions > Complete Certificate Request.... Následuje vybrání souboru s certifikátem, poté je certifikát nainstalován. Certifikát je nutno přiřadit k website: Connections > Sites > website. Actions > Bindings..., objeví se okno Site Bindings. V okně Site Bindings klepnout na Add.... Zde nastavit protokol (https), IP adresu, port a jméno domény. Klepnutím na OK nastavení dokončíte. T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 21 / 23

Připojení z příkazové řádky tomas$ openssl s_client -connect www.gmail.com:443 CONNECTED(00000003) depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain <<odstraněno>> --- Server certificate -----BEGIN CERTIFICATE----- <<odstraněno>> -----END CERTIFICATE----- <<odstraněno>> --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-SHA Session-ID: F0ED4D4521DC77B71C6F15BA6E805DFC5441591B21FD4600CE4436A539713AD2 Session-ID-ctx: Master-Key: 4AF8C3FBB9BF383716FE2C42AD6D5CE4D56451F28782234610328B8ECD8A27BE3D99A8515854ED487980D57F0B9E6F6C Key-Arg : None Start Time: 1305476544 Timeout : 300 (sec) Verify return code: 0 (ok) --- GET /index.html HTTP/1.0CRCR T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 22 / 23

Bibliografie Howard M., LeBlanc D.: Writing Secure Code, 2 nd edition, Microsoft Press, 2003. OWASP Foundation: Open Web Application Security Project, https://www.owasp.org/index.php/main Page, 2011. Network Working Group: The Transport Layer Security (TLS) Protocol Version 1.2, RFC 5246, http://tools.ietf.org/html/rfc5246, 2008. Harris, J. K.: Understanding SSL/TLS, or What is an SSL Certificate and What Does It Do for Me?, http://computing.ece.vt.edu/ jkh/understanding SSL TLS.pdf, Virginia Tech, 2008 T. Zahradnický (ČVUT FIT) Bezpečnost soketů MI-BPR, 2011, Předn. 11 23 / 23