UTOK | Hello 7Q | Získanie prístupu k šifrovanej komunikácii

2015
http://excel.fit.vutbr.cz
Získanie prístupu k šifrovanej komunikácii
Miroslav Slivka*
Legitímna
SSL/TLS relácia
Podvrhnutá
SSL/TLS relácia
Užívateľ
MiddleMan / Proxy
Server
Abstrakt
Táto práca sa zaoberá sprístupnením šifrovanej komunikácie pre nástroj Netfox, ktorý vzniká
na Fakulte informaˇcních technologií, VUT v Brneˇ pod záštitou bezpeˇcnostného výskumu
(VG20102015022) - SEC6NET. Okrem analýzy SSL/TLS protokolu je v práci popísaný spôsob
útoku na šifrované spojenie, návrh a implementácia modulu, ktorý za pomoci súkromného kl’úˇca
serveru dešifruje danú SSL/TLS reláciu a testovanie implementovaného riešenia. Algoritmy šifrovaˇ
nia poskytla nástroju externá knižnica Bouncy Castle. Výsledný modul sprístupnuje
šifrovanú
komunikáciu pre d’alšie spracovanie a extrakciu dát v dešifrovanej podobe.
ˇ
Kl’úcové
slová: SSL — TLS — šifrovaná komunikácia — Netfox
Priložené materiály: N/A
*xslivk02@stud.fit.vutbr.cz, Faculty of Information Technology, Brno University of Technology
ovom rozhraní tak, ako chodí na sieti, nástroje tohto
projektu sa snažia zo zachytenej komunikácie extrahoMnožstvo komunikácie na dnešnom Internete je prenášané vat’ aplikaˇcné dáta a tie analyzovat’.
šifrovane. K zavedeniu šifrovania viedli napríklad regHl’adat’ nedostatky v samotných algoritmoch alebo
ulaˇcné opatrenia, ktoré vyžadujú aby citlivé informáie použit’ útok hrubou silou by zabralo množstvo cˇ asu.
boli prenášané šifrovane. Taktiež šifrované spojenie Pre spracovanie v reálnom cˇ ase je nutné hl’adat’ iné
potrebovali l’udia, ktorí musia pristupovat’ na internet možnosti. Ako efektívne riešenie sa ukázalo získat’
ˇ
anonymne, napríklad obyvatelia Cíny.
Dnes asi na- prístup k súkromnému kl’úˇcu serveru a pomocou neho
jpoužívanejším protokolom, ktorý poskytuje šifrované potom danú TLS/SSL reláciu dešifrovat’. Táto práca
spojenie, je protokol TLS. Okrem šifrovanej komu- rieši problém ako sa dostat’ k súkromnému kl’úˇcu sernikácie tento protokol zabezpeˇcí, aby sa komunikujúce veru, ku ktorému normálne nemáme prístup a potom
strany dohodli na spoloˇcnom tajnom kl’úˇci symetrickej tento kl’úˇc použit’ na získanie ostatných parametrov
kryptografie pomocou asymetrickej kryptografie, prí- relácie a túto reláciu pomocou získaných znalostí dešifrovat’.
padne sa navzájom autentizovali. Asymetrická krypDoposial’ projekt Netfox dešifrovanie neriešil. S vytografia vd’aka svojím vlastnostiam slúži aj na autenti- užitím tohto modulu budú nástroje rodiny Netfox mat’
zovanie.
možnost’ analyzovat’ aj šifrované dáta. Inšpiráciu pri
Tento projekt vzniká ako TLS/SSL dešifrovací implementovaní je možné do urˇcitej miery nabrat’ v
modul väˇcšieho nástroja Netfox.Framework[1]. Nástroje projekte Wireshark, ktorého zdrojové kódy sú verejne
rodiny Netfox vznikajú za úˇcelom analýzy zachytenej dostupné. Avšak implementaˇcne sú tieto dva projekty
komunikácie. Na rozdiel napríklad od nástroju Wire- pomerne odlišné.
shark, ktorý sa používa na analýzu prevádzky na siet’Prvá kapitola sa zaoberá analýzou SSL/TLS komu-
1. Úvod
ˇ
nikácie. Citatel’a
oboznámi so správami vyžadovanými
pre zostavenie šifrovaného spojenia a struˇcne rozoberie
jeho princíp. Druhá kapitola pojednáva o útokoch na
SSL/TLS komunikáciu. V tretej kapitole je popis algoritmu dešifrovania SSL/TLS relácie ako je implementovaný v module, o ktorom je táto práca. Štvrtá
kapitola popisuje testovanie implementovaného modulu. Na prípravu testovacích dát sa vhodne použijú
informácie z kapitoly 3.
Obrázok 1. Protokolový zásobník SSL. Zdroj:
W. Stallings, 1998. [4]
Inicializácia
Po výmene Hello správ nasleduje autentizaˇcná
cˇ ast’. Táto fáza je v RFC definovaná ako nepovinná.
Autentizaˇcnú cˇ ast’ môžeme rozdelit’ na autentizáciu
serveru a autentizáciu klienta. Autentizácia serveru
je obalená medzi správy Server Hello a Server Hello
Done. Autentizácia klienta prebieha vždy až po autentizácii serveru.
Server teda pokraˇcuje v posielaní správy Certificate. Táto správa obsahuje sekvenciu certifikátov. Na
2. Analýza SSL/TLS komunikácie
zaˇciatku sekvencie je odosielatel’ov certifikát a každý
Transport Layer Security (TLS) protokol je IETF štand’alší certifikát musí autentizovat’ ten predchádzajúci.
dard navrhnutý na poskytnutie bezpeˇcnej komunikácie
Ked’že validácia certifikátov je založená na koreˇnových
cez Internet (najnovšie v RFC 5246 [2]). Predchodcom
certifikátoch, ktoré nie sú podpísané, tak koreˇnový cerTLS je Secure Socket Layer (SSL) protokol (vid’ RFC
tifikát v tejto sekvencii nie je. Oˇcakáva sa, že druhá
6101 [3]). TLS bol navrhnutý ako vylepšnie SSL a
strana tento certifikát má.
stal sa široko používaným protokolom poskytujúcim
Následne môže byt’ odoslaná správa Server Key
bezpeˇcnú komunikáciu pre webové aplikácie.
Exchange, ak server nemá certifikát alebo certifikát
SSL/TLS je vrstvový protokol, ktorý definuje d’alšie
je urˇcený len pre podpisovanie. Táto správa teda obprotokoly (vid’ Obrázok 1).
sahuje nejaký verejný kl’úˇc, ku ktorému má server
Na vyjednanie parametrov šifrovanej relácie sa
súkromný kl’úˇc.
používa Handshake protokol. Handshake protokol
Klient
Server
môžeme rozdelit’ na tri cˇ asti (vid’ Obrázok 2): inicializaˇcnú, autentizaˇcnú a ukonˇcenie handshaku.
client_h
ello
V inicializaˇcnej fáze klient posiela správu Client
Hello, na ktorú server musí odpovedat’ správou Server
hello
server_
Hello. Tieto správy sú použité na zvolenie najbezpeˇcnejších možností, ktoré podporujú obe strany. Vyjednajú sa nasledujúce parametre:
ertificate
c
–
–
–
–
metóda na výmenu kl’úˇcov,
autentizaˇcná metóda,
symetrická šifra,
message authentication code (MAC), na
kontrolu integrity,
certifica
te
client_ke
y_excha
• kompresný algoritmus,
• náhodné hodnoty
(client.random a server.random)
nge
certifica
te_verify
change
Change
Cipher
Spec Protocol
_cipher_
Alert
Protocol
HTTP
spec
finished
change_
SSL Record Protocol
pec
cipher_s
Ukončenie
SSL
Handshake
Protocol
Autentizácia
ange
ey_exch
server_k
est
te_requ
certifica
one
hello_d
server_
• verzia protokolu,
• ID relácie,
• CipherSuite
finished
TCP
Obrázok 2. Prehl’ad komunikácie SSL/TLS
IP
handshake
Server môže vyžiadat’ autentizáciu po klientovi
pomocou správy Certificate Request. Následne server
odošle správu Server Hello Done, ktorá indikuje ukoncˇ enie inicializaˇcnej fázy handshake protokolu.
Na správu Certificate Request klient musí odpovedat’ správou Certificate. Inak je odoslaná správa
Client Key Exchange, ktorej obsahom je zašifrovaná
hodnota pre-master secret verejným kl’úˇcom algoritmu
zvoleného v inicializaˇcnej fáze. V prípade použitia Diffie-Hellman Ephemeral [5] správa obsahuje zašifrovaný verejný exponent tohto algoritmu. Pri použití
statickej verzie Diffie-Hellman, klient posiela certifikát
obsahujúci statický exponent a táto správa musí byt’
prázdna. Správa Certificate Verify sa posiela ak klient
poslal certifikát s možnost’ou podpisu. Touto správou
klient potvrdí, že je držitel’om súkromného kl’úˇca toho
certifikátu. V tejto správe sa použijú všetky správy
handshaku odoslané a prijaté do tejto chvíle.
Pomocou hodnoty pre-master secret sa vygeneruje
master secret používaný na vypoˇcítanie tzv. key material. Z key material sa potom cˇ ast’ použije ako kl’úˇc
symetrickej šifry, cˇ ast’ ako inicializaˇcný vektor a cˇ ast’
ako kl’úˇc HMAC funkcie.
V ukonˇcovacej fáze sa odosiela správa Change
Cipher Spec, ktorá oznamuje, že nasledujúce správy
budú odosielané šifrovane. Táto správa nepatrí do
handshake protokolu.
Správa Finished je poslednou správou handshake
protokolu a zároveˇn prvou šifrovanou správou. Je
šifrovaná šifrou, ktorá je inicializovaná dohodnutými
parametrami. Ako odpoved’ server odošle tiež správu
Change Cipher Spec a rovnako aj Finished šifrovanú
vyjednanými parametrami. Po tejto výmene klient a
server majú nadviazavané šifrované spojenie a môžu
pomocou neho komunikovat’.
Po ustanovení relácie sa šifrované dáta prenášajú
Record protokolom.
3. Útok na SSL/TLS komunikáciu
Pre získanie prístupu k dátam prenášaným v TLS/SSL
existujú dva základné prístupy, ktoré spomínajú aj
S. Davidoff a J. Ham, 2012 [6].
• Prvou možnost’ou je získat’ privátny kl’úˇc serveru na získanie kl’úˇcov relácie a dešifrovanie
obsahu. To ale závisí na algoritme použitom
na výmenu kl’úˇcov a taktiež je nutný prístup k
súkromnému kl’úˇcu serveru.
• Druhou možnost’ou je ukonˇcit’ TLS/SSL reláciu niekde na proxy a nadviazat’ novú SSL/TLS
reláciu smerom od proxy ku klientovy. Pri tomto
prístupe je dôležité mat’ prístup ku klientskej
stanici za úˇcelom nainštalovania certifikátu proxy
serveru. Inak užívatel’ klientskej stanice môže
dostat’ upozornenie od systému na potenciálny
útok Man-In-The-Middle.
Ak existuje prístup k súkromnému kl’úˇcu serveru,
pomocou neho je možné dešifrovat’ hodnotu pre-master
secret odoslanú klientom a získat’ kl’úˇce relácie. Na to
je potrebné mat’ prístup ku kompletnému obsahu handshake fáze TLS/SSL a následnej výmene dát vytvorenou reláciou. Súkromný kl’úˇc serveru pri dešifrovaní
prevádzky nepomôže ak bol na výmenu kl’úˇcov zvolený algoritmus Diffie-Hellman Ephemeral. Ten používa špeciálnu schému generovania hodnoty pre-master
secret, kde pre každú novú reláciu generuje nové súkromné hodnoty. Táto verzia sa používa v kombinácii
s iným asymetrickým algoritmom, ktorý zabezpeˇcí autentizáciu. Teda verejné hodnoty Diffie-Hellman sú
podpísané súkromným kl’úˇcom.
Princíp s proxy funguje tak, že celá komunikácia s vonkajším svetom smeruje cez proxy. Ak chce
server komunikovat’ cez TLS/SSL s nejakým klientom, tak TLS/SSL odpovede serveru sú ukonˇcené na
proxy a proxy udržuje šifrované spojenie so serverom.
Na strane ku klientovi proxy poskytuje falošný certifikát serveru a zostaví druhý TLS/SSL tunel. Potom proxy môže prehliadat’ prevádzku v dešifrovanej
podobe alebo posielat’ túto prevádzku na iný systém
k d’alšej analýze. TLS/SSL je navrhnuté na ochranu
proti tomuto typu útoku. Ide vlastne o Man-In-TheMiddle. Teda certifikát proxy serveru nebýva podpísaný dôveryhodnou CA a používatel’ovi na klientskej stanici sa zobrazujú varovania. Tomu sa dá predíst’
nainštalovaním certifikátu proxy servera medzi dôveryhodné koreˇnové certifikáty na klientovi (obeti).
SSLsplit[7] je aplikácia vytvorená Daniel Roethlisbergerom a distribuovaná pod zjednodušenou BSD
Licenciou. SSLsplit ukonˇcuje TLS/SSL spojenia a
vytvára nové smerom k pôvodnej ciel’ovej adrese a
zároveˇn loguje celú prevádzku. Je možné si zvolit’
šifry, ktoré sa majú používat’, rovnako aj privátny kl’úˇc,
ktorým sa majú podpisovat’ falšované certifikáty. Na
správne fungovanie je potrebné nastavit’ IP forwarding1 .
SSLstrip[8] je nástroj vytvorený Moxie Marlinspike a je distribuovaný pod licenciou GNU GPLv3.
Implementuje útok podobný ako SSLsplit, s tým rozdielom, že relácia medzi obet’ou a útoˇcníkom prebieha
nešifrovane.
1 https://www.kernel.org/doc/Documentation/networking/ip-
sysctl.txt
NewMessage()
called
No More Messages / False
Client Hello
Negotiation Init
No More Msgs / False
Server Hello
No More Msgs / False
Negotiation
Client Hello
Client Key Exchange
Intermezzo
Decryption Failed
Decryption Success / True
Data Exchange
Decryption Success / True
Obrázok 3. Stavový automat modulu PDUDecrypter
4. Návrh a implementácia dešifrovania
Projekt Netfox.Framework[1] je modulárny systém,
ktorý sa stará o spracovanie PCAP súborov a ich analýzu. Súˇcast’ou frameworku je reassembling packetov (spojenie súvisiacich rámcov do jednej štruktúry,
postaranie sa o znovuzasielanie a pod.) a vytváranie
konverzácií. Konverzácia v Netfox.Framework je identifikovaná zdrojovou a ciel’ovou IP adresou, zdrojovým
a ciel’ovým portom a protokolom siet’ovej vrstvy. Konverzácie sú ale iba aproximácie TCP relácií, získaných
z komunikácie, ktorá môže byt’ aj nekompletná. Pred
vstupom do modulov, ktoré analyzujú danú komunikáciu sa reassemblované PDU naˇcítajú pomocou modifikovanej triedy System.IO.Stream. Trieda implementujúca dešifrovanie bude postavená na rovnaké
miesto v spracovaní. Vstupom teda sú reassemblované
L7 PDU, ktoré sú obsahom konverzácie. A výstupom
sú dešifrované dáta ako prúd bytov.
Na Obrázku 3 je stavový diagram, ktorý reprezentuje princíp algoritmu. Vstupným bodom je metóda
NewMessage(), ktorá pri každom zavolaní dešifruje
jednu správu a pripraví ju na cˇ ítanie. Návratová hodnota metódy je True ak existuje d’alšia dešifrovaná
správa na cˇ ítanie, False ak nebolo možné dešifrovat’
žiadnu d’alšiu správu. Táto metóda principiálne implementuje koneˇcný automat, aktuálne so štyrmi stavmi:
• Init - decrypter zatial’ nie je nainicializovaný
parametrami relácie,
• Negotiation - decrypter je nainicializovaný
algoritmami, ale cˇ aká sa na vyjednanie tajného
kl’úˇca (správa Client Key Exchange),
• Intermezzo - medzistav po inicializácii, v
ktorom sa dešifruje prvá správa,
• Data Exchange - v tomto stave sa dešifrujú
správy.
Ak bude potrebné zohl’adnit’ autentizaˇcnú cˇ ast’, je
možné pridat’ d’alší stav pred Intermezzo, v ktorom
sa budú spracovávat’ požadované správy. V momentálnej implementácii je podporovaný algoritmus na
výmenu kl’úˇcov RSA, pri ktorom z hl’adiska dešifrovania autentizaˇcnú cˇ ast’ nie je potrebné riešit’.
Tento stavový automat je uzavretý v cykle, ktorý sa
ukonˇcí po prechode do stavu Data Exchange, aby
pri každom zavolaní metódy NewMessage() bola
dešifrovaná nejaká správa.
V prvom stave Init sa cˇ aká na Hello správy od
klienta a od serveru, z ktorých sa získajú potrebné
parametre (náhodné cˇ ísla, a CipherSuite). Z popisu
CipherSuite sa nainicializuje trieda KeyDecrypter,
starajúca sa o dešifrovanie kl’úˇca (pre-master secret) a
trieda DataDecrypter, ktorá sa postará o dešifrovanie samotných správ. Tieto dve triedy sú abstraktné,
a ich implementácia závisí od konkrétneho šifrovacieho algoritmu. Na ich implementáciu bola použitá
knižnica BouncyCastle [9].
Po prijatí správy Server Hello sa prechádza do
stavu Negotiation. V tomto stave automat zotrvá
po dobu, kým nedostane správu Client Key Exchange.
Pomocou triedy KeyDecrypter, sa dešifruje hodnota pre-master secret. Z tejto hodnoty sa pomocou
PRF popísanej v RFC 2246 [10] pre TLS v1.0 a TLS
v1.1, a v RFC 5246 [2] pre TLS v1.2 získa tzv. key
material. Pomocou tohto materiálu sa nainicializujú
HMAC a symetrická šifra v triede DataDecrypter.
Medzi prechodom z inicializaˇcných stavov do stavov, ktoré dešifrujú komunikáciu, je potrebné dešifrovat’
taktiež správu Finished. To je dôležité pri použití prúdových šifier, napr. RC4, ktorých vnútorný stav sa
mení (de)šifrovaním každého bytu. Finished správa je
šifrovaná, jediné cˇ o vieme zistit’ po prijatí je, že patrí
do Handshake protokolu. Vieme však, že je odosielaná
bezprostredne po správe Change Cipher Spec. Na to
sa spolieha aj algoritmus.
Po tomto kroku algoritmus prechádza do stavu
Intermezzo. Tento stav vykonáva rovnaké kroky
ako stav Data Exchange. Ak by automat prechádzal zo stavu Negotiation priamo do stavu Data
Exchange, cyklus v ktorom je stavový automat uzavretý (a metóda NewMessage()) by mohol skonˇcit’
bez dešifrovania správy. Zároveˇn tento stav rieši situáciu ak sa do konverzácie dostane nejaká nedešifrovatel’ná správa. Teda automat sa neprepne do stavu
Data Exchange, kým sa nepodarí dešifrovat’ nejakú správu.
Po prechode do stavu Data Exchange sa cyklus automatu skonˇcí. Stav však ostane zachovaný, a pri
d’alšom volaní metódy NewMessage() sa vykoná
cyklus iba raz a jeho výstupom bude dešifrovaná správa.
Automat však môže prejst’ do iného stavu aj ked’ je už
v Data Exchange. Napríklad v prípade SSL Alert
protokolu, cˇ i zmene parametrov relácie.
Pri parsovaní SSL/TLS správy modul zist’uje kol’ko
bytov SSL/TLS správa obsahuje. Tu sa môže vyskytnút’ situácia kedy v reassemblovanom PDU nie je
dostatok bytov, respektíve je ich viac. Popisovaný
modul túto situáciu rieši tak, že skontroluje ohlásenú
d´lžku SSL/TLS správy a porovná ju s množstvom bytov, ktoré dostane zo správy. Ak ich nie je dost’, dáta
uloží do doˇcasného pol’a (ContinuationData) a
dáta z nasledujúceho paketu sa potom prilepia za ne.
Podobne je vyriešené ak je dát v správe viac ako je
treba, s tým rozdielom, že dáta z pôvodnej správy
sa orežú a prebytoˇcné dáta sa po prijatí nasledujúcej
správy prilepia pred nˇ u.
5. Testovanie
Testovanie implementovaného riešenia prebehlo pomocou Unit Testov.
Priebeh SSL/TLS komunikácie sa dá rozdelit’ na
niekol’ko testovatel’ných cˇ astí, ktoré preveria správne
dešifrovanie SSL/TLS relácie:
• Výmena kl’úˇcov. SSL/TLS protokol môže použit’ na výmenu kl’úˇcov rôzne algoritmy asymetrickej kryptografie. Pre každý implementovaný
algoritmus je vytvorený osobitný test. V rámci
testu sa triede implementujúcej daný algoritmus
pošle správa Client Key Exchange a preverí sa
správnost’ získaného kl’úˇca na základe informácií z Wireshark-u.
• Generovanie kl’úˇca symetrickej kryptografie.
Kl’úˇc symetrickej kryptografie sa generuje v
dvoch krokoch, v oboch sa ale používa rovnaká
funkcia (PRF). Implementácia tejto funkcie sa
mení podl’a verzie protokolu.
• Dešifrovanie správy. Testovanie samotnej implementácie šifrovacieho algoritmu nemá zmysel, ked’že ako implementácia týchto šifrovacích
algoritmov bola využitá externá knižnica. Má
ale zmysel otestovat’, že sa implementovanými
krokmi skutoˇcne dostaneme k dešifrovanej správe.
Na overenie správnosti implementácie triedy
PDUdecrypter sa otestuje dešifrovanie jednej relácie SSL/TLS. Overí sa poˇcet dešifrovaných správ a vybratá cˇ ast’ dešifrovaného prúdu
dát. Tento postup sa použije pre všetky implementované symetrické šifry.
Vstupné a referenˇcné hodnoty testov boli získané
z debugovacích výstupov Wireshark-u, konkrétne modulu SSL dissector. Vo Wireshark-u sa tento modul
stará práve o dešifrovanie SSL/TLS relácií. Testovacie
dáta2 boli nazbierané využitím znalostí z kapitoly 3.
Úspešné testy zobrazuje Tabul’ka 1.
Tabul’ka 1. Úspešné testy modulu PDUDecrypter
Popis testu
Test chovania PRF metódy v TLS v1.0 a TLS v1.1
Test chovania PRF metódy v TLS v1.2
Získanie hodnoty pre-master secret zo správy Client
Key Exchange - RSA
Test dešifrovania - AES v CBC režime
Test dešifrovania - RC4
Neúspešné testy zobrazuje Tabul’ka 2.
Tabul’ka 2. Neúspešné testy modulu PDUDecrypter
Dôvod zlyhania
Popis testu
Test dešifrovania - AES v Obmedzenie
knižnice
režime GCM
BouncyCastle (využit’ inú
knižnicu)
6. Záver
Táto práca sa zaoberala TLS/SSL komunikáciou a jej
dešifrovaním pre použitie v projekte Netfox. V práci
bol navrhnutý modul dešifrovania, ktorý bol následne
implementovaný a aktuálne je testovaný. Naimplementované sú niektoré symetrické šifry a asymetrický
algoritmus RSA, ktorý sa používa na výmenu kl’úˇcov.
ˇ
Dalším
pokraˇcovaním je implementácia ostatných
verzií protokolu (napr. DTLS) a šifrovacích algoritmov.
Zahrnutie autentizaˇcnej cˇ asti TLS/SSL handshaku pre
budúcu implementáciu statickej verzie Difiie-Hellman.
Výstupom je kompletný modul dešifrovania použitý
v projekte Netfox. V prípade prístupu k privátnemu
kl’úˇcu serveru dovol’uje Netfoxu extrakciu a analýzu
šifrovaných dát. Ked’že tento privátny kl’úˇc nie je
bežne dostupný, je možné pôvodnú SSL/TLS reláciu
ukonˇcit’ na nejakom bode medzi klientom a serverom
(proxy), nahradit’ pôvodný privátny kl’úˇc vlastným, a
2 http://1drv.ms/1Cmg3es
Legitímna
SSL/TLS relácia
Podvrhnutá
SSL/TLS relácia
Užívateľ
MiddleMan / Proxy
Server
Obrázok 4. Možnosti nástroja Netfox.Framework s
implementovaným modulom.
nadviazat’ novú SSL/TLS reláciu od proxy ku klientovy. Popisované nové možnosti spojené s týmto modulom sú na obrázku 4.
Tento modul rozširuje možnosti rodiny nástrojov
Netfox v oblasti forenznej analýzy poˇcítaˇcových sietí
a zákonných odposluchov.
Literatúra
[1] Jan Pluskal. Framework for captured network
communication. diplomová práce, FIT VUT v
Brnˇe, Brno, 2014.
[2] T. Dierks and E. Rescorla. The Transport Layer
Security (TLS) Protocol Version 1.2. RFC 5246,
RFC Editor, August 2008.
[3] A. Freier, P. Karlton, and P. Kochar. The Secure
Socket Layer (SSL) Protocol Version 3.0. RFC
6101, RFC Editor, August 2011.
[4] William Stallings. Cryptography and Network
Security. Prentice Hall, 1998.
[5] E. Rescorla. Diffie-Hellman Key Agreement
Method. RFC 2631, RFC Editor, June 1991.
[6] S. Davidoff and J. Ham. Network Forensics. Prentice Hall, 2012.
[7] Daniel Roethlisberger. Sslsplit - transparent and
scalable ssl/tls interception. https://www.
roe.ch/SSLsplit, 2015 cit. 2015-03-23.
[8] Moxie Marlinspike.
Moxie marlinspike » software » sslstrip.
http:
//www.thoughtcrime.org/software/
sslstrip/, 2012 cit. 2015-03-23.
[9] The legion of the bouncy castle. https://
www.bouncycastle.org/, 2013 cit. 201503-23.
[10] T. Dierks and C. Allen. The TLS Protocol Version 1.0. RFC 2246, RFC Editor, January 1999.
Download PDF