Internet Technology Sheet 2

8/9/2019 Internet Technology Sheet 2

1/8

Cairo University

Faculty of Computers and Information Fall 2014

Internet Technology, sheet 2 Due date Dec!2" th, 2014

Q1# Consider the follo$ing threats to %e& security protocols and descri&e ho$ each is countered

&y a particular feature of each security protocol!

a' (an)in)the)middle attac* on S/MIME# +n attac*er interposes during *ey echange, acting as

the client to the server and as the server to the client!

The Key exchange is a pre-process that takes place before the S/MIME protocol in order to

exchange secure key between both the client and server This process is needed if the protocol

uses a sy!!etric cryptography" however S/MIME protocol uses public key cryptography"

where client and server have their public/private keys Therefore MITM attackers has no

oportunity with S/MIME protocol due to the public key cryptography usage in both encryption

and authentication

&' -ass$ord sniffing on DKIM# -ass$ords in D.I( or other application traffic are

eavesdropped!

#o!ain Keys Identified Mail" or #KIM" is a !ethod by which the sender of e!ail digitally

signs the !essage to prove it really ca!e fro! the do!ain that is clai!s it ca!e fro!

$ key pair is generated" the private key is kept on the !ail syste!s handling outgoing !ail for

the do!ain in %uestion" and the public key is published in #&S

'utgoing !ail gets signed in the !ail syste!" using the private key The entire !ail content

and selected parts of the header are covered by this signature" which is added to the !ail

header The receiving !ail syste! can now verify this signature using the public key it fetchesfro! #&S Since the private key ( ie" the password) is not trans!itted anyway on the

co!!unication line" password sniffing attacker is prevented in #KIM protocol

c' I- spoofing on IPSec# Uses forged I- addresses to fool a host into accepting &ogus data!

I* spoofing is forging a new I* datagra! i!personating a different !achine fro! your

own This is done by !odifying the I* header" replacing the source address (your own) with a

forged one This is successful because I* is a stateless protocol and (in addition) provides no

type of integrity on its own $ny type of integrity control would prevent it such as I*sec

I*Sec i!ple!ent Encryption and/or authentication to the I* packets +owever" the

authentication service i!ple!ented in I*Sec is only !essage authentication ( ie" integrity)

and user authentication is not applied This opens the door for I* spoofing attacker to

i!personate another user and send fake data

d' I- hi/ac*ing on IPSec# +n active, authenticated connection &et$een t$o hosts is

disrupted and the attac*er ta*es the place of one of the hosts!


2/8

This attack can also be done on I*Sec due to the absent of user authentication in I*Sec

e' flooding 3 or Denial of ervice attac*' on SSL# +n attac*er sends TC-

messages to reuest a connection &ut does not respond to the final message to esta&lish the

connection fully! The attac*ed TC- module typically leaves the 5half)open connection6 around

for a fe$ minutes! 7epeated messages can clog the TC- module!

,ant be defeated (S.& flooding attack is not solved in the SS) " SS is not stateless and

working on top of T,* " S.& flooding it is solved in T,* layer by considering the ti!e out

clock


3/8

Q2# For an 8TT- $e& &ro$sing, is it allo$ed to receive an out of order pac*ets at the receiver!

If so, is it possi&le to reorder the received unordered pac*ets9 Consider specific features in

8TT- that ma*e it possi&le to do or not to do!

0eb browsers and servers use T,*/I* protocols to connect through the Internet 'ne of

the two co!!on T,*/I* protocols used for web browsing application is +TT*S (+TT* over

SS) which refers to the co!bination of +TT* and SS to i!ple!ent secure co!!unication

between a 0eb browser (client) and a 0eb server

So" .es it is allowed to receive an out of order packet at the receiver to deal with the best effort

nature of the internet that will likely lead to receiving packets out of order

It also possible to reorder the received unordered packets" as at the +TT* level an +TT*

client re%uests a connection to an +TT* server by sending a connection re%uest to the next

lowest layer (TS/SS in this case) $t the level of TS/SS" a session is established between a

TS client and a TS server Then the SS 1ecord *rotocol that provides basic security

services to various higher layer protocols In particular" the +ypertext Transfer *rotocol(+TT*) in this case trans!its the resulting unit in a T,* seg!ent after frag!entation"

co!pression" adding M$," encryption of application data" and $ppending SS record header

So T,* which is a connection oriented protocol used in the lower Transport layer as shown in

the figure will deal with the reliable end to end trans!ission between the sender and the

receiver" which includes ordering the received packet using Se%uence nu!ber field of the T,*

header at the receiver and then passing ordered frag!ents up to the SS protocol which in

turn will decrypt the received data" verify it" deco!press it" and reasse!ble it using info fro!

SS record header" and then deliver original application data to higher-level users (+TT* in

