How does SSL use symmetric and asymmetric encryption? And how do I manage certificated for multiple sites on one host?

Question

First, some quotation from Microsoft TechNet's Managing Microsoft Certificate Services and SSL:

To recap, secure SSL sessions are established using the following technique:

1. The user's Web browser contacts the server using a secure URL.

2. The IIS server sends the browser its public key and server certificate.

3. The client and server negotiate the level of encryption to use for the secure communications.

4. The client browser encrypts a session key with the server's public key and sends the encrypted data back to the server.

5. The IIS Server decrypts the message sent by the client using its private key, and the session is established.

6. Both the client and the server use the session key to encrypt and decrypt transmitted data.

So, basically speaking, the SSL use the asymmetric encryption (public/private key pair) to deliver the shared session key, and finally achieved a communication way with symmetric encryption.

Is this right?

Add - 1 - 5:55 PM 12/17/2010

I am using IIS to host my websites. Suppose I have multiple sites on my single machine, and I want the client brower to use SSL URL to connect my sites. How many certificates do I need? Which of the following approach should I take?

1 - Apply for a single certicate and associate it to my single server machine which hosts mutiple sites.

2 - Apply for several certificates and associate each of my sites with its own certificate.

In IIS7, it seems I could only do approach 1.

Update - 1 - 6:09 PM 12/17/2010

I figure it out. I could install mutiple certificates on my server machine and bind each site with seperate certificate as necessary.

Solution 1

Yes, that's right. Asymmetric encryption is necessary to verify the others identity and then symmetric encryption gets used because it's faster.

Solution 2

You're wrong at points 4 and 5. The server and client independently compute the same session key. It is never actually transmitted at all.

Solution 3

I would suggest that you post your update as a separate question.

In any case - you will require multiple certificate - one per site. Remember that these certificates tie your machine to your address. Since each of the websites is going to have a different address (potentially) , you need different certs for each of the sites

Solution 4

You can only have a single SSL cert per listening port on the server. This is because the very first thing that is sent is the server certificate (as in your timeline). This is before the HTTP request so if you try to host two domains on a single server (say foo.com and bar.com) there is no way for the server to know which certificate to send to the client.

There are a few different ways to solve this problem:

1. Host different domains on different servers
2. Host different domains on different ports (eg. foo.com is serverd from 443 and bar.com is served from 8443). If you put your host behind multiple load-balancers, you can have them service all the sites on 443.
3. If the different domains are all sub-domains of a single parent domain, you can get a wildcard certificate. (e.g. domains www.foo.com, bar.foo.com, and baz.foo.com can all use a certificate for *.foo.com)
4. Get a single certificate for one of the domains and have the other domains listed as AltNames. (e.g. both foo.com and bar.com can use a foo.com certificate with a bar.com AltName)

Solution 5

.

The answer is both. You will find a nice explanation in 4 steps from digicert.com below:

.

• Server sends a copy of its asymmetric public key.
• Browser creates a symmetric session key and encrypts it with the server's asymmetric public key. Then sends it to the server.
• Server decrypts the encrypted session key using its asymmetric private key to get the symmetric session key.
• Server and Browser now encrypt and decrypt all transmitted data with the symmetric session key. This allows for a secure channel because only the browser and the server know the symmetric session key, and the session key is only used for that session. If the browser was to connect to the same server the next day, a new session key would be created.

https://www.digicert.com/ssl-cryptography.htm

View more solutions

Comments

[smwikipedia]

The quotation is from a MSDN tech article. Could you share your idea about how the session key is generated? I am new to this. Thanks.

[President James K. Polk]

No, the OP is not wrong. Your statement is only true for DH and DHE ciphersuites, which are not even supported by IIS. For RSA ciphersuites without DH the OP is correct.

[user207421]

That's the pre-master secret. The master secret is never exchanged, and neither is the session key which is derived from it. See RFC 2246 #8.1.

[sameers]

For which HTTP server is the claim, "You can only have a single SSL cert per listening port" true? It's not the case for Apache 2, as of at least summer 2014, I regularly run multiple domains off the same IP/port combo.

[user207421]

The session key is never encrypted and it is never sent. It is always negotiated. RFC 2246 #8.1.

[user207421]

Public key encryption of the pre-master secret is only used in DSA cipher suites.

[user207421]

No it isn't right. The session key is never transmitted at all, whether encrypted or otherwise.

[user207421]

@JamesKPolk Both the OP and the Microsoft article are wrong. The only normative reference here is RFC 2246 and successors. Not Microsoft. Your confusion between the session key and the pre-master secret remains uncorrected.

[KeyC0de]

AFAIK SSL uses public key cryptography (ie. asymmetric encryption) to verify the identity (as the answerer said) and afterwards symmetric encryption to get things rolling faster (since the possibility of id theft is out).

[user207421]

You can have as many certificates as you like, and send whichever one matches what is specified in the ClientHello message or the hostname the client sent to. The very first thing that is sent by the server is the ServerHello message, which does not contain a certificate. The Vertificate message is the second message from the server, and the third in the handshake counting the ClientHello.

[user207421]

The session key is never sent. See RFC 2246 and successors. Link is wrong. CAs don't seem to have clue 1 about this stuff. GoDaddy make the same mistake in their literature.

[bhosleviraj]

Why switch to symmetric encryption for communication? Because it is faster and easier to do so?