SSL and TLS Protocols

SSL stands for Secure Sockets Layer and was initiated by Netscape, SSLv1, SSLv2 and SSLv3 are the 3 versions of this protocol. After SSLv3, SSL was renamed to TLS.

TLS stands for Transport Layer Security and started with TLSv1 which is an upgraded version of SSLv3.

Those protocols are standardized and described by RFC.

OpenSSL provides implementation for those protocols and is often used as the reference implementation for any new feature.

Goal of SSL was to provide a secure communication using classical tcp sockets with very few change in api usage of socket to be able to leverage security on existing tcp socket code.

SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.

latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while upcoming TLS v1.3 is still draft.

Connectionless support is provided with DTLS.

Those protocols are configurables and can use various ciphers depending on their version.

Security

Besides implementation problems leading to security issues, there are security inherent to protocol itself.

It is recommanded to run TLSv1 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.

For the very same reason it is recommanded to control protocol downgrade.

POODLE : Sslv3 harmfull

SSL MODE SEND FALLBACK SCSV

versions tricks

SCSV

signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems. Its presence it used to signal some facts or contextual information allowing to not break existing implementation that just ignore this unsupported cipher suite.

SCSV was created with TLS_EMPTY_RENEGOTIATION_INFO_SCSV in rfc5746 draft. http://tools.ietf.org/html/rfc5746#section-3.3 usage of a cipher suite value is explained but the fact that some SslV3 and TLsV1 implementation fails to ignore Extensions they do not support, so using a cipher suite allow to bypass these implementations problems.

• TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
• TLS_FALLBACK_SCSV 0x56 0x00

Handshake

A connection always starts with an handshake between a client and a server. This handshake is intended to provide a secret key to both client server that will be used to cipher the flow.

in fact a master secret is kept from the handshake from which the secret key is derived. In OpenSsl this master_secret is kept within Ssl Session SSL_SESSION.

Initial handshake can provide server authentication, client authentication or no authentication at all.

Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by browser.

A quick presentation for a classical TLS handshake ( RSA, without Session tickets and without client authentication ) under CC BY license http://blog.artisanlogiciel.net/public/tech/classical_handshake.odp feel free to improve it.

Session Resumption

Since handshake uses heavily public key cryptography and that this is cpu intensive compared to symetric ( secret key ), protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new tcp connections ) or to renew existing connections.

Browsers uses that heavily when connecting to https sites since they are opening mutliple connections to same site at a time, first connection does the handshake all others use a quick handshake (can be named resumed, abbreviated or restart handshake) allowing to save both client and server cpu.

RFC 2246, section 7, p. 23

   These items are then used to create security parameters for use by
   the Record Layer when protecting application data. Many connections
   can be instantiated using the same session through the resumption
   feature of the TLS Handshake Protocol.

This explains difference between OpenSSl SSL Connection ( SSL ) and SSL Session ( SSL_SESSION ) , each SSL Connection runs on its TCP connection and can share same SSL Session than other SSL connections.

( to obtain session from connection use function : SSL_SESSION *SSL_get_session(const SSL *ssl) )

Alternate Authentication Methods

public key certificate

This is the most commonly used method. With X509 Certficates and Certficate Authorities.

pre-shared keys

TLS PSK Pre Shared Key

Password

TLS SRP : Secure Remote Password. Allows to authenticate with a password over TLS.

Supported by openssl with 1.0.1 version.

RFC5054

TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.

With SRP trust is based on fact that both parties should know password ( or Password Verifier ) to complete SRP Verify Handshake.

It is possible to use RSA or DSS additionnaly to prove Server identity with Certificates.

TLS Extensions

Server Name Indication

SNI Extension from RFC 3546, Transport Layer Security (TLS) Extensions.

Allows a client to specify at very beginning of handshake to what server name it wants to connect.

This is very usefull for a web server that serve multiple domains but don't have a wildcard certifcate or a certifcate containing full list of supported domains.

In this case server can learn from client what Certificate the client expects to receive.

See how a C program can use Libssl API and provide sni information with SSL_set_tlsext_host_name See example in SSL/TLS_Client

Server Authentication

Server Certificate

It is crucial that clients checks Server Certificate towards expected hostname Hostname_validation

Client Authentication

Client Certificates

• Certificate Request ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.4 )

Server can send a Certificate Request with digest algorithms and a list CA Distinguished names which will be used by Client to select Client Certicicate it will send.

• Client Certificate ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.6)

Client send its Client Certificate first then all intermediate Certificates if any up to the CA ( optionaly excluded ).

• CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )

Then Client send a Certificate Verify that is signed by the private key counterpart of its Client publick key included in Certificate with digest algorithm over whole hanshake messages so far ( excluding this one of course ).

It proves then that client own the private key and applies to this specific handshake hence authenticates client for this session.