TLS ( Transport Layer Security)

TLS provides a secure channel between two communicating peers; the only requirement from the underlying transport is a reliable, in-order data stream.

It is used by popular applicaion layer protocl todays like HTTPS and SIP over TLS , DTLS  etc. Historically TLS was also used in logging sistive data and even in credit card information.

TLS has its roots in SSL (Secure socket Layer ) . Seirs of TLS version from IETF are:

RFC 4346 – The Transport Layer Security (TLS) Protocol Version 1.1
RFC 5246 – The Transport Layer Security (TLS) Protocol Version 1.2
RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3

TLS 1.3 eliminated a number of older algorithms which had vulnerabilities, these include:

  • RC4 Steam cipher
  • DES
  • 3DES
  • RSA Key transport
  • SHA-1 hashing
  • CBC Mode ciphers
  • MD5
  • Diffie-Hellman groups
  • EXPORT ciphers


Server side of the channel is always authenticated; the client side is optionally authenticated.
can happen via asymmetric cryptography like
RSA,Elliptic Curve Digital Signature Algorithm (ECDSA) [ECDSA], or Edwards-Curve Digital Signature Algorithm (EdDSA) or a symmetric pre-shared key (PSK).

2. Confidentiality:
Data sent over the channel after establishment is only visible to the endpoints. TLS does not hide the length of the data it transmits, though endpoints are able to pad TLS records in order to obscure lengths and improve protection against traffic analysis techniques.

3. Integrity:
Data sent over the channel after establishment cannot be modified by attackers without detection.

Two primary components:

Handshake protocol

authenticates the communicating parties,
negotiates cryptographic modes and parameters,
establishes shared keying material.
designed to resist tampering;

Record protocol

uses the parameters established by the handshake protocol to protect traffic between the communicating peers.
divides traffic up into a series of records, each of which is independently protected using the traffic keys.

TLS Hybrid Cryptosystems

For TLS to work a handshake needs to take place to exchange cryptographic data between the peers to agree on a key.  A Hybrid ecosystem uses both symmetric key cryptography (fast ans cheap)  and public key cryptography ( slow and expensive)

Steps :

  1. First a public key cryptography ( diff encryption and decryption keys ) is used to establish a shared secret between both parties.
  2. Then the shared secret is used to create symmetric keys (same encryption and ddecryption keys ) that can be used to encrypt the data exchanged.

Handshake can be thought of as having 3 phases

1.Key Exchange:

Establish shared keying material and select the cryptographic parameters. Everything after this phase is encrypted.

2. Server Parameters:

Establish other handshake parameters (whether the client is authenticated, application-layer protocol support, etc.).

3. Authentication:

Authenticate the server (and, optionally, the client) and provide key confirmation and handshake integrity.

Basic TLS handshake

Negotiation phase

1.client sends a ClientHello message

It contains

  • highest TLS protocol version it supports,
  • random nonce,
  • list of suggested cipher suites
  • suggested compression methods.
  • session ID if it is a resumed handshake.
  • list of supported application protocols, such as HTTP/2 for if doing Application-Layer Protocol Negotiation

2.server responds with a ServerHello message

  • chosen protocol version,
  • random number,
  • cipher suite and
  • compression method from the choices offered by the client
    session ID if it is a resumed handshake.

The combination of the ClientHello and the ServerHello determines the shared keys.

3.server sends its Certificate message

4. server sends its ServerKeyExchange message

5..server sends a ServerHelloDone message,

  • indicating it is done with handshake negotiation

6. client responds with a ClientKeyExchange message, 

  • may contain a PreMasterSecret( encrypted using the public key of the server certificate), public key, or nothing.
  • client and server then use the random numbers and PreMasterSecret to compute a common secret, called the “master secret”.

Record level

Handshke is complete
client and server derive the keying material required by the record layer to exchange application-layer data protected through authenticated encryption.

7.Client sends ChangeCipherSpec 

  • record-level protocol with content type of 20.
  • client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.
  • server will attempt to decrypt the client’s Finished message and verify the hash and MAC.

