{"id":338,"date":"2013-04-01T20:21:08","date_gmt":"2013-04-01T19:21:08","guid":{"rendered":"http:\/\/under12oot.noblogs.org\/?p=338"},"modified":"2013-04-01T20:21:08","modified_gmt":"2013-04-01T19:21:08","slug":"best-practices-and-applications-of-tlsssl-parte-1","status":"publish","type":"post","link":"https:\/\/under12oot.noblogs.org\/?p=338","title":{"rendered":"Best practices and applications of TLS\/SSL (parte 1)"},"content":{"rendered":"<p>Questa \u00e8 la prima parte del mini how-to che ho deciso di tradurre, sia per tenere la mente fresca e allenata, sia per fare un po&#8217; di chiarezza agli utenti\/passanti di under_r00t.<\/p>\n<p>Per lavoro mi serviva avere a disposizione e \u201csotto mano\u201d un buon documento consultabile, ho spulciato tra le mie risorse ed ho trovato quello che mi serviva, per questioni di Copyright preferisco non dire chi \u00e8 il proprietario n\u00e9 il titolo del \u201cwhite paper\u201d, sappiate che \u00e8 affidabile \ud83d\ude09 .<\/p>\n<p>Queste sono le \u201c<em>best practices and applications of TLS\/SSL<\/em>\u201d .<\/p>\n<p><em>Transport Layer Security<\/em> o TLS, largamente conosciuto anche come <em>Secure Sockets Layer<\/em> o SSL, \u00e8 l&#8217;applicazione pi\u00f9 popolare al mondo per la crittografia delle chiavi pubbliche. E&#8217; famoso per il suo utilizzo in sessioni sicure di browsing ma pu\u00f2 essere impiegato anche in altri campi.<\/p>\n<p>TLS\/SSL pu\u00f2 essere utilizzato per fornire una solida autenticazione tra 2 parti in una sessione di comunicazione, una forte criptazione dei dati in transito tra i 2 e per la verifica dell&#8217; integrit\u00e0 dei dati. Come sempre, se usato impropriamente, TLS pu\u00f2 dare l&#8217;illusione di sicurezza dove invece le comunicazioni sono state compromesse. E&#8217; importante mantenere i certificati aggiornati e controllare con rigore la presenza di errori.<\/p>\n<p>In alcuni, ma non tutti, degli utilizzi di TLS l&#8217;integrit\u00e0 dei processi \u00e8 supportata dai certificati rilasciati da una \u201cCertificate Authority\u201d (CA) riconosciuta.<\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"text-decoration: underline\">INTRODUZIONE<\/span><\/p>\n<p>Lo scenario attuale vede la continua crescita e sviluppo di applicazioni \u201cbusiness\u201d , allo stesso passo cresce la necessit\u00e0 di sviluppare modelli sicuri. Assieme alla complessit\u00e0 e alla funzionalit\u00e0 cresce anche l&#8217;opportunit\u00e0 di abusi da parte di malintenzionati.<\/p>\n<p>Le soluzioni a questo problema sono svariate e devono essere esplorate individualmente, ma una tecnologia ricorre spesso: TLS o <em>Transport Layer Security<\/em>, conosciuta spesso con il nome della tecnologia precedente SSL o<em> Secure Socket Layer<\/em>.<\/p>\n<p>Basilarmente TLS fornisce 3 benefici:<\/p>\n<ul>\n<li>Provvede all&#8217;autenticazione di soggetti in comunicazione, sia in una direzione sia in entrambe le direzioni.<\/li>\n<li>Cripta le sessioni di comunicazione.<\/li>\n<li>Assicura l&#8217;integrit\u00e0 dei dati trasferiti.<\/li>\n<\/ul>\n<p>In questo documento si parler\u00e0 anche delle CA e del loro ruolo nelle infrastruture delle chiavi pubbliche o PKI.<\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"text-decoration: underline\">COS&#8217;\u00c8 TSL\/SSL<\/span><\/p>\n<p>TLS\/SSL \u00e8 un protocollo di tunneling che lavora al transport layer <em>(livello di trasporto della pila ISO\/OSI ndr)<\/em> e fornisce criptazione, autenticazione e verifica dell&#8217;integrit\u00e0 dei dati.<\/p>\n<p>&nbsp;<\/p>\n<p><b>Certificati digitali<\/b><\/p>\n<p>un certificato digitale \u00e8 un documento elettronico che conferma l&#8217;identi\u00e0 di un soggetto<em> (che pu\u00f2 essere un utente, un server, una societ\u00e0, un programma su un client, pi\u00f9 o meno qualsiasi cosa)<\/em> e associa questo soggetto ad una chiave pubblica. Il certificato digitale \u00e8 l&#8217;identificazione di un soggetto nell&#8217;infrastruttura delle chiavi pubbliche. Ogni soggetto che partecipa ad una comunicazione assicurata da TLS pu\u00f2 valutare il contenuto del certificato. Il campo maggiormente esaminato \u00e8 il \u201ccommon name\u201d. Ognuno poi confronta il valore con quello aspettato.<\/p>\n<p>Utenti possono generare un proprio certificato digitale, chiamati self-signed certificates,\u00a0 grazie all&#8217;utilizzo di free tools ma hanno senso se vengono utilizzati all&#8217;interno della propria rete. Di fatto la miglior cosa \u00e8 acquisire certificati da CA riconosciute <em>(\u2026 speculazione ndr).<\/em><\/p>\n<p>&nbsp;<\/p>\n<p><b>Autenticazione e verifica<\/b><\/p>\n<p>Le chiavi pubbliche crittografate permettono 2 soggetti di autenticarsi a vicenda. Ogni soggetto ha 2 chiavi, le chiavi sono valori numerici molto grandi. Un messaggio scambiato tra le 2 parti viene fatto girare attraverso un algoritmo di hash. La funzione di hash prende un blocco di dati e ne calcola un valore, questo valore \u00e8 conosciuto come hash o digest. Modificare anche una piccolissima parte questo blocco di dati farebbe variare l&#8217;hash in modo significativo. Allo stesso tempo non \u00e8 possibile ricreare il blocco di dati partendo dall&#8217;hash.<\/p>\n<p>Il mittente usa la propria chiave privata per criptare il valore dell&#8217;hash. Questo valore criptato viene chiamato \u201cdigital signature\u201d<em> (firma digitale).<\/em> Il messaggio assieme alla signature viene spedito al destinatario. Il destinatario usa la chiave pubblica del mittente per decriptare la firma. A questo punto viene generato un hash del messaggio utilizzando lo stesso algoritmo del mittente e poi vengono comparati i valori.<\/p>\n<p>Se i valori coincidono si possono fare 2 considerazioni certe: <span style=\"text-decoration: underline\">i dati non sono stati modificati e il mittente \u00e8 chi dice di essere.<\/span><\/p>\n<p><span style=\"text-decoration: underline\">L&#8217;autenticazione e la verifica non sono facoltativi nel TLS.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><b>Sicurezza della chiave<\/b><\/p>\n<p>Ci sono delle regole fondamentali che devono essere seguite in modo che l&#8217;infrastruttura delle chiavi pubbliche lavori adeguatamente.<\/p>\n<p><em>Le chiavi private devono essere private<\/em>: il firmatario di un messaggio deve mantenere la propria\u00a0chiave privata assolutamente confidenziale. Chiunque la possedesse potrebbe effettivamente impersonare il mittente.<\/p>\n<p><em>\u00a0Le chiavi pubbliche devono essere pubbliche:<\/em> non necessariamente pubbliche, ma devono essere accessibili a chiunque abbia una ragione valida per leggere il messaggio o per criptare un messaggio al soggetto nominato nel certificato.<\/p>\n<p><em>\u00a0Gli algoritmi di hash non devono collidere:<\/em> una collisione si ha quando l&#8217;algoritmo di hash genera lo stesso digest da due differenti blocchi di dati. In qualche punto questo \u00e8 inevitabile, ma l&#8217;abilit\u00e0 di generare collisioni intenzionalmente compromette tutte le funzioni delle chiavi pubbliche. Questo \u00e8 il motivo per cui vengono continuamente sviluppati e rilasciati nuovi e migliori algoritmi di hash.<\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"text-decoration: underline\">CRIPTAZIONE<\/span><\/p>\n<p>Anche quando non viene utilizzata l&#8217;autenticazione, TLS pu\u00f2 usare le chiavi di criptazione e un algoritmo di cifratura per criptare\/decriptare dati in una comunicazione. La cifratura \u00e8 anche usata per criptare il digest di un messaggio.\u00a0Ci sono differenti algoritmi di cifratura per differenti circostante.<\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"color: #ff9900\">Fine della prima parte! Stay tuned stay hack \ud83d\ude09<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Questa \u00e8 la prima parte del mini how-to che ho deciso di tradurre, sia per tenere la mente fresca e allenata, sia per fare un po&#8217; di chiarezza agli utenti\/passanti di under_r00t. Per lavoro mi serviva avere a disposizione e \u201csotto mano\u201d un buon documento consultabile, ho spulciato tra le mie risorse ed ho trovato [&hellip;]<\/p>\n","protected":false},"author":5820,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[52,51,53],"class_list":["post-338","post","type-post","status-publish","format-standard","hentry","category-howto","tag-crypt","tag-tlsssl","tag-white-paper"],"_links":{"self":[{"href":"https:\/\/under12oot.noblogs.org\/index.php?rest_route=\/wp\/v2\/posts\/338","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/under12oot.noblogs.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/under12oot.noblogs.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/under12oot.noblogs.org\/index.php?rest_route=\/wp\/v2\/users\/5820"}],"replies":[{"embeddable":true,"href":"https:\/\/under12oot.noblogs.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=338"}],"version-history":[{"count":1,"href":"https:\/\/under12oot.noblogs.org\/index.php?rest_route=\/wp\/v2\/posts\/338\/revisions"}],"predecessor-version":[{"id":339,"href":"https:\/\/under12oot.noblogs.org\/index.php?rest_route=\/wp\/v2\/posts\/338\/revisions\/339"}],"wp:attachment":[{"href":"https:\/\/under12oot.noblogs.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=338"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/under12oot.noblogs.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=338"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/under12oot.noblogs.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=338"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}