SSL/TLS Introduction with Practical Examples Including Wireshark Captures

SSL/TLS Introduction
with Practical Examples Including Wireshark Captures

Scope
 within the scope
 basic understanding of Public Key Infrastructure (PKI)
 basic understanding of SSL/TLS protocols
 practical demonstrations of various scenarios with Wireshark captures
 out of scope
 history of the protocols and distinctions between the protocol versions
 vulnerabilities and attacks
 details of particular cipher suites
 advanced techniques like certificate pinning, Server Name Indication etc.
 math behind the cryptography

Agenda
 Brief Introduction to Public Key Infrastructure (PKI)
 Introduction to SSL/TLS Protocols
 Practical Examples and Hints

Symmetric versus Asymmetric Cryptography
 symmetric cryptography (e.g. RC4, DES, 3DES, AES)
 both participants use the same secret key to encrypt as well as to decrypt
 the secret key should only be accessible to the participants
 asymmetric cryptography (e.g. RSA)
 key pair consisting of private key and public key
 what has been encrypted with one of the keys can only be decrypted with the other
 none of the keys can decrypt what it has encrypted
 private key should only be accessible to its owner
 public key is accessible to anyone

Symmetric versus Asymmetric Cryptography
Symmetric
Cryptography
Asymmetric
Cryptography
Speed of encryption  
Compact cipher-text  
Support for digital signatures
and non-repudiation  
Encryption key can be securely transferred
over insecure channel  
(public key)
Key exchange does not require prior
relationship between the participants  
Scalability (how does the number of keys
grow with the number of participants?)

(roughly the square)

(linear growth)

Cryptographic One-Way Hash Functions
 a cryptographic one-way hash function (e.g. MD5, SHA-1, SHA-256)
 takes an input of arbitrary length
 produces a fixed-length hash value (aka digest)
 properties
 it is impossible to recover the input from the digest
 the resulting digest does not reveal anything about the input
 even a small change of the input leads to a significantly different digest
 it should be computationally infeasible to calculate input that will hash to a specific
digest
 it should also be impossible to calculate two inputs leading to the same digest

RecipientSender
Digital Signature (First Draft)
Document
Digest
Digital signature
hash
encrypt with
sender’s private
key
Communication channel
Document
Digital signature
Document
hash
Digest
decrypt with
sender’s public key
Digital signature
Digest’
?
==Sender’s public key

Security Aspects of Digital Signature
 given
 you have received a signed document
 and the private key of the signer has not been compromised
 when you have successfully verified the signature, then you can trust that
 the document really originates from the signer (authentication)
 and the document has not been changed after the signing (data integrity)

Recipient
Sender
Digital Signature Reconsideration
Document
Digital signature
Sender’s public key
Modified document
Attacker’s public key
Digital signature’
Attacker

Public Key Certificate
 electronic document confirming that the public key
contained in the certificate is associated with the
subject of the certificate
 in other words, it establishes an association between
an identity and a private/public key pair
 contents
 information about the subject
 public key of the subject
 information about the issuer (i.e. Certification
Authority that issued the certificate)
 digital signature of the issuer
 additional information plus (optional) extensions

Analogy between Physical Certificates and Public
Key Certificates
Passport
(example of physical certificate)
Public key certificate
Name
Nationality
Birth date and place
Sex
Photograph and signature
Subject
Public key of the subject
Issued by Issuer
Passport no Serial number
Date of issue/date of expiry Valid from/to
Official insignia
Page numbers + passport no on each page
Digital signature of the issuer

Certification Authority (CA)
 trusted authority responsible for
 issuing public key certificates, thus establishing associations between identities and
their corresponding key pairs
 supporting certificate lifecycle workflow
 protects its own private keys
 implements procedures that verify the identity of the entities requesting
certificates
 a root CA usually also has to comply with local laws and pass regular audits
 from business point of view, the goal of a root CA is to maximize the presence of
