STEP 0: Lab Prep

  1. Make sure you are viewing this page in Firefox, and do the lab in Firefox!
    If not, close your browser and reopen this page in Firefox.
    This page uses forms in which you will enter values, so Javascript must be enabled.
    Once the page is open in Firefox, do NOT refresh/reopen the page: you will lose information you have already entered.
  2. Create a directory named class28 on your Desktop. All files downloaded and created for this lab MUST be in this directory!
  3. Open two Administrator command-prompt windows.
    All commands for this lab MUST be entered and executed in these command-prompt windows.
    DO NOT CLOSE THESE WINDOWS!
    In the command-prompt windows, use the cd command to change directory to your class28 directory.
  4. This lab will use openssl extensively. You should have already installed openssl when you installed the SI110 Course Software. The following command will ensure that Windows will find the openssl program (assuming you installed it!). Copy the below command, paste it into your command window, and execute it. 
    set path=%path%;C:\OpenSSL-Win32\bin
  5. Give the command hostname in your command-prompt window.
    Copy the hostname that appears in the command window, paste it into the box below, and click the Submit button.
    (should look like: 16dumbrows-m34a)
  6. Use Notepad (or Notepad++) to create a file with the following contents: 
    <html>
<body>
<h1>Welcome to </h1> Trust me, I really am who I say I am!
</body>
</html>
    Name the file index.html, and save it in your class28 directory.

    Open the file in Firefox and verify that it looks like it should. (And you should be able to tell what it ought to look like!)

STEP 0.5: Instructor Demo

Sit tight and participate in this demo.

STEP 1: Certificates and Trust

In a new Firefox tab, open https://www.navyfederal.org.
This is Navy Federal Credit Union's page. Certainly we would like to be sure that this really is Navy Federal's page before entering a username and password! If a Bad Guy using a Man-In-The-Middle attack could successfully pose as the Navy Federal website, some very bad things could result.
  1. If you click on the box immediately to the left of the URL, you'll see a pop-up box that tells you: to whom you are connected, who verified this identity, and that your communication is encrypted. It's the identity and the verification of that identity that we care about. That information comes to your browser as a certificate (more precisely, a certificate using the X.509 standard).

    The certificate certifies that the identity www.navyfederal.org is associated with a particular public key.
    Why? So that when you send data to navyfederal.org that has been encrypted with that public key, you know the actual entity "www.navyfederal.org" is the only one who can decrypt the data.

    But what makes you trust the certificate?

    The idea is that there are Certificate Authorities, entities that vouch for the validity of certificates by signing them. When your browser was installed, it came with a list of Certificate Authorities that it (and thus you) already trust -- but you can add or remove authorities.

    You might be surprised at who you are currently trusting. Let's look!
  2. Certificate authority TURKTRUST not so trustworthy
    Certificates that your browser is set to "trust" are labelled with what exactly you trust them for: HTTPS sessions, digitally signing e-mail, digitially signing code, or issuing certificates, are some examples. Certificate authorities that your browser is set to trust to issue certificates are given essentially unlimited trust.

    In January 2013, it was discovered that the authority Certificate Authority TURKTRUST had accidently issued a certificate to a customer that stated that the certificate was valid for issuing new certificates — it should only have been valid for HTTPS sessions. This certificate was then used to issue fradulent certificates for google domain names, which allowed the bad guys to carry out man-in-the-middle attacks. The blog krebsonsecurity.com has the story: Turkish Registrar Enabled Phishers to Spoof Google.

    Click on the Firefox logo in the upper left corner of the Firefox window, choose Options then click on Options in the resulting menu.
    (If you have the firefox Toolbar installed, open the Tools menu, and from it choose Options)
    Click on the Advanced button, choose the Encryption tab, and click on the View Certificates button in the resulting window.
    Choose the Authorities tab. This is the list of authorities you've been trusting. Scroll through the list.
    Is there anyone on that list you're not sure you'd want to trust?
  3. Going back to www.navyfederal.org ...
    Click on the box immediately to the left of the the www.navyfederal.org URL, and from the resulting pop-up click on the More Information... button. This lets you look at all the information contained in the certificate (View Certificate). Check out the details section:
    Who signed this certificate (the O (Organization) value of the Certificate Issuer) ?
    When does this certificate expire (i.e., Valid Not After ...) ?
    What algorithm is used for the signature (Certificate Signature Algorithm) ?
    Note: The Subject's Common Name (CN) is the real, no-kidding identity that the certificate is about.
  4. You will now download an unknown certificate and look at it.

    Right click the following link, select Save Link As ..., navigate to your class28 directory, and save the certificate there: unknown certificate

    Examine the certificate by entering the following command in your command window: 

    openssl x509 -text -in ra37891_cert.pem

    To see what happens when you send your browser to a site with a fishy certificate like this, pull up: 

    https://rona.cs.usna.edu
    What happened? Check out the "Technical Details".

