Vous êtes sur la page 1sur 8

Cairo University

Faculty of Computers and Information


Internet Technology, sheet 2

Fall 2014
Due date= Dec.28 th, 2014

Q1: Consider the following threats to Web security protocols and describe how each is countered

by a particular feature of each security protocol.


a) Man-in-the-middle attack on S/MIME: An attacker interposes during key exchange, 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 symmetric 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.
b)
Password sniffing on DKIM: Passwords in DKIM or other application traffic are
eavesdropped.
Domain Keys Identified Mail, or DKIM, is a method by which the sender of email digitally
signs the message to prove it really came from the domain that is claims it came from.
A key pair is generated, the private key is kept on the mail systems handling outgoing mail for
the domain in question, and the public key is published in DNS.
Outgoing mail gets signed in the mail system, using the private key. The entire mail content
and selected parts of the header are covered by this signature, which is added to the mail
header. The receiving mail system can now verify this signature using the public key it fetches
from DNS. Since the private key ( i.e., the password) is not transmitted anyway on the
communication line, password sniffing attacker is prevented in DKIM protocol.
c)
IP spoofing on IPSec: Uses forged IP addresses to fool a host into accepting bogus data.
IP spoofing is forging a new IP datagram impersonating a different machine from your
own. This is done by modifying the IP header, replacing the source address (your own) with a
forged one. This is successful because IP is a stateless protocol and (in addition) provides no
type of integrity on its own. Any type of integrity control would prevent it such as IPsec.
IPSec implement Encryption and/or authentication to the IP packets. However, the
authentication service implemented in IPSec is only message authentication ( i.e., integrity)
and user authentication is not applied. This opens the door for IP spoofing attacker to
impersonate another user and send fake data.
d)
IP hijacking on IPSec: An active, authenticated connection between two hosts is
disrupted and the attacker takes the place of one of the hosts.

This attack can also be done on IPSec due to the absent of user authentication in IPSec.
e)
SYN flooding ( or Denial of Service attack) on SSL: An attacker sends TCP SYN
messages to request a connection but does not respond to the final message to establish the
connection fully. The attacked TCP module typically leaves the half-open connection around
for a few minutes. Repeated SYN messages can clog the TCP module.
Can't be defeated (SYN flooding attack is not solved in the SSL) , SSL is not stateless and
working on top of TCP , SYN flooding it is solved in TCP layer by considering the time out
clock.

Q2: For an HTTPS web browsing, is it allowed to receive an out of order packets at the receiver.

If so, is it possible to reorder the received unordered packets? Consider specific features in
HTTPS that make it possible to do or not to do.
Web browsers and servers use TCP/IP protocols to connect through the Internet. One of
the two common TCP/IP protocols used for web browsing application is HTTPS (HTTP over
SSL) which refers to the combination of HTTP and SSL to implement secure communication
between a Web browser (client) and a Web server.
So, Yes 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 HTTP level an HTTP
client requests a connection to an HTTP server by sending a connection request to the next
lowest layer (TLS/SSL in this case). At the level of TLS/SSL, a session is established between a
TLS client and a TLS server. Then the SSL Record Protocol that provides basic security
services to various higher layer protocols. In particular, the Hypertext Transfer Protocol
(HTTP) in this case transmits the resulting unit in a TCP segment after fragmentation,
compression, adding MAC, encryption of application data, and Appending SSL record header.
So TCP 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 transmission between the sender and the
receiver, which includes ordering the received packet using Sequence number field of the TCP
header at the receiver and then passing ordered fragments up to the SSL protocol which in
turn will decrypt the received data, verify it, decompress it, and reassemble it using info from
SSL record header, and then deliver original application data to higher-level users (HTTP in
this case).

SSL Protocol Stack

In conclusion, it is possible to reorder the unordered packet due to the feature of always using
SSL protocol under the HTTPS protocol. this feature allows the SSL to reorder the packets on
behalf of the HTTPS.

Q3: A replay attack is one in which an attacker obtains a copy of an authenticated packet and

later transmits it to the intended destination. The receipt of duplicate, authenticated IP packets
may disrupt service in some way or may have some other undesired consequence. The Sequence
Number field in the IPsec authentication header is designed to thwart such attacks. Because IP is
a connectionless, unreliable service, the protocol does not guarantee that packets will be
delivered in order and does not guarantee that all packets will be delivered. Therefore, the IPsec
authentication document dictates that the receiver should implement a window of size W , with a
default of W _ 64. The right edge of the window represents the highest sequence number, N , so
far received for a valid packet. For any packet with a sequence number in the range from N
W _ 1 to N that has been correctly received (i.e., properly authenticated), the
corresponding slot in the window is marked ( Figure 22.8 ). Deduce from the figure how
processing proceeds when a packet is received and explain how this counters the replay attack.