8. Client sends Finish 

MAC (Message Authentication Code) over the entire handshake.
provides key confirmation, binds the endpoint’s identity to the exchanged keys

9.server sends a ChangeCipherSpec

  • server sends its authenticated and encrypted Finished message.
  • client performs the same decryption and verification procedure

10 Server sends finish 

Application phase 

Everythings endt now is encrypted

TLS hand (1)

Handshake Protocol

      enum {
      } HandshakeType;

      struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* remaining bytes in message */
          select (Handshake.msg_type) {
              case client_hello:          ClientHello;
              case server_hello:          ServerHello;
              case end_of_early_data:     EndOfEarlyData;
              case encrypted_extensions:  EncryptedExtensions;
              case certificate_request:   CertificateRequest;
              case certificate:           Certificate;
              case certificate_verify:    CertificateVerify;
              case finished:              Finished;
              case new_session_ticket:    NewSessionTicket;
              case key_update:            KeyUpdate;
      } Handshake;

Client Hello

uint16 ProtocolVersion;
      opaque Random[32];

      uint8 CipherSuite[2];    /* Cryptographic suite selector */

      struct {
          ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
          Random random;
          opaque legacy_session_id<0..32>;
          CipherSuite cipher_suites<2..2^16-2>;
          opaque legacy_compression_methods<1..2^8-1>;
          Extension extensions<8..2^16-1>;
      } ClientHello;

Server Hello

struct {
          ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
          Random random;
          opaque legacy_session_id_echo<0..32>;
          CipherSuite cipher_suite;
          uint8 legacy_compression_method = 0;
          Extension extensions<6..2^16-1>;
      } ServerHello;


Alert Protocol

Signals a fatal error  and session will be closed immediately after sending this record . Can be sent at any time during the handshake and up to the closure of the session.

Alert level types

1 warning connection or security may be unstable.
2 fatal connection or security may be compromised, or an unrecoverable error has occurred.

Alert Description Types

Code Description Level types Note
0 Close notify warning/fatal
10 Unexpected message fatal
20 Bad record MAC fatal Possibly a bad SSL implementation, or payload has been tampered with e.g. FTP firewall rule on FTPS server.
21 Decryption failed fatal TLS only, reserved
22 Record overflow fatal TLS only
30 Decompression failure fatal
40 Handshake failure fatal
41 No certificate warning/fatal SSL 3.0 only, reserved
42 Bad certificate warning/fatal
43 Unsupported certificate warning/fatal e.g. certificate has only Server authentication usage enabled and is presented as a client certificate
44 Certificate revoked warning/fatal
45 Certificate expired warning/fatal Check server certificate expire also check no certificate in the chain presented has expired
46 Certificate unknown warning/fatal
47 Illegal parameter fatal
48 Unknown CA (Certificate authority) fatal TLS only
49 Access denied fatal TLS only – e.g. no client certificate has been presented (TLS: Blank certificate message or SSLv3: No Certificate alert), but server is configured to require one.
50 Decode error fatal TLS only
51 Decrypt error warning/fatal TLS only
60 Export restriction fatal TLS only, reserved
70 Protocol version fatal TLS only
71 Insufficient security fatal TLS only
80 Internal error fatal TLS only
86 Inappropriate Fallback fatal TLS only
90 User canceled fatal TLS only
100 No renegotiation warning TLS only
110 Unsupported extension warning TLS only
111 Certificate unobtainable warning TLS only
112 Unrecognized name warning/fatal TLS only; client’s Server Name Indicator specified a hostname not supported by the server
113 Bad certificate status response fatal TLS only
114 Bad certificate hash value fatal TLS only
115 Unknown PSK identity (used in TLS-PSK and TLS-SRP) fatal TLS only
120 No Application Protocol fatal TLS only, client’s ALPN did not contain any server-supported protocols


shows extended functionality by sending data in the extensions field.

