SSL: Man ln Mlddle ALLack

!
! ! !

Ceorala lnsLlLuLe of 1echnoloav
ALlanLa, Ceorala 30308
L-Mall: cazv[onesamall.com
mkare3mall.aaLech.edu
ro[ecL 8eporL
AuLhored 8v: unmesh v. ueolekar, Mohll khare
!"#$#%&#'!()!*++,!
SSL: Man ln Mlddle ALLack
-.'#%!/012%!
! ! !



!

Sr no. INDEX a no.
1. AbsLracL 1
2. lnLroducLlon 2
3. SSL nC8MAL SLSSlCn 3
4. Ml1M A11ACkS Cn SSL 3
3. Cu8 A8CACP 6
6. 8LvLn1lCn Cl Ml1M A11ACkS 7
7. 8LlL8LnCLS 8

SSL: Man ln Mlddle ALLack
-.'#%!/012%!
! ! !



"#$%&'(%)

TCP/IP protocols have long been subject to man-in-the-middle (MITM) attacks, but the introduction of
SSL/TLS was supposed to mitigate that risk by providing endpoint authentication and encryption, in web
transactions. Since the use of proxy servers is being welcomed as a way to provide increased network security
and improved performance, the type of attacks pertaining to this domain needs to be understood. This project
focuses on the greater risk of SSL attacks when the client is not properly implemented or configured. It is
shown that SSL/TLS could be subjected to man-in-the-middle attacks using (forged) proxy servers.



























-1-
SSL: Man ln Mlddle ALLack
-.'#%!/012%!
! ! !



*+,)!-.%&/01(%2/.!
!
he MITM is a type of attack in which the attacker eavesdrops and independent connections with
the victims and relays messages between them, fooling them to believe that they are talking
directly to each other over a private connection when in fact they are talking to the attacker(in middle).
SSL/TLS are protocols which provide cryptographic security over internet. SSL when used with HTTP forms
HTTPS. HTTPS is used to secure World Wide Web pages .SSL-encrypted web sessions authenticate the
server to the client using a PKI x509 certificate. Since the server does not authenticate the client, the SSL
protocol for web transactions is inherently susceptible to man-in-the-middle attack (MITM). These types of
attacks to an extent depend on social engineering.























-2-

T
SSL: Man ln Mlddle ALLack
-.'#%!/012%!
! ! !



3+,)!445!6789"5!4:44-76!

The communication starts with handshake signals. Using these handshake signals the client and server
negotiate on various parameters used to establish connections security. The handshake begins when a client
connects to a TLS/SSL-enabled server requesting a secure connection, and presents a list of supported
ciphers and hash functions. From this list, the server picks the strongest cipher and hash function that it also
supports and notifies the client of the decision. The server then sends back its digital certificate for
authenticating itself. The certificate usually contains the server name, the trusted certificate authority (CA), and
the server's public encryption key. In order to generate the session keys used for the secure connection, the
client encrypts a random number with the server's public key, and sends the result to the server. Only the
server can decrypt it because the private key is available with server only. From the random number, both
parties generate key material for encryption and decryption. Finally, the Client sends an encrypted Finished
message, containing a hash and MAC over the previous handshake messages. The Server will attempt to
decrypt the Client's Finished message, and verify the hash and MAC. The Server sends its encrypted
Finished message, and the Client performs the same decryption and verification. If any one of the above
steps fails, the SSL/TLS handshake fails, and the connection is not created. The purpose of the Finished
message is to provide added security. Following is the diagrammatic representation of the above mentioned
handshake protocol:






-3-
SSL: Man ln Mlddle ALLack
-.'#%!/012%!
! ! !




SSL: Man ln Mlddle ALLack
-.'#%!/012%!
! ! !





"!#$%&'()!*"+!,&-.!//*!01%)2123-(-&43!

!
;+,)!9-<9!"<<"=>4!76!445!

