RE: More SSL questions

["Yvan Boily" <yboily () seccuris com>]

A basic understanding of how HTTPS connections work is required to
understand how data is protected.  When using HTTPS to connect to a server
the client and server undergo a handshake to negotiate a key for symmetric
encryption.  This key is then used to encrypt all further communications for
that connection.

Once that encrypted channel has been created any HTTP transactions are
performed.  It does not matter if it is a GET, POST, TRACE, PUT, or
MYCUSTOMMETHOD.  The HTTP exchange is completely encapsulated within the
encrypted communication, and will be accorded the level of protection
granted by the specific algorithm agreed on by the client and server.

The two most commonly used forms of encryption for HTTPS are SSLv2 and TLS
(which supports a fallback to SSLv3).

The first excerpt below is a discussion of the SSL handshake which is
performed prior to the transmission of data.  It is followed by an excerpt
from the RFC for TLS and the handshake used for key negotiation for TLS.

Also, just a heads up for those who don't know about or read the RFCs...
They are valuable resources, and most (all?) can be viewed at
http://www.ietf.org/rfc.html if you know the rfc number, or if you are
particularly nerdy (like me) you could just browse the RFC Index for
interesting topics :P

[------------ Excerpt from
http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
------------]
The SSL Handshake 
The SSL protocol uses a combination of public-key and symmetric key
encryption. Symmetric key encryption is much faster than public-key
encryption, but public-key encryption provides better authentication
techniques. An SSL session always begins with an exchange of messages called
the SSL handshake. The handshake allows the server to authenticate itself to
the client using public-key techniques, then allows the client and the
server to cooperate in the creation of symmetric keys used for rapid
encryption, decryption, and tamper detection during the session that
follows. Optionally, the handshake also allows the client to authenticate
itself to the server.

The exact programmatic details of the messages exchanged during the SSL
handshake are beyond the scope of this document. However, the steps involved
can be summarized as follows (assuming the use of the cipher suites listed
in Cipher Suites with RSA Key Exchange):


The client sends the server the client's SSL version number, cipher
settings, randomly generated data, and other information the server needs to
communicate with the client using SSL. 

The server sends the client the server's SSL version number, cipher
settings, randomly generated data, and other information the client needs to
communicate with the server over SSL. The server also sends its own
certificate and, if the client is requesting a server resource that requires
client authentication, requests the client's certificate. 

The client uses some of the information sent by the server to authenticate
the server (see Server Authentication for details). If the server cannot be
authenticated, the user is warned of the problem and informed that an
encrypted and authenticated connection cannot be established. If the server
can be successfully authenticated, the client goes on to Step 4. 

