SSL includes a handshake stage which is responsible for authenticating the server (and optionally the client), determining the encryption and hashing algorithms to be used, and exchanging keys. The handshake may use public keys.
Following the handshake stage, data may be transferred. It is always encrypted, using private key encryption (for speed).
The next sections are an extracted version of the SSL 3.0 protocol from http://home.netscape.com/eng/ssl3/3-SPEC.HTM
The connection state includes the following elements:
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.
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 either the certificate message or a no certificate alert. 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.)
7.6 Handshake protocol
The SSL Handshake Protocol is one of the defined higher level clients of
the SSL Record Protocol. This protocol is used to negotiate the secure
attributes of a session. Handshake messages are supplied to the SSL
Record Layer, where they are encapsulated within one or more SSLPlaintext
structures, which are processed and transmitted as specified by the current
active session state.
enum {
hello_request(0), client_hello(1),
server_hello(2), certificate(11),
server_key_exchange (12), certificate_request(13),
server_hello_done(14), certificate_verify(15),
client_key_exchange(16), finished(20), (255)
} HandshakeType;
struct {
HandshakeType msg_type; /* type of handshake message */
uint24 length; /* # bytes in handshake message body */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
The handshake protocol messages are presented in the order they must be sent; sending handshake messages in an unexpected order results in a fatal error.
7.6.1 Hello messages
The hello phase messages are used to exchange security enhancement
capabilities between the client and server. When a new session begins, the
CipherSpec encryption, hash, and compression algorithms are
initialized to null. The current CipherSpec is used for
renegotiation messages.
The client hello message includes a random structure, which is used later in the protocol.
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
The CipherSuite list, passed from the client to the server in the client hello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (first choice first).
The client hello includes a list of compression algorithms supported by the client, ordered according to the client's preference. If the server supports none of those specified by the client, the session must fail.
The structure of the client hello is as follows.
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..216-1>;
CompressionMethod compression_methods<1..28-1>;
} ClientHello;
After sending the client hello message, the client waits for a
server hello message. Any other handshake message returned by the
server except for a hello request is treated as a fatal error.
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
7.6.3 Server key exchange message
The server key exchange message is sent by the server if it has no
certificate, has a certificate only used for signing (e.g., DSS [DSS]
certificates, signing-only RSA [RSA] certificates), or fortezza/DMS key
exchange is used. This message is not used if the server certificate
contains Diffie-Hellman [DH1] parameters.
7.6.5 Server hello done
The server hello done message is sent by the server to indicate the
end of the server hello and associated messages. After sending this
message the server will wait for a client response.
struct { } ServerHelloDone;
Upon receipt of the server hello done message the client should verify that the server provided a valid certificate if required and check that the server hello parameters are acceptable.
7.6.6 Client certificate
This is the first message the client can send after receiving a server
hello done message. This message is only sent if the server requests a
certificate. If no suitable certificate is available, the client should
send a no certificate alert instead. This error is only a warning,
however the server may respond with a fatal handshake failure alert
if client authentication is required.
Client certificates are sent using a Certificate structure.
7.6.7 Client key exchange message
The choice of messages depends on which public key algorithm(s) has (have)
been selected.
7.6.9 Finished
A finished message is always sent immediately after a change
cipher specs message to verify that the key exchange and authentication
processes were successful. The finished message is the first
protected with the just-negotiated algorithms, keys, and secrets. No
acknowledgment of the finished message is required; parties may
begin sending confidential data immediately after sending the
finished message. Recipients of finished messages must verify
that the contents are correct.
The record layer fragments information blocks into SSLPlaintext records of 214 bytes or less. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType may be coalesced into a single SSLPlaintext record).
struct {
uint8 major, minor;
} ProtocolVersion;
enum {
change_cipher_spec(20), alert(21),
handshake(22), application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[SSLPlaintext.length];
} SSLPlaintext;
SSLRef changes the implementation of the standard socket library, replacing it with one that talks on port 443. The client and server implementations transfer the "old" information on this port, and then send it on to the "real" ports (I guess).
SSLRef controls security behaviour by adding behaviour to setsockopt() and getsockopt(). Extra flags and structures use new security values.
SSLRef is used to build the SSL support in Netscape browser and HTTP server. The international versions of these are crippled because of US export restrictions.
When a user makes a purchase, they tell the merchant the cost, their cardnumber. The merchant forwards this information to FV. FV will then query the user as to whether or not they authorise this purchase, with a reply of Yes, No or Fraud. If the replay is Yes, then FV tells the merchant who will then forward the goods. FV will bill the credit card of the purchaser at some later date.
The principal advantages are security to the purchaser. Their credit card is never on the network, not even encrypted. They cannot be charged for goods they never ordered because they have to approve each purchase with FV. Their email address is not publically linked to the cardnumber, so there is little chance of forgery.
The protocol used is defined in the Green Commerce Model, an IETF draft. It is a low-bandwidth model, assuming that most of the information will be sent around by email, although the possibility of a dedicated service is allowed.
The quantity of money to be paid is represented as a floating point number, rounded as necessary for the relevant currency.
An account identifier is used by a green commerce server to determine names and email addresses, which are not public information.
The following is simplified from the full syntax.
1. TRANSFER-REQUEST -- Initiates a fund transfer between two account holders. To be RECEIVED by a Green Commerce server.
2. TRANSFER-QUERY -- Query the paying party to verify a fund transfer requested by a TRANSFER-REQUEST transaction. To be SENT by a Green Commerce server.
3. TRANSFER-RESPONSE -- The paying party's response to a TRANSFER-QUERY transaction. To be RECEIVED by a Green Commerce server.
4. TRANSFER-RESULT -- The acknowledgment to the party receiving payment informing that party of the buyer's response. To be SENT by a Green Commerce server.
5. TRANSFER-NOTIFICATION -- The notification to the party receiving payment that an actual charge has been authorized by the underlying payment engine. To be SENT by a Green Commerce server if requested in the TRANSFER-REQUEST.
6. PAYIN-NOTIFICATION -- The notification to the paying party that an actual charge has been posted to the underlying payment engine. To be SENT by a Green Commerce server.
7. PAYOUT-NOTIFICATION -- The notification to an account holder that a credit has been posted to the underlying payment engine. To be SENT by a Green Commerce server.
8. PAYIN-CHARGEBACK-NOTIFICATION -- A report to the paying party in a previous transfer, indicating that a chargeback has been received from the underlying payment engine, and detailing its consequences. To be SENT by a Green Commerce server.
9. PAYOUT-CHARGEBACK-NOTIFICATION -- A report to the party receiving payment in a previous transfer, indicating that a chargeback has been received from the underlying payment engine, and detailing its consequences. To be SENT by a Green Commerce server.
10. PAYIN-FAILURE-NOTIFICATION -- A report to the paying party in a funds transfer, indicating that the underlying payment engine has declined to issue payment. To be SENT by a Green Commerce Server.
11. COLLECTION-FAILURE-NOTIFICATION -- A report to the party receiving payment in a funds transfer, indicating that the underlying payment engine has declined to issue payment. To be SENT by a Green Commerce Server.
The following are among the required attributes for TRANSFER-REQUEST transactions:
As of 1996 only one such encryption format is supported: PGP (Pretty Good Privacy). Anyone submitting a message to a Green Commerce server may do so using this format, encrypting with one of the privacy keys returned by a KEY-REQUEST transaction.
An example of such an encrypted message follows below:
To make a purchase, you send cash to the merchant, who forwards it on to
the bank for validation (checking that it hasn't been spent twice)
The cash normally goes back to the bank, but can be sent to the merchant
via a round-trip
The ecash flow is
Anyone can check the signature to ensure that the money really came from the bank. To avoid forgery, the bank can check that the money has not been spent twice.
The format of an encrypted message is
SSLeay - ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/
R. Kalakota and A. B. Whinston Frontiers of Electronic Commerce Addison-Wesley, 1996
G. Wrightson and A. Furche Computer Money: A Systematic Overview of Electronic Payment Systems Springer-Verlag, 1996
N. Borenstein and M. Rose The Green Commerce Model IETF RFC
The digicash protocol http://www.digicash.com/ecash/protocol.html
The IETF RFC's may be obtained from http://ds.internic.net/ds/dspg1intdoc.html