STEP 2: How it Works

Under the hood, here's basically what happens:
Alice wants to connect via https to bob.org, which is Bob's server.
Alice trusts a Certificate Authority named Cedric.
All three of these - Alice, Bob, and Cedric - have public/private key pairs. Alice, of course, has Cedric's public key, and she trusts it is authentic, because she trusts that Certificate Authority.
  1. Bob submits to Cedric: proof of his identity, the domain name he wants a certificate for, and his public key.
  2. After verifying Bob's identity, Cedric uses his private key to encrypt the pair (domain name, public key) ... which in this case is (bob.org,Bob's-public-key). That encrypted "thing" is the actual certificate bob.org will use to prove its identity.
  3. When Alice browses to bob.org, it sends Alice its certificate: (bob.org,Bob's-public-key) which has been encrypted with Cedric's private key.
  4. Alice decrypts the certificate with Cedric's key public key (remember, Cedric is a certificate Authority she trusts). She now has (bob.org,Bob's-public-key). She knows Cedric must indeed have created this certificate, because his private key is required to make something decryptable by his public key.
  5. Because she trusts Cedric, Alice trusts that the public key in the certificate really belongs to bob.org. She can then use it to send data and ensure confidentiality.
The actual scheme used by X.509 is a little more complicated that what we described, but conceptually the same.

STEP 3: Set up your own secure webserver with a signed certificate

You are going to run a dirt-simple web-server hosting a dirt-simple web-site off of your laptop. The site will be accessible via https, with certificates and all. Your site will be accessible via your computer's full domain name (N/A), and you will create a certificate, which will be signed by the SI110 Certificate Authority, will certify that the name matches your public key (which you will generate for yourself).

1. Generate a public private key pair


  
2. Fill in a certificate request form, requesting that the identity
N/A
be certified to match the public key generated in (1).


  
3. Submit request to SI110 Certificate Authority to have a certificate created and signed.


  
4. Start an HTTPS webserver process listening to port 443


  1. This command generates a 1024-bit RSA public/private key pair and stores it in a file named pubpri.key file:
    N/A
    Use the dir command in your command-prompt window and verify that you have just created a file named pubpri.key
  2. The next command generates a request to certify that identity is associated with the public key you've just created. You will later submit this request to the SI110 Certificate Authority. Fill in all fields for the request except for "common name" with lies (i.e. make stuff up). The "common name" field must be your computer's full domain name.

    Important For "Common Name" you must enter exactly this:    ← READ THIS    
    N/A
    Use the dir command in your command-prompt window and verify that you have just created a file named .csr and that it's size is not 0.
  3. The next step is to actually submit your request to the SI110 Certificate Authority.
    Using the Browse button below, choose the file .csr from your class28 directory, then press the Sign This File button.
    Choose a file to upload:

    Follow the directions on that page, then return to this page, then use the dir command in your command-prompt window and verify that you have just created a file named .crt

  4. Finally, you need to actually launch your very own secure webserver, which can serve up your beautiful index.html page in a secure and authenticated manner!
    Important: Just let this run. If you need to bring the webserver down, just give a ctrl-c while in the terminal window. However ...
    Importanter: Please leave the server running for the rest of the period. That means this particular command shell won't be available for entering commands. 
    N/A

STEP 4: Testing

