Final exam

Due 5:00PM Monday, 20 November 2023
Hand in as final.pdf via Moodle

This is an open-notes, open-Internet, open-book exam. You may post questions about the exam on #general on our Slack workspace, but otherwise you may not discuss the exam with anybody other than Jeff Ondich.

1. The TLS handshake (15 points)

We spent a lot of time in the first half of the course acquiring the basic vocabulary and background you needed to make sense of the TLS. What we didn't do is dig deeply into the TLS specification to see how it arranges for a client and a server to encrypt their communications. We're going to correct that omission now.

Start by taking a look at the slides for Friday, October 6. On page 11 of that PDF, there's a drawing of a rough protocol named "Protocol 2.2: DH + challenge", in which Alice follows the DH process by sending Bob a challenge in the form of a random number R, and Bob sends a response to the challenge. This problem will focus on comparing Protocol 2.2 to the actual TLS 1.3 handshake as described in RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3.

1. Briefly, what are the goals of a TLS handshake (under the assumptions outlined in the "advice" section below)?
2. Why isn't a Diffie-Hellman key exchange sufficient to meet these goals?
3. In our "Protocol 2.2" from Oct 6, explain carefully why you believe this protocol to achieve the TLS handshake goals. (A good explanation here would clarify how, when, and by whom interference in the handshake could be detected if it were attempted.) Alternatively, if you think Protocol 2.2 is not up to the task, explain carefully why not, with a detailed example of what could go wrong.
4. [I expect that this answer will be substantially longer than any of the previous answers.] For each of the elements of Protocol 2.2, identify where in RFC 8446 that element or its analogue occurs during a TLS handshake. When I say "elements", I mean things like "what is S_B and where does it come from?" and "when does Alice share g^a mod p with Bob" and "where/when does Alice issue a challenge to Bob", etc.

Here's a little advice for completing this problem.

• Assume that this TLS handshake uses "DHE (Diffie-Hellman Exchange) over finite fields", which is the form of Diffie-Hellman that we have studied this term. You don't need to learn anything about ECDHE (Elliptic Curve DHE) at this point, even though it's very cool.
• Assume that this TLS handshake does not use "pre-shared keys". That's a whole different can of worms, and you can just skip all of that.
• Assume there are no error states to deal with. For example, assume there's no "HelloRetryRequest" in this handshake.
• One good place to start studying the TLS handshake is the diagram at the start of Section 2: Protocol Overview.
• There's some useful notation and vocabulary in Section 3: Presentation Language. If you find yourself unclear about how a particular formal notation is being used, or what a word like "opaque" or "octet" means, you'll probably find the answer in section 3.
• Good answers to most of the questions above will include one or more quote or citation from RFC 8446. Please make it easy for me to find the sentence (or diagram, etc.) you're citing.
• You're going to spend a fair amount of time being confused. That's natural and OK. Just try to find the thread that corresponds roughly to our "Protocol 2.2", and you'll be fine.

2. A little pen-testing (15 points)

Take a look at http://danger.jeffondich.com/index.php. Try uploading a picture. Before you do this, here are some notes and requests.

• THE BIG NOTE: Your classmates and I are trusting you to upload only pictures that are consistent with a welcoming and inclusive class environment. Please don't violate this trust.
• Please only upload pictures of size 1MB or less. (It's easy to use standard macOS or Windows image-viewing software to export your images as smaller files.)
• Please include your username in the name of any file you upload (e.g., dmusican.jpg, jondich_moose.png, etc.). Again, please don't abuse this upload capability by, for example, using somebody else's username.

OK, now that you've got the idea of what's going on, you're going to use techniques related to those I used in one of my demos on Friday, November 11 to find a secret on the danger.jeffondich.com server.

1. Use gobuster to try to find all the subfolders of this website's top-level folder (i.e., the folder that contains index.php). List all the subfolders that gobuster finds.
2. Use the gobuster results to help you find a file named kindasecret.txt. Tell me where you found this file, and what the secret is.
3. In what folder are the uploaded files stored? How do you know?
4. Are you able to view the uploaded files with a browser? If so, how? If not, why not?
5. Will the website allow you to upload files that are not image files? (Subtle hint: the answer to this question is Yes.)
6. I wonder what would happen if I uploaded a PHP file instead of an image file...maybe you could show me a particular PHP file, modeled on the class notes from November 11, that I could upload for nefarious purposes.
7. Assuming you now have a sufficiently nefarious PHP file living on the danger.jeffondich.com server, show me how you can list all the subfolders of the web root folder, not just the ones that the gobuster output gave you.
8. Find a file named secret.txt, tell me which folder it's in, and give me its contents.
9. [1 point extra credit] Find a file named supersecret.txt somewhere on this server, tell me which folder it's in, and tell me its contents.

3. Same-origin policy (12 points)

Next time, an alternative to this problem might involve Kerberos (ASP-REP roasting, Kerberoasting) to talk about things like what kinds of attacks preauthentication either prevents or makes more visible.

This term, we have studied many scenarios where there are various human, organizational, and software entities exchanging information in a sequence of steps over time. Often, these scenarios have included a "normal flow" of information and then one or more "attack flows". For example, the normal flow for the Diffie-Hellman key exchange procedure Alice and Bob exchanging g, p, g^a mod p, and g^b mod p at various times. But there's also an attack flow, where Mal acts as persion-in-the-middle and engages in a different sequence of exchanges with both Alice and Bob. (Then, of course, there are a bunch more information flows showing how TLS and a certificate-based public key infrastructure can thwart the person-in-the-middle attack on Diffie-Hellman.) Practicing how to articulate these flows clearly and in detail has been an important part of your work this term.

For this exercise, you will read about the same-origin policy and describe some flows associated with it.

The best answers to the following questions will be detailed but easy to read. For many information flows, I like to use a simple diagram showing the communicating entities (e.g. a browser and a web server) on the left and right, with arrows running horizontally labeled with the pertinent information being conveyed. Sometimes, there's more to say for a step than an arrow label can contain, or there might be more than two entities exchanging information, so use your judgment on how to express your answers clearly and simply.

1. Assume that the browser is not using the same-origin policy. Show an information flow illustrating how an attacker could harm the user of the browser. (Even the simplest attacks of this sort have several steps and several types of information sent between more than two entities, so this will require a little care to answer clearly.)

2. Now assume that the browser is using the same-origin policy. Show the step(s) in the flow from your previous answer at which this policy thwarts the attack. Explain clearly why the attack fails.

3. Suppose a website wanted to provide web pages from port 443 and also an API from port 8888. For example, suppose there's a search form at https://tapirsunlimited.com/search/, but when the user clicks the Submit button on that page, the Javascript on the search page issues a query to https://tapirsunlimited.com:8888/ to get the search results. This architecture separates the user interface from the database access in a fairly natural way, so you can imagine why a web developer might want to organize things this way.

   • What about this system architecture would violate the same-origin policy on the user's browser? (This question has a very short answer.)

   • In specific detail, what would the tapirsunlimited.com developer need to do to take advantage of Cross-Origin Resource Sharing (CORS) to enable the two-port architecture to work?

4. Fun for Jeff (2 points)

Suggest something fun I can do over break. I love books, music, movies, TV, hiking, coding, games, and lots of other stuff, so don't be shy about anything that might come to mind. Thanks!

Let's call it a term

Congratulations on getting through the term. It was a tremendous pleasure working with you all this term. Have a great break, and keep in touch!