SSL/TLS Brown Bag (Ⅰ)

TLS is different from SSL on technical part but the two terms are largely used interchangeable in the production. Secure Socket Layer(SSL) came first and was developed by Netscape. IETF standardized SSL and then Transport Layer Security(TLS) came alone later and is defined in a series of internet RFCs.
TLS was built upon SSL3.0. Due to the encryption algorithm are different, SSL and TLS don't interoperate. In a word,the purpose of TLS is fix the bugs on SSL. It did that. So TLS is more secure than SSL.🧐

In this article, I will use SSL to depict the SSL/TLS unless it need a specific protocol and version.

SSL provide integrity, encryption and authentication.


  1. Symmetric encryption
    Encryption key is same as decryption key.
  2. Asymmetric encryption
    Encryption key is different from decryption key. The two keys were so-called key pairs(Public Key & Private Key).

The data which encrypted by public key could be decrypted only by private key and vice versa.


Digest algorithm make various input into a fixed output. The input with little change will result in the output with a large difference. Only the same input could get the same output.


To ensure client communicate with a correct server. It need use certificate to authenticate the server.

There are some concepts about SSL.

  • Certificates

Generally certificates represent the server. They includes the public half of a public/private key pair. Certificates have many properties. For example the object issued by, the object issued to, Validity period, Common Name, Subject Alternate Names(SAN) and so on.
Certificates are signed - either by themselves or an certificates authority. Client need validate server's certificate by checking signatures.
As you can see here certificates and their issuers are arranged in a chain. So client need trust the chain and not just the server's certificate. Client and OS can have different CA trust stores and sometimes a chain is necessary for the client application to fully validate the signatures.

Also,if server need validate client, client must provide their certificate. But that's optional.

  • Cipher Suite

There is not just a single encryption method used with SSL. Key exchange, encryption and hashing are organized into cipher suites. Key exchange is the process by which the two sides determine the keys to be used for the secure part of communication Authentication here means verifying that the server has the private key associated with the provided certificate confidentiality in the encryption part of the process, obscuring the data integrity happens by doing hashes across the messages and secret data; ensure the data is not changed in flight.
The client and server must have at least one cipher suite in common to communicate. The suite to be used for a connection is selected by the server, during the initial handshake, from a list supplied by the client.

  • Perfect Forward Secrecy(PFS)

If the private key has been leaked, PFS could make past conversations still secure. But it need be supported by both server and client.

  • Server Name Indication(SNI)

SNI is like a Host header for TLS. This extension allows the client to indicate, in the CLIENT HELLO, which hostname it is trying to reach. This enables a server application to serve content for multiple hostnames through a single secure socket. It also need be supported by both server and client.

At next article, I will show the SSL handshake.


  • OωO
  • |´・ω・)ノ
  • ヾ(≧∇≦*)ゝ
  • (☆ω☆)
  • (╯‵□′)╯︵┴─┴
  •  ̄﹃ ̄
  • (/ω\)
  • ∠(ᐛ」∠)_
  • (๑•̀ㅁ•́ฅ)
  • →_→
  • ୧(๑•̀⌄•́๑)૭
  • ٩(ˊᗜˋ*)و
  • (ノ°ο°)ノ
  • (´இ皿இ`)
  • ⌇●﹏●⌇
  • (ฅ´ω`ฅ)
  • (╯°A°)╯︵○○○
  • φ( ̄∇ ̄o)
  • (งᵒ̌皿ᵒ̌)ง⁼³₌₃
  • (ó﹏ò。)
  • Σ(っ°Д°;)っ
  • ╮(╯▽╰)╭
  • o(*
  • >﹏<
  • (。•ˇ‸ˇ•。)
  • 泡泡
  • 颜文字