CISE Help & Resources

SSL & Certificates

Download CISE Certificate

If you would like to skip the following explanation of certificates and just download the Site Certificate for CISE, you can import the site certificate into your current browser now by following the following link:

Import the CISE Site Certificate

This will allow your current browser to download any certificate issued by the CISE department without the need for prompting (no annoying boxes on https:// pages!)

NOTE: Windows Users:
If you use Internet Explorer to import the certificate, all Microsoft programs (IE, Outlook, etc.) should recognize the certificate and all certificates signed by it.
NOTE: Eudora Users:
You will need to download the CISE certificate to your home machine and import with Eudora.
Download CISE Certificate

Then, select SSL. To do this, from the Personalities Window, Right Click on the Personality in question and select 
Properties
    -> Incoming Mail
	    -> Last SSL Info
Then go to the Certificate Manager and select the SSL Certificate in question. Click Add to Trusted.

If you're interested in what's going on, read on.

Public Key Cryptography -- What is it?

Public Key cryptography is an encryption system that requires two keys. A message encrypted with one key can only be decrypted by the other. In practice, one key is made available to the public, and one key is kept private.

Anyone who has another person's public key can encrypt a message that can only be decrypted by that person, the holder of the private key. This allows anyone who knows someone's public key to send a private message to that person.

Signatures

Public key cryptography can also be used to verify that you are who you say you are.

A message encrypted by the private key can be decrypted by everyone who has the public key. Since the public key may be held by any number of people, such a message cannot be viewed as private, however it does serve as verification that the private key holder and no one else encrypted the message (provided they key wasn't compromised, etc.). This can act as a type of signature.

For instance, if Alice generated a message, then encrypted the message with her private key, and sent both the unencrypted and encrypted messages to Bob (who has Alice's public key), Bob could decrypt the second message and compare it to the first, and if both messages are identical, Bob can conclude within a reasonable doubt that:

Confirming a public key

One of the main problems with public key cryptography is the initial verification. Once Bob is positive that he has Alice's public key (she gave it to him face-to-face), Bob can be reasonably sure that signed messages from Alice are really from her.

However, if Bob retrieves Alice's public key from her home page, how can he be sure it's her public key in the first place, and not a fake key set up by Mallory (notorious for attempting to intercept Alice's communications)?

In general, there are two approaches: a person-to-person web of trust, or a top-down Public Key Infrastructure (PKI).

Web of Trust

In the web of trust, a group of people electronically submit their public keys to a keyserver (place to store keys), then meet in person to verify that the key at the server is their own public key. Once everyone is satisfied of the veracity of the other keys, each person signs everyone else's public key, certifying that the key actually belongs to the person in question, and then sends the signed key back to the keyserver, which keeps track of who has signed whose key. The more signatures a person's public key gets, the lower the likelihood that their key is a forgery, in general.

This forms the initial web of trust. Each member of the web can then sign other's public keys, bringing them into the web as well.

While this is a good way for groups of people to authenticate each other, it becomes difficult when various disparate organizations need to be able to authenticate each other. This is where a public-key infrastructure comes in.

Public Key Infrastructure

In a typical PKI implementation, one or more sites are setup to be Certificate Authorities. The CA creates the root key, which is declared "trusted by all", and then creates keys for other entities and signs them with the CA root key, denoting them as certified by the CA. The signed keys are called certificates, indicating that the CA is declaring them certified to be valid.

This of course begs the question, "How can I trust that the root CA is who they say they are?". The answer is, you can't know for certain, you simply have to trust that they are, and that if they aren't they'll be discovered eventually. In general, however, this narrows down the number of people you have to blindly trust to a few organizations that most people are trusting. You can check

Netscape->Security->Signers

to get a list of organizations that your browser "pre-trusts" as valid certificate issuers. Verisign and Thawte are the two most widely known.

Connecting to Sites Securely

There are several methods for connecting to remote sites securely. "Connecting securely" means, in general

One of the most popular methods for secure connections is the Secure Sockets Layer (SSL), also known as Transport Layer Security(TLS).

SSL makes use of server certificates for verification of server identity. When you connect to a remote SSL server using, say Netscape, the site sends the cert to your browser. The browser checks signature against the list of default signers, and if the cert was signed by one of them, verifies and accepts the cert silently, and the user never sees any part of the transaction.

However, if the cert was not signed by any of the default signers, the browser pops up a window asking the user if he/she wishes to accept the cert. The user can accept the cert for the session, accept the cert until it expires, or deny the cert altogether.

For users who have not imported the CISE site certificate into their list of default signers, these messages will occur every time they connect if they accept certs for one session at a time, or they will occur when the key expires if they accept the cert until then (approximately once a year at CISE).

However, users can import the CISE Site Certificate to prevent prompting altogether.

The CISE Site Certificate

The point of all of this is that you can set up your browser to accept all certificates ever issued by CISE for whatever service to which you are connecting, such as secure http, imap, or ftp. All you need to do is click on the link at the top of this page to begin the import process. You will be prompted this one time to verify you wish to accept CISE as a default signer, and afterwards, even when the certificates change, you shouldn't be prompted to accept new certificates.

Remember, however, you're then trusting the CISE certificate maintainers to be who they say they are, and not someone forging the certs, getting you to connect to fake servers, and taking all kinds of personal information. How do you know for sure? Well, you can't. Computer security is about risks and probabilities, not "Is this absolutely secure or absolutely not" . You'll simply have to decide to trust that the cert is from CISE. To help in your decision, here are the fingerprints of the certificate:

MD5  Fingerprint=45:F8:A7:A5:67:5E:29:4D:9A:7E:E0:61:68:A0:43:C3
SHA1 Fingerprint=40:FF:C4:30:D0:B8:77:2D:64:A8:E1:6B:3C:B6:2C:1B:2B:93:52:28

After importing, check the fingerprints (you should see at least one) at

Netscape->Security->Signers->Edit->CISE_Certificate_Authority

to make sure they match. If they do, you can be reasonably certain that whoever generated the cert also created this web page. Whether you think it's likely that whoever did both is an intruder not actually affilitated with CISE is up to you :->

References

About CISE

Academics

People

Research

News

Help & Resources

Contact Us

 

Info for Students

Info for Faculty & Staff

Industrial Advisory Board