Program Design

1.Secure_chat.py:

Overview:
It uses TCP socket to establish TCP connection between client and server, on request by client
it establishes TLS connection between client and server on existing TCP connection. This file
consists of code for both server and client side. Using threads we made a chat application full
duplex, so at any time client and server can send/receive messages.

Flow:

Server side:
● A server socket is created and the server starts listening on the socket( ip = 0.0.0.0, port
= 1234), to establish TCP connection between server and client.
● After accepting the connection from the client, the server receives the chat_hello
message from client, server sends chat_reply message to client.
● Then reader thread, writer thread, and dispatch thread starts.
● Reader thread handles incoming messages and adds them into messageQueue,
similarly write thread handles outgoing messages and adds them into messageQueue,
then dispatcher thread handles sending and receiving messages from messageQueue.
● On chat_close message all of these threads get terminated and the chat application gets
closed.
● On receiving message chat_STARTTLS, server can send chat_STARTTLS_ACK if
server wants to have TLS connection so from this point TLS connection is started, if
server doesn't want to have TLS connection then server can send
chat_STARTTLS_NOT_SUPPORTED
● So now serverTLS() function is called which creates an ssl socket id, by providing the
server’s certificate and key.
● So using this TLS handshake is done between client and server.
● This function sets a key log file which is server_keylog.txt which has a pre master secret
key, which can be used in wireshark to see encrypted messages in plaintext.
● Then again reader, writer and dispatched threads start as described earlier but now
messages are encrypted instead of plain text.

Client side:
● Client socket is created and connected to server using server ip and server port, which
creates TCP connection between client and server.
● Client sends chat_hello to server and gets chat_reply from server.
● Then reader thread, writer thread, and dispatch thread starts.
 ● Reader thread handles incoming messages and adds them into messageQueue,
similarly write thread handles outgoing messages and adds them into messageQueue,
then dispatcher thread handles sending and receiving messages from messageQueue.
● On chat_close message all of these threads get terminated and the chat application gets
closed.
● To start TLS connection client need to send chat_STARTTLS and if server agrees upon
that server sends chat_STARTTLS_ACK, and if server doesn’t want to establish TLS
connection
● On receiving message chat_STARTTLS, server can send chat_STARTTLS_ACK if
server wants to have TLS connection, so from this point TLS connection is started, and if
server sends chat_STARTTLS_NOT_SUPPORTED, means TLS connection will not
established.
● If a client sends/receives a chat_close message then all of the threads will terminate
and the chat application will close.
● On receiving chat_STARTTLS_ACK clientTLS() function is called.
● clientTLS() function which creates ssl socket id by providing client certificate and client’s
key.
● So using this TLS handshake is done between client and server.
● Then reader, writer and dispatcher threads start which works as described above.
● So now all sending/receiving messages are encrypted, so chat is secured now.

2. Secure_chat_interceptor.py

Overview:
It uses a TCP socket to establish TCP connection between Alice and Bob. On receiving TLS
connection setup request from Alice, it can either drop the chat_STARTTLS message and send
chat_STARTTLS_NOT_SUPPORTED to Alice so that the conversation continues to be in
unencrypted mode (Downgrade attack), or it can forward the request to Bob and supply fake
certificates to both Alice and Bob so that it can decrypt and encrypt messages sent by either of
the party(Man in the middle attack). This file consists of code for both server and client side.
Using threads we made a chat application full duplex, so at any time client and server can
send/receive messages.

Downgrade Attack:

Flow:

● A server socket is created and the server starts listening on the socket( ip = 0.0.0.0, port
= 1234), to establish TCP connection between Trudy and Alice.
● After accepting the connection from Alice, a client socket is created and connected to
Bob using Bob ip and Bob port, which creates TCP connection between Trudy and Bob.
● Then the reader thread and dispatch thread starts.
 ● Reader thread handles incoming messages and adds them into messageQueue, then
dispatcher thread handles sending and receiving messages from messageQueue.
● The dispatcher thread takes messages from Alice and forwards them to Bob, similarly it
forwards the messages from Bob to Alice
● The dispatcher thread checks if for ‘chat_STARTTLS’ message and drops it and sends
‘chat_STARTTLS_NOT_SUPPORTED’ immediately to Alice after it finds the match.
● On chat_close message all of these threads get terminated and the chat application gets
closed.

Man in the middle attack

Flow:

● A server socket is created and the server starts listening on the socket( ip = 0.0.0.0, port
= 1234), to establish TCP connection between Trudy and Alice.
● After accepting the connection from Alice, a client socket is created and connected to
Bob using Bob ip and Bob port, which creates TCP connection between Trudy and Bob.
● Then the reader thread and dispatch thread starts.
● Reader thread handles incoming messages and adds them into messageQueue, then
dispatcher thread handles sending and receiving messages from messageQueue.
● The dispatcher thread takes messages from Alice and can forward edit or drop the
message.
● If Trudy receives a ‘chat_STARTTLS’ message, it can further forward the message or
can drop the packet and send ‘chat_STARTTLS_NOT_SUPPORTED’ to Alice.
● If Trudy decides to forward the message to Bob, it starts a TLS connection with Alice and
Bob. It sends fake alice certificate to Bob and similarly sends fakebob certificate to Alice.
● Hence two TLS connections are established i.e between Alice, Trudy and between Trudy
and Bob.
● On chat_close message all of these threads get terminated and the chat application gets
closed.

3. attacker.py

Overview:
The objective of this code is to perform Man in the Middle Attack using ARP cache poisoning.
attacker.py uses ARP packets to poison the ARP caches of Alice and Bob. It continuously sends
false ARP responses to Alice and Bob. Alice's ARP cache now contains the MAC address of
Trudy mapped against the IP address of Bob and Bob’s ARP cache contains the MAC address
of Trudy mapped against the iP address of Alice.
Flow:

● The actual MAC addresses of Alice and Bob are obtained by sending ARP requests.
● For sending the ARP request, an ARP packet is created by concatenating the broadcast
frame and ARP packet with the required destination IP address.
● After obtaining the IP addresses of the hosts, false ARP responses are sent to the hosts
impersonating the other host.
● False ARP responses are continuously sent by the attacker to the hosts to prevent the
ARP caches of the hosts from recovering.
● The IP routing tables are modified so that the attacker, Trudy, can get access to the
packets that are sent by Alice.
● Executing the server code on the Trudy machine can now read all the information sent
by Alice.
● The false ARP packets are flooded as long as there is no interruption. When an
exception occurs, ARP responses with actual source and destination IP and MAC
addresses are sent to both the hosts.
Task 1

Send openssl_users.conf to Alice

After the CA directory has been created, we will create a public private key pair for the CA using
the following command.
openssl ecparam -name brainpoolP512r1 -genkey -noout -out CA.pem
Create certificate signing request of the certificate authority using the following command.
openssl req -config openssl_ca.conf -new -key CA.pem -out ca-self.csr

Following is the CSR created

The generated certificate signing request should be self-signed by the certificate authority.
openssl ca -out root.crt -keyfile CA.pem -selfsign -config openssl_ca.conf -in ca-self.csr -md
sha1
Following is CA certificate generated

CA certificate is uploaded in the root store of Alice, so that Alice can verify the certificate of Bob
using the CA certificate from the root store.
Alice will generate it’s CSR
Following is the CSR generated by the Alice
Generate key pair at Bob and send openssl_users.conf to Bob
Bob generates CSR
Following is the CSR generated by Bob
CSR is received by CA from Alice

Alice CSR is verified by CA

CSR is received by CA from Bob

Bob CSR is verified by CA

CA signs Alice’s certificate

Following is the certificate signed by CA

CA sends signed certificate to Alice

CA signed certificate sent by Bob

Following is the certificate signed by CA

Send signed certificate to the Bob. Alice and Bob verifies the certificate received from CA
Task 2

Client (Alice) side:

● Client creates a TCP socket.
○ sockid = socket(AF_INET, SOCK_STREAM)

● The IP address of the server is obtained from DNS name resolution using the function
gethostbyname.
 ○ ip_addr = socket.gethostbyname(‘bob1’)

● Now the client connects to the server using the server IP address and the port number
using connect function.
○ sock_id.connect((ipaddr, portnum))

● After the connect function is successful, a TCP connection is established between the
client and the server.

● Now the client sends a “chat_hello” message to the server and waits for the “chat_reply”
message from the server.

● After the “chat_reply” message is received by the client, both parties can exchange
messages on the established TCP connection.

● Client sends a “chat_STARTTLS” message to the server, to start a TLS connection and
waits for the “chat_STARTTLS_ACK” message. This involves creating an SSL socket
using the following command.
○ ssl_socket = context.wrap_socket(sock_id, server_side = False,
server_hostname = ‘bob1’)

● Once the TLS connection is established, they can exchange messages as long as one
of the parties sends a “chat_close” message.

Server (Bob) side:

● Server creates a socket using the socket constructor.
○ sockid = socket(AF_INET, SOCK_STREAM)

○
○ Failure of socket creation results in termination of the program.

● The server socket is bind to the IP address and the port number using the bind function.
○ sockid.bind((serverIP, serverPort))
 ○
○ If the port is already blocked, then it leads to termination of the program.

● After binding the server socket to the port and IP address, the server starts listening to
the incoming connections on the port using the listen function.
○ sockid.listen(num)

● Once the server receives the connection request from the client, it accepts the
connection using the accept function.
○ id, addr = sockid.accept()