A proper web-browslna cllenL wlll warn Lhe user of cerLlflcaLe problems lf anv of Lhe followlna are noL Lrue:
A. 1he cerLlflcaLe has been slaned bv a recoanlzed cerLlflcaLe auLhorlLv.
8. 1he cerLlflcaLe ls currenLlv valld and has noL explred.
C. 1he common name on Lhe cerLlflcaLe maLches Lhe unS name of Lhe server.
A Lvplcal aLLack would conslsL of Lhe followlna scenarlo:
a) All Lhe lnLerneL Lrafflc from Lhe cllenLs ls rouLed vla a proxv server, whlch ls aLLackers machlne. A8 polsonlna
lnlLlallzes Lhls Lvpe of aLLack. 8v polsonlna, Lhe cllenL ls fooled wlLh Lhe MAC address of Lhe aLLackers proxv lnsLead of
aaLewav's MAC address. 1he aLLacker can Lhen seL up hls own cerLlflcaLe auLhorlLv and load LhaL rooL cerLlflcaLe lnLo Lhe
vlcLlm's LaraeL browser. lf an aLLacker has access Lo a mlsconflaured svsLem, sav, ln a mulLl-user work area or publlc
access Lermlnal ln a llbrarv Lhen he can load hls own rooL cerLlflcaLes and laLer aLLack Lhe LaraeL offllne".

SSL: Man ln Mlddle ALLack
-.'#%!/012%!
! ! !




b) Some browsers handle hLLps Laas ln lmproper fashlon. lor lnsLance lf a mallclous u8L ls conflaured ln place of lmaae
paLh Lhe cllenL wlll access Lhe aLLackers webslLe ln order Lo access LhaL ob[ecL.

?+,)!7@8!"AA87"=B!

We lnLroduced our own [ava-based SSL proxv server, whlch acLs as a "man ln Lhe mlddle". 1he browser of Lhe cllenL
(vlcLlm) ls conflaured Lo use Lhls server as a proxv server Lo connecL Lo lnLerneL. When user connecLs Lo lnLerneL uslna
Lhls proxv, P11S requesLs are rouLed vla Lhls proxv Lo Lhe remoLe webserver. roxv server llsLens Lo Lhe cllenL requesLs
Lo connecL Lo Lhe remoLe webserver. lL Lhen obLalns Lhe remoLe websevrer cerLlflcaLe. 1he server Lhen creaLes a fake
copv of Lhe cerLlflcaLe:
-Sub[ecL un, Serlal number, LxLenslons are kepL Lhe same
-lssuer, ubllc kev, SlanaLure are chanaed
Following is the diagrammatic representation of the above mentioned topology:

*"+!52-6%!,&-.!7849$!/28:28!
-6-
SSL: Man ln Mlddle ALLack
-.'#%!/012%!
! ! !



1he cllenL ls fooled lnLo bellevlna Lhls foraed cerLlflcaLe as Lhe aenulne SSL server cerLlflcaLe .1he server cerLlflcaLes
presenLed Lo Lhe cllenL are dvnamlcallv aeneraLed/slaned bv Lhls proxv and conLaln mosL of Lhe same flelds as Lhe
orlalnal webserver cerLlflcaLes. 1he publlc/prlvaLe kevs of Lhe proxv are used ln creaLlna Lhe foraed cerLlflcaLe. A flle ls
aeneraLed aL proxv, whlch has Lhe loa of all Lhe hLLps Lrafflc LhaL has passed Lhrouah Lhls proxv. lollowlna ls a dlaaram
descrlblna how Lhe aLLack works.

!
//*!;(3!03!;&<<)2!(--('=!&3!>481!4>!7849$!/28:28!


C+,)!!!!A8:D:6<-76!7E!9-<9!"<<"=>4!

1he Ml1M aLLacks relv upon spooflna A8 and unS. SlLes should use sLaLlc A8 Lables when posslble, and should mlaraLe
Lo unSSLC as soon as pracLlcable. ln all cases, everv local neLwork should deplov an lnLruslon deLecLlon devlce and
provlde a rapld response meLhod, such as dropplna Lhe swlLch porL of Lhe aLLacker, Lo Lackle acLlve aLLacks.


-7-
SSL: Man ln Mlddle ALLack
-.'#%!/012%!
! ! !



8:E:8:6=:4!

[1]. Ellison, C. and B. Schneier. "Ten Risks of PKI: What You're Not Being Told About Public Key
Infrastructure," Computer Security Journal, v 16, n 1, 2000, pp. 1-7.
[2]. Peter Burkholder. SSL Man-In-The-Middle-Attacks [3] http://grinder.sourceforge.net/g2/tcpsniffer
[3]. Schneier, Bruce. Secrets and Lies : Digital Security in a Networked World.
[4]. Stephen A. Thomas (2000). SSL and TLS essentials securing the Web. New York: Wiley. ISBN 0-471-
38354-6.













-8-