its (self-signed) certificate(s) in trust-stores

Certificate Chain
(aka Chain of Trust, or Certification Path)
End-entity certificate
Subject’s name
Subject’s public key
Issuer’s (CA) name
Issuer’s (CA) signature
Intermediate CA certificate
Subject’s name
Root CA certificate
Subject’s name
Derived trust
Trust anchor, assumed trust
Reference
Reference
Signed with private key
Signed with private key
Self-signed with private key
Self-reference

Certificate Validation
 validity of the complete certificate chain is checked, starting with the end-entity
certificate
 for each certificate in the chain, the following is verified
 for end-entity certificate, the subject must match with the expected communication
partner
 issuer's signature (verified by issuer's public key; certificate must not be modified)
 current date/time within the validity period (certificate must not be expired)
 revocation status (certificate must not be revoked)
 compliance with the intended certificate use (e.g. private key corresponding to server
certificate must not be used to sign other certificates)
 issuer identical with the subject of the next certificate in the chain
 at the end of the chain, there must be a self-signed certificate of a trusted CA

Crucial Aspects of PKI
PKI works pretty well as long as
 no private key is compromised
 this is valid for end-entity private keys and even more for CA private keys
 compromise of CA private key can lead to issuance of (many) fraudulent certificates
 compromise of root CA private key can lead to issuance of complete hierarchies of
fraudulent certificates
 and no certificate of a compromised/negligent/fraudulent CA appears in any
trust-store
 let's assume such a certificate appears in the trust-store of your Web browser (e.g.
DigiNotar)
 you will automatically trust any fraudulent certificate whose trust anchor is the CA

Revocation Mechanisms for the Case of
Compromised Private Key
 Certificates Revocation List (CRL)
 list of serial numbers of revoked certificates that have not expired yet
 CAs maintain one or more such lists
 CRLs tend to be large, thus leading to slow lookups
 CRL Distribution Points extension within a certificate should provide the CRL location
 Online Certificate Status Protocol (OCSP)
 allows to query the revocation status of a single certificate
 Authority Information Access extension within a certificate should provide the URL of
the OCSP responder

RecipientSender
Digital Signature Revised
Document
Digest
Digital signature
hash
encrypt with
sender’s private
key
Document
Digital signature
Sender’s certificate
chain
Document
hash
Digest
decrypt with
sender’s public key
Digital signature
Digest’
?
==
Finally, validate sender’s
certificate chain including
revocation status

Certificate Extensions
 add flexibility to the certificate format
 allow to
 distinguish CA certificates from end-entity certificates
 restrict the usage of the key-pair associated with the certificate
 provide further information about the issuer (access points for OCSP, CRL, CPS)
 specify more DNS names for server certificates
 etc.
 two types
 critical – must be understood and successfully processed; otherwise, the certificate
must be rejected
 non-critical

Frequently Used End-Entity Certificate Extensions
(specific for certificates used by SSL/TLS servers & clients)
Extension Critical Usual Value(s)/Content
Basic Constraints Yes/No  Subject is not CA
Key Usage Yes
 Digital Signature
 Key Encipherment
Extended Key Usage No
 TLS Web Server Authentication
 TLS Web Client Authentication
Subject Alternative Name No  one or more DNS names
Authority Information Access No  URL of issuer’s OCSP responder
CRL Distribution Points extension No  URL of issuer’s CRL
Certificate Policies No  URL of issuer’s CPS

Frequently Used CA Certificate Extensions
Extension Critical Usual Value(s)
Basic Constraints Yes  Subject is CA
Key Usage Yes
 Certificate Signing
 CRL Signing
Authority Information Access No  URL of subject’s OCSP responder
CRL Distribution Points extension No  URL of subject’s CRL
Certificate Policies No  URL of subject’s CPS

