1.
SSL UNICAPT32
1.1
Introduction
The following introduction contains large excerpts from the « TCP/IP Tutorial and Technical Overview IBM Redbook”. Readers already familiar with SSL may directly go to section 1.1.3, which presents the SSL API in UNICAPT32.
The SSL library will be delivered in several releases. Restrictions of release 1 are shown as follows: Release 1. Release 1 of SSL is compliant with LNET API documents 1.1 and 1.2.
1.1.1 Security Over the Internet
Threats for terminals communicating over TCP/IP on a public network are numerous: tapping the wire, getting unauthorized access, getting access of information and changing it in transit, getting access to services that would normally be denied, getting access of encrypted data and passwords, and so on…
Some solutions commonly used in order to guarantee a certain level of safety and security are:
- Encryption: to protect data and passwords,
- Authentication by digital signatures and certificates: to verify who is sending data over the network,
- Authorization: to prevent improper access,
- Integrity checking: to protect against improper alterations of messages,
- Frequent key refresh: to protect against the cracking of keys.
The SSL library implements solutions to guarantee some of those security factors.
1.1.2 A Few Words On Cryptography
The purpose of this chapter is to introduce the terminology and give a brief overview of the major cryptographic concepts that relate to TCP/IP security implementations. The information presented here only scratches the surface. Some issues are left open or not mentioned at all. SSL uses the concepts presented below: ciphers, symmetric and asymmetric algorithms, MAC, certificates and certificate authority.
1.1.2.1
Ciphers
Encryption is the transformation of a clear text message into an unreadable form in order to hide its meaning. The opposite transformation, which retrieves the original clear text, is the decryption. The mathematical function used for encryption and decryption is the
cryptographic algorithm or cipher.
The currently used algorithms are keyed, that is, the encryption and decryption make use of a parameter, known as the key.
1.1.2.2
Symmetric Algorithms
Symmetric algorithms are keyed algorithms where the decryption key is the same as the encryption key. These are conventional cryptographic algorithms where the sender and the receiver must agree on the key before any secured communication can take place between them. The private key is called the shared secret. Exemples are DES, 3-DES and RSA. DES operates on 64-bit blocks and has a key length of 56 bits. With 3-DES, the DES algorithm is applied in three rounds in order to improve security.
The advantage of the symmetric algorithms is their efficiency. They can be easily
implemented in hardware. A major disadvantage is the difficulty of key management. A secure way of exchanging the secret must exist. In SSL, symmetric algorithms are used for data exchange.
1.1.2.3
Asymmetric Algorithms
Asymmetric algorithms address the major drawback of symmetric ciphers, i.e. the
requirement of the secure key-exchange channel. The idea is that two different keys should be used: a public key which, as the name implies, is known to everyone, and a private key, which is to be kept in tight security by the owner. The private key cannot be determined from the public key. A clear text encrypted with the public key can only be decrypted with the corresponding private key. A clear text encrypted with the private key can only be decrypted with the corresponding public key. Thus, if someone sends a message encrypted with the recipient's public key, it can be read by the intended recipient only.
An interesting property of the public-key algorithms is that they can provide authentication. The private key is used for encryption. Since anyone has access to the corresponding public key and can decrypt the message, this provides no privacy. However, it authenticates the message. If one can successfully decrypt it with the claimed sender's public key, then the message has been encrypted with the corresponding private key, which is known by the real sender only. Thus, the sender's identity is verified. Encryption with the private key is used in digital signatures.
Examples of asymmetric algorithms are RSA and DH.
Asymmetric algorithms, while providing for easier key management, privacy and
authentication also have some disadvantages. The most important one is that they are slow and difficult to implement in hardware. Their most important use is key exchange and authentication. This is the way they are used in SSL.
1.1.2.4
MAC
Message Authentication Codes (or MAC) are hashes (powerful checksums) that are encrypted with a key. They are used to assure integrity (if the MAC is correct, then the message is most probably unchanged).
MACs may also be used to authenticate the issuer of a document by encrypting the MAC with a private key. In that case, the MAC is called a digital signature.
Examples of hash functions are MD5 and SHA-1. SSL uses MACs to ensure message integrity.
1.1.2.5
Certificates and Certification Authorities (CA)
One major security exposure in using public key algorithms is not knowing if the public key used really is the public key of the receiver. An intruder could replace a public key with its own and read encrypted messages that were supposed to go to the receiver.
The origin of public keys needs to be certified. This is the role of certificates.
A certificate is a file that binds an identity (the subject) to a public key. This binding is validated by a Certification Authority (the issuer).
A digital certificate is signed with the private key of the certification authority, so it can be authenticated. It is only issued by the CA after a verification of the applicant. Apart from the public key and identification, a digital certificate usually contains other information, as shown below:
There is an international standard in place for digital certificates: The ISO X509 protocols described in RFC 3280.
If needed, the parties retrieve each other's digital certificate and authenticate it using the public key of the issuing certification authority. They have confidence that the public keys are real, because a trusted third party vouches for them.
When a terminal receives a server’s certificate, it can only be trusted if the certificate was signed by a CA that the terminal trusts. A trusted CA called the ROOT is locally stored and all other CAs are trusted provided their certificates can belong to a chain made from the ROOT, where the next certificate’s issuer in the chain is the current certificate’s subject. This is shown in the diagram below.
Certificate
CertificateVersion Version of the certificate (indicates if optional fields are being used)
Serial Number Identification number of the certificate assigned by the CA
Issuer Name Name of the CA that issued the certificate Validity
Not before Certificate not valid before this date Not after Certificate not valid after this date
Subject Name Name of the entity identified by that certificate Subject Public Key Public key of the entity identified by that certificate Subject Public key algorithm Algorithm associated to the public key
Signature Algorithm Signature algorithm used by the CA to sign the certificate
ROOT certificate issuer = ROOT subject = CA1 validity certificate 1 issuer = CA1 subject = CA2 validity certificate 2 issuer = CA2 subject = CA3 validity SERVER'S CERTIFICATE TO VALIDATE issuer = CAn-1 subject = CAn validity
.../...
If such a path can be established with the server's certificate at the end and all validity ranges correct, the server's certificate can be trusted.
trusted certificates locally stored in the terminal
SSL uses certificates during the connection phase in order to certify the origin of public keys.
1.1.3 Secured Socket Layer (SSL)
SSL is a security protocol that was developed by Netscape Communications Corporations, along with RSA Data Security, Inc. The primary goal of the SSL protocol is to provide a private channel between communicating applications, which ensures privacy of data, authentication of the partners, and integrity. SSL provides an alternative to the standard TCP/IP socket API that has security implemented within it.
The SSL protocol addresses the following security issues:
- Privacy: After the symmetric key is agreed upon in the initial handshake, the messages are encrypted using this key.
- Integrity: Messages contain a message authentication code (MAC) ensuring the message integrity.
- Authentication: During the handshake, the client authenticates the server using an asymmetric (a.k.a public) key. It can also be based on certificates.
SSL is composed of two layers:
- On the upper layer, a protocol for initial authentication and transfer of encryption keys, called the SSL Handshake Protocol.
- At the lower layer, a protocol for transferring data using a variety of predefined ciphers and authentication combinations, called the SSL Record Protocol.
SSL works on top of TCP and offers a specific socket API to applications (the secured socket API):
TCP
IP
N E T W O R K IN T E R F A C E N E T W O R K IN T E R F A C E N E T W O R K IN T E R F A C ESSL
APPLICATIONS S S L A P I handshake protocol record protocolIn SSL terminology, the client is the peer that initiates the SSL connection. The handshake protocol is in charge of reaching an agreement between the client and the server. Both sides may identify each other and must agree on the cipher methods to be used. Once an SSL session has been established, the secured channel is transparent, that is, data is encrypted between the client and the server, but data sent at one end is exactly the same as data received at the other end.
In Unicapt32, terminals are SSL clients, that is, they request SSL connections to SSL servers. Furthermore, terminals may request an identification of the server and provide a certificate to the server if this one want to identify the terminal.
The following sequence diagram shows how a connection request from the terminal side translates into messages on the network.
CLIENT
(TERM INAL) SERVER
clie ntHe llo(ssl version, client random, previous session id, supported ciphers)
se rv e rHe llo (ssl version, server random, this session id, chosen cipher)
se rv erKeyExchange (additional params)*
server chooses a cipher suite and notifies of its choice
for certain key exchange algorithm, server sends additional parameters separately*
serve rHe lloDone
serve rX509Certificate List (server public key)
if cipher is not anonymous, server sends its certificates
client checks server certificates
clientKe yExchange{premaster secret}server public key
clientChange Ciphe rSpecs
se rv erChangeCiphe rSpe cs
client computes 48-byte master secret from premaster, server random and client random
client computes
CLIENT_WRITE_KEY {clie ntFinished}client_wri te_key
{se rv erFinishe d}server_write_key
encrypted with server's public key encrypted with agreed encryption method
Message Exchange in SSL v3 and TLSv1 (no client certificate)
* the serverKeyExchange is sent only for the follow ing key exchange methods: RSA_EXPORT w ith server key > 512 bits, DHE_DSS, DHE_DSS_EXPORT, DHE_RSA, DHE_RSA_EXPORT, DH_anon
{DATA}client-write-key {DATA}server-wri te-key
client generates premaster secret
server computes 48-byte master secret from premaster, server random and client random
server computes SERVER_WRITE_KEY
{...}xxx indicates a message encrypted with key xxx
•Step 1: the client sends a connection request with a clientHello message, which includes, among others, a list of supported cipher suites. Each cipher suite specifies authentication modes, key exchange modes, encryption and MAC algorithms. •Step 2: the server evaluates the parameters sent by the clientHello and returns a serverHello message that includes, among others, the selected cipher suite and a session ID.
•Step 3: If the server is requested to authenticate (that depends on the chosen cipher), it sends a serverX509CertificateList message, which contains its certificate(s) along with its public key(s), which authenticate its identity.
•Step 3”: in some cases, the server sends a serverKeyExchange message, which contains additional parameters related to the chose cipher.
•Step 4: the server sends a serverHelloDone message and begins to wait for the client‘s response.
•Step 5: If the server has sent a certificate (step 3), the client checks the certificate. Then, it computes a pre-master secret and sends it in a clientCertificateVerify message. This message is encrypted with the server’s public key and can thus be decrypted only by the server.
•Step 6: the client generates the master secret that will be used for data encryption and sends a clientChangeCipherSpecs.
•Step 7: the client sends a clientFinished message indicating its negotiation part is finished. This is the first message encrypted with the symmetric algorithm chosen for the session.
•Step 8: the server generates the master secret that will be used for data encryption and sends a clientChangeCipherSpecs.
•Step 9: the server sends a serverFinished message indicating its negotiation part is finished.
•Step 10… Following the handshake, both session partners have generated a master key. From that key they generate other session keys (private keys), which are used in the symmetric-key encryption of the session data and in the creation of message digests (MACs). Note that the record protocol transmits frames in chunks of 16 kbytes at most. Message boundaries are not preserved (multiple messages may be coalesced into a single record, or a single message may be fragmented across several records).
The first message encrypted with the agreed-upon symmetric cipher is the “finished” message from the client. If the server can interpret the “finished” message, it means:
• Privacy has been achieved, because the message is encrypted using a symmetric-key block- or stream-cipher (such as DES or RC4).
• The message integrity is assured, because it contains a Message Authentication Code (MAC), which is a message digest of the message itself plus material derived from the master key.
• The server has been authenticated, because it was able to derive the master key from the pre-master key. As this was sent using the server's public key, it could only have been decrypted by the server (using its private key). Note that this relies on the integrity of the server's public key certificate.
The following diagram is a synthesis of the message sequence showing certificate and key exchanges in a specific case where Diffie-Hellman is used to exchange keys, authority used RSA to sign the certificate, data encryption is done with DES and MAC function is SHA1:
SSL SERVER
HELLO HELLO
certificate
server name server public key
pre master secret
DATA EXCHANGE encrypted with private
check certificate
compute master secret
and private keys compute master secretand private keys
DH-encrypted with server's public key
signed by CA w ith RSA key
clear text
encrypted w ith server's public key: Diffie-Hellman
encryption w ith DES secret and MAC is SHA1
Simplified sequenced diagram for a DHE_RSA_WITH_DES_CBC_SHA cipher suite
The Unicapt32 SSL library is compatible with SSLv2, SSLv3 (Netscape standards), and TLSv1 (latest IETF standard based on SSLv3 and described in RFC 2246).
As compared with the RFC2246, the LSSL library does NOT support the optional feature of “session caching”, which allows a client to send a previous session ID in its client hello message in order to avoid cipher re-negotiation.
1.2
Supported Ciphers
During the handshake, in the clientHello message, the terminal sends the “cipher suites” that it supports. Each cipher suite is composed of a list of algorithms, one for key exchange, one for certificate signing, one for encryption and one for MAC. The server (v3, tls) or the client (v2) will then select one of those.
A cipher name is composed of the following elements:
- the key exchange algorithm: algorithm used during key exchange,
- the encoding method: algorithm for encoding data,
- the MAC method,
- an export flag: indicating export version of a cipher that may be distributed outside of the US,
- a strength value: the number of bits of the symmetric key for encryption. This is a “logical” level instead of a fixed number (512 bits, 1024 bits…) so as to adapt to standard changes without having to change application code (currently, US law forbids exportation of more than 56-bit symmetric keys , and more than 1024-bit asymmetric keys).
- and the SSL version.
The table below lists all the ciphers that will be supported in the final release of LSSL: Cipher Name from RFC 2246 RFC Id (2
or 3 bytes in hexa) Key Exchan ge Algo Authenti cation method Ciphe r Algo MAC metho d Expor t Strengt h SSL versio n
RC4_128_WITH_MD5 01 00 80 RSA RSA RCA
128
MD5 No Medium
(128 bits)
V2
RC4_128_EXPORT40_WITH_MD5 02 00 80 RSA RSA RCA 128
MD5 Yes EXP40
(40 bits) V2
RC2_CBC_128_CBC_WITH_MD5 03 00 80 RSA RSA RC2 MD5 No Medium (128 bits)
V2
RC2_CBC_128_CBC_EXPORT40_WITH_MD5 04 00 80 RSA RSA RC2 MD5 Yes EXP40 (40 bits)
V2
IDEA_128_CBC_WITH_MD5 05 00 80 RSA RSA IDEA MD5 No Medium (128 bits)
V2
DES_64_CBC_WITH_MD5 06 00 40 RSA RSA DES MD5 No Low
(56 bits) V2
DES_192_EDE3_CBC_WITH_MD5 07 00 C0 RSA RSA 3DES MD5 No High (168 bits)
V2
RC4_64_WITH_MD5 (*) 08 00 80 RSA RSA RCA MD5 No Low
(64 bits) V2
RSA_WITH_NULL_MD5 00 01 RSA RSA NULL MD5 Yes None V3
RSA_WITH_NULL_SHA 00 02 RSA RSA NULL SHA1 Yes None V3
DH_anon_EXPORT_WITH_RC4_40_MD5 00 17 EDH NULL RC4 MD5 Yes EXP40 (40 bits)
V3
DH_anon_WITH_RC4_128_MD5 00 18 EDH NULL RC4 MD5 No Medium (128 bits)
V3
DH_anon_EXPORT_WITH_DES40_CBC_SHA 00 19 EDH NULL DES SHA1 Yes EXP40 (40 bits)
V3
DH_anon_WITH_DES_CBC_SHA 00 1A EDH NULL DES SHA1 No Low (56 bits)
V3
DH_anon_WITH_3DES_EDE_CBC_SHA 00 1B EDH NULL 3DES SHA1 No High (168 bits)
V3
RSA_EXPORT_WITH_RC4_40_MD5 00 03 RSA RSA RC4 MD5 Yes EXP40 (40 bits)
V3
RSA_WITH_RC4_128_MD5 00 04 RSA RSA RC4 MD5 No Medium
(128 bits)
V3
RSA_WITH_RC4_128_SHA 00 05 RSA RSA RC4 SHA1 No Medium
(128 bits)
V3
RSA_EXPORT_WITH_RC2_CBC_40_MD5 00 06 RSA RSA RC2 MD5 Yes EXP40 (40 bits)
V3
RSA_WITH_IDEA_CBC_SHA 00 07 RSA RSA IDEA SHA1 No Medium (128 bits)
RSA_EXPORT_WITH_DES40_CBC_SHA 00 08 RSA RSA DES SHA1 Yes EXP40 (40 bits)
V3
RSA_WITH_DES_CBC_SHA 00 09 RSA RSA DES SHA1 No Low
(56 bits) V3
RSA_WITH_3DES_EDE_CBC_SHA 00 0A RSA RSA 3DES SHA1 No High (168 bits)
V3
DH_DSS_EXPORT_WITH_DES40_CBC_SHA 00 0B DHd DH DES SHA1 Yes EXP40 (40 bits)
V3
DH_DSS_WITH_DES_CBC_SHA 00 0C DHd DH DES SHA1 No Low (56 bits)
V3
DH_DSS_WITH_3DES_EDE_CBC_SHA 00 0D DHd DH 3DES SHA1 No High (468 bits)
V3
DH_RSA_EXPORT_WITH_DES40_CBC_SHA 00 0E DHr DH DES SHA1 Yes EXP40 (40 bits)
V3
DH_RSA_WITH_DES_CBC_SHA 00 0F DHr DH DES SHA1 No Low (56 bits)
V3
DH_RSA_WITH_3DES_EDE_CBC_SHA 00 10 DHr DH 3ES SHA1 No High (168 bits)
V3
DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 00 11 EDH DSS DES SHA1 Yes EXP40 (40 bits)
V3
DHE_DSS_WITH_DES_CBC_SHA 00 12 EDH DSS DES SHA1 No Low (56 bits)
V3
DHE_DSS_WITH_3DES_EDE_CBC_SHA 00 13 EDH DSS 3ES SHA1 No High (168 bits)
V3
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 00 14 EDH RSA DES SHA1 Yes EXP40 (40 bits)
V3
DHE_RSA_WITH_DES_CBC_SHA 00 15 EDH RSA DES SHA1 No Low (56 bits)
V3
DHE_RSA_WITH_3DES_EDE_CBC_SHA 00 16 EDH RSA 3DES SHA1 No High (168 bits)
V3
FZA_DMS_NULL_SHA (*) 00 1C FZA FZA NULL SHA1 No None V3
FZA_DMS_FZA_SHA (*) 00 1D FZA FZA FZA SHA1 No None V3
FZA_DMS_RC4_SHA (*) 00 1E FZA FZA RC4 SHA1 No Medium
(128 bits)
V3
(*) not explicitly listed in RFC but supported by LSSL. Acronyms are explained in the glossary in appendix.
EXPn indicates a cipher where n bits of the session key are sent in the clear and other bits encrypted. Export : indicates export version of a cipher that may be distributed outside of the US. Export versions have a secret key length restricted to 40 bits.
Release 1 of LSSL supports 4 ciphers only: RC4_64_WITH_MD5, RSA_WITH_RC4_128_MD5,
DHE_RSA_WITH_3DES_EDE_CBC_SHA and RSA_WITH_DES_CBC_SHA.
In LSSL, a sub list of supported ciphers is linked to an object called a CONTEXT. Within that context, all sessions will send their sub-lists in their clientHello messages for the server to choose (v3,TLS).
Via sslContextSetCipherList(), the application passes the list of algorithms it wants to be used within a context and the SSL library computes the list of authorized ciphers.
Example:
The application indicates that the following algorithms may be used: RSA for key exchange, RSA for authentication, any algorithm for encryption and MAC, only non exportable
algorithms and in any SSL version. From that information, the SSL library will send the following supported suites in the client Hello message: RC4_128_WITH_MD5,
RC2_CBC_128_CBC_WITH_MD5, IDEA_128_CBC_WITH_MD5, DES_64_CBC_WITH_MD5, DES_192_EDE3_CBC_WITH_MD5,
RC4_64_WITH_MD5, RSA_WITH_RC4_128_MD5, RSA_WITH_RC4_128_SHA, RSA_WITH_IDEA_CBC_SHA, RSA_WITH_DES_CBC_SHA, RSA_WITH_3DES_EDE_CBC_SHA.
1.3
Example of an X509 certificate in PEM format:
---BEGIN CERTIFICATE---MIIDNjCCAp+gAwIBAgIBITANBgkqhkiG9w0BAQQFADBdMQswCQYDVQQGEwJGUjEM MAoGA1UECBMDSURGMRAwDgYDVQQHEwdwdXRlYXV4MREwDwYDVQQKEwhpbmdlbmlj bzEMMAoGA1UECxQDciZkMQ0wCwYDVQQDEwRNT01PMB4XDTAzMTIwOTEzNDY1NFoX DTA0MTIwODEzNDY1NFowXzELMAkGA1UEBhMCRlIxEDAOBgNVBAgTB1B1dGVhdXgx DDAKBgNVBAcTA0lERjERMA8GA1UEChMIaW5nZW5pY28xDDAKBgNVBAsUA3ImZDEP MA0GA1UEAxMGc2VydmVyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3fksg GIes4gvtrc9BaaP0rVcf0MQ9oH2IKioGLPypD18Vna5i4VkDU3mj4og3s0Mc4q/3 KlHANNz/WCMbGj+Z5lNbyttL+qYnEBOv4r28JzADSfQQ1N0O5OGTmjNtidH+71dH /Rt1H+j/n8J9GdQJZRNFKDoDjeMMCGE+cWgzJQIDAQABo4IBAjCB/zAJBgNVHRME AjAAMBEGCWCGSAGG+EIBAQQEAwIGQDAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBH ZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFLc0SvpfAcPUdvp3HJ/UXyc9 UzRfMG8GA1UdIwRoMGahYaRfMF0xCzAJBgNVBAYTAkZSMQwwCgYDVQQIEwNJREYx EDAOBgNVBAcTB3B1dGVhdXgxETAPBgNVBAoTCGluZ2VuaWNvMQwwCgYDVQQLFANy JmQxDTALBgNVBAMTBE1PTU+CAQAwIQYDVR0RBBowGIEWc2VydmVyQGZyLmluZ2Vu aWNvLmNvbTANBgkqhkiG9w0BAQQFAAOBgQA3ePmVAy+4WkNq3dvQ7g3xT3Ea5EVA LTGvTN2T59SgLmp34kRB4AB8jWDS65pMknNh/Hav8gKXlROa1bORKqTBtu/d+4vl 6qPiL7r2ny+ffwCp6V0uCsTqXyIWpU9/XXJVXuz2LOwedhbakeX4XeAyaERBEsWD sIUq9p4fNwzTEQ== ---END
CERTIFICATE---1.4
Example of an X509 certificate followed by a RSA private key in
PEM format:
---BEGIN CERTIFICATE---MIID8jCCA1ugAwIBAgIBAjANBgkqhkiG9w0BAQQFADCBnzELMAkGA1UEBhMCRlIx FjAUBgNVBAgTDUlsZS1kZS1GcmFuY2UxEDAOBgNVBAcTB1B1dGVhdXgxETAPBgNV BAoTCEluZ2VuaWNvMRIwEAYDVQQLEwlBdXRob3JpdHkxFjAUBgNVBAMTDURhdmlk IEdpcmF1bHQxJzAlBgkqhkiG9w0BCQEWGGRnaXJhdWx0QGZyLmluZ2VuaWNvLmNv bTAeFw0wNTAxMjAxNDA3MDhaFw0wNjAxMjAxNDA3MDhaMHcxCzAJBgNVBAYTAkZS MRYwFAYDVQQIEw1JbGUtZGUtRnJhbmNlMRAwDgYDVQQHEwdQdXRlYXV4MREwDwYD VQQKEwhJbmdlbmljbzEOMAwGA1UECxMFVGVzdHMxGzAZBgNVBAMTEkNlcnRpZmll ZCBUZXJtaW5hbDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA6dMh1azTHRgs 8G2kWqiRqvYqY+u6O/IB4GS0drOX3X1Hvj9YMLE8BgDrAsRgHW3Bg/wpl7zZuWKv u9XFp1/PSkvvmkd0mS/zaZjIUEGF8fyPNW0ToWxQYefemv8l4y2Y7CpX11ceiFJ3 QyE0hm5X9gQKnC8tj8yH2/zWJFyGpY0CAwEAAaOCAWMwggFfMAkGA1UdEwQCMAAw EQYJYIZIAYb4QgEBBAQDAgZAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdlbmVy YXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQULcTrf7WcezWFQDakapvKidVaJxkw gcwGA1UdIwSBxDCBwYAUCfZuuATFNvkh6EJzv8ZVBwtPqpOhgaWkgaIwgZ8xCzAJ BgNVBAYTAkZSMRYwFAYDVQQIEw1JbGUtZGUtRnJhbmNlMRAwDgYDVQQHEwdQdXRl YXV4MREwDwYDVQQKEwhJbmdlbmljbzESMBAGA1UECxMJQXV0aG9yaXR5MRYwFAYD VQQDEw1EYXZpZCBHaXJhdWx0MScwJQYJKoZIhvcNAQkBFhhkZ2lyYXVsdEBmci5p bmdlbmljby5jb22CAQAwIwYDVR0RBBwwGoEYZGdpcmF1bHRAZnIuaW5nZW5pY28u Y29tMA0GCSqGSIb3DQEBBAUAA4GBAK3wB5rjhC8FRxQFjD1V98Q2CALZQe62LP4V 1k9sOMK7I9SsU/Pdx1MJpDPysEFujJyAKR29eC4i+nzolsJxvfFrtVfKcND6d8wk hHeN6A+22BPZwyfX/ee4+u1l9ZsHnJqnb5+yU+AV/MLzrL6+Y/xD4NVUKHvlRCqQ mMEtZUWs ---END CERTIFICATE---BEGIN RSA PRIVATE KEY---Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,BA9A46592E8B71AF 6vOshxzWR3sAxUckiSFDoUxkfA09u/JdrMnrkm9VLIyevT9BKZN7e7nL8oTqkiKr HJfH3fHF4hBOPNYoAgHizeimUhyhFVJBYPUiWJ3m8BxSN3CX6iatYlRAFzEwb+ba 6CUXzmKwC+eAXv8IUqeAr8eSsAkXHatyO0Hf/Qxf6f3lBXcJyNN+0gZTAGTJRlvE KI+vpwWiN/hWN048Cyj6INQeD53p1q3XBWLq25YHLydlAVKUW+5IXKjNsP0EhRZq s8BpPvRjGrIbdehCdQKMKDGioFYZ7nzVE+Ib7XWcbO4oYu5I6P31KbMprdSNUic7 ClVfM+N0ZfPqHKKrYD7Fw7nImLsM3ifl0XGWTfGojh57DtH4EwACKJuSoTXdRmlT /DO91DxpdBn1NdgxFaCHG2phlKB02k3gOUU7jO1WTrklM/K6kVrEyupbhZnYVwuX l9nYFDaPczLUUnDWt+Qqk69N8XQGsnGu/DYnUWxiN4BnQTrjYeyqKnrs0oJQeyVi mG1w1TsXBS1T+4VeZ0Jc5sBExWbsUhIoWfNJCImo1muce9tYopeqMP9q1/VR+/JS8VR7SsJVVFg6dfRjPB76xsNnu+tXgqonI5jFvMgEOCnNEpTIXu8Ybnd6UYcuYCAJ KlBYscy6InS5M9AW3rmzFW2ueohQgN0v6KySQN+pqIN4oAswL4NgH8rEZY4zcuyp Q42GLXSZ8XkPP+wAubrvSgZFDzqExKK/u/CvCzhMDw3EHilpJ33P9d95ZFMFk+q0 wJ5DAZ6TKsnLNSlg8ko5DoIuAgLGQjHd9flc/cGgnD/jcJQrcdaAsg==
---END RSA PRIVATE
KEY---1.5
Appendix: List of X509 Error Codes
The following table lists the errors that may occur during the verification of a server’s
certificate. Each error condition may lead to a termination or continuation of the handshake, as specified with function sslCtxCertificateVerifySet().
SSL_V_X509_OK The operation was successful. SSL_V_X509_ERR_UNABLE_TO_GET
_ISSUER_CERT The issuer certificate could not be found: this occurs if the
issuer certificate of an untrusted certificate cannot be found.
SSL_V_X509_ERR_UNABLE_TO_DECRYPT
_CERT_SIGNATURE The certificate signature could not be decrypted. This means
that the actual signature value could not be determined rather than it not matching the expected value, this is only meaningful for RSA keys.
SSL_V_X509_ERR_UNABLE_TO_DECODE
_ISSUER_PUBLIC_KEY The public key in the certificate
SubjectPublicKeyInfo could not be read.
SSL_V_X509_ERR_CERT_SIGNATURE
_FAILURE The signature of the certificate is invalid.
SSL_V_X509_ERR_CERT_NOT_YET_VALID The certificate is not yet valid: the notBefore date is after the
current time.
SSL_V_X509_ERR_CERT_HAS_EXPIRED The certificate has expired: the notAfter date is before the
current time.
SSL_V_X509_ERR_ERROR_IN_CERT_NOT
_BEFORE_FIELD The certificate notBefore field contains an invalid time. SSL_V_X509_ERR_ERROR_IN_CERT_NOT
_AFTER_FIELD The certificate notAfter field contains an invalid time. SSL_V_X509_ERR_OUT_OF_MEM An error occurred trying to allocate memory.
SSL_V_X509_ERR_DEPTH_ZERO_SELF
_SIGNED_CERT The passed certificate is self signed and the same certificate
cannot be found in the list of trusted certificates.
SSL_V_X509_ERR_SELF_SIGNED_CERT
_IN_CHAIN The certificate chain could be built up using the untrusted
certificates but the root could not be found locally.
SSL_V_X509_ERR_UNABLE_TO_GET
_ISSUER_CERT_LOCALLY The issuer certificate of a locally looked up certificate could not
be found. This normally means the list of trusted certificates is not complete.
SSL_V_X509_ERR_UNABLE_TO_VERIFY
_LEAF_SIGNATURE No signatures could be verified because the chain contains only
one certificate and it is not self signed.
SSL_V_X509_ERR_INVALID_CA A CA certificate is invalid. Either it is not a CA or its
extensions are not consistent with the supplied purpose.
SSL_V_X509_ERR_INVALID_PURPOSE The supplied certificate cannot be used for the specified
purpose.
SSL_V_X509_ERR_CERT_UNTRUSTED The root CA is not marked as trusted for the specified purpose. SSL_V_X509_ERR_CERT_REJECTED The root CA is marked to reject the specified purpose.
SSL_V_X509_ERR_SUBJECT_ISSUER
_MISMATCH The current candidate issuer certificate was rejected because its
subject name did not match the issuer name of the current certificate.
SSL_V_X509_ERR_AKID_SKID_MISMATCH The current candidate issuer certificate was rejected because its
subject key identifier was present and did not match the authority key identifier current certificate
SSL_V_X509_ERR_AKID_ISSUER_SERIAL
_MISMATCH The current candidate issuer certificate was rejected because its
the authority key identifier of the current certificate.
SSL_V_X509_ERR_KEYUSAGE_NO
_CERTSIGN The current candidate issuer certificate was rejected because its
1.6
Message Exchange in SSL v2
Note that in SSL v2, the client chooses the cipher to be used, not the server.
CLIENT
(TERM INAL) SERVER
clie ntHe llo(supported ciphers, challenge)
se rv e rHe llo (sublist of supported ciphers, certificate with server public key, connnection id)
se rve rFinishe d{sessionId}server-write-key
encrypted with server's public key encrypted with symmetric algorithm
{DATA}client-write-key
{DATA}server-write-key
{...}xxx indicates a message encrypted with key xxx
clie ntM aste rKe y {cipher chosen, master key}server-public-key client chooses a cipher,
determines a master key
client computes its CLIENT_READ_KEY(s) and CLIENT_WRITE_KEY(s) from master key, challenge and connection ID
server computes its SERVER_READ_KEY(s) and SERVER_WRITE_KEY(s)
se rv e rVe rify{challenge}server-write-key client decrypts challenge and checks
clie ntFinishe d{sessionId}client-write-key
1.7
SSL Glossary
Authentication
Authentication is the ability of one entity to determine the identity of another entity. In SSL, authentication means the binding between a public key and a name and the the implicit ownership of the
corresponding private key. Asymmetric cipher
See public key cryptography.
CA Certificate Authority that delivers certificates that can be trusted. Certificate
As part of the X.509 protocol (a.k.a. ISO Authentication framework), certificates are assigned by a trusted Certificate Authority and provide a strong binding between a party's identity or some other attributes and its public key.
Cipher
Mathematical function used for encryption and decryption. Client
The application entity that initiates a TLS connection to a server. This may or may not imply that the client initiated the underlying transport connection. The primary operational difference between the server and client is that the server is generally authenticated, while the client is only optionally authenticated.
CLIENT_READ_KEY
The session key that the client uses to initialize the client read cipher. This key has the same value as the SERVER-WRITE-KEY (symmetric algorithm).
CLIENT_WRITE_KEY
The session key that the client uses to initialize the client write cipher. This key has the same value as the SERVER-READ-KEY (symmetric algorithm).
Digital signatures
Digital signatures utilize public key cryptography and one-way hash functions to produce a signature of the data that can be authenticated, and is difficult to forge or repudiate.
Encryption
Transformation of a clear text message into an unreadable form in order to hide its meaning.
Handshake
An initial negotiation between client and server that establishes the parameters of their transactions.
Message Authentication Code (MAC)
A Message Authentication Code is a one-way hash computed from a message and some secret data. It is difficult to forge without knowing the secret data. Its purpose is to detect if the message has been altered. Master secret
Secure secret data used for generating encryption keys, MAC secrets, and IVs.
Public key cryptography
A class of cryptographic techniques employing two-key ciphers.
Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key.
One-way hash function
A one-way transformation that converts an arbitrary amount of data into a fixed-length hash. It is computationally hard to reverse the
transformation or to find collisions. MD5 and SHA are examples of one-way hash functions.
Session identifier
A session identifier is a random value generated by a client that identifies itself to a particular server. The session identifier can be thought of as a handle that both parties use to access a recorded secret key (in our case a session key). If both parties remember the session identifier then the implication is that the secret key is already known and need not be negotiated.
SERVER_READ_KEY
See CLIENT_READ_KEY SERVER_WRITE_KEY
See CLIENT_WRITE_KEY Symmetric cipher
Keyed algorithms where the decryption key is the same as the encryption key.
RSA Ron Rivest, Adi Shamir and Leonard Adleman algorithm. A very widely used public-key algorithm that can be used for either encryption or digital signing. The security of RSA relies on the difficult problem of factoring large numbers. As computing power grows, keeping RSA secure is a matter of increasing the key length (unlike DES, where the key length is fixed).
DH Another public-key algorithm, actually the very first ever invented, is Diffie-Hellman. This is a key-exchange algorithm; that is, it is used for securely establishing a shared secret over an insecure channel. The communicating parties exchange public information from which they derive a key. An eavesdropper cannot reconstruct the key from the information that went through the insecure channel. More precisely, the reconstruction is computationally infeasible. The security of Diffie-Hellman relies on the difficulty of calculating discrete logarithms in finite
fields. After the shared secret has been established, it can then be used to derive keys for use with symmetric key algorithms such as DES. MD2 an older version of MD5.
MD5 MD5 is a hash algorithm designed by Ron Rivest. It produces a 128-bit hash. Used in keyed-mode, the key and data are concatenated as input to the algorithm so as to produce a MAC.
SHA1 SHA1 is a hash algorithm largely inspired from MD5. It was designed by the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA). It produces a 160-bit hash and is regarded as more secure than MD5. Used in keyed-mode, the key and data are concatenated as input to the algorithm so as to produce a MAC. RC4 a stream symmetric encryption algorithm licensed by RSA Data Security. RC2 a block symmetric encryption algorithm developed by Ron Rivest at RSA
Data Security.
IDEA symmetric algorithm: International Data Encryption Algorithm. It uses 64-bit blocks and 128-64-bit keys. It was aimed to replace DES.
DES awell-known symmetric block algorithm, developed by IBM. It operates on 64-bit blocks and has a key length of 56 bits. From the key, 16 subkeys are derived, which are used in the 16 rounds of the algorithm. 3DES The DES algorithm applied three times to improve security.
EDH Ephemeral Diffie-Hellman xxx
DHd Acronym used in cipher suite definition indicating a suite using DH key agreement and DH certificates signed by CAs using DSS keys.
DHr Acronym used in cipher suite definition indicating a suite using DH key agreement and DH certificates signed by CAs using RSA keys.
DSS Digital Signature Standard. Digital authentication standard of the U.S. government. The standard describes a Digital Signature Algorithm used to sign and verify signatures of message digests produced with SHA1. X509 A format and management of certificates as described in RFC 3280. PEM Privacy Enhanced Mail. A former format and management of certificates
described in RFC 1422 now deprecated by the X509 standard, which extends the PEM.
