Difference between revisions of "SSL and TLS Protocols"

From OpenSSLWiki
Jump to navigationJump to search
 
(43 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
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.
+
SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly released). After SSLv3, SSL was renamed to TLS.
  
−
TLS stands for Transport Layer Security and started with TLSv1 which is an upgraded version of SSLv3.
+
TLS stands for Transport Layer Security and started with TLSv1.0 which is an upgraded version of SSLv3.
  
−
Those protocols are standardized and described by RFC.
+
Those protocols are standardized and described by RFCs.
  
−
OpenSSL provides implementation for those protocols and is often used as the reference implementation for any new feature.
+
OpenSSL provides an 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.
+
The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets 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.
 
SSL/TLS is used in every browser worldwide to provide https ( http secure ) functionality.
  
−
latest version is TLS v1.3 still draft.
+
The latest standard version is TLSv1.2 http://tools.ietf.org/html/rfc5246, while the upcoming TLS v1.3 is still in the draft stage.
  
−
Connectionless support is provided with DTLS.
+
Connection-less support is provided via DTLS.
  
−
Those protocols are configurables and can use various ciphers depending on their version.  
+
Those protocols are configurable and can use various ciphers depending on their version.  
 +
 
 +
== Security ==
 +
 
 +
Besides implementation problems leading to security issues, there is security inherent to the protocol itself.
 +
 
 +
It is recommended to run TLSv1.0, 1.1 or 1.2 and fully disable SSLv2 and SSLv3 that have protocol weaknesses.
 +
 
 +
For the very same reason it is recommended to control protocol downgrade.
 +
 
 +
=== POODLE : SSLv3 harmful ===
 +
 
 +