Exercise: Exploration of Certificate Chains
 use Examine SSL functionality provided by KeyStore Explorer
 explore the complete certificate chains for various URLs
 for each certificate, explore
 subject and issuer
 validity period
 public key and signature algorithm
 various fingerprints
 for each certificate, explore these extensions
 Key Usage + Extended Key Usage
 CRL Distribution Points (click the URL to open the CRL)
 Authority Information Access
 Subject Alternative Name

Exercise: Issuance of Certificate
1. generation of key-pair
 private + public key
 self-signed public key certificate
2. export of Certificate Signing Request (CSR)
 carries the public key and the identity of the applicant
 signed with the applicant’s private key
3. signing of the CSR by Certification Authority (CA)
 CA has to verify the identity of the subject
 Certification Practices Statement (CPS) describes how the CA issues and manages
public key certificates (Certificate Policies extension refers to CPS)
4. import of CA reply into the applicant’s key-store
 certificate chain rather than just applicant’s certificate

Smart Combination of Symmetric and Asymmetric
Cryptography
 symmetric cryptography used to encrypt the application data
 new encryption key is usually generated for each session/connection
 this is where the strengths of symmetric cryptography (i.e. speed and compact cipher-
text) are advantageous
 asymmetric cryptography used for
 authentication of participants
 secure exchange of information needed to establish the common symmetric
encryption key
 this is where the strengths of asymmetric cryptography shine

Security Aspects of SSL/TLS
 authentication
 mandatory server authentication
 optional client authentication
 usually based on public key certificates
 before you send your Internet-Banking username/password to a server, you would like to
know you talk with the server of your bank rather than with a hacker’s server
 confidentiality
 symmetric encryption
 encryption key generated/exchanged during the initial handshake
 data integrity
 Message Authentication Code (MAC) rather than digital signature
 simplified: MAC = hash(payload + symmetric encryption key)

Information Revealed Despite of SSL/TLS
 IP and TCP headers (i.e. IP addresses, TCP ports etc.)
 length of messages
 the initial handshake is not encrypted, so anyone capturing the data can also see
 capabilities of the client (i.e. best supported protocol plus enabled cipher suites)
 negotiated protocol and cipher suite
 target virtual host if Server Name Indication (SNI) is used
 server certificate chain
 client certificate chain if client authentication is used
 if user certificate is used for client authentication, even the identity of the user

Attributes of a Cipher Suite
 examples of modes
 Electronic Codebook (ECB)
 Cipher Block Chaining (CBC)
 Galois/Counter Mode (GCM)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Key exchange Authentication Symmetric encryption MAC
Encryption algorithm ModeKey size
See also
SSL and TLS Cipher Suites

Examples of Cipher Suites
 NULL no data encryption and/or no data integrity
useful for debugging
 Anon no key authentication
vulnerable to man in the middle attack
 TLS_NULL_WITH_NULL_NULL used during initial session establishment
Name Key exchange Authentication Encryption MAC
TLS_DH_RSA_WITH_AES_256_GCM_SHA384 DH RSA AES_256_GCM SHA384
TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256
TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
TLS_DH_Anon_WITH_AES_128_CBC_SHA DH Anon AES_128_CBC SHA
TLS_NULL_WITH_NULL_NULL NULL NULL NULL NULL

Perfect Forward Secrecy (PFS)
 key-exchange algorithms like RSA have one fundamental weakness
 key generation material exchanged during the handshake is encrypted with server's
private key
 an attacker could capture and retain traffic for a longer time
 if he gains access to the server's private key one day, all the captured key generation
material can be decrypted
 future communications using the same private key for key exchange would not be secure
as well
 PFS addresses this by use of ephemeral key-exchange protocols (e.g. DHE, ECDHE)
 temporary public/private key-pair is used to exchange the key generation material
 each session uses a new key-pair, so a compromise of such a temporary private key does
not impact other sessions

The Role of Key-Store and Trust-Store in
Authentication
Server Key-Store
 server’s private key
 certificate chain starting with
server’s public key certificate
 used by the server to prove its
