CSCI 7000-008 Assignment 2

Matt Niemiec

9/17/19

Part 2.1
It took a few minutes to figure out that serial was a file, not a folder, and that serial, not index.txt,
contained the number. I also made the educated guess that openssl.conf was a typo, and instead used
openssl.cnf. However, once I got past that, the first command went very smoothly. I decided to run
everything inside my ∼/rootca directory. The result of the key generation is shown in the screenshot
below.

1
Part 2.2
I didn’t realize at first that it was just easier to create all the keys in the same directory. Of course, it doesn’t
really matter, but I wasn’t comfortable enough to know how to move the keys around until the end of the
lab. I also didn’t really get the point of the key-signing request, so I kept getting errors saying that the
information didn’t line up. But I think I’ve got it now. Anyways, below is the result of me running all the
commands that it said to run exactly as it said to run them. I felt this was really straightforward...

2
3
Part 2.3
Parts 2.3.1 and 2.3.2
Configuring /etc/hosts was obviously a no-brainer. Following the commands to create server.pem
was also really straightforward, and getting the server running worked without a hitch, once I entered the
right password. As promised, and as shown below, Firefox was not happy to accept this new site.

4
Part 2.3.3
This part was also not bad. Firefox is really straightforward with how to add a trusted certificate. At least,
their old versions were, and trusted the certificate completely. Below you’ll see a screenshot of the https site
working well.

5
Part 2.3.4
Part 2.3.4.1
This was actually the hardest task in the entire lab. I could not, for the life of me, get Firefox to clear the
certificate and request a new one from the server. I assumed that it was storing it somewhere. At least, that’s
what I thought until I started to realize that I was editing the parts I could read in server.pem, which
are not the parts that get sent over. Anyways, after clearing everything, searching through files, reinstalling
Firefox, and just starting over on a different machine, I finally got the error message I wanted. Ta-da! Firefox
didn’t trust the certificate! I changed the value from what was signed, so when Firefox computed the values,
it didn’t match up anymore. I also definitely had to try modifying several different parts of server.pem
before I got one that was modify-able. We can see Firefox telling us below about an ”invalid signature.”

6
Part 2.3.4.2
As shown in the screenshot below, pointing the browser to https://localhost.com does not give a
secure connection because we specifically asked the CA to sign our address for https://SEEDPKILab2018.com,
and so when Firefox goes to verify that the certificate is the one that it’s expecting, it shows a different do-
main name. Good think browsers don’t let any domain name authenticate itself for any other one!

7
Part 2.4
I followed the directions, and, surprise, a website came up! I set up a new folder, /var/www/seed, and
made my Apache config files point to that folder. That’s really the only thing I changed about the commands
that were provided. And, of course, I had to customize the directory locations for the certificate and key.
No, I didn’t try very hard on the HTML, but it’s a site running through Apache on port 80. You’ll find the
screenshots of the working site, running it, and even the Apache config files below.

8
9
Part 2.5
Part 2.5.1
I decided to emulate my bank, US Bank. So, I followed many of the same steps that I used for generating
certificates for SEEDPKILab2018.com and instead put in information for usbank.com. Of course,
I didn’t emulate the real US Bank’s certificate exactly, but the domain name was right. But, oh, no! My
browser didn’t accept the certificate! Well, that’s because I just generated a certificate on its own, and Firefox
doesn’t know to trust that certificate. Interestingly enough, though, Firefox didn’t remember to redirect to
port 443, so I could use the site over HTTP perfectly fine. However, when I went to port 443, the broken
lock came up, and it made me know I was doing a bad thing. This makes sense because there’s no SSL
certificate to verify over HTTP, so there’s nothing to be triggered as wrong. However, when we use the
secure version, there’s no trusted root CA. The screenshots of both scenarios are posted below.

10
.

11
Part 2.6
For this part, I completely deleted the old files from the old hacker’s certificates. Instead, I followed exactly
the directions for creating the SEEDPKILab2018.com certificate, but I put in usbank.com instead.
This included the CA signing the certificate this time. Because it was signed by the CA, and the CA is
trusted by Firefox, it was trivial to redirect the page to a now green-locked usbank.com page. It was a bit
of an odd sight, to be sure. But you can see the genuine page below. Yeah, I didn’t try any harder on this
HTML.

12
Conclusion
So, that’s it! A step-by-step of how I went through, generated keys, started web servers, and performed a
MITM attack. Overall the lab was interesting. I think the part I learned the most was when I was beating
my head against the table trying to get Firefox to “clear my certificate,” but realized that I wasn’t actually
changing the information. I also found it astonishing how easy it was to SSL strip US Bank and pass in an
HTML site that didn’t raise any flags whatsoever. Then, on top of that, if just one CA signs a false certificate,
there’s no way to verify that site beyond what you have, which is really scary. I guess this is why two-factor
authentication is becoming more and more prevalent.

13