Review Questions

Network Traffic Interception

(Q 1.1)

Ways in which an attacker can intercept network traffic

  • ARP Spoofing

  • DNS Cache Poisoning

  • Attacks on BGP

    • One-hop Attack

    • Sub-prefix Hijacking

All the attacks listed above cause packets to be routed to a machine controlled by the attacker (interception), so that they can read and/or manipulate traffic, and monitor activity and/or carry out attacks.

Attackers can usually cause most damage when they are in the same local network as their victims, which is why everyone cautions against using public WiFi Access Points for insecure HTTP browsing and sensitive internet usage, such as internet banking.

TLS Protection

(Q 1.2)

Protections TLS provides to reduce problems caused by interceptions

  • TLS makes use of Digital Certificates to prove identity, so an interception attempt will fail, because the attacker will not be able to provide a valid certificate for the actual server.

  • TLS includes random values in its messages and uses those values in its integrity checking, so even if an attacker is recording all messages, they cannot replay them, as the server will generate a different random value for every connection, which will lead to the handshake failing.

  • TLS uses the Diffie-Hellman (DH) Key Exchange Algorithm to exchange key generation material and the algorithm has been created such that the master secret cannot be created by someone intercepting the connection.

    • Perfect Forward Secrecy is also provided by TLS connections using the Ephemeral DH (DHE) Key Exchange Algorithm, which implies that even if the attacker is able to compromise the key material of the current TLS session, they cannot compromise the previous or future connections using those values.

  • Once new keys are generated on both ends at the end of a TLS handshake, TLS encrypts all the handshake messages on both ends and sends it across in a Finished message. The client and the server compare these exchanged encrypted messages and only if they match, does the handshake succeed. An attacker who has intercepted a message and modified it will be caught here, as they cannot change the encrypted 'Finished' message.

  • After the handshake is complete, TLS encrypts and MACs all application data, so an attacker cannot understand the data being shared and cannot even mess with the encrypted data due to the MAC signature.

Importance of Certificates in TLS

(Q 1.3)

Digital Certificates are a key component of TLS, as they provide authentication, i.e., they prove that the server the client is communicating with, is actually the server that they requested and not someone impersonating the server.

If an impersonating server sends another server’s certificate to the client, the impersonating server won’t be able to produce a valid signature for the Diffie-Hellman g^b value that it sends to the client, as it does not have access to the private key of that certificate to create a valid signature.

So, a LOT of the security of TLS is dependent on the client verifying the server’s certificate chain. In the absence of this, anyone can impersonate the real server. An attacker can intercept messages and can carry out a Monkey in the Middle (MITM) Attack.

In a certificate chain, each certificate is signed by the certificate having higher authority that it and this finally ends at the root certificate by a Certificate Authority (CA), which has the highest authority and is self-signed. This self-signed root certificate is a trusted certificate that ships with Operating Systems and browsers.

Generally when attackers want to play mischief and impersonate a site, they cannot get a CA to sign their fake impersonated certificate (because a real certificate for that site exists and the attacker is not the owner of the actual domain), so attackers self-sign their fake certificate. Web browsers and protocols are smart-enough to realise that a self-signed certificate that is not signed by any trusted CAs signals security issues and so does not let the user access the site.

So if the signature verification is skipped, then an attacker presenting a fake self-signed certificate will not be caught and a successful MITM Attack can be carried out.

The MITM Attack:

  • The client starts communication with the server by first establishing a TCP connection with it and then sending a Client Hello message.

  • The server responds with a Server Hello message and its certificates.

  • The attacker will replace the legitimate certificate chain with its own fake self-signed certificate, change and sign the Diffie-Hellman parameter sent by the server (g^b to g^b') using the public key in the fake certificate and then send it to the client.

  • As the client is not verifying the signature on the certificate it is being presented, it accepts the fake certificate, fake signature and malicious g^b' pre-master secret, and successfully verifies the pre-master secret (g^b') using the public key in the fake certificate.

  • The attacker then compromises the Client Key Exchange message, where instead of the server receiving g^a from the client, it receives g^a' from the attacker, as the attacker has intercepted the actual value (g^a).

  • Thus, the attacker was able to generate a different set of keys for the client (g^ab') and the server (g^a'b), and every time messages are exchanged between the two, it will decrypt the intercepted messages, make modifications as necessary, encrypt them again and send them across.

  • The attacker then encrypts and MACs the client and server Finished messages, thus acting as a transparent proxy, unbeknownst to the two communicating parties.