identity to the client
Client Trust-Store
 certificate(s) of root CA(s)
trusted by the client
 server authentication can only
succeed if one of them is trust
anchor for the certificate chain
received from the server
Client Key-Store
 client’s private key
 certificate chain starting with
client’s public key certificate
 used by the client to prove its
identity to the server
Server Trust-Store
 certificate(s) of root CA(s)
trusted by the server
 client authentication can only
succeed if one of them is trust
anchor for the certificate chain
received from the client
Client Server
Server authentication
Optional
client authentication
Certificate chain
Certificate chain

Key-Store
 content
 private key + public key certificate of the local communication endpoint
 complete certificate chain including CA certificates
 no private keys of any CAs!!!
 presence
 needed for server as server authentication is mandatory
 not needed for client unless client authentication is required
 deployments with two or more private keys + certificates
 virtual hosting
 two or more key algorithms (e.g. RSA and DSA) to support more cipher suites

Trust-Store
 content
 no private keys at all!!!
 only public key certificates of trusted root CAs
 no public key certificate of any communication endpoint
 the only exception are self-signed certificate(s) of remote communication endpoint(s)
if self-signed certificate(s) are used
 the above described setup with self-signed certificates setup should never be used in
production!!!
 presence
 needed for client as server authentication is mandatory
 not needed for server unless client authentication is required

Key-Store and Trust-Store Tools
 Java keytool
 simple command line tool
 rather basic management of keys and certificates, not suitable for CA use cases
 inconvenient for key-stores and trust-stores with many entries and non-trivial certificate
chains
 KeyStore Explorer
 compared to Java keytool, easier to use and more feature-rich with GUI
 basic CA use cases supported as well
 OpenSSL
 commercial-grade, full-featured toolkit supporting all CA use cases including revocation
 used by organizations operating their own private CAs
 Docker image with OpenSSL is available as well

Two Crucial Verifications Varying with the
Implementation
 hostname verification for server certificates
 certificate chain, in particular
 extensions
 revocation status
 for Java, it depends on the provider(s) and the API you use
 there is no hostname verification if you use default JSEE provider and the
javax.net.SSLSocketFactory/SSLSocket API
 javax.net.HttpsURLConnection involves hostname verification even with the
default JSSE provider
 HttpsURLConnection can be customized with HostnameVerifier and
TrustManager

SSL Handshake
 initial sequence of unencrypted messages responsible for
 authentication
 negotiation of protocol & cipher suite
 exchange of information leading to generation of encryption key
 3 variants of handshake
 handshake without client authentication
 handshake with client authentication
 session resumption (not covered by this training)

SSL Handshake: ClientHello
(message payload relevant for debugging)
 always the very first message of the handshake
 reveals client capabilities
 the best protocol supported by (and enabled for) the
client
 list of cipher suites supported by (and enabled for)
the client in order of preference
 empty session ID unless this is an attempt to resume
an earlier session
 random data relevant for the verification of the
integrity of the handshake (see Finished)
Client Server
ClientHello

SSL Handshake: ServerHello
 always the second message of the handshake
 protocol
 client’s proposal confirmed if supported by (and enabled
for) the server
 otherwise, the best protocol supported by (and enabled
for) the server
 cipher suite
 the first cipher suite offered by the client which is
supported by (and enabled for) the server
 in other words, client's order of preference is taken into
account
 new session ID (unless this is session resumption)
 random data similar to ClientHello
Client Server
ClientHello
ServerHello

SSL Handshake: Certificate
 server's certificate chain, with the server's
certificate being the first
 public key algorithm must match with the cipher
suite
 optional message, omitted if
 the cipher suite does not require authentication
(Anon)
 or the cipher suite uses authentication method that
does not require certificates (e.g. PSK)
Client Server
ClientHello
ServerHello
[Certificate]

SSL Handshake: ServerKeyExchange
 carries data needed for key exchange
 content varies depending on the negotiated cipher
suite
 content reveals the key exchange algorithm, but it
