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ů


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ů


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 2

nišží — na té běží TLS Record Protocol 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ě.


Bezpečnost soketů


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 214 B. T. Zahradnický (ČVUT FIT)

Bezpečnost soketů


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 214 B, musí ohlásit fátální chybu dekomprese.

Výstupem kompresní fáze je struktura TLSCompressed.


Bezpečnost soketů


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.


Bezpečnost soketů


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.


Bezpečnost soketů


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.


Bezpečnost soketů


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ů


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.


Bezpečnost soketů


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

Bezpečnost soketů


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ů


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ů


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ů


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čí.


Bezpečnost soketů


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ů


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 []:[email protected]


Bezpečnost soketů


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 []:.


Bezpečnost soketů


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/[email protected] 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: <>


Bezpečnost soketů


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.


Bezpečnost soketů


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 <> --Server certificate -----BEGIN CERTIFICATE----<> -----END CERTIFICATE----<> --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ů


22 / 23

Bibliografie

Howard M., LeBlanc D.: Writing Secure Code, 2nd 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


Bezpečnost soketů


23 / 23

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

Recommend Documents