This part not needed/not graded


Sequence number counter generation by the sender
When a new Security Association SA is established, the sender initializes a sequence number
counter (32-bit field in Authentication Header AH or Encapsulating Security Payload ESP
headers) to 0.
Each time that a packet is sent on this SA, the sender increments the counter and places the
value in the Sequence Number field. Thus, the first value to be used is 1.
the sender must not allow the sequence number to overflow or cycle past 2 32 -1 back to zero
this handled by sequence counter overflow flag . Otherwise, there would be multiple valid
packets with the same sequence number. If the limit of 2 32 -1 is reached, the sender should
generate an auditable event and prevent further transmission of packets on this SA so
terminate this SA and negotiate a new SA with a new key.

When a packet is received:


If the received packet falls within the window or its sequence number in the range from
(N-w+1 to N) and its corresponding slot in the window isnot marked yet, the MAC is
checked. If the packet is authenticated, the corresponding slot in the window is marked.
If the received packet is to the right of the window which means that its sequence
number>N and its corresponding slot in the window is not marked yet, the MAC is
checked. If the packet is authenticated, the window is advanced so that this sequence
number is the right edge of the window, and the corresponding slot in the window is
marked.
If the received packet is to the left of the window which means that its sequence
number<=N-w, or if authentication fails, or its corresponding slot in the window is
already marked, the packet is discarded; this is an auditable event.
This anti-replay window describes means to determine that a sequence number is correct in
respect to its position to the window as the sequence number must fall on it and it is also deal
with packets delivered out of order.
Q4: X.509 is a standard for supporting public key certificate formats as well as an
authentication protocol between two parties A and B. However, X.509 is vulnerable to MITM
attack. The authentication protocol of X.509 is as follows:
A----> B : A {tA , nonceA , IDB }
B----> A : B {tB , nonceB , IDA , nonceA}
A----> B : A {nonceB}
Where tA and tB are timestamps, nonceA and nonceB are random numbers generated by A and B,
respectively. and the notation X{Y} means that the message Y is transmitted, encrypted, and
signed by X. The X.509 protocol states that checking timestamps in received messages are
optional for the authentication process explained above. Now consider an MITM attack C that
impersonates A to B. When using the previous 3 messages for authentication, while not using
the timestamps, C initially sends the first captured message to B:
C----> B : A {0 , nonceA , IDB)
B responds, thinking it is talking to A but is actually talking to C:
B----> C : B {0 , nonce'B , IDA , nonceA}
C meanwhile causes A to initiate authentication with C by some means. As a result, A sends C
the following:
A----> C : A {0 , nonce'A , IDC }

C responds to A using the same nonce provided to C by B:


C----> A : C {0 , nonce'B , IDA, nonce'A }
A responds to C with:

A----> C : A {nonce'B}
This is exactly what C needs to convince B that it is talking to A, so C now repeats the incoming
message back out to B:
C----> B : A {nonce'B}
Therefore, B will believe it is talking to A whereas it is actually talking to C.

a) Draw the diagram between A, B, and C to illustrate the above attack scenario. Number the
messages transmitted among the three entities so it will be easy to understand the diagram.
The diagram between A, B, and C will be as follow:

b) Suggest a simple solution to this problem that does not involve the use of timestamps.
MITM Man-in-the-middle attacks: A person intercepts both the client and server
communications and then acts as an intermediary between the two without each ever
knowing. This gives the middle man the ability to read and potentially modify messages
from either party in order to implement another type of attack.
Any message is transmitted, encrypted, and signed by the sender. So for the 3 rd message when
C causes A to initiate authentication with C by some means, the message will be encrypted
then signed by A.

The solution involves that each entity should add their ID in the message, So any MITM
attacker C shouldn't deceive neither A nor B because the message should include their
identities.
The authentication between A & B will be as follow:

C) Pretend as the MITM attacker C, can C find another way to break the authentication between
A and B again after the solution in part b is applied.
The MITM can break the authentication between A and B after adding the identity of the
sender in the message, the middle attacker will allow the 1 st message to be sent from A to B
also will allow B replies to A. But for the 3 rd message that should be sent from A to B, C will
break the connection and the message will not be sent to B then C will complete the
connection with A as A thinks that C is B.
In case that the messages are encrypted by a shared key between A & B, if C knew the shared
key by any way then C can decrypt the messages and complete the connection.
At this case B will think that the connection is broken because A didnt reply.
This attack is successfully achieved because A and B is only authenticate each other in te
begin of the session. However, to solve this attack, the subsequent messages sent between A
and B after the authentication should be encrypted by the public key of the receiver, so the
attacker will only take the message and break the connection between A and B but still C cant
decrypt the message or reply to A, At this case A will think that the connection is closed also
because A didnt receive another messages. As shown in the figure:

Vous aimerez peut-être aussi