is known from ServerHello message anyway
 for some cipher suites (e.g. RSA key exchange), this
message is omitted
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]

SSL Handshake: CertificateRequest
 omitted unless client authentication is required
 server communicates acceptable
 key pair algorithms (e.g. server can accept
certificates containing RSA and DSA keys)
 signature algorithms
 optionally, server can also send a list of acceptable
root CAs
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]
[CertificateRequest]

SSL Handshake: ServerHelloDone
 indicates that the server
 has already sent all intended handshake messages
 is waiting for further messages from the client
 upon the receipt of this message, the client should
validate the server’s certificate
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]
ServerHelloDone

SSL Handshake: Certificate
 omitted unless client authentication is required
 client certificate chain
 if client authentication is required, and no suitable
certificate is available, the client sends a
Certificate message containing no certificates
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]
ServerHelloDone
[Certificate]

SSL Handshake: ClientKeyExchange
 carries data needed for key exchange
 content varies depending on the negotiated cipher
suite
 content reveals the key exchange algorithm, but it
is known from ServerHello message anyway
 mandatory message regardless of the key exchange
algorithm
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]
ServerHelloDone
[Certificate]
ClientKeyExchange

SSL Handshake: CertificateVerify
 omitted unless client authentication is used
 used to prove the possession of the client’s private
key corresponding to the public sent together with
the client’s certificate by the Certificate message
 digital signature of all handshake messages
exchanged so far
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]
ServerHelloDone
[Certificate]
ClientKeyExchange
[CertificateVerify]

SSL Handshake: ChangeCipherSpec
 indicates that the client
 has received everything needed to establish secure
connection
 has generated the encryption key
 is switching to encrypted communication
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]
ServerHelloDone
[Certificate]
ClientKeyExchange
[CertificateVerify]
ChangeCipherSpec

SSL Handshake: Finished
 indicates completed handshake
 must follow immediately after ChangeCipherSpec
 the first encrypted message sent by the client
 carries a hash of all handshake messages mixed
with the negotiated master secret
 used to verify the integrity of the entire handshake
 random data sent as part of ClientHello &
ServerHello prevents replay attacks
 each side can verify whether the messages it has
sent/received are the same as the other side has
received/sent
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]
ServerHelloDone
[Certificate]
ClientKeyExchange
[CertificateVerify]
ChangeCipherSpec
Finished

SSL Handshake: ChangeCipherSpec
 indicates that the server
 has received everything needed to establish secure
connection
 has generated the encryption key
 is switching to encrypted communication
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]
ServerHelloDone
[Certificate]
ClientKeyExchange
[CertificateVerify]
ChangeCipherSpec
Finished
ChangeCipherSpec

SSL Handshake: Finished
 indicates completed handshake
 must follow immediately after ChangeCipherSpec
 the first encrypted message sent by the server
 carries a hash of all handshake messages mixed
with the negotiated master secret
 used to verify the integrity of the entire handshake
 random data sent as part of ClientHello &
ServerHello prevents replay attacks
 each side can verify whether the messages it has
sent/received are the same as the other side has
received/sent
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]
ServerHelloDone
[Certificate]
ClientKeyExchange
[CertificateVerify]
ChangeCipherSpec
Finished
ChangeCipherSpec
Finished

Termination of Connection – Alert message
 level
 warning
 fatal leads to immediate abort of the connection, for instance if there is no common
protocol version or cipher suite
 description
 just an enumeration of opcodes, no error message with details of the error
 examples: protocol_version, handshake_failure, certificate_expired,
certificate_revoked, unexpected_message, close_notify, ...

Happy Case Closure Alert (close_notify)
 regular termination of connection after all data has been sent (i.e. no error)
 each party is required to send close_notify before closing its output stream
 depends on whether the implementation closes the output stream before closing the
socket
 either party may initiate the termination
 any data received after close_notify should be ignored

