School of Computing and Information Systems
COMP30023: Computer Systems
Practical Week 6
Copyright By PowCoder代写 加微信 powcoder
1 Introduction
The internet was not built with privacy nor security in mind. Therefore, most if not all modern communication
channel overlay over transport layer security (TLS) or secure socket layer (SSL). In this workshop, we will be going
through the cryptographic primitives underpinning TLS/SSL and how all of these primitives interplay to realise
NOTE: You have been granted sudo privileges from this week onwards.
You should only use your VM for the purpose of completing COMP30023 activities (please ask for approval from
your demonstrator otherwise).
The university’s policies on the use of IT services: https://policy.unimelb.edu.au/category/Facilities%
20and%20IT.
2 Digital Certificates
1. Browse to https://lms.unimelb.edu.au. Is this domain using a digital certificate? Why is it important
that traffic to the LMS is encrypted?
2. View the digital certificate the LMS is using.
The procedure differs between browsers, and even between different versions of browsers. In some versions of
Chrome and Firefox the option to view the certificate can be found by clicking on the padlock icon. In other
versions you will need to open the Developer Console by pressing F12, and then go to the Security tab.
3. Which CA signed the certificate that the LMS is using? Which CA signed the certificate of the CA which
signed the LMS certificate? What is the root CA of the chain?
4. Is www.eng.unimelb.edu.au using a digital certificate? Why is it less important (though still recommended)
that this website uses HTTPS?
5. View the digital certificate for https://www.melbournepollen.com.au/. Which other domains names does
this digital certificate relate to? You can view this information under Subject Alternative Names.
6. Browse to https://badssl.com/. Visit the expired and wrong.host links and view the certificates. Identify
the fields which indicate why the certificate is no longer valid or not valid for the current host.
3 Services with SSL Certificates
In this section, we will be learning about how to setup SSL certificates for a basic webserver. The goal of issuing
a SSL certificate is to publicly share your public key in a secure manner. Recall that negotiating an ephemeral
symmetric key using the Diffie-Hellman key exchange protocol is fundamental insecure over the internet due to
Man-in-the-Middle attacks. Setting up a SSL certificate is one way around this problem1. In this exercise today,
we will walk through how to:
1Typically, you will need to issue a SSL certificate signed by a Trusted Certificate Authority. You can do so using certbot which
automatically uses ACME provided by LetsEncrypt (free service).
https://policy.unimelb.edu.au/category/Facilities%20and%20IT
https://policy.unimelb.edu.au/category/Facilities%20and%20IT
https://lms.unimelb.edu.au
www.eng.unimelb.edu.au
https://www.melbournepollen.com.au/
https://badssl.com/
1. Set up a CA.
2. Create a certificate signing request and have the CA to sign the certificate.
3. Set up a web server with the certificates.
This activity is intended to be completed in pairs. One person will play the roles of both the CA and client, while
the other person will be the server administrator.
3.1 CA: Creating a CA certificate
A certificate authority (CA) typically distributes their root certificate offline to be included in OS distributions.
One key responsibility of a CA is to keep their private key secure as mismanagement can lead to a breakdown in
the chain of trust which enables an adversary to arbitrarily sign any random rogue intermediate certificates.
A chain of trust is established where the root certificate is used to sign downstream certificates. Clients verify
downstream certificates by checking their signatures against the public key encoded in their upstream certificate
(i.e. the root certificate).
root certificate →signs intermediate certificate →signs end certificate
Example: Verisign →signs unimelb.edu.au →signs www.unimelb.edu.au
In the following steps, we will produce our own chain of trust to setup TLS/SSL.
1. Generate a secure private key and name the private key myCA.key.
$ openssl genrsa -out myCA.key 4096
2. Generate the root CA certificate for your CA.
$ openssl req -x509 -new -nodes -key myCA.key -sha256 -days 365 -out myCA.crt \
-subj ‘/CN=COMP30023 CA/O=COMP30023’
Note that we have specified the common name and organisation name of the certificate in the command.
It is also possible to manually input this information (by removing -subj …) or load this information from
a configuration file. Try it out!
Normally, an intermediate certificate will also created, but we will omit it for the sake of time.
3.2 Client: Install the root certificate
1. The client now needs to obtain the root certificate from the CA and install it into their OS trust store.
Note that myCA.key should be kept as a secret, while myCA.crt should be distributed.
2. Copy the .crt file (from the CA) to this directory.
$ sudo cp myCA.crt /usr/local/share/ca-certificates/myCA.crt
3. Let Ubuntu add the .crt file’s path relative to /usr/share/ca-certificates to /etc/ca-certificates.conf.
$ sudo update-ca-certificates
3.3 Server: Create a Certificate Signing Request
1. Install and setup a basic nginx webserver.
$ sudo apt install nginx
2. Create a private key for the service.
$ openssl genrsa -out service.key 4096
3. Create a certificate signing request (CSR), this is basically an unsigned certificate for your service.
$ openssl req -new -key service.key -out service.csr \
-subj ‘/CN=<###insert-server-ip-here###>/O=COMP30023′
4. Send the CSR (and only the CSR) to the CA.
3.4 CA: signing the CSR
1. Verify that the person who is requesting the CSR is who they claim to be.
2. Use your CA certificate and key to sign the CSR.
$ openssl x509 -req -in service.csr -CA myCA.crt -CAkey myCA.key -CAcreateserial \
-out service.crt -days 365 -sha256
3. Send the signed service.crt to the web server.
3.5 Server: Setting the Webserver up for HTTPS
• Setting up nginx is quite cumbersome, so copy the configurations over to your VM. Replace /etc/nginx/sites-
available/default with the provided default file (appendix), filling in your IP address.
• Create a directory to store your service certificate and private key.
$ sudo mkdir -p /etc/ssl/service
• Copy the certificate (from CA) and private key (previously generated) to the directory.
$ sudo cp service.* /etc/ssl/service/
• Reload the nginx configuration (the nginx service should already be started).
$ sudo nginx -s reload
So we now have a webserver which is robust against man-in-the-middle attacks.
3.6 Client: Visit the service
Try curling the web server (you may need to install the curl package).
$ curl https://
You can also try to access the service using your browser. Note that will be warned by the browser because the
root certificate is not installed (trusted) locally, whereas it was installed on the VM in a previous step.
Consider the implications of installing the CA certificate into your local root certificate store.
3.7 Client Certificates (Challenge, Bonus)
Certificates can also be used for Client Authentication, where clients prove their identity to the server through the
use of digital certificates.
1. Server: Create a new CA for the web server (following prior instructions).
Copy serverCA.crt to the server certificate directory.
sudo cp serverCA.crt /etc/ssl/service/serverCA.crt
2. Server: Add the following lines directly above location / in /etc/nginx/sites-available/default :
ssl_client_certificate /etc/ssl/service/serverCA.crt;
ssl_verify_client optional;
And this line directly below location / :
if ($ssl_client_verify != SUCCESS) { return 403; }
Reload the nginx configuration to enable client certificate verification.
3. Client: Create a key client.key. Create a CSR client.csr.
4. Server: With the server CA, sign the CSR, to produce client.crt.
5. Client: Use the client key client.key and certificate client.crt to authenticate with the server.
$ curl –key client.key –cert client.crt https://
Now remove the –key and –cert arguments and observe the results.
6. Client (Extension): Create a PKCS#12 file and visit the website before and after installing it in your browser.
4 2-way communication using symmetric key encryption
In this section, we will be looking at setting up authenticated secure communication channels using Diffie- Exchange protocol. You must have completed Section 3 before this. You are encouraged to work in pairs
to do this section.
4.1 Diffie- Exchange
A primer on how it works.
1. There must be a mutually agreed public parameter such as the generator, g and the group order, always a
prime, p. This is typically a value chosen from well-defined internet standards.
2. Keying material is generated by both the client and the server. Let sk be a randomly chosen number between
0 and 2256 and pk = gsk. By the discrete logarithm hardness problem, it is computationally infeasible2 for an
adversary to compute logg(pk) to find sk3.
3. The client and server will exchange their public key over an insecure channel. The client typically generates
keying materials on the fly. So, client has (skc, pkc, g) and server has (sks, pks, g). sk is the secret key; pk is
the private key.
4. Client sends pkc and receives pks.
5. Client then computes ek = gskcpks ; while server computes ek = gskspkc
6. ek is ephemeral symmetric key for the secure communication channel between the client and the server.
Now let us setup a very simple chatting application that is secured using TLS using Netcat.
WARN: This section of the workshop is an extension of last week’s workshop material.
Realistically, you would want to author a proper program to do all the above steps automatically, but just to
observe and learn how everything works like clockwork under the hood, we will be doing every single step by hand,
manually using netcat and openssl. As a bonus, you are encouraged to author a program in any programming
language of your choice to properly accomplish the task.
The purpose of this exercise is to get your hands on how key derivation happens and numerical operations involved.
You will usually use libraries to perform these steps. Do not write your own crypto.
1. Let g = 2, p = 22953686867719691230002707821868552601124472329079 and pick a random sk ∈ [0, p− 1]4
2. Compute pk = gsk (mod p), and give this pk to your friend.
3. Your friend should now have given you their pkfriend, now compute the ephemeral symmetric key ek = (gsk)pk
4. The arbitrary-precision decimal calculator dc has an inbuilt operator for computing ga (mod p) for very
large numbers. The syntax is slightly cryptic (for the curious: it uses reverse Polish notation) but the value
can be computed by entering
g
where the g, a and p should be your values, the
above
p (for “print”).
Run the command dc with no arguments, and then cut-and-paste your numbers into the above expression.
To exit dc, enter either ^C or ^D (control-C or control-D).
Tasks using the material above:
2For now, it is computational infeasible, but not necessarily a decade later. Always stay up to date with the state of the art in
Cryptography.
3Convince yourself by briefly searching up how logarithm tables are constructed.
4We use smaller numbers to make it easier. This is very insecure.
1. Compute the symmetric key, ek to realise a secure communication channel between your partner and you.
Confirm that both of you got the same key independent of each other.
2. Both of you should now have the same key. However, this is not in the format required for AES. To overcome
this, we will use this shared secret value to generate a shared symmetric (AES) key:
openssl enc -aes-256-cbc -k your key -S 0 -P -md sha1.
3. You may want to save the initialisation vector (iv) shown to be used when encrypting your message later. How-
ever, remember that initialisation vectors need to be random, unknown to the person choosing the message,
and not reused. However they do not need to be kept secret.
4. Recall that last week, we have some experience using the same command.
4.2 Running Netcat
Netcat can be used in both client/server mode. You and your partner should now start a netcat server to receive
incoming connections.
nc -l
Pick a port number between 8000 to 10000.
Your partner should now be able to connect by running
nc
Now you can send/receive messages (without encryption) with your partner.
To improve your security further, overlay the netcat communication channel with encryption by encrypting your
messages using the same steps in last week’s workshop. To send the encrypted message to your partner, just paste
the encrypted output in the netcat client session and your partner should receive the encrypted message on their
server session. Your partner should then decrypt the encrypted message using the same decryption steps as per last
week’s workshop material.
4.3 Bonus: Authenticating your partner’s Public Key
As you’d have already known, reliably receiving your partner’s public key over the internet is not very secure
since there’s no way for you to know that your partner’s public key have not been tampered with. One way to
authenticate the public key is to get a CA to issue a certificate that signs your partner’s public key. In section 3,
we have shown you how your can start your own CA and issue certificates for your services, but this is inadequate
for the purposes of authenticating your public key. Discuss why not with your demonstrator?
Strategy to achieve authenticated encryption.
1. Ask your partner to install your root certificate you have generated in section 3.
2. Your partner should now be able to verify the authenticity of your public key by visiting your website with
cURL since it conveniently does all the requisite TLS checks.
3. Extract the public key from the webserver certificate. e.g.
openssl s_client -connect gitlab.eng.unimelb.edu.au:443 < /dev/null 2>&1 |
openssl x509 -pubkey -noout -modulus 2>&1 |
grep Modulus | cut -d ‘=’ -f2
4. You can use this public key to compute the symmetric key for a shared secret key as per the procedure
described above.
5 Endnotes
This is just the tip of the iceberg. There are many many more other interesting protocols at play that aim to make
internet communication more secure and private. In your own time, you should also check out DNSSEC, SMTPS,
Domain Authenticated Named Entity, DNS-over-TLS, and more.
A NGINX Configuration File
# SSL configuration
listen 8443 ssl default_server;
listen [::]:8443 ssl default_server;
ssl_certificate /etc/ssl/service/service.crt;
ssl_certificate_key /etc/ssl/service/service.key;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
Introduction
Digital Certificates
Services with SSL Certificates
CA: Creating a CA certificate
Client: Install the root certificate
Server: Create a Certificate Signing Request
CA: signing the CSR
Server: Setting the Webserver up for HTTPS
Client: Visit the service
Client Certificates (Challenge, Bonus)
2-way communication using symmetric key encryption
Diffie- Exchange
Running Netcat
Bonus: Authenticating your partner’s Public Key
NGINX Configuration File
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com