Tinkering with TLS

Missing client_random Value

(Q 2.1)

The protocol is secure against Replay Attacks even with the client_random value missing, due to the presence of the server_random value.

If an attacker decides to replay client messages, the server will send a different server random value each time, so the generated master secret will be different each time, leading to the generation of different messages, message hashes and cipher texts, which will cause the TLS handshake to fail in the final Finished message stage.

Missing server_random Value

(Q 2.2)

TLS 1.2 is not secure against Replay Attacks if Key Encapsulation or Static Diffie-Hellman (DH) Key Exchange Algorithm are used to exchange keys, but TLS 1.2 is secure against Replay Attacks if the Ephemeral Diffie-Hellman (DHE) Key Exchange Algorithm is used.

Key Encapsulation or Static DH

When a TLS handshake is using Key Encapsulation or Static DH, an attacker can replay client messages to have the server generate the same responses every time messages are replayed, thus allowing Replay Attacks.

Replay attacks allow the attacker to repeat the encrypted application data communication with the server, which can cause some unwanted repeated actions on user data, depending on the contents of the request. The attacker will not be able to read and understand the encrypted data, but they don’t need to do that to cause harm. They can keep doing these attacks for a lot of connections and they will eventually replay a message that modifies the state of a user’s data, thus causing problems.

To carry out this attack, the attacker has to

  • Capture and store all messages of a TLS communication.

  • Establish a TCP connection with the server.

  • Blindly replay all the stored messages (the ones sent from the client to the server) without changing their contents, one-by-one in order of timestamp as the server keeps responding.

The attacker has to send the following intercepted messages unchanged one-by-one in order, after creating a TCP connection with the server:

  • Client Hello

  • Client Key Exchange

  • Finished

  • Application data


With the Ephemeral Diffie-Hellman (DHE) Key Exchange Algorithm, new key generation material is generated for every connection, to maintain Perfect Forward Secrecy.

It is being assumed that the server does not cache the key generation material (b, g, p, g^b, etc.).

This means that if no caching is assumed, the absence of the server_random value does not make TLS 1.2 vulnerable to Replay Attacks. The newly generated Key Exchange parameters provide the same protection as the server_random value does.

Missing Hash Value

(Q 2.3)

TLS 1.2 is vulnerable to Downgrade attacks whether hashes are present or not, but missing hash values in the handshake makes it easier to carry out these attacks, as it is an important checking mechanism against tampering.

An attacker intercepting communication can modify a TLS Client Hello message and strip out all the strong cipher suites and just use weak ones. The server then choses the best one out of the weak cipher suites it receives. The attacker records all the parameters that it receives and can trivially figure out the keys due to the weak ciphers used. Thus, the attacker can now selectively encrypt, decrypt and modify messages and transparently read and/or modify messages without anyone noticing.

The presence of hashes in the Finished message just slows down the attacker as it has to compute a new hash (which is computer from a version of all messages exchanged in the handshake that includes the modifications it made to all the previous messages). This can cause timeout issues leading to handshake failure, but the absence of hashes eases some of that burden on the attacker, speeding up the attack, thus leading to better chances of the attack succeeding.

The attack steps:

tls 12 downgrade attack

Tricking Your Browser

Hijacking a domain on a local by issuing fake certificates.