Trouble-Shooting Hints
 Java system property for SSL debugging
 javax.net.debug=ssl[:flags] (flags: record, handshake, session, sslctx, …)
 works for Oracle JVM as well as for IBM JVM
 works also for WebSphere
 does not work for Bouncy Castle
 if the TCP connect fails, the SSL handshake cannot be started at all, so it cannot
be SSL/TLS problem
 connection refused (RST response to SYN)
 connect timed out (no response to SYN)

Wireshark Support for SSL/TLS
 the above depicted approach allows to see the handshake messages, but not the
application data
 you can also import the session key if your client supports session key logging;
this way, you can also decrypt application data

Few Facts You Should Be Aware of
 if proxy is involved, the TCP (and hence the SSL/TSL) connection is terminated
at the proxy, not at the destination server
 if applicable, use connection pooling
 opening a new SSL/TLS connection is quite expensive
 one network round-trip for TCP handshake
 two network round-trips involving up to 13 messages for SSL handshake (except of
session resumption)
 check of revocation status
 CPU-intensive cryptographic operations involved in the SSL handshake
 further network round-trips for termination of the connection

SSL Sandbox
 dummy SSL Server + SSL Client based on Java SE
 both easily configurable via configuration files in YAML format
 easy switching between the default JSSE provider and Bouncy Castle
 ready-to-use configurations for demonstration of various scenarios
 configuration files for both client and server
 key-stores and trust-stores for both client and server (JKS format)
 for each of the scenarios, there is also a capture file which can be analyzed with
Wireshark, so you do not have to repeat the scenario yourself
 accessible at https://github.com/Jardo72/SSL-Sandbox

SSL Sandbox
 ready-to-use configurations & capture files available in the scenarios subdirectory;
password for all key-stores and trust-stores is aardwark
 each scenario has a separate directory
 certificates valid till 2038 (except of those which are intentionally expired)
 both client and server automatically register Bouncy Castle providers
 the configuration changes above do not affect the (persistent) configuration of your
JRE, only the current process is affected
 you have to
 install the unrestricted policy files to your JRE
 adapt the IP address in the client and server configurations to your environment

Successful Handshake without Client
Authentication 1/2
 TLSv1.1 and TLSv1.2 enabled for the client
 only TSLv1.1 enabled for the server
 ClientHello carries
 the highest protocol version enabled for the client (TLSv1.2
in our case)
 cipher suites enabled for client in client’s order of
preference
 ServerHello carries
 the highest protocol version enabled for the server
(TLSv1.1 in our case)
 the first cipher suite from the received list which is also
enabled for the server
 messages specific to client authentication are missing
Client Server
ClientHello
ServerHello
[Certificate]
[ServerKeyExchange]
ServerHelloDone
[Certificate]
ClientKeyExchange
[CertificateVerify]
ChangeCipherSpec
Finished
ChangeCipherSpec
Finished

Successful Handshake without Client
Authentication 2/2
 the server sends the entire certificate chain available in its key-store
 in this particular case, the complete chain including root CA certificate is available
 the same approach is used by the majority of the presented scenarios
 handshake successfully completed by two pairs of messages (CipherSpecChange and
Finished)
 each end-point sends one pair
 these are the last messages before the transmission of application data
 application data encrypted and thus not visible

Successful Handshake with Client
Authentication 1/2
 TLSv1.2 enabled for both end-points
 some of the cipher suites enabled for the client are not enabled for the server
 in addition, server's order of preference differs from client's order of preference
 choice of cipher suite seems to depend on the SSL/TLS implementation used by the
server
 Sun provider seems to take client's order of preference into account
 Bouncy Castle seems to take server's order of preference into account
 at the bottom line, the cipher suite carried by ServerHello message is used