For the next phase, you need to partner up with someone. You'll test their page by trying to access it, while they test yours. So you'll need to get your partner's hostname and enter it in the form below:
← if you refresh this page, reenter partner's hostname and resubmit
  1. Note: DO NOT ADD AN EXCEPTION when you try to open the following web page!
    Pull up your partner's page using the URL: ENTER PARTNER'S HOSTNAME ABOVE TO GET URL ← you must put "/index.html" on the end!
    Note: DO NOT ADD AN EXCEPTION.
    Does your browser accept its certificate? No! (What message do you get?)
    The problem is that the certificate is not signed by a certificate authority you actually trust! So while Firefox (and thus you!) trust the Hongkong Post to certify identities, it (and thus you) don't trust the SI110 Certificate Authority.
  2. For the rest of this period, you are going to trust the SI110 Certificate Authority. You indicate this trust by adding its certificate to Firefox's list of trusted Authorities. To do this:
  3. Now try pulling up your partner's page again. Note: It may take several seconds to load. It should appear in your browser with no warnings, and if you click on the little blue box or lock icon to the left of the address bar, you should see a pop-up message that tells you that you have a secure connection. Click on the More Information... button and verify that this site's certificate is indeed signed by the SI110 certificate authority. Thus, your browser trust your partner's site's certificate because it trusts the SI110 certificate authority.

STEP 5: How does this stop bad guys?

What would a bad guy attempting a man-in-the-middle attack look like? He'd look like another host running a webserver claiming to be ENTER PARTNER'S HOSTNAME ABOVE TO GET URL. Let's simulate that, and see what happens.
  1. Choose a third member of your class to serve as your Bad Guy, and enter IP address of his machine:
    ← if you refresh this page, renter the Bad Guy's IP and resubmit

    We're going to trick your machine into thinking that the Bad Guy's computer is really your partner's.
  2. In your Administrator shell give the following command, which will allow you to edit (Note: there is no .txt extension at the end of the filename hosts!) 
    notepad \Windows\System32\drivers\etc\hosts
  3. Add the following line to the end of the file: 
    ENTER BAD GUY IP ABOVE TO GET LINE FOR ETC\HOSTS FILE
    ... and Save (not Save As), but do not exit Notepad.

    What this does is to tell Windows that the domain name ENTER PARTNER HOSTNAME ABOVE should resolve to ENTER BAD GUY IP ABOVE. and not to bother querying a nameserver.

  4. Now enter the URL for your partner's website again (or shift+refresh if it's still in the URL bar). What message do you get? (Be sure to check "Technical Details".) The Bad Guy doesn't have the proper certificate for the domain name, and your browser knows it!
    What other alternatives does the Bad Guy have? The Bad Guy can't make a fake certificate, because he can't even pretend-sign something as the SI110 Certificate Authority, because he doesn't have their private key. And he can't just use your partner's certificate, because he'd need their private key. So the Bad Guy's only option is to trick one of your trusted Certificate Authorities into signing a bogus certificate that claims your partner's domain name identity as his own. This happens! Check out this discussion.

STEP 6: Lab Cleanup

  1. Remove the line you added to your C:\Windows\System32\drivers\etc\hosts file.
  2. Remove the SI110 Certificate Authority from your Firefox list of trusted Certificate Authority.

STEP ∞: Your Personal Certificates

Using Chrome, and without your CAC card, visit one or all of following sites: Did that work? What was the website looking for?

You need to use DoD issued personal certificates! To learn about your own digital certificates on your CAC card, perform the following steps.

  1. Insert your CAC card in the card reader slot on your laptop. Double click on the gray and blue ActiveClient Agent - Smart Card Inserted icon in the lower right portion of your screen. Click on My Certificates and then you should see your three certificates. Right click on each one and select View to see what information that certificate stores.
  2. Now that your CAC has been inserted to the card reader, your certificates have been loaded into the browser and are ready for use. To see this, Close Chrome, reopen, and try to visit any of the sites again (NOTE: The https://www.portal.navy.mil site can be finicky and slow). This time you should be prompted to select one of your digital certificates from your CAC card. Select one (EMAIL certificate is usually best) and you should be prompted next to enter your CAC PIN. If you know your PIN, type it, and you will get access to the sites. If you do not know your PIN, you cannot get to the site. The site requires two-factor authentication: something you have (your CAC card) and something you know (your CAC PIN)!
  3. To see your certificates in Chrome's certificate list, go to Chrome's Options --> Under the Hood. Scroll down to HTTPS/SSL and click on Manage certificates...select the tab for Personal and you will see your CAC certificates there. The Intermediate Certificate Authorities tab should show a bunch of DOD certificates - those are also needed to get to DoD sites and are part of the chain of trust from DoD root certificates down to your DoD issued personal certificate!