this case).

SS *rotocol Stack

In conclusion" it is possible to reorder the unordered packet due to the feature of always using

SS protocol under the +TT*S protocol this feature allows the SS to reorder the packets on

behalf of the +TT*S


4/8

Q3# + replay attac* is one in $hich an attac*er o&tains a copy of an authenticated pac*et and

later transmits it to the intended destination! The receipt of duplicate, authenticated I- pac*ets

may disrupt service in some $ay or may have some other undesired conseuence! The euence

um&er field in the I-sec authentication header is designed to th$art such attac*s! :ecause I- is

a connectionless, unrelia&le service, the protocol does not guarantee that pac*ets $ill &e

delivered in order and does not guarantee that all pac*ets $ill &e delivered! Therefore, the I-sec

authentication document dictates that the receiver should implement a $indo$ of si;e % , $ith a

default of % < =4! The right edge of the $indo$ represents the highest seuence num&er, , so

far received for a valid pac*et! For any pac*et $ith a seuence num&er in the range from

% < 1 to that has &een correctly received 3i!e!, properly authenticated', the

corresponding slot in the $indo$ is mar*ed 3 Figure 22!" '! Deduce from the figure ho$

processing proceeds $hen a pac*et is received and eplain ho$ this counters the replay attac*!

This part not needed/not graded

Se%uence nu!ber counter generation by the sender

0hen a new Security $ssociation S$ is established" the sender initiali2es a se%uence nu!ber

counter (34-bit field in $uthentication +eader $+ or Encapsulating Security *ayload ES*

headers) to 5

Each ti!e that a packet is sent on this S$" the sender incre!ents the counter and places the

value in the Se%uence &u!ber field Thus" the first value to be used is 6

the sender !ust not allow the se%uence nu!ber to overflow or cycle past 4 34 -6 back to 2ero

this handled by se%uence counter overflow flag 'therwise" there would be !ultiple valid

packets with the sa!e se%uence nu!ber If the li!it of 4 34 -6 is reached" the sender should

generate an auditable event and prevent further trans!ission of packets on this S$ so

ter!inate this S$ and negotiate a new S$ with a new key


5/8


6/8

C responds to + using the same nonce provided to C &y :#

C))))A + # C B0 , nonceE:, ID+, nonceE+

+ responds to C $ith#

+))))A C # + BnonceE:

This is eactly $hat C needs to convince : that it is tal*ing to +, so C no$ repeats the incoming

message &ac* out to :#

C))))A : # + BnonceE:

Therefore, : $ill &elieve it is tal*ing to + $hereas it is actually tal*ing to C!

a' Dra$ the diagram &et$een +, :, and C to illustrate the a&ove attac* scenario! um&er the

messages transmitted among the three entities so it $ill &e easy to understand the diagram!

The diagra! between $" =" and , will be as follow7

&' uggest a simple solution to this pro&lem that does not involve the use of timestamps!

>MITM? Man-in-the-!iddle attacks7 $ person intercepts both the client and server

co!!unications and then acts as an inter!ediary between the two without each ever

knowing This gives the @!iddle !anA the ability to read and potentially !odify !essages

fro! either party in order to i!ple!ent another type of attack$ny !essage is trans!itted" encrypted" and signed by the sender So for the 3 rd!essage when

, causes $ to initiate authentication with , by so!e !eans" the !essage will be encrypted

then signed by $


7/8

The solution involves that each entity should add their I# in the !essage" So any MITM

attacker >,? shouldnt deceive neither $ nor = because the !essage should include their

identities

The authentication between $ B = will be as follow7

C' -retend as the (IT( attac*er C, can C find another $ay to &rea* the authentication &et$een

+ and : again after the solution in part & is applied!

The MITM can break the authentication between $ and = after adding the identity of the

sender in the !essage" the !iddle attacker will allow the 6st!essage to be sent fro! $ to =

also will allow = replies to $ =ut for the 3 rd!essage that should be sent fro! $ to =" , will

break the connection and the !essage will not be sent to = then , will co!plete the

connection with $ as @$ thinks that , is =A

In case that the !essages are encrypted by a shared key between $ B =" if , knew the shared

key by any way then , can decrypt the !essages and co!plete the connection$t this case = will think that the connection is broken because $ didn?t reply

This attack is successfully achieved because $ and = is only authenticate each other in te

begin of the session +owever" to solve this attack" the subse%uent !essages sent between $

and = after the authentication should be encrypted by the public key of the receiver" so the

attacker will only take the !essage and break the connection between $ and = but still , can?t

decrypt the !essage or reply to $" $t this case $ will think that the connection is closed also

because $ didn?t receive another !essages $s shown in the figure7


8/8

Internet Technology Sheet 2

Documents

Transcript of Internet Technology Sheet 2