Successful Handshake with Client
Authentication 2/2
 messages specific to client authentication (CertificateRequest, Certificate,
CertificateVerify) are present
 CertificateRequest message carries acceptable
 key pair and signature algorithms
 root CAs acceptable for server
 each end-point sends the entire certificate chain available in its key-store
 in this particular case, no root CA certificate is available in any of the key-stores
 each end-point sends only its own certificate plus certificate of intermediate CA (i.e.
issuer); root CA certificate not sent
 handshake completed by the same two pairs of messages as in the previous scenario
(i.e. CipherSpecChange and Finished)

Two Successful Handshakes, Each Using
Distinct Server Certificate
 server with two key pairs (RSA and DSA) and two certificates
 client A
 RSA key-pair
 cipher suites using RSA key exchange and RSA authentication
 client B
 DSA key-pair
 cipher suites using DHE key exchange and DSA authentication
 two successful handshakes, one for each of the two clients
 each handshake leads to cipher suite reflecting client capabilities
 each handshake uses distinct server certificate
 ServerKeyExchange message absent for RSA, but present for DHE/DSA

Successful Handshake without Encryption
 for both end-points, just a single cipher suite with NULL
encryption is enabled
 despite of valid SSL session, application data is not
encrypted
 in contrast with other scenarios with successful
handshake, Finished messages and close_notify alerts are
not encrypted either
 such a cipher suite should never be enabled for
communication channels transferring sensitive data!!!
 however, it can be handy in case of trouble shooting when
you need to see the application data

Failed Handshake Due to Absence of Common
Protocol Version
 client supports only TLSv1.2, server supports only
TLSv1.1
 ClientHello carries only the best protocol version
supported by the client (i.e. TLSv1.2)
 the server does not know if the client supports
other protocol versions, so it proposes a protocol
version it supports via ServerHello (i.e. TLSv1.1)
 after receiving the ServerHello message, the client
aborts the connection with fatal alert
(handshake_failure used as description)
Client Server
ClientHello
ServerHello
Fatal alert

Failed Handshake Due to Absence of Common
Cipher Suite
 client configuration enables
 TLSv1.2
 only TLS_RSA_WITH_AES_256... cipher suites
 server configuration enables
 TLSv1.1 and TLSv1.2
 only TLS_RSA_WITH_AES_128... cipher suites
 after receiving the ClientHello message, the server
aborts the connection with fatal alert
(handshake_failure used as description)
Client Server
ClientHello
Fatal alert

Failed Handshake Due to Expired Server
Certificate
 server certificate expired
 after receiving the initial sequence of handshake
messages from the server, the client aborts the
connection with fatal alert
 description seems to depend on the SSL/TLS
implementation used by the client
 certificate_expired, bad_certificate and
certificate_unknown are the most likely
descriptions
 Bouncy Castle provider seems to use
bad_certificate
Client Server
ClientHello
ServerHello
Certificate
[ServerKeyExchange]
ServerHelloDone
Fatal alert

Failed Handshake Due to Broken Server
Certificate Chain
 server certificate without the certificate chain sent
to the client
 client has only the root CA certificate; the
certificate of the intermediate CA that issued the
server certificate is not available
 bad_certificate and certificate_unknown are the
most likely descriptions
 Sun provider seems to use certificate_unknown
Client Server
ClientHello
ServerHello
Certificate
[ServerKeyExchange]
ServerHelloDone
Fatal alert

Failed Handshake Due to Absence of Trust Anchor
for Server Certificate
 server certificate chain without the root CA
certificate sent to the client
 client does not have the root CA certificate in its
trust-store
bad_certificate
Client Server
ClientHello
ServerHello
Certificate
[ServerKeyExchange]
ServerHelloDone
Fatal alert

Failed Handshake Due to CA Certificate with
Invalid Extensions
 server certificate issued by CA whose certificate is
marked as non-CA certificate
 critical Basic Constraints extension → subject is NOT
a CA
implementation used by the client
 Sun provider seems to use unknown_certificate
bad_certificate
Client Server
ClientHello
ServerHello
Certificate
[ServerKeyExchange]
ServerHelloDone
Fatal alert