Certificate Authority

  • Create a directory for all Certificate Authority (CA) information. (bucs558-ca here.)

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw>mkdir bucs558-ca
X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw>cd bucs558-ca
  • The CA’s certificate and private key have been provided in the assignment. Paste the contents in two separate files bucs558-ca.crt and bucs558-ca.key respectively.

  • It is easy to extract the public key of the CA from its private key

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>openssl rsa -in bucs558-ca.key -pubout -out bucs558-ca.pubkey
writing RSA key

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>cat bucs558-ca.pubkey
-----END PUBLIC KEY-----
  • Details of the provided CA certificate can be found as shown below.

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>openssl x509 -in bucs558-ca.crt -noout -text
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = MA, L = Boston, O = BostonUniversityCS558, OU = CS558, CN =, emailAddress = [email protected]
            Not Before: Apr  3 21:49:43 2023 GMT
            Not After : May  3 21:49:43 2023 GMT
        Subject: C = US, ST = MA, L = Boston, O = BostonUniversityCS558, OU = CS558, CN =, emailAddress = [email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
            X509v3 Authority Key Identifier:

            X509v3 Basic Constraints:
    Signature Algorithm: sha256WithRSAEncryption
  • Create a configuration file bucs558-ca.cnf for future certificate generation and add the following content to it

# we use 'ca' as the default section because we're using the ca command
[ ca ]
default_ca = bucs558-ca

[ bucs558-ca ]
# a text file containing the next serial number to use in hex. Mandatory.
# This file must be present and contain a valid serial number.
serial = ./serial

# the text database file to use. Mandatory. This file must be present though
# initially it will be empty.
database = ./index.txt

# specifies the directory where new certificates will be placed. Mandatory.
new_certs_dir = ./newcerts

# the file containing the CA certificate. Mandatory
certificate = ./bucs558-ca.crt

# the file contaning the CA private key. Mandatory
private_key = ./bucs558-ca.key

# the message digest algorithm. Remember to not use MD5
default_md = sha256

# for how many days will the signed certificate be valid
default_days = 30

# a section with a set of variables corresponding to DN fields
policy = bucs558-ca-policy

[ bucs558-ca-policy ]
# if the value is "match" then the field value must match the same field in the
# CA certificate. If the value is "supplied" then it must be present.
# Optional means it may be present. Any fields not mentioned are silently
# deleted.
countryName = match
stateOrProvinceName = supplied
organizationName = supplied
commonName = supplied
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
  • Run the following commands in the CA directory (bucs558-ca), in preparation of generating certificates.

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>mkdir newcerts
X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>touch index.txt
X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>echo 01 > serial

Target Domain

  • Pick a domain to target ( here), create a directory for the domain ( here).

  • Generate a 4096 bit RSA private key and send the output to a file named

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\>openssl genrsa -out 4096
Generating RSA private key, 4096 bit long modulus (2 primes)
e is 65537 (0x010001)
  • Create a Certificate Signing Request (CSR) that the CA will use to generate a certificate for this domain.

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\>openssl req -new -key -out
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Massachusetts
Locality Name (eg, city) []:Boston
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Harsh Kapadia
Organizational Unit Name (eg, section) []:hk
Common Name (e.g. server FQDN or YOUR name) []
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
  • Create an extensions configuration file and add the following content to it. This is mainly to add all the subdomains that can be authenticated by the certificate.

    • The * entry implies that all the sub-domains of are covered by the certificate.

subjectKeyIdentifier = hash

[ hk_subject_alt_names ]
DNS.1 =
DNS.2 = *

Creating a Certificate for the Target Domain

  • All the configuration files required for generating a certificate have already been created above.

  • Generate a certificate for the target domain

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>openssl ca -config ./bucs558-ca.cnf -out ../ -extfile ../ -in ../
Using configuration from ./bucs558-ca.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :ASN.1 12:'Massachusetts'
localityName          :ASN.1 12:'Boston'
organizationName      :ASN.1 12:'Harsh Kapadia'
organizationalUnitName:ASN.1 12:'hk'
commonName            :ASN.1 12:''
emailAddress          :IA5STRING:'[email protected]'
Certificate is to be certified until May 12 21:53:40 2023 GMT (30 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
  • The target domain certificate file should have been generated in the target domain’s directory ( here). The details of the certificate can be printed and the certificate can be verified as well.

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\>ls -a
.  ..

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\>openssl x509 -in -noout -text # Certificate details
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = MA, L = Boston, O = BostonUniversityCS558, OU = CS558, CN =, emailAddress = [email protected]
            Not Before: Apr 12 21:53:40 2023 GMT
            Not After : May 12 21:53:40 2023 GMT
        Subject: C = US, ST = Massachusetts, O = Harsh Kapadia, OU = hk, CN =, emailAddress = [email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
            X509v3 Subject Alternative Name:
      , DNS:*
            X509v3 Subject Key Identifier:
    Signature Algorithm: sha256WithRSAEncryption

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\>openssl verify -CAfile ../bucs558-ca/bucs558-ca.crt # Verify certificate OK
  • In the CA directory (bucs558-ca) some files have been generated

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>ls -a
.   bucs558-ca.cnf  bucs558-ca.key     index.txt       index.txt.old  serial
..  bucs558-ca.crt  bucs558-ca.pubkey  index.txt.attr  newcerts       serial.old

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>cat index.txt
V       230512215340Z           01      unknown /C=US/ST=Massachusetts/O=Harsh Kapadia/OU=hk/[email protected]

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>cat index.txt.old
# empty

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>cat index.txt.attr
unique_subject = yes

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>cat serial
02 # The next serial number was automatically generated

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>cat serial.old
01 # The last serial number that was manually configured

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw\bucs558-ca>ls -a newcerts
.  ..  01.pem # The CA has a copy of the certificate with the serial number as the title

Configuring Host Operating System

  • In this case, the host Operating System (OS) is Microsoft Windows 11.

  • To be able to redirect the target domain to another web page, it has to be redirected on the OS.

    Add the following lines to the C:\Windows\System32\drivers\etc\hosts file.

# Added by Harsh Kapadia for BU CAS CS 558
The sub-domains of (eg: have to be added individually, as the hosts file does not support wildcards (*
  • To serve an alternate page once the domain is hijacked, create an index.html file outside the CA and target domain directories.

X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw>vim index.html # Add content shown below
X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw>cat index.html
                <title>Harsh Kapadia</title>

        <body style="text-align: center;">
                <h1>Harsh Kapadia</h1>
  • The CA certificate (bucs558-ca.crt) is a root certificate that is providing trust to the certificate ( that we created for the target domain ( The host OS and browser doesn’t trust the CA root certificate (bucs558-ca.crt) though, so the domain certificate ( won’t be accepted. So, the root certificate (bucs558-ca.crt) needs to be added to the OS’s certificate store manually. Adding the root certificate separately to the browser’s key store might also be required (like in Mozilla Firefox, as shown below).

windows cert store
Microsoft Windows' Certificate Store
firefox cert store
Mozilla Firefox’s Certificate Store
  • To be able to carry out the attack, there has to be a TLS terminating server (openssl s_server) running that captures the request to the target domain ( that was redirected to (localhost) by the OS due to the host file configuration above.

    • The server is listening at port 443, as that is the default port for HTTPS requests.

The command below has to be run from the directory where the index.html file was created.
X:\ms-bu\sem-2\bu-cas-cs-558\cert-hw>openssl s_server -accept -cert ./ -cert_chain ./bucs558-ca/bucs558-ca.crt -key ./ -WWW
Using default temp DH parameters

Accessing the Target Domain

Original Web Pages

This is how the two web pages looked before hijacking:

Mozilla Firefox

After the hijacking:

firefox security
Firefox’s site security dialog box
firefox leaf cert
The leaf (domain) certificate as seen in Firefox
firefox root cert
The root (CA) certificate as seen in Firefox

Microsoft Edge

After the hijacking:

edge leaf cert 1
General view of the leaf (domain) certificate as seen in Edge
edge leaf cert 2
Hierarchical view of certificates as seen in Edge