● If the first message received from the client is a “chat_hello” message, then the server
responds with a “chat_reply” message.

● If the message received from the client is a “chat_STARTTLS” message, then the server
responds with a “chat_STARTTLS_ACK” message and initiates the TLS connection.

● Server also creates an SSL socket similar to the client using wrap_socket function, this
time the server_side flag is set to True.

● The server and client can now exchange messages in a secure channel until one of the
parties sends a “chat_close” message.
Task 3

Client (Alice) side:

No explicit changes are made to the client side Task 2 secure_chat code

Server (Bob) side:

No explicit changes are made to the server side Task 2 secure_chat code

Attacker (Trudy) side:

Downgrade Attack:
In Trudy’s secure_chat_interceptor, Trudy will initially poison the dns of alice and bob so
that all the requests from Alice are forwarded to Trudy. Trudy will connect to Bob after it receives
a message from Alice.
Trudy will keep on reading the messages sent by Alice and keep watch on chat_STARTTLS
message
After it receives the chat_STARTTLS message from Alice, it will drop the message and send
chat_STARTTLS_NOT_SUPPORTED message to Alice so that the conversation continues in
non encrypted mode
Task 4

Client (Alice) side:

No explicit changes are made to the client side Task 2 secure_chat code

Server (Bob) side:

No explicit changes are made to the server side Task 2 secure_chat code

Attacker (Trudy) side:

Man in the Middle Attack:

In Trudy’s secure_chat_interceptor, Trudy will initially poison the dns of alice and bob so that all
the requests from Alice are forwarded to Trudy. Trudy will connect to Bob after it receives a
message from Alice.
Trudy will be able to Forward/ Change/ Drop and return messages from Alice/Bob. After Alice
sends chat_STARTTLS message to Trudy, it can either drop the packet and send
chat_STARTTLS_NOT_SUPPORTED to Alice (as in previous task) or it can simply forward the
message to Bob. In the later case, Trudy will establish a TLS connection with Alice and Bob.
Trudy will be assured that Bob has started TLS after it receives chat_STARTTLS_ACK from Bob

Trudy will send fakealice certificate to Bob and similarly send fakebob certificate to Alice.
Since Trudy herself has issued the fake certificates, it will be able to intercept the messages
sent from both parties and will be able to perform the same operations as in non tls messages
Bonus

Spoof function

The spoof function takes input the destination IP address, source IP address and the destination
MAC address. Now it creates an ARP response, with destination IP address and MAC address
being remain intact and source MAC address is by default taken to be the sender’s MAC
address. This way the receiver of the ARP packet updates the ARP cache with false
information. The verbose flag is set to False to prevent the printing of log messages.
The above code snippet shows that the host1 is sent a false ARP response of host2, and host2
is sent a false ARP response of host1.

Executing attacker.py

After performing cache poisoning, execute the server code on the Trudy container and Alice
connects to Trudy assuming that it is connected to Bob.

Working
● Start ARP cache poisoning on Alice and Bob i.e., execute attacker.py on the Trudy
container.

● Start the server on another terminal of the Trudy container.

○ Command: ./secure_chat -s

Now the fraudulent server of Trudy is listening on port 1234.

● Start the client process on the Alice container.

 ○ Command: ./secure_chat -c bob1

Now a TCP connection is established between Alice and Trudy which can be converted
into a TLS connection by sending a chat_STARTTLS message.

Now any message sent by Alice is received by Trudy and even if the connection is secured
using TLS, Trudy will still be able to read the messages.

Trudy can read the data from the TCP packets.

REFERENCES

[1] Scapy - https://scapy.readthedocs.io/en/latest/

[2] Openssl documentation - /docs/index.html (openssl.org)
[3] ARP cache poisoning -
https://medium.datadriveninvestor.com/arp-cache-poisoning-using-scapy-d6711ecbe112
[4] Sockets in Python - https://docs.python.org/3/library/ssl.html#
PLAGIARISM STATEMENT

We certify that this assignment/report is our own work, based on our personal
study and/or research and that we have acknowledged all material and sources
used in its preparation, whether they be books, articles, packages, datasets, reports, lecture
notes, and any other kind of document, electronic or personal communication. We also
certify that this assignment/report has not previously been submitted for
assessment/project in any other course lab, except where specific permission has been granted
from all course instructors involved, or at any other time in this course, and that we
have not copied in part or whole or otherwise plagiarized the work of other
students and/or persons. We pledge to uphold the principles of honesty and responsibility at
CSE@IITH. In addition, We understand my responsibility to report honor violations by other
students if we become aware of it.

Names: Ravi Chandra Duvvuri, Kishan Nayanbhai Bhinde, Pratik Abhijeet Bendre
Date: 07-04-2022
Signature: DRC, KNB, PAB