Using all data generated in the handshake so far, the client (with the
cooperation of the server, depending on the cipher being used) creates the
premaster secret for the session, encrypts it with the server's public key
(obtained from the server's certificate, sent in Step 2), and sends the
encrypted premaster secret to the server. 

If the server has requested client authentication (an optional step in the
handshake), the client also signs another piece of data that is unique to
this handshake and known by both the client and server. In this case the
client sends both the signed data and the client's own certificate to the
server along with the encrypted premaster secret. 

If the server has requested client authentication, the server attempts to
authenticate the client (see Client Authentication for details). If the
client cannot be authenticated, the session is terminated. If the client can
be successfully authenticated, the server uses its private key to decrypt
the premaster secret, then performs a series of steps (which the client also
performs, starting from the same premaster secret) to generate the master
secret. 

Both the client and the server use the master secret to generate the session
keys, which are symmetric keys used to encrypt and decrypt information
exchanged during the SSL session and to verify its integrity--that is, to
detect any changes in the data between the time it was sent and the time it
is received over the SSL connection. 

The client sends a message to the server informing it that future messages
from the client will be encrypted with the session key. It then sends a
separate (encrypted) message indicating that the client portion of the
handshake is finished. 

The server sends a message to the client informing it that future messages
from the server will be encrypted with the session key. It then sends a
separate (encrypted) message indicating that the server portion of the
handshake is finished. 

The SSL handshake is now complete, and the SSL session has begun. The client
and the server use the session keys to encrypt and decrypt the data they
send to each other and to validate its integrity. 

[------------ Excerpt from http://www.ietf.org/rfc/rfc2246.txt?number=2246
------------]
The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS Record
Layer. When a TLS client and server first start communicating, they
agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and use public-key encryption
techniques to generate shared secrets.

The TLS Handshake Protocol involves the following steps:

  - Exchange hello messages to agree on algorithms, exchange random
 values, and check for session resumption.

  - Exchange the necessary cryptographic parameters to allow the
 client and server to agree on a premaster secret.

  - Exchange certificates and cryptographic information to allow the
 client and server to authenticate themselves.

  - Generate a master secret from the premaster secret and exchanged
 random values.

  - Provide security parameters to the record layer.

  - Allow the client and server to verify that their peer has
 calculated the same security parameters and that the handshake
 occurred without tampering by an attacker.

Note that higher layers should not be overly reliant on TLS always
negotiating the strongest possible connection between two peers:
there are a number of ways a man in the middle attacker can attempt
to make two entities drop down to the least secure method they
support. The protocol has been designed to minimize this risk, but
there are still attacks available: for example, an attacker could
block access to the port a secure service runs on, or attempt to get
the peers to negotiate an unauthenticated connection. The fundamental
rule is that higher levels must be cognizant of what their security
requirements are and never transmit information over a channel less
secure than what they require. The TLS protocol is secure, in that
any cipher suite offers its promised level of security: if you
negotiate 3DES with a 1024 bit RSA key exchange with a host whose
certificate you have verified, you can expect to be that secure.

However, you should never send data over a link encrypted with 40 bit
security unless you feel that data is worth no more than the effort
required to break that encryption.

These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a client hello message to
which the server must respond with a server hello message, or else a
fatal error will occur and the connection will fail. The client hello
and server hello are used to establish security enhancement
capabilities between client and server. The client hello and server
hello establish the following attributes: Protocol Version, Session
ID, Cipher Suite, and Compression Method. Additionally, two random
values are generated and exchanged: ClientHello.random and
ServerHello.random.

The actual key exchange uses up to four messages: the server
certificate, the server key exchange, the client certificate, and the
client key exchange. New key exchange methods can be created by
specifying a format for these messages and defining the use of the
messages to allow the client and server to agree upon a shared
secret. This secret should be quite long; currently defined key
exchange methods exchange secrets which range from 48 to 128 bytes in
length.

Following the hello messages, the server will send its certificate,
if it is to be authenticated. Additionally, a server key exchange
message may be sent, if it is required (e.g. if their server has no
certificate, or if its certificate is for signing only). If the
server is authenticated, it may request a certificate from the
client, if that is appropriate to the cipher suite selected. Now the
server will send the server hello done message, indicating that the
hello-message phase of the handshake is complete. The server will
then wait for a client response. If the server has sent a certificate
request message, the client must send the certificate message. The
client key exchange message is now sent, and the content of that
message will depend on the public key algorithm selected between the
client hello and the server hello. If the client has sent a
certificate with signing ability, a digitally-signed certificate
verify message is sent to explicitly verify the certificate.

At this point, a change cipher spec message is sent by the client,
and the client copies the pending Cipher Spec into the current Cipher
Spec. The client then immediately sends the finished message under
the new algorithms, keys, and secrets. In response, the server will
send its own change cipher spec message, transfer the pending to the
current Cipher Spec, and send its finished message under the new 
Cipher Spec. At this point, the handshake is complete and the client
and server may begin to exchange application layer data. (See flow
chart below.)

-----Original Message-----
From: athena () buyukada co uk [mailto:athena () buyukada co uk] 
Sent: Wednesday, July 28, 2004 3:55 AM
To: webappsec () lists securityfocus com
Subject: More SSL questions

Sorry to throw more questions into the mix but...

What if you have an issue such as (or similar to) Cross-Site-Trace... how
does that affect this? Is it the case that the SSL negotiation will still
happen, but the content served will be less than secure? Or am I missing
something here?