Protokol DTLS
--Blaza.marinic 19:16, 11. siječnja 2017. (CET)
Sigurnost aplikacija za rad u realnom vremenu s pomoću DTLS-a
Sadržaj |
Uvod
Sigurnost aplikacija uvelike ovisi o dizajnu istih, stoga se programeri aplikacija u današnje vrijeme moraju konstantno informirati o novitetima na polju sigurnosti interneta. Napadač otkriva ranjivosti aplikacija i prema njima odlučuje o izboru jedne od mnoštva napadačkih tehnika. Prema organizaciji „Web Application Security Consortium“ te su tehnike podijeljene u šest grupa, tzv. klasa napada: autentifikacijski, autorizacijski napadi, napadi na klijentsku stranu, napadi izvršavanja naredbi i otkrivanja informacija te logički napadi. U radu ćemo ih ukratko opisati. [1]
Od sve je veće važnosti i rad aplikacija u realnom vremenu. Real-time sustav mora procesirati informacije i pružiti odgovore u okviru zadanog vremena, u suprotnom riskira suočavanje s posljedicama, koje mogu biti klasificirane kao teške (eng. hard) – potpuni kvar sustava u slučaju prekoračenja zadanog roka, solidne (eng. firm) - rijetka prekoračenja su podnošljiva, ali mogu smanjiti kvalitetu sustava, nema korisnosti rezultata nakon prekoračenja i blage (eng. soft) - korisnost rezultata se smanjuje nakon prekoračenja, smanjujući time i kvalitetu sustava. [2] Definicija navodi Real-time Application (RTA) kao aplikacijski program koji funkcionira u vremenskom okviru kojeg korisnik doživljava kao trenutno. Je li ili nije aplikacija kvalificirana kao RTA ovisi o najgorem slučaju u kojem se ista izvrši (eng. Worst-case Execution Time). [3]
Nakon kratkog uvoda u sigurnost aplikacija i rad u realnom vremenu, detaljnije je objašnjen protokol DTLS. Datagram Transport Layer Security protokol razvijen je iz Transport Layer Security protokola i dizajniran je kako bi bio što sličniji njemu. TLS je najčešće korišten protokol što se tiče sigurnosti mrežnog prometa. Aplikacije bazirane na pouzdanom prijenosu podataka, kojeg omogućuje Transmission Control Protocol, mogu biti osigurane pomoću protokola TLS. Primarna prednost je ta što pruža siguran, transparentan kanal; jednostavno je omogućiti sigurnost aplikacijskim protokolima stavljajući TLS između aplikacijskog i mrežnog sloja. Međutim, zbog toga što zahtijeva pouzdan transportni kanal (uobičajeno je to TCP), ne može biti korišten za osiguravanje nepouzdanog prometa datagrama. Razvojem TLS-a, ovo ograničenje nije se uzimalo kao problem jer je većina aplikacija koristila TCP kao transportni protokol, no kroz zadnjih nekoliko godina sve veći broj protokola aplikacijskog sloja, kao što su Session Initiation Protocol (SIP), Real Time Protocol (RTP), Media Gateway Control Protocol (MGCP) i mnogi protokoli za igre, dizajnirano je da koristi UDP transport. Stoga su dizajneri takvih aplikacija u današnje vrijeme suočeni s mnogim nezadovoljavajućim izborima pružanja sigurnosti. Dobra alternativa je dizajniranje sigurnosnog protokola koji će osigurati prijenos datagrama za spomenute aplikacije. [4]
Protokol DTLS je modificirana verzija TLS-a i dizajniran je kako bi osigurao podatke između aplikacija koje komuniciraju. Razlog zbog kojeg TLS ne može direktno biti korišten u datagramskom okruženju je taj što može doći do gubitka ili razmještaja paketa. Upravo je svrha DTLS-a stvaranje minimalnih promjena u TLS-u koje su potrebne kako bi se riješili ovi problemi. [5]
Sigurnost web aplikacija
Izvršavanje napada na web aplikaciju zahtijeva korištenje neke od napadačkih tehnika. Te su tehnike zajednički nazvane klasama napada, a Web Application Security Consortium ih dijeli na sljedeće klase:
1. Autentifikacijski napadi: Brute Force, Insufficient Authentication, Weak Password Recovery Validation
2. Autorizacijski napadi: Credential/Session Prediction, Insufficient Authorization, Insufficient Session Expiration, Session Fixation
3. Napadi na klijentsku stranu: Content Spoofing, Cross-side Scripting
4. Napadi izvršavanja naredbi: Buffer Overflow, Format String Attack, LDAP/SQL/XPath Injection, SSI Injection (Server-side Include), OS (eng. Operating System) Commanding
5. Napadi otkrivanja informacija: Directory Indexing, Information Leakage, Path Traversal, Predictable Resource Location
6. Logički napadi: Abuse of Functionality, Denial of Service, Insufficient Anti-automation, Insufficient Process Validation.
Budući da su protokoli za sigurnost datagrama izuzetno podložni raznim DoS napadima, recimo nešto više o njima. Denial-of-Service napadi su uspješni zbog toga što uskraćuju sustavu potrebne resurse, kao što su CPU (eng. Central Processing Unit), memorija, prostor na disku i sl., uzrokujući nedostupnost web stranice. Primjerice, ako imamo veliku bazu podataka i pošaljemo joj određeni zahtjev, u vremenu dok čekamo na odgovor, server doseže do 60% iskoristivosti. DoS napadač će poslati 10 sličnih zahtjeva kako bi CPU dosegao 100% iskoristivosti, nakon čega sustav postaje nedostupan običnom korisniku. [1]
Protokol TLS
Primarni cilj Transport Layer Security protokola je osiguravanje privatnosti i pouzdanosti prijenosa podataka između aplikacija. Sigurnosni kanal kojeg pruža ima tri primarne sigurnosne značajke: autentifikaciju servera, povjerljivost komunikacijskog kanala i integritet poruka komunikacijskog kanala. Opcionalno, TLS može pružiti i autentifikaciju klijenta. Slijedi prikaz TLS handshake-a:
TLS klijent inicira handshake šaljući ClientHello poruku koja sadrži TLS verziju i listu algoritama. Server odgovara s tri poruke: ServerHello sadrži serverov odabir verzije i algoritma; Certificate sadrži serverov lanac certifikata; ServerHelloDone je jednostavna poruka koja znači da ne slijedi više nijedna poruka. Klijent tada slučajnim odabirom izabire PreMasterSecret koji će biti korišten kao osnova za ključeve obiju strana, kriptira ga pomoću serverovog javnog ključa te šalje serveru u ClientKeyExchange poruci. Šalje i ChangeCipherSpec poruku kako bi naznačio promjenu u novopregovoreni sigurnosni set. I na kraju šalje Finished poruku koja sadrži MAC prijašnjih handshake poruka. Server odgovara s vlastitim ChangeCipherSpec i Finished porukama.
Handshake protokol pretpostavlja da su podaci poslani pouzdanim prijenosom, redoslijed poruka je precizno definiran i svaka poruka ovisi o prethodnoj, svaki drugi redoslijed je pogrešan i rezultira neuspjehom protokola. Također, ne postoji mehanizam za rukovanje gubitkom poruka. [4]
Zahtijevana svojstva DTLS-a
U informacijskoj tehnologiji, protokol DTLS pruža privatnost pri komunikaciji. Dopušta aplikacijama baziranim na podacima komunikaciju na način koji je dizajniran kako bi spriječio prisluškivanje ili krivotvorenje poruka. Protokol DTLS je baziran na protočnom (eng. stream-oriented) TLS protokolu i namijenjen je pružanju sličnih sigurnosnih garancija. Aplikacija neće imati kašnjenja koja su povezana s protočnim protokolima, ali će se morati suočiti s razmještajem paketa, gubitkom datagrama, i podacima koji su veći od veličine mrežnog datagrama. [6]
Nepouzdanost TLS-a stvara probleme na dvije razine:
1. TLS ne dopušta nezavisne dekripcije individualnih zapisa. Budući da provjera integriteta ovisi o slijednom broju, ukoliko N zapis nije stigao, provjera N+1 zapisa bit će bazirana na krivom slijednom broju.
2. TLS handshake sloj pretpostavlja da su handshake poruke pouzdano dostavljene te se veza prekida ukoliko su iste poruke izgubljene.
Slijedi opis pristupa DTLS-a u rješavanju ovih problema.
Gubici pri razmjeni poruka
U TLS-ovom sloju za enkripciju mrežnog prometa (eng. record layer) zapisi nisu nezavisni. Postoje dvije vrste međuzapisne ovisnosti:
1. Kriptografski sadržaj je zadržan između zapisa.
2. Zaštite razmještaja poruka i neovlaštenog odgovora za vrijeme aktivne sjednice (eng. anti-replay) osigurane su MAC-om, koji uključuje slijedni broj, koji je implicitan u zapisu.
DTLS rješava prvi problem zabranjujući protok kriptografskog sadržaja, a drugi dodajući eksplicitne slijedne brojeve.
Osiguravanje pouzdanosti za handshake
Gubitak paketa
DTLS koristi jednostavan tajmer ponovnog slanja za rukovanje gubitkom paketa.
Sljedeća slika demonstrira osnovni koncept:
Kada je klijent poslao ClientHello poruku, očekuje dobiti HelloVerifyRequest od servera. Međutim, ukoliko je poruka servera izgubljena, klijent zna da je ili ClientHello ili HelloVerifyRequest poruka izgubljena te ponovno odašilje istu poruku. Kada server primi ponovno odaslanu poruku klijenta, zna da treba ponovno poslati svoju poruku odgovora. Primijetimo da se tajmaut i retransmisija ne primjenjuju na HelloVerifyRequest zato što bi to zahtijevalo stvaranje stanja na serveru. HelloVerifyRequest je dizajniran da bude dovoljno malen kako se ne bi mogao fragmentirati, time ne brinući o ostavljanju nekoliko HelloVerifyRequest-ova.
Razmještaj
Kod DTLS-a, svakoj handshake poruci dodijeljen je specifičan slijedni broj unutar tog handshake-a. Kada računalo primi handshake poruku, može brzo utvrditi je li ta poruka sljedeća koju mora primiti. Ako je, obrađuje ju, ako nije, stavlja ju u red za rukovanje (eng. buffer). [5]
DTSL
DTLS koristi gotovo sve protokolne elemente TLS-a s malim, ali značajnim promjenama kako bi pravilno radio s prijenosom datagrama. U ovom je poglavlju opisan protokol DTLS i izmjene u odnosu na TLS.
Sloj zapisa
Kako bi se izbjegla fragmentacija, zahtijeva se da DTLS zapis stane u jedan datagram. Ovaj zahtjev donosi tri prednosti. Prva je ta da se djelomični zapisi ne moraju spremati u buffer pa se memorija domaćina može efikasnije iskoristiti što ga čini manje podložnim na DoS napade. Druga prednost je što pri fragmentaciji, datagrami koji prenose fragmente mogu biti izgubljeni, u tom slučaju su primljeni fragmenti beskorisni i ne mogu se obraditi. I treća prednost je što pri spremanju fragmenata u buffer nije jasno definirano koliko dugo oni trebaju biti čuvani prije nego ih se odbaci, pohranjivanje fragmenata bi dodatno zakompliciralo DTLS implementaciju bez pružanja očitih prednosti. [4]
DTLS-ov sloj zapisa je vrlo sličan onom kod TLS-a 1.2, jedina promjena je uključenje slijednog broja i epoch-a u zapisima. Format DTLS zapisa je prikazan na sljedećoj slici:
type – protokol višeg sloja kojim se procesuira fragment
version – verzija korištenog protokola
epoch – vrijednost koja je uvećana pri svakoj promjeni stanja šifre
sequence_number – slijedni broj zapisa
length – dužina ne bi trebala prelaziti 2^14
fragment – transparentan aplikacijski podatak kojim se rukuje pomoću protokola višeg sloja efiniranog u type polju
DTLS ne koristi implicitan, nego eksplicitan slijedni broj, sadržan u polju zapisa slijedni broj. Svaki započinje od nule za svaku epohu. Primjerice, ako je handshake poruka iz epohe 0 ponovno odaslana, ona može nakon poruke sadržavati slijedni broj iz epohe 1, iako je prvo odaslana poruka iz epohe 0. Kako bi se osigurala jedinstvenost svakog slijednog broja i epohe, implementacije ne smiju dopustiti korištenje iste vrijednosti epohe u razdoblju maksimalnog životnog vijeka segmenta TCP-a.
Nadalje, zbog toga što DTLS zapisi mogu biti razmješteni, zapis iz epohe 1 može biti primljen nakon što je započela epoha 2. Općenito, implementacije bi trebale odbaciti pakete iz prijašnjih epoha, no ukoliko gubitak paketa uzrokuje probleme potrebni materijal može se zadržati za potrebe prerazmještaja paketa.
U posebnim slučajevima ponovljenog handshake-a na postojećoj vezi, sigurno je odmah procesirati paket, iako ChangeCipherSpec ili Finished poruke još nisu primljene, ukoliko je osigurano da ponovljeni handshake nastavlja postojeću sjednicu ili koristi iste sigurnosne parametre kao postojeća veza. U svakom drugom slučaju, primatelj mora čekati Finished poruku kako bi se spriječio napad presretanja mreže.
Transportni sloj
Svaki DTLS zapis mora stati u jedan datagram. Kako bi izbjegli IP fragmentaciju, klijenti DTLS-ovog sloja zapisa trebaju prilagoditi veličinu zapisa kako bi stali u bilo koju PMTU ((eng. Path Maximum Transmission Unit) služi za određivanje maksimalne veličine jedinice prijenosa između dva IP hosta) procjenu sadržanu u sloju zapisa. Neki transportni protokoli, kao što je DCCP ((eng. Datagram Congestion Control Protocol) je transportni protokol koji služi za kontrolu zakrčenosti), pružaju kontrolu zakrčenosti prometa koji se prenosi preko njih. Ukoliko je prozor zakrčenosti dovoljno uzak, ponovljeni prijenos DTLS handshake-a mogao bi biti zadržan, što može dovesti do tajmauta ili lažnih retransmisija. O tome treba brinuti kada se koristi DTLS preko transporta takve vrste.
Handshake protokol
Na slici ispod prikazan je slijed DTLS handshake-a:
DTLS koristi gotovo iste handshake poruke kao i TLS, uz tri glavne promjene:
1. Dodana je razmjena kolačića bez stanja kako bi se spriječili DoS napadi.
2. Modificirano je handshake zaglavlje kako bi se spriječili gubitak, razmještaj i fragmentacija poruka.
3. Dodani su tajmeri za ponovan prijenos kako bi se spriječio gubitak poruka.
Denial-of-service protumjere
Protokoli za sigurnost datagrama su izuzetno podložni raznim DoS napadima. Dva napada su posebno zabrinjavajuća:
1. Napadač može zauzeti mnogo resursa na serveru odašiljući serije inicijalnih handshake zahtjeva zbog čega bi server potencijalno mogao izvesti skupocjene kriptografske operacije.
2. Napadač može koristiti server kao pojačivač šaljući poruke za inicijaciju vezu s krivotvorenim izvorom žrtve. Server tada šalje svoju sljedeću poruku žrtvinom računalu (kod DTLS-a je to Certificate poruka, koja može biti jako velika), time ga preplavljujući.
Kako bi se obranio od ovih napada, DTLS posuđuje tehnologiju kolačića bez stanja koju koriste Photuris (protokol za upravljanje ključevima i sjednicom namijenjen za korištenje s IP sigurnosnim protokolima) i IKE (eng. Internet Key Exchange protokol, komponenta Ipsec-a korištena za izvođenje zajedničkih autentifikacija te uspostavljanje i održavanje sigurnosne povezanosti).
Na sljedećoj slici možemo vidjeti prikaz handshake-a s kolačićem:
Kada klijent pošalje ClientHello poruku serveru, server može odgovoriti HelloVerifyRequest porukom koja sadrži kolačić bez stanja. Klijent mora ponovno poslati ClientHello s dodanim kolačićem nakon čega ga server provjerava i nastavlja s handshake-om samo ukoliko je kolačić valjan. Ovaj mehanizam prisiljava napadača/klijenta da bude u mogućnosti primiti kolačić, što otežava DoS napade s krivotvorenim IP adresama. S druge strane, ne osigurava obranu od istih napada s valjanim IP adresama.
Slijedni broj poruke
Prva poruka koju bilo koja strana odašilje u svakom handshake-u uvijek ima message_seq = 0. Svaki put kad se generira nova poruka, vrijednost message_seq se inkrementira za 1. Ukoliko dođe do ponovnog slanja iste poruke, message_seq ne mijenja vrijednost, kao što vidimo na sljedećoj slici:
DTLS implementacije sadrže next_receive_seq brojač koji je inicijalno postavljen na 0. Kada je poruka primljena, ukoliko njezin slijedni broj odgovara next_receive_seq, isti se povećava za jedan i poruka je obrađena. Ukoliko je slijedni broj manji, poruka mora biti odbačena. Ukoliko je veći, poruka se stavlja u red ili se odbacuje. [5]
Timeout i retransmisija
Budući da DTLS handshake poruke mogu biti izgubljene, potreban je mehanizam za ponovno slanje. DTLS ga implementira pomoću tajmera na svakoj krajnjoj točki, koja ponovo šalje zadnju poruku sve dok nije primljen odgovor. [4]
DTLS poruke su grupirane u serije takozvanih flight (u DTLS-u označava logički grupirane poruke) poruka, prikazane na slici:
Iako se svaki flight može sastojati od nekoliko poruka, na njega se treba gledati kao na jednu cjelinu radi tajmauta i retransmisije.
DTLS koristi jednostavnu shemu tajmauta i retransmisije, prikazanu na slici ispod, sa sljedećim stanjima: budući da klijent šalje prvu poruku, on je u stanju pripreme (eng. preparing state), dok je server u stanju čekanja (eng. waiting state), ali s praznim buffer-om i bez tajmera za ponovno slanje.
Stroj s konačnim brojem stanja ima tri osnovna stanja. U stanju PRIPREME implementacija čini potrebne izračune za pripremu sljedećeg flight-a poruka. Nakon toga ih sprema u buffer za prijenos (ispražnjujući buffer prije toga) i ulazi u stanje slanja. U stanju SLANJA, implementacija prenosi flight poruke iz buffer-a. Kada su poruke poslane, implementacija ulazi u ZAVRŠNO stanje ukoliko se radi o zadnjem flight-u u handshake-u. A ukoliko očekuje primiti još poruka, postavlja tajmer za ponovno slanje i ulazi u stanje ČEKANJA.
Iako su vrijednosti tajmera izbor implementacije, loše rukovanje tajmerom može dovesti do problema zakrčenosti. Primjerice, ako mnogo instanci DTLS-a isteknu rano i brzo se pošalju na zakrčenu vezu. Implementacije trebaju koristiti inicijalnu vrijednost tajmera od jedne sekunde i poduplati tu vrijednost pri svakom ponovnom prijenosu, sve do maksimuma od 60 sekundi. Trebaju zadržati trenutnu vrijednost tajmera sve dok ne dođe do prijenosa bez gubitaka, kada se ta vrijednost može resetirati na inicijalnu. [5]
Implementacija
DTLS je implementiran na osnovi OpenSSL biblioteke i koristi većinu koda iz TLS implementacije, time DTLS nasljeđuje dobro testiran i stabilan kod. OpenSSL je standardna TLS/SSL implementacija otvorenog koda. Modificirani su demo server i klijent aplikacije kako bi odgovarali UDP-u, također je implementiran UDP proxy , koji je sposoban za otpuštanje, odgađanje i dupliciranje paketa. Pri implementaciji DTLS-a dodano je oko 7 000 linija koda osnovnoj distribuciji OpenSSL-a, koja ima ukupno 240 000 linija. [4]
Implementacija je napravljena na operacijskom sustavu Ubuntu 16.04.1 LTS koji je instaliran na virtualnu mašinu kreiranu korištenjem alata VirtualBox . Za programski jezik odabran je Python (verzija 2.7.12) te je korištena PyDTLS (verzija 1.0.1) [8] biblioteka. Biblioteka sadrži metodu čiji poziv dodaje podršku za protokol DTLS u Python ssl [9] biblioteku. Instalacija navedene datoteke napravljena je korištenjem Python paketnog menadžera:
pip install dtls
Projektna struktura sastavljena je od dvije Python datoteke koje predstavljaju server i klijenta te direktorija certs koji sadrži potrebne certifikate i ključeve. Implementacija se bazira na socket serveru koji čeka vezu te kada istu uspostavi čeka i ispisuje poruke koje klijent šalje. Komunikacija je ostvarena prijenosom UDP paketa kroz protokol DTLS.
Izrada certifikata i ključeva
Izrada certifikata i ključeva napravljena je prema uputama koje su dane u službenim man stranicama openssl naredbe koja je dostupna u operacijskom sustavu Ubuntu. Kreirana je konfiguracijska datoteka koja će se koristiti pri izradi certifikata:
Generiranje samopotpisanog CA (eng. Certificate Authority) certifikata:
openssl req –config dtls.cnf –x509 –newkey rsa –nodes –keyout tmp_ca.key –out ca-cert.pem –days 3650
Generiranje zahtjeva za certifikatom (eng. certificate request):
openssl req –config dtls.cnf –newkey rsa –nodes –keyout tmp_server.key –out tmp_server.req
Potpisivanje zahtjeva za certifikatom sa CA certifikatom:
openssl x509 –req –in tmp_server.req –CA ca-cert.pem –CAkey tmp_ca.key –CAcreateserial –days 3650 –out server-cert.pem
Izrada .pem datoteke koja sadrži privatni i javni ključ servera:
cat tmp_server.key server-cert.pem > keycert.pem
Brisanje nepotrebnih datoteka:
rm tmp_* ca-cert.srl
Server
# -*- coding: utf-8 -*-
import sys
import socket
import ssl
from dtls import do_patch
EXIT_WORDS = ('close', 'exit', 'quit', 'bye')
def close_connections():
conn.shutdown(socket.SHUT_RDWR)
conn.close()
wrap.close()
do_patch()
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(('127.0.0.1', 5000))
wrap = ssl.wrap_socket(sock,
server_side=True,
certfile='certs/keycert.pem',
ca_certs='certs/ca-cert.pem',
ssl_version=ssl.PROTOCOL_DTLSv1)
wrap.listen(0)
while True:
try:
acc_ret = wrap.accept()
if acc_ret:
conn, conn_addr = acc_ret
client = ':'.join(map(str, conn_addr))
print '[DTLS Server] Nova veza (%s)' % client
try:
loop = True
while loop:
msg = conn.recv()
if msg.lower() in EXIT_WORDS:
loop = False
print '[DTLS Server] Zatvaram vezu (%s)' % client
else:
print '[DTLS Klijent] %s' % msg
except ssl.SSLError:
print '[DTLS Server] Došlo je do pogreške u radu'
close_connections()
sys.exit(1)
except KeyboardInterrupt:
print '[DTLS Server] Manualni prekid rada'
close_connections()
sys.exit(0)
Za jednostavnu implementaciju socket servera u programskom jeziku Python bilo je potrebno pozvati metodu do_patch iz PyDTLS biblioteke. Kreiran je socket server koji koristi UDP kao transportni protokol te sluša na lokalnoj IPv4 adresi (127.0.0.1) i portu 5000. Nakon toga taj socket je upakiran u SSL kontekst s ranije izrađenim certifikatom i ključem, također eksplicitno je navedeno da se kao protokol komunikacije koristi DTLS. Server u beskonačnoj petlji čeka novu vezu, odnosno klijenta. Kada je veza uspostavljena server u petlji čeka poruku od klijenta te ju ispisuje na ekran. U slučaju da je poruka jedna od, u kodu, navedenih riječi (varijabla EXIT_WORDS) petlja se prekida te server ponovno čeka na novu vezu. Rad servera može se prekinuti slanjem signala SIGINT (CTRL + C na operacijskom sustavu koji je baziran na Unix-u).
Klijent
# -*- coding: utf-8 -*-
import sys
import socket
import ssl
from dtls import do_patch
EXIT_WORDS = ('close', 'exit', 'quit', 'bye')
def close_connections():
wrap.shutdown(socket.SHUT_RDWR)
wrap.close()
do_patch()
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
wrap = ssl.wrap_socket(sock,
server_side=False,
ssl_version=ssl.PROTOCOL_DTLSv1)
try:
wrap.connect(('127.0.0.1', 5000))
msg = ''
while msg.lower() not in EXIT_WORDS:
msg = raw_input('Poruka: ')
if msg.strip() is not '':
wrap.send(str(msg))
close_connections()
sys.exit(0)
except ssl.SSLError:
print '[DTLS Klijent] Server nije dostupan'
close_connections()
sys.exit(1)
except KeyboardInterrupt:
print '[DTLS Klijent] Manualni prekid rada'
wrap.send('close')
close_connections()
sys.exit(0)
Na klijentskoj strani je također potrebno pozvati metodu do_patch iz PyDTLS biblioteke. Zatim je kreiran socket koji koristi UDP kao transportni protokol. Socket je upakiran u SSL kontekst te je eksplicitno navedeno da se kao protokol komunikacije koristi DTLS. Klijent pokuša otvoriti vezu prema serveru kojeg očekuje na lokalnoj IPv4 adresi (127.0.0.1) i portu 5000. Ako se uspostavi veza omogućuje se upis i slanje poruka prema serveru dok god poruka nije jedna od, u kodu, navedenih riječi (varijabla EXIT_WORDS). Rad klijenta može se prekinuti slanjem signala SIGINT (CTRL + C na operacijskom sustavu koji je baziran na Unix-u).
Zaključak
DTLS je sigurnosni protokol baziran na dobro znanom protokolu TLS. Dok TLS ovisi o pouzdanom transportnom kanalu (najčešće TCP-u), DTLS može podupirati nepouzdane transporte kao što je UDP. Inače je gotovo identičan TLS-u i podržava iste kriptografske mehanizme. Svaka DTLS veza započinje razmjenom handshake-a, tijekom kojeg se računala autentificiraju i pregovaraju o algoritmima, modovima, i drugim parametrima te dogovaraju način razmjene ključeva. Kako bi se osigurao nepouzdani transport, svaka strana održava tajmere za ponovno slanje u svrhu pouzdane dostave poruka. Kada je handshake završio, kriptirani podaci mogu biti poslani. Podaci su zaštićeni tako što su poslani u serijama DTLS zapisa. Ti su zapisi međusobno neovisni i mogu biti uspješno obrađeni čak i kada dođe do gubitka ili razmještaja. [7]
TCP nije dobar za komunikaciju u realnom vremenu jer usporava slanje poruka zbog kontrole zakrčenja. SSL/TLS ne mare za gubitak ili razmještaj podataka jer su pokrenuti na TCP-u i računaju na njega da se brine o tome. Potreba za autentifikacijom i privatnošću TLS-a, ali u isto vrijeme i rad u realnom vremenu kojeg omogućuje UDP dovode do nastanka protokola DTLS. [6]
Najvažnija dodatna sigurnosna mjera DTLS-a je zaštita od denial-of-service napada. DTLS uključuje razmjenu kolačića kojom se štiti od ovih napada. Za razliku od TLS implementacija, DTLS implementacije ne trebaju nevažećim zapisima odgovoriti prekidom veze. [5]
Literatura
[1] Web Application Security Consortium: Threat Classification. Dostupno na: http://projects.webappsec.org/f/WASC-TC-v1_0.pdf [09.01.2017.]
[2] Wikipedia: Real-time computing. Dostupno na: https://en.wikipedia.org/wiki/Real-time_computing [09.01.2017.]
[3] TechTarget: Real-time application. Dostupno na: http://searchunifiedcommunications.techtarget.com/definition/real-time-application-RTA [09.01.2017.]
[4] Modadugu N., Rescorla E.: The Design and Implementation of Datagram TLS. Dostupno na: https://crypto.stanford.edu/~nagendra/papers/dtls.pdf [09.01.2017.]
[5] Internet Engineering Task Force: Datagram Tranport Layer Security Version 1.2. Dostupno na: https://tools.ietf.org/html/rfc6347 [09.01.2017.]
[6] Wikipedia: Datagram Transport Layer Security. Dostupno na: http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security [09.01.2017.]
[7] Internet Engineering Task Force: Datagram Tranport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP). Dostupno na: https://tools.ietf.org/html/rfc5764 [09.01.2017.]
[8] Python: Dtls 1.0.1. Dostupno na: https://pypi.python.org/pypi/Dtls/1.0.1 [09.01.2017.]
[9] Python: ssl 1.16. Dostupno na: https://pypi.python.org/pypi/ssl [09.01.2017.]