client sends its extension requests in the ClientHello message, and the server sends its extension responses in the ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate messages.
Server sends extension requests in the CertificateRequest message which a client MAY respond to with a Certificate message.

   | Extension                                        |     TLS 1.3 |
   | server_name [RFC6066]                            |      CH, EE |
   |                                                  |             |
   | max_fragment_length [RFC6066]                    |      CH, EE |
   |                                                  |             |
   | status_request [RFC6066]                         |  CH, CR, CT |
   |                                                  |             |
   | supported_groups [RFC7919]                       |      CH, EE |
   |                                                  |             |
   | signature_algorithms (RFC 8446)                  |      CH, CR |
   |                                                  |             |
   | use_srtp [RFC5764]                               |      CH, EE |
   |                                                  |             |
   | heartbeat [RFC6520]                              |      CH, EE |
   |                                                  |             |
   | application_layer_protocol_negotiation [RFC7301] |      CH, EE |
   |                                                  |             |
   | signed_certificate_timestamp [RFC6962]           |  CH, CR, CT |
   |                                                  |             |
   | client_certificate_type [RFC7250]                |      CH, EE |
   |                                                  |             |
   | server_certificate_type [RFC7250]                |      CH, EE |
   |                                                  |             |
   | padding [RFC7685]                                |          CH |
   |                                                  |             |
   | key_share (RFC 8446)                             | CH, SH, HRR |
   |                                                  |             |
   | pre_shared_key (RFC 8446)                        |      CH, SH |
   |                                                  |             |
   | psk_key_exchange_modes (RFC 8446)                |          CH |
   |                                                  |             |
   | early_data (RFC 8446)                            | CH, EE, NST |
   |                                                  |             |
   | cookie (RFC 8446)                                |     CH, HRR |
   |                                                  |             |
   | supported_versions (RFC 8446)                    | CH, SH, HRR |
   |                                                  |             |
   | certificate_authorities (RFC 8446)               |      CH, CR |
   |                                                  |             |
   | oid_filters (RFC 8446)                           |          CR |
   |                                                  |             |
   | post_handshake_auth (RFC 8446)                   |          CH |
   |                                                  |             |
   | signature_algorithms_cert (RFC 8446)             |      CH, CR |



Also Called HTTP over TLS.

Most of the security is derived form underlying TLS


Authentication protecets against man-in-middle attacks

bidirectional encryption of communications between a client and server protects against eavesdropping, tampering

Protects aganist packet sniffers on a public Wifi access point and packet injection on WLAN

Forward Secracy : To ensure that even if long-term secret keys or passwords are compromised in future , the past encrypted communications cannot be retrieved and decrypted

Trusting websites

USer should trust an HTTPS connection to a website if and only if all of the following are true:

  • The user trusts that the browser software correctly implements HTTPS with correctly pre-installed certificate authorities.
  • The user trusts the certificate authority to vouch only for legitimate websites.
  • The website provides a valid certificate, which means it was signed by a trusted authority.
  • The certificate correctly identifies the website
  • The user trusts that the protocol’s encryption layer (SSL/TLS) is sufficiently secure against eavesdroppers.

HSTS (HTTP Strict Transport Security).

request HTTPS pages automatically, even if the user enters http in the browser location bar.
minimizes the risk of serving unsecured content to your users.

protects websites against protocol downgrade attacks and cookie hijacking.

Addressed threats include

  • Passive Network Attackers
  • Active Network Attackers
  • \Web Site Development and Deployment Bugs

communicated by the server to the user agent via an HTTPS response header field named “Strict-Transport-Security”

Common issues in Assigning Web certificates

  • Expired certificates
  • Certificate registered to incorrect website name – check the CSR ( Certificate Signing Request)
  • Missing Server name indication (SNI) support – ask users to switch to SNI supported browsers
  • Crawling issues – Don’t block your HTTPS site from crawling using robots.txt.
  • Indexing issues – Allow indexing of your pages by search engines. Avoid the noindex meta tag
  • Mixed security elements Embed only HTTPS content on HTTPS pages.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s