[[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 is used to signal some facts or contextual information allowing it to not break existing implementations 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 by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.
 +
 
 +
* TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF
 +
openssl : SSL3_CK_SCSV
 +
* TLS_FALLBACK_SCSV 0x56 0x00 See [[SSL MODE SEND FALLBACK SCSV]]
 +
openssl : SSL3_CK_FALLBACK_SCSV
  
 
== Handshake ==
 
== 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.
+
A connection always starts with a handshake between a client and a server. This handshake is intended to provide a secret key to both client and 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. This master_secret is kept within Ssl Session '''SSL_SESSION'''.
+
In fact a '''master secret''' is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session '''SSL_SESSION'''.
  
−
Initial handshake can provide server authentication, client authentication or no authentication at all.
+
The 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.
+
Default usage in HTTPS is to verify server authenticity with trusted Certificate Authorities known by the 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.
 
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.
 +
 +
== Cipher Suites ==
 +
 +
* How are cipher suites negotiated?
 +
 +
What TLS 1.2 rfc says :
 +
<pre>
 +
      The single cipher suite selected by the server from the list in
 +
      ClientHello.cipher_suites.  For resumed sessions, this field is
 +
      the value from the state of the session being resumed.
 +
</pre>
 +
 +
So basically server has the decision choice and does not provide a list of its own ciphersuites but just the selected one
 +
 +
What are best ciphersuites to choose ?
 +
 +
An interesting hint here: http://zombe.es/post/4078724716/openssl-cipher-selection
 +
 +
* Is there a normalized cipher suite ordering ?
 +
 +
Not much more than what is told for 'How cipher suites are negotiated?'
 +
 +
So it is implementation dependent. In openssl there are two modes:
 +
** default is to choose the first compatible cipher suite from client hello.
 +
** SSL_OP_CIPHER_SERVER_PREFERENCE to SSL_CTX_set_option to choose from server cipher list order.
 +
 +
* How to setup ciphersuites in openssl ?
 +
 +
[[Manual:SSL_CTX_set_cipher_list(3)]] where string cipher parameter is described in [[Manual:ciphers(1)]]
  
 
== Session Resumption ==
 
== 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.  
+
Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the 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.
+
Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named '''resumed''', '''abbreviated''' or '''restart''' handshake)  allowing saving for  both client and server CPU.
  
 
RFC 2246, section 7, p. 23
 
RFC 2246, section 7, p. 23
Line 44: Line 100:
 
</pre>
 
</pre>
  
−
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.
+
This explains difference the between an OpenSSL SSL Connection ( '''SSL''' ) and an SSL Session ( '''SSL_SESSION''' ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.
  
 
( to obtain session from connection use function :  [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )
 
( to obtain session from connection use function :  [[Manual:SSL_get_session(3)|SSL_SESSION *SSL_get_session(const SSL *ssl)]] )
  
−
== Alternate Authentication Methods ==
+
== Renegotiation ==
  
−
=== public key certificate ===
+
On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.
  
−
This is the most commonly used method. With X509 Certficates and Certficate Authorities.
+
To renegotiate :
  
−
=== pre-shared keys ===
+
a Client will send a '''ClientHello''' over its existing SSL connection
  
−
TLS PSK Pre Shared Key
+
a Server will send a '''HelloRequest''' and expects Client to renegotiate with a ClientHello in very short time.
  
−
=== Kerberos ===
+
Server renegotiation ( without resumption ):
 +
<pre>
 +
# Given a SSL Connection con :
 +
SSL *con;
  
−
=== Password ===
+
SSL_renegotiate(con);
−
 
+
i=SSL_do_handshake(con);
−
TLS SRP : Secure Remote Password. Allows to authenticate with a password over TLS.
+
</pre>
−
 
 
−
Supported by openssl with 1.0.1 version.
 
−
 
 
−
RFC5054
 
  
−
TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.
+
To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).
  
−
With SRP trust is based on fact that both parties should know password ( or Password Verifier ) to complete SRP Verify Handshake.
+
It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.
  
−
It is possible to use RSA or DSS additionnaly to prove Server identity with Certificates.
+
This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform '''Secure Renegotiation'''
  
 
== TLS Extensions ==
 
== TLS Extensions ==
Line 80: Line 135:
 
SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt RFC 3546, Transport Layer Security (TLS) Extensions].
 
SNI Extension from [https://tools.ietf.org/rfc/rfc3546.txt 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.
+
Allows a client to specify at the very beginning of the handshake what server name it wants to connect to.
  
−
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.
+
This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.
  
−
In this case server can learn from client what Certificate the client expects to receive.
+
In this case the server can learn from the client what Certificate the client expects to receive.
  
−
See how a C program can use [[Libssl API]] and provide sni information with  
+
See how a C program can use [[Libssl API]] and provide SNI information with  
 
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]
 
'''<tt>SSL_set_tlsext_host_name</tt>''' See example in [[SSL/TLS_Client]]
 +
 +
== Server Authentication ==
 +
 +
=== Server Certificate ===
 +
 +
This is '''Public Key''' Certified by a Certificate with Trust from the client. Trust from the client can be done automatically with Certificate Authority trust.
 +
 +
It is crucial that clients check the Server Certificate against the expected hostname [[Hostname_validation]]
 +
 +
=== No Authentication Aka Anonymous ===
 +
 +
Even if it look like is a strange idea, it is possible to select cipher suite that does not provide any server authentication but still provide confidentiality.
 +
 +
Selecting string cipher '''aNULL''' [[Manual:ciphers(1)]] allows to select such cipher suite. Remark this is not same a '''eNULL''' that provides no confidentiality at all.
 +
 +
Anonymous Diffie_Hellman exchange ('''DH''') and Anonymous Elliptic Curves Diffie Hellman Exchange ('''ECDH''') methods provide this anonymous authentication.
 +
 +
== Client Authentication ==
 +
 +
Client authentication is optional. In many cases the client does not authenticate at the ssl layer, but rather with the usage of protocols above ssl, for example with HTTP authentication methods.
 +
 +
=== 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 the client to select the Client Certificate 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 ( optionally excluded ).
 +
 +
* CertificateVerify ( TLS v1.2 http://tools.ietf.org/html/rfc5246#section-7.4.8 )
 +
The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).
 +
 +
This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.
 +
 +
== Alternate Authentication Methods ==
 +
 +
=== Public Key Certificate ===
 +
 +
This is the most commonly used method. With X509 Certificates and Certficate Authorities.
 +
 +
It applies To '''Server Certificate''' or to '''Client Certificate''' authentication.
 +
 +
Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.
 +
 +
=== Pre-Shared Keys ===
 +
 +
TLS PSK Pre Shared Key
 +
 +
=== Kerberos ===
 +
 +
=== Password ===
 +
 +
TLS SRP : Secure Remote Password. Allows authentication with a password over TLS.
 +
 +
Supported by OpenSSL with version 1.0.1.
 +
 +
RFC5054
 +
 +
TLS SRP is negotiated with various ciphersuites, currently all use SHA to compute SRP.
 +
 +
With SRP trust is based on the fact that both parties should know the password ( or Password Verifier ) to complete the SRP Verify Handshake.
 +
 +
It is possible to use RSA or DSS additionaly to prove Server identity with Certificates.

Latest revision as of 16:23, 27 June 2017

SSL stands for Secure Sockets Layer and was originally created by Netscape. SSLv2 and SSLv3 are the 2 versions of this protocol (SSLv1 was never publicly released). After SSLv3, SSL was renamed to TLS.

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

Those protocols are standardized and described by RFCs.

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

The goal of SSL was to provide secure communication using classical TCP sockets with very few changes in API usage of sockets 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.

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

Connection-less support is provided via DTLS.

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

Security[edit]

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

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

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

POODLE : SSLv3 harmful[edit]

SSL MODE SEND FALLBACK SCSV

versions tricks[edit]

SCSV[edit]

Signaling cipher suite value (SCSV), i.e., it does not actually correspond to a suite of cryptosystems. Its presence is used to signal some facts or contextual information allowing it to not break existing implementations 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 by the fact that some SSLv3 and TLSv1.0 implementations fail to ignore extensions that they do not support, so using a cipher suite allows the bypass of these implementation problems.

  • TLS_EMPTY_RENEGOTIATION_INFO_SCSV 0x00 0xFF

openssl : SSL3_CK_SCSV

openssl : SSL3_CK_FALLBACK_SCSV

Handshake[edit]

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

In fact a master secret is obtained from the handshake from which the secret key is derived. In OpenSSL this master_secret is kept within the SSL Session SSL_SESSION.

The 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 the 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.

Cipher Suites[edit]

  • How are cipher suites negotiated?

What TLS 1.2 rfc says : 

      The single cipher suite selected by the server from the list in
      ClientHello.cipher_suites.  For resumed sessions, this field is
      the value from the state of the session being resumed.

So basically server has the decision choice and does not provide a list of its own ciphersuites but just the selected one

What are best ciphersuites to choose ?

An interesting hint here: http://zombe.es/post/4078724716/openssl-cipher-selection

  • Is there a normalized cipher suite ordering ?

Not much more than what is told for 'How cipher suites are negotiated?'

So it is implementation dependent. In openssl there are two modes:

    • default is to choose the first compatible cipher suite from client hello.
    • SSL_OP_CIPHER_SERVER_PREFERENCE to SSL_CTX_set_option to choose from server cipher list order.
  • How to setup ciphersuites in openssl ?

Manual:SSL_CTX_set_cipher_list(3) where string cipher parameter is described in Manual:ciphers(1)

Session Resumption[edit]

Since the handshake uses public key cryptography heavily and this is CPU intensive compared to symmetric ( secret key ) cryptography, the protocol provides ways to reuse existing credentials to reissue new secret keys for new connections ( new TCP connections ) or to renew existing connections.

Browsers use this heavily when connecting to https sites since they open multiple connections to the same site at a time. The first connection does the handshake while all the others use a quick handshake (can be named resumed, abbreviated or restart handshake) allowing saving for 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 the between an OpenSSL SSL Connection ( SSL ) and an SSL Session ( SSL_SESSION ) , each SSL Connection runs on its TCP connection and can share the same SSL Session with other SSL connections.

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

Renegotiation[edit]

On a Ssl connection a renegotiation can occur to request for new cipher suites or key materials.

To renegotiate :

a Client will send a ClientHello over its existing SSL connection

a Server will send a HelloRequest and expects Client to renegotiate with a ClientHello in very short time.

Server renegotiation ( without resumption ): 

# Given a SSL Connection con : 
SSL *con;

SSL_renegotiate(con);
i=SSL_do_handshake(con);

To use both renegotiation and resumption use : SSL_renegotiate_abbreviated(con) which won't request to recreate a new session ( since 1.0.1 ).

It created a vulnerability that was addressed by TLS extension to notify server whenever a connection is renegotiating and allows to verify it is legit.

This is RFC5746 "Transport Layer Security (TLS) Renegotiation Indication Extension" http://tools.ietf.org/html/rfc5746 to perform Secure Renegotiation

TLS Extensions[edit]

Server Name Indication[edit]

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

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

This is very useful for a web server that serves multiple domains but doesn't have a wildcard certificate or a certificate containing a full list of supported domains.

In this case the server can learn from the 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[edit]

Server Certificate[edit]

This is Public Key Certified by a Certificate with Trust from the client. Trust from the client can be done automatically with Certificate Authority trust.

It is crucial that clients check the Server Certificate against the expected hostname Hostname_validation

No Authentication Aka Anonymous[edit]

Even if it look like is a strange idea, it is possible to select cipher suite that does not provide any server authentication but still provide confidentiality.

Selecting string cipher aNULL Manual:ciphers(1) allows to select such cipher suite. Remark this is not same a eNULL that provides no confidentiality at all.

Anonymous Diffie_Hellman exchange (DH) and Anonymous Elliptic Curves Diffie Hellman Exchange (ECDH) methods provide this anonymous authentication.

Client Authentication[edit]

Client authentication is optional. In many cases the client does not authenticate at the ssl layer, but rather with the usage of protocols above ssl, for example with HTTP authentication methods.

Client Certificates[edit]

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

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

The Client sends a Certificate Verify that is signed by the private key counterpart of its Client public key included in the Certificate with digest algorithm over whole handshake messages so far ( excluding this one of course ).

This proves that this client owns the private key that applies to this specific handshake and hence authenticates the client for this session.

Alternate Authentication Methods[edit]

Public Key Certificate[edit]

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

It applies To Server Certificate or to Client Certificate authentication.

Depending on CipherSuite, for Server Public Key can be used to derive pre-master-key.

Pre-Shared Keys[edit]

TLS PSK Pre Shared Key

Kerberos[edit]

Password[edit]

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

Supported by OpenSSL with version 1.0.1.

RFC5054

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

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

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

Retrieved from "https://wiki.openssl.org/index.php?title=SSL_and_TLS_Protocols&oldid=2606"