Failed Handshake Due to Absence of Server
Certificate
 server configured with empty key-store (i.e. no
server certificate is available)
 all enabled cipher suites use RSA authentication,
some of them even RSA key exchange
 after receiving the ClientHello message from the
client, the server aborts the connection with fatal
alert
 handshake_failure used as description
 Sun provider and Bouncy Castle provider behave
exactly the same way
Client Server
ClientHello
Fatal alert

Failed Handshake Due to Expired Client
Certificate
 client certificate expired
 after receiving the Certificate and
ClientKeyExchange messages from the client, the
server aborts the connection with fatal alert
implementation used by the server
 certificate_expired, bad_certificate, and
certificate_unknown are the most likely
descriptions
 Sun provider seems to use certificate_unknown
Client Server
ClientHello
ServerHello
Certificate
[ServerKeyExchange]
CertificateRequest
ServerHelloDone
Certificate
ClientKeyExchange
Fatal alert

Failed Handshake Due to Broken Client
Certificate Chain
 client authentication requested by the server (and
enabled for the client)
 client certificate without the certificate chain
present in client’s key-store
 surprisingly, empty Certificate message is sent by
the client (Sun as well as Bouncy Castle)
 Sun provider seems to use bad_certificate
Client Server
ClientHello
ServerHello
Certificate
[ServerKeyExchange]
CertificateRequest
ServerHelloDone
Certificate
ClientKeyExchange
Fatal alert

Failed Handshake Due to Absence of Trust Anchor
for Client Certificate
 client certificate chain without the root CA
certificate sent to the server
 server does not have the root CA certificate in its
trust-store
 bad_certificate, and certificate_unknown are the
Client Server
ClientHello
ServerHello
Certificate
[ServerKeyExchange]
CertificateRequest
ServerHelloDone
Certificate
ClientKeyExchange
Fatal alert

Failed Handshake Due to Absence of Client
Certificate
 empty key-store configured for the client
 empty Certificate message sent by the client
implementation used by the server
 bad_certificate, and certificate_unknown are the
Client Server
ClientHello
ServerHello
Certificate
[ServerKeyExchange]
CertificateRequest
ServerHelloDone
Certificate
ClientKeyExchange
Fatal alert

Tips for Further Experiments
 client authentication required by the server but not enabled for the client
 none of the cipher suites enabled for both end-points is compatible with the common
protocol version
 for instance, TLS_RSA_WITH_AES_256_GCM_SHA384 will not work with TLSv1.1
 one of the CA certificates in the certificate chain is
 expired
 not eligible for certificate signing (critical Key Usage extension)
 client or server certificate is not eligible for SSL handshake
 critical Key Usage extension → certificate and/or CRL signing
 revoked certificate
 client or server
 CA

Resources
Internet
 the presentation involves several
slides with hyper-links to various
Internet resources
 TLS Protocol Version 1.2 (RFC)
 SSL Labs
 SSL/TLS and PKI History (includes
well known attacks)
Books
Bulletproof SSL and TLS: Understanding and
Deploying SSL/TLS and PKI to Secure Servers
and Web Applications
by Ivan Ristic
ISBN-10: 1907117040
PKI: Implementing & Managing E-Security
by Andrew Nash, Bill Duane, Derek Brink,
Celia Joseph
ISBN-13: 978-0072131239

Thank you for your attention
Jaroslav Chmúrny
jaroslav.chmurny@aardwark.com
https://www.linkedin.com/in/jaroslav-chmurny-05b26277/
Aardwark s.r.o.
Trnavská cesta 84
821 01 Bratislava
Slovakia
www.aardwark.com

SSL/TLS Introduction with Practical Examples Including Wireshark Captures

More Related Content

What's hot (20)

Similar to SSL/TLS Introduction with Practical Examples Including Wireshark Captures (20)

Recently uploaded (20)

SSL/TLS Introduction with Practical Examples Including Wireshark Captures