2015 SSL/TLS Survey
of Financial Institutions
in Luxembourg
Benchmarking for a Trustworthy Internet
Philippe Caturegli
Malo Trevalinet
Nov, 2015
Table of Contents
1.
Cryptography basics
2.
Definitions
3.
SSL/TLS basics
4.
SSL/TLS weaknesses
5.
Survey findings
6.
Conclusion
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
1. Cryptography basics
Basic cryptography
Plaintext (M)
Encryption (E)
Decryption (D)
Recovered
Plaintext (M’)
Ciphertext (C)
Encryption key
Decryption key
KE
KD
The process of encryption and decryption, can be expressed using the following equations:
C = E(M, KE)
Encryption
M' = D(C, KD)
Decryption
M' = M
(if all goes well)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
1. Cryptography basics
Symmetric cryptography
Principle: Use the same crypto keys for both encryption of plaintext and decryption of ciphertext
KE = KD
Secret key
Alice
Secret key
KE
KD
Untrusted network
Decrypt
Encrypt
Plaintext
Bob
Ciphertext
Ciphertext
Pros:
Very fast
Cons:
How to send the secret key across the untrusted network ?
Plaintext
Since both parties use the same secret, we can’t tell who produced the ciphertext
(non-repudiation)
Example: DES (56 bits), 3DES (112 bits), AES (128-192-256 bits)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
1. Cryptography basics
Stream cipher
Principle: Encrypt bits individually
Plaintext (M)
Plaintext bits
Encryption (E)
Key
Generator
Seed key
Ciphertext (C)
Keystream bits
KE
Pros:
Very fast
Cons:
No integrity protection
Example: A5/1, RC4
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
1. Cryptography basics
Block cipher – Electronic Codebook (ECB)
Principle: Encrypt an entire block of plaintext bits at a time with the same key
Encryption key
KE
Plaintext (M)
Encrypted block 1
Plaintext block 1
Encryption (E)
Encryption (E)
Plaintext block 2
Padding
Ciphertext (C)
Encrypted block 2
Encryption key
KE
Pros:
Generally considered stronger than stream ciphers
Cons:
Need to know the length of the message before encryption
The same plaintext block result in the same
encrypted block
Example: 3DES, AES
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
1. Cryptography basics
Block cipher – Cipher Block Chaining (CBC)
Principle: Encrypt an entire block of plaintext bits at a time with the same key
Encryption key
Initialization
Vector
Plaintext (M)
KE
Encrypted block 1
Plaintext block 1
Encryption (E)
Encryption (E)
Plaintext block 2
Padding
Ciphertext (C)
Encrypted block 2
Encryption key
KE
Pros:
Generally considered stronger than stream ciphers
Cons:
Need to know the length of the message before encryption
The same plaintext block result in the same
encrypted block
Example: 3DES, AES
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
1. Cryptography basics
Asymmetric cryptography
Principle: Use a matching pair of keys; one for encryption and the other for decryption
KE ≠ KD
Public
Key B
Alice
KE
Private
Key B
KD
Untrusted network
Decrypt
Encrypt
Plaintext
Bob
Ciphertext
Private
Key A
Ciphertext
Plaintext
Public
Key A
Pros:
Immune to passive eavesdropping
Cons:
Expensive exponential operations involved (i.e. slow & computationally intensive)
No authentication, hence no protection from active attacks
(whereby an attacker impersonates one of the parties involved in the exchange)
Example: RSA, ElGamal, Digital Signature Algorithm (DSA)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
1. Cryptography basics
Key exchange
Principle: Use asymmetric cryptography to securely exchange over public channel crypto keys
required to use symmetric cryptography
Common
Value
Private
Value A
+
Alice
=
Public
Value B
Common
Secret
Public
Value B
Public
Value A
Untrusted network
Private
Value B
=
+
+
+
=
=
KE
KD
Encrypt
Common
Value
Public
Value A
Common
Secret
Decrypt
KE = KD
Example: RSA, Diffie-Hellman
Issues:
Subject to active man-in-the-middle attack unless you are sure the public value
belongs to the other party.
If Bob’s private value gets exposed, it is possible to decrypt all exchanges
previously recorded.
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
Bob
2. Definitions
Internet Engineering
Task Force (IETF)
Netscape
Communications
History
~ Mid 1994
SSL v1.0
Never publicly released because of serious security
flaws (e.g. no data integrity protection, vulnerable to
replay attacks, etc. )
Feb 1995
SSL v2.0
First public release
Nov 1996
SSL v3.0
Complete redesign of the protocol
Introduction of SHA1 hashing algorithm
Jan 1999
TLS 1.0
Update master key calculation process to rely on
both MD5 and SHA1
Aug 2006
TLS 1.1
Added protection against cipher-block
chaining attacks
Aug 2008
TLS 1.2
Change of default hashing algorithm to SHA256
Added support for AES
TLS 1.3
Lots of security improvement, remove weak algo,
remove insecure features such as compression,
renegotiation, change cipher spec protocol, etc.)
TBD
(~ Apr 2016)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
2. Definitions
SSL/TLS implementation
There are more than 15 different implementations of SSL/TLS standards. The
most popular are:
 OpenSSL (Apache mod_ssl, Nginx, Rails)
 Network Security Services – NSS (Mozilla - Firefox, Google – Chrome, Android)
 Schannel (Microsoft - Internet Explorer / IIS)
 Secure Transport (Apple - Safari)
 Java Secure Socket Extension – JSEE (Oracle - Websphere)
Other implementations include GnuTLS, Botan, Bouncy Castle, Cryptlib, RSA BSAFE,
MatrixSSL, PolarSSL, SharkSSL, wolfSSL
In April 2014, OpenBSD announced its own fork of OpenSSL called LibreSSL
In June 2014, Google announced its own fork of OpenSSL called BoringSSL.
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
2. Definitions
Digital certificate
A digital certificate is a document containing the public key that a client will use to
compute key material. It also includes additional information such as the name of
the person (or the organization), a serial number, the issuer, the expiration date, etc.
The purpose of a digital certificate is to ensure a public key belongs to the entity
that claims ownership of it.
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
2. Definitions
Certificate authorities
A Certificate Authority is as a Trusted Third Party between server and client, that
issues and revokes digital certificates.
A CA signs the digital certificate using its private key. Consequently, the certificate’s
signature can only be decrypted using CA's public key.
CAs are considered trustworthy and their public keys are pre-installed into
internet browsers.
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
2. Definitions
Certificate authorities (cont’d)
To solve the practical problem of having a single CA sign all the digital certificates,
CAs are organized in hierarchy.
The root CA signs the certificate of sub-CAs. The sub-CAs can then sign the
certificate of the end-user.
Because of this hierarchical structure, the certificate verification process involves
a chain of certificates, all the way back to a root CA.
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
2. Definitions
Certificate Revocation List
A Certificate Revocation List (CRL) is a list of certificates’ serial numbers that
have been revoked. Entities presenting revoked certificates should not be trusted.
There are two states of revocation, Revoked or Hold.
Issues:
No real-time status check
Required lots of bandwidth
An alternative to using CRLs is the Online Certificate Status Protocol (OCSP).
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
2. Definitions
Message digest
A message digest is a function that takes an input (message) and outputs a fixedlength string (digest value or hash), which can be considered as the characteristic of
the message. This is usually used to ensure that a message was not altered
(integrity)
The function used to calculate a digest value is often called a one-way hash function
and must fulfil two properties:

Irreversibility, which means that given a message, it is easy to compute the
digest value. On the other hand, given a digest value, it is computational infeasible
to recover the original message.

Collision-resistance, which means that it is very difficult to find two messages
with the same digest value.
Example: SHA-1 (160-bit), MD5 (128-bit), SHA-256 (256-bit).
Problem: Message digests are not authenticated. As a result, an attacker
conducting a man in the middle attack can intercept a message and its digest, modify
the message, re-calculate the new digest value and sends it back to the receiving end.
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
2. Definitions
Message Authentication Code
A Message Authentication Code (MAC) is a special digest, which incorporate a
shared secret key into the computation of the digest. The MAC value is dependent on
both the message and the key. Since the key is only known from the two
communicating parties, MAC ensure both integrity and authentication.
MAC can be expressed using the following equations:
 MAC = H(key || message)
or
 MAC = H(message || key)
=> Subject to length-extension attack
=> Subject to collision attack
Hash-based Message Authentication Code (HMAC) was introduced to address
MAC’s shortcomings. HMAC can be expressed using the following equations:
HMAC = H(key1 || H(key2 || message))
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
2. Definitions
Types of SSL certificates
There are several types of SSL certificates:

Domain Validated – DV ($) – no company background checking, just a simple
comparison to the domain whois information before issuing.

Organization Validated – OV ($$) – company background is vetted, site ip/name is
validated.

Extended Validation – EV ($$$) – industry standard certificate guidelines. This will
turn the browser locator bar green and publish company name, as well. Introduced in 2007.

Unified Communications – UC ($$$) – this certificate takes advantage of the Subject
Alternative Name field (SAN) to secure multiple domain names with one certificate.
Microsoft Exchange is a popular application requiring a UC Certificate, as it supports several
names owa.site.com, autodiscover.site.com, cas1.site.com, etc.

Wildcard Certificate ($$$) – this certificate supports any number of subdomains based
on *.site.com but it doesn’t protect site.com. Certain mobile device operating systems don’t
support wildcard certificates (e.g. Windows Mobile 5).

Wildcard Plus ($$$) – this is a combination UCC/Wildcard Certificate. It protects
site.com, *.site.com, and subdomains specified in the several specified Subject Alternative
Name field (SAN).
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
3. SSL / TLS Basics
How SSL/TLS Works ?
The following schema pictures the different phases required to establish a SSL/TLS
session.
Cipher Suite
Negotiation
Handshake
Key Exchange
SSL Session
Data Transfer
The handshaking must be completed before data transfer can take place in a
secure manner.
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
3. SSL / TLS Basics
Cipher suite
Negotiation
Handshake (RSA)
Cipher suites
supported
client_random
1
7
ClientHello
ServerHello
server_random
(also include a session ID)
client_random
7
2
server_random
Cipher suites
selected
Key exchange
certificate
pre_master_secret
5
8
9
Certificate
3
ServerHelloDone
4
certificate
Encrypted
pre_master_secret
ClientKeyExchange
ChangeCipherSpec
6
Private key
ClientFinished
pre_master_secret
ChangeCipherSpec
Session key
ServerFinished
10
Session key
11
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
3. SSL / TLS Basics
Cipher suite
Negotiation
Handshake (Diffie-Hellman)
Cipher suites
supported
client_random
1
8
ClientHello
ServerHello
server_random
(also include a session ID)
client_random
8
2
server_random
Cipher suites
selected
Key exchange
certificate
Server DH params
7
pre_master_secret
6
9
10
Session key
3
ServerKeyExchange
4
ServerHelloDone
Signature
Client DH params
Certificate
certificate
Server DH params
7
5
ClientKeyExchange
Private key
Client DH params
ChangeCipherSpec
pre_master_secret
ClientFinished
ChangeCipherSpec
ServerFinished
11
Session key
12
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
3. SSL / TLS Basics
Abbreviated Handshake
In order to allow performance gains (especially on the server side), it is possible
to abbreviate the handshake by resuming a previously established session.
Cipher suites
supported
client_random
1
ClientHello
ServerHello
server_random
(include the same session ID)
3
4
2
server_random
Cipher suites
selected
ChangeCipherSpec
ClientFinished
ChangeCipherSpec
Session key
client_random
(also include a session ID)
ServerFinished
5
Session key
6
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
3. SSL / TLS Basics
Data Transfer
Once the session key is establish between the client and server, data transfer can
take place in a secure manner.
1
Compressed message
2
Message integrity
secret key
Message integrity
secret key
Hash Message
Authentication Code
Encryption secret
key
Encryption secret
key
5
3
Encrypted data
4
Data Transfer
Encrypted data
Compressed message
6
Hash Message
Authentication Code
Compare HMAC
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
7
3. SSL / TLS Basics
PFS (Perfect forward secrecy)
“If the server’s private key gets exposed, it is possible to
decrypt all exchanges previously recorded.”
There are three versions of Diffie-Hellman used in SSL/TLS.
 Anonymous Diffie-Hellman
The keys used in the exchange are not authenticated. As a result, the protocol is
susceptible to Man-in-the-Middle attacks.
 Fixed Diffie-Hellman
Use the server’s public-key parameters stored in the Certificate. Those parameters
never change. If the server’s private key gets exposed, it is possible to decrypt all
exchanges previously recorded.
 Ephemeral Diffie-Hellman
Each instance or run of the protocol uses a different key. The authenticity of the
server's temporary key can be verified by checking the signature on the key.
Because the keys are temporary, a compromise of the server's private key does not
jeopardize the privacy of past sessions. This is known as Perfect Forward Secrecy
(PFS).
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
3. SSL / TLS Basics
Server Name Indication (SNI)
https://www.secure1.com
?
1
https://www.secure2.com
ClientHello
ServerHello
Certificate
2
3
The Server Name Indication is an extension that was introduced in the TLS 1.0
protocol specification to allow the client to include the requested hostname in the
first message of the handshake (ClientHello). This allows the server to determine
the correct certificate to be used.
https://www.secure1.com
1
https://www.secure2.com
ClientHello (requesting secure1.com)
ServerHello
Certificate
2
3
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
3. SSL / TLS Basics
Renegotiation
Occasionally, client or server may require the establishment of a new SSL session
over an already established SSL connection. For example, SSL renegotiation is
useful when client authentication is required in certain sections of a Website.
/public/
/private/ (requires client cert)
1
ClientHello
...
ServerFinished
GET /public/ HTTP/1.0
11

GET /private/ HTTP/1.0
HelloRequest

ClientHello
ServerHello
...
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4. SSL/TLS weaknesses
4.1 Trust Challenges
 Certificate Authorities
 Trust Store
4.3 Deployment mistakes
 Server side
4.2 Implementation Flaws
 Client Side
 Server side
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.1 SSL/TLS weaknesses
Trust Challenges – Certificate Authorities
In March 2011, a 21 year old Iranian cybercriminal hacked into
InstantSSL.it and recovered a DLL coded in C#. By decompiling
the DLL, he was able to recover clear text credentials to access
Comodo’s signing API.
Source: http://pastebin.com/74KXCaEZ
In July 2011, a large-scale man-in-the-middle attack against
Gmail users in Iran was discovered. Investigations revealed that
the attack used a wildcard certificate for *.google.com issued by
DigiNotar. Further investigation showed that more than 500
fraudulent certificates were issued by Diginotar CA. The same
cybercriminal claimed responsibility for this hack as well as two
other certificate authorities (StartCOM and GlobalSign)
Source: http://pastebin.com/1AxH30em and http://pastebin.com/GkKUhu35
In October 2011, in a SEC filling, Verisign admitted that in 2010,
it suffered several successful security breaches in its
corporate network in which “access was gained to information
on a small portion of [their] computers and servers… Information
stored on the compromised corporate systems was exfiltrated”
Source: http://apps.shareholder.com/sec/viewerContent.aspx?companyid=VRSN&docid=8209064
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.1 SSL/TLS weaknesses
Trust Challenges – Trust Store
In September 2014, several users started to complain on
Lenovo forums about a piece of software installed on recently
purchased laptops.
The software (Superfish – VisualDiscovery.exe), was an adware
software that injected advertising into search engine results.
Further investigation revealed that Superfish performed ads
injection using a SSL interception engine by Komodia.
Specifically, upon installation, it installed a self-signing
certificate authority on affected machines in order to view the
content of any encrypted connections.
The biggest issues relied on the fact that the self signing certificate authority
shared the same secret key among all installations. Within hours, security
researchers recovered the private key of the self signing CA, allowing anyone to
conduct SSL/TLS man-in-the-middle attacks against laptops having Superfish
installed.
Source: https://blog.filippo.io/komodia-superfish-ssl-validation-is-broken/
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.2 SSL/TLS weaknesses
Implementation Flaws – Internet Explorer Basic Constrains - 2002
In May 2002, Moxie Marlinspike discovered that Internet Explorer failed to
properly verify the certificate chain. Specifically, IE didn’t check the Basic
Constraints on intermediate certificates. As a result, it was possible to use a
simple leaf certificate (signed by a valid CA) to sign any other certificates.
Certificate Authority
Sub CA
seralys.com
isaca.org
Note: The same vulnerability was (re)discovered in Apple iOS in July 2011 by Paul
Kehrer (SpiderLabs).
Source: http://www.thoughtcrime.org/ie-ssl-chain.txt
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.2 SSL/TLS weaknesses
Implementation Flaws – MD5 Collision attack - 2008
In 2008, a group of security researchers used a cluster of
200 Playstation 3 devices to practically exploit a known
weakness in the MD5 algorithm.
Specifically, they sent a crafted certificate signing request
to a certificate authority that used MD5 hash function to
generate the certificate signature. Then they created a
rogue intermediary CA certificate that had the same
MD5 hash as the legitimate certificate previously signed.
Because both certificates had the same hash, they were
able to copy the digital signature of the legitimate
certificate into the rogue CA certificate.
Source: http://www.win.tue.nl/hashclash/rogue-ca/
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.2 SSL/TLS weaknesses
Implementation Flaws – Debian predictable random number generator - 2008
In May 2008, Luciano Bello (Debian) discovered that the random number
generator in Debian's openssl package was predictable.
The vulnerability was caused by the removal of a few lines of code in md_rand.c
Removing this code has the side effect of crippling the seeding process for the
OpenSSL PRNG. Instead of mixing in random data for the initial seed, the only
"random" value that was used was the current process ID. On the Linux platform,
the default maximum process ID is 32,768, resulting in a very small number of
seed values being used for all PRNG operations.
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.2 SSL/TLS weaknesses
Implementation Flaws – Null Prefix Attacks - 2009
In July 2009, Moxie Marlinspike discovered that SSL certificates define the
Common Name (CN) as PASCAL strings as opposed to C strings.
Pascal String
Length
I
S
A
C
A
.
O
R
G
NULL
S
E
R
A
L
Y
S
0x11
0x09 0x49 0x53 0x41 0x43 0x41 0x2E 0x4F 0x52 0x47 0x00 0x53 0x45 0x52 0x41 0x4C 0x59 0x53
C String
I
S
A
C
A
.
O
R
G
0x49 0x53 0x41 0x43 0x41 0x2E 0x4F 0x52 0x47
NULL NULL
0x00
S
E
R
A
L
Y
S
0x00 0x53 0x45 0x52 0x41 0x4C 0x59 0x53
One important effect of representing strings as PASCAL is that NULL characters
are treated just like any other characters.
However, most SSL/TLS implementation treated fields obtained from SSL
certificates as C strings. As a result:
www.isaca.org\0.seralys.com == www.isaca.org
PASCAL string
C string
Source: http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.2 SSL/TLS weaknesses
Implementation Flaws – OCSP “Try Again Later” attack - 2009
By design, OCSP responses have to be digitally signed by the CA to avoid forgery.
In July 2009, Moxie Marlinspike discovered that both Windows (schannel) and NSS
implementation of SSL/TLS was treating one non-signed OSCP response as a
successful revocation check. As a result, an attacker conducting man-in-themiddle attack was able to defeat OCSP verification by sending a forged “Try
Again” response (code 3).
1
ClientHello
ServerHello
Certificate
4
3
OCSP Request + Cert Serial #


2
OCSP Response 5
“Revoked” + Signature
OCSP Response
Code 3 (“Try Later”)
Source: http://www.thoughtcrime.org/papers/ocsp-attack.pdf
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.2 SSL/TLS weaknesses
Implementation Flaws – Renegotiation attack - 2009
In 2009, three security researchers (Marsh Ray, Steve Dispensa and Martin Rex)
discovered separately a vulnerability in the SSL renegotiation procedure that
allows an attacker to inject plaintext into the victim’s requests.
Handshake session #1
client <-> server
1
2
3
4
5
Client is authenticated
GET /home
Cookie: QWERTZ
6
Attacker holds the packets
Handshake session #2
attacker <-> server
Attacker sends malicious request
GET /transfer?accnt=LU12345
&amount=999
X-Ignore:
Renegotiation is triggered
Attacker relay
handshake session #1
within session #2
GET /transfer?accnt=LU12345
&amount=999
X-Ignore: GET /home
Cookie: QUERTZ
Source: http://www.g-sec.lu/practicaltls.pdf
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.2 SSL/TLS weaknesses
Implementation Flaws – Heartbleed - 2014
As part of the SSL/TLS protocol, one endpoint can send a heartbeat request to the
other endpoint to ensure that the other end is still alive.
HeartbeatRequest:
Payload: 12345
Payload Size: 65,536
5
Bytes
...secret_key...
1
2
...cookie...
...password...
3
12345......
HeartbeatResponse:
HeartbeatResponse:
Payload: 12345...password
Payload: 12345
...cookie...private_key...
In April 2014, Neel Mehta (Google) discovered that the OpenSSL implementation
of the heartbeat specification, relied on the payload size specified in the request
packet to copy data from memory into the response packet.
Source: http://heartbleed.com/
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.2 SSL/TLS weaknesses
Implementation Flaws – Early ChangeCipherSpec Attack (CCS) - 2014
In June 2014, Masashi Kikuchi discovered that OpenSSL accepted
ChangeCipherSpec inappropriately during a handshake.
Cipher suite
Negotiation
As a result, if a ChangeCipherSpec message is injected into the connection after the
ServerHello, but before the master secret has been generated, then OpenSSL would
generate the keys and the expected Finished hash for the handshake with an
empty master secret.
Cipher suites
supported
client_random
ClientHello
client_random
ServerHello
server_random
ChangeCipherSpec
(also include a session ID)
ChangeCipherSpec
Certificate
Key exchange
certificate
pre_master_secret
ServerHelloDone
server_random
Cipher suites
selected
certificate
Encrypted
pre_master_secret
ClientKeyExchange
ChangeCipherSpec
Private key
ClientFinished
pre_master_secret
ChangeCipherSpec
Session key
ServerFinished
Session key
Source: http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.2 SSL/TLS weaknesses
Implementation Flaws – iOS Signature verification - 2014
In Feb 2014, Apple released a security update for iOS indicating “An attacker with a
privileged network position may capture or modify data in sessions protected by
SSL/TLS”.
A basic programmatic error caused the signature verification to never fail in
the SecureTransport implementation of SSL, allowing an attacker to conduct manin-the-middle attacks against all Apple devices.
if ((err
goto
if ((err
goto
if ((err
goto
if ((err
goto
if ((err
goto
goto
if ((err
goto
= SSLFreeBuffer(&hashCtx)) != 0)
fail;
= ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
fail;
= SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
fail;
= SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
fail;
= SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
fail;
fail;
= SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
fail;
err = sslRawVerify(...);
Source: https://www.imperialviolet.org/2014/02/22/applebug.html
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.2 SSL/TLS weaknesses
Implementation Flaws – Winshock (CVE-2014-6321) - 2014
In Nov 2014, as part of the an internal security assessment, Microsoft discovered a
heap overflow in the function schannel!DecodeSigAndReverse of their SSL
implementation (i.e. Schannel).
The function is responsible for decoding the encoded client certificate
signature. By sending a specially crafted client certificate, an attacker could trigger
this vulnerability that may result in remote code execution.
Note: It was also discovered that vulnerable IIS servers process a client certificate
that is forcefully presented regardless of the configured SSL settings.
Source: http://www.securitysift.com/exploiting-ms14-066-cve-2014-6321-aka-winshock/
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.3 SSL/TLS weaknesses
Deployment mistakes – HTTP/HTTPS redirect (ssl-strip) - 2009
In 2009, Moxie Marlinspike presented an attack that targeted the transition from
non-encrypted to encrypted communication (HTTPS redirect) and released a
tool (SSL-STRIP) to automate this attack.
HTTP Connection
(tcp/80)
Modified
HTTP Response
Non-encrypted
communication
1
2
3
HTTP Connection
(tcp/80)
Redirect to
HTTPS(tcp/443)
Encrypted
communication
HTTP Strict Transport Security (HSTS) specification was published in Nov 2012
to address this weakness. To activate HSTS protection, a single response header
(Strict-Transport-Security) in the websites is required. After that, browsers that
support HSTS (at this time, Chrome and Firefox) will enforce the protection.
Source: http://www.thoughtcrime.org/software/sslstrip/
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.3 SSL/TLS weaknesses
Deployment mistakes – POODLE (Padding Oracle On Downgraded Legacy Encryption)
Between 2011 and 2013, several security researchers described various attacks
exploiting cryptographic oracles to recover small fragments of information
from an encrypted data flow, including:
 BEAST (Browser Exploit Against SSL/TLS) – 2011
 CRIME (Compression Ratio Info-leak Made Easy) – 2012
 BREACH (Browser Recon. & Exfilt. via Adaptive Compression of Hypertext) –
2013
In Oct 2014, security researchers from Google described the most practical attack
that could allow an attacker to use padding oracle in order to recover 1 byte of
cleartext information for every 256 requests sent to a server. The issue lays on
the fact that when using block cipher, SSLv3 does not verify the integrity of the
padding added to the last block.
Source: https://www.openssl.org/~bodo/ssl-poodle.pdf
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.3 SSL/TLS weaknesses
Deployment mistakes – POODLE (Padding Oracle On Downgraded Legacy Encryption)
To exploit this vulnerability an attacker simply copies the value of a chosen block
into the last block (holding the padding). Upon decryption of the padding block,
the server will take the last byte and remove the associated number of bytes
(padding). If the server accepts the modified packet, we know that the last byte of
the chosen block decrypts to the same as the size of the padding.
SSLv3

HTTPS request
Modify padding
TLS 1.0
1
2

Reject request
HTTPS request
Response
3
4
Modify padding
Response


Source: https://www.openssl.org/~bodo/ssl-poodle.pdf
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.3 SSL/TLS weaknesses
Deployment mistakes – POODLE (Padding Oracle On Downgraded Legacy Encryption)
Block1
Block2
Block3
Block4
IV
GET / HT
TP/1.0\r\n
Cookie:
123ABCDE
008FE5E0
488BAC80
64186083
3635BEF3
260F1290
6A54C812
Decrypt
(D)
008FE5E0
D2A2AE12
=
0000007

260F1290
Decrypt
(D)
18BAB3B8
D2A2AE12
=
CA181DAA

Block1
Block2
Block3
Block4
IV
GET / HT
TP/1.0\r\n
Cookie:
123ABCDE
F1238DC1
252EC977
5E86306D
75D5E406
F47FADE4
Block5
HMAC
\r\n\r\nxxxx A039D27C
7CE0AC35
Block5
D2A2AE12
HMAC
\r\n\r\nxxxx A039D27C
BE4BD04A
5F5FB39F
F47FADE4
Decrypt
(D)
67EF58D8
5F5FB39F
=
38B0EB47
F47FADE4
Decrypt
(D)
67EF58D8
75D5E406
=
123ABCDE
Block1
Block1
Block1
Block2
GET /a H
TTP/1.0\r
\nCookie:
123ABCD
Padding
Block3

HMAC
E\r\n\r\nxxx 90A8D225
00000007
6A54C812
Padding
00000007
F47FADE4
F
7
=
8
8
6
=
E
Padding
00000007
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4.3 SSL/TLS weaknesses
Deployment mistakes – FREAK (Factoring Attack on RSA-EXPORT Keys) – 2015
In March 2015, a group of cryptographers from INRIA, Microsoft and IMDEA
discovered a vulnerability in most of the SSL/TLS implementations that allows
an attacker, who is able to intercept SSL/TLS connections between vulnerable clients
and servers, to force them to use a weakened RSA encryption (512 bits). The
attacker can then break the encryption in less than 7 hours to steal or
manipulate exchanged data.
ClientHello requesting
Standard RSA cipher suite
1
2
Encrypted
pre_master_secret
ClientHello requesting
“Export” RSA cipher suite
Response using weak
512-bit RSA key
Attacker recover the private
key using factoring attack
3
Attacker decrypt pre_master_secret
and calculate session key
Data Transfer
4
Data Transfer
Attacker use session key to
decrypt all traffic
Source: https://www.smacktls.com/
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
Methodology
Retrieve names of financial
institution from CSSF
supervised entities list
Use preferred search engine to
identify public and
authenticated websites
Compile a list of gathered URLs
Use SSL Labs to perform tests
on identified URLs
Combine results and compare
with top 1M websites
159 Banks
109 Investment firms
10 Payment institutions
6 Electronic money institutions
126 SSL/TLS secured URLs
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
Methodology
For the purposes of this survey, we’ve followed SSL Labs methodology. The
analysis was performed as follows:
1. Verify that the certificate is valid and trusted (if this fails, final score is zero)
2. Inspect Protocol support (30% of the final score)
3. Inspect Key exchange support (30% of the final score)
4. Inspect Cipher support (40% of the final score)
The final score (between 0 and 100) is a combination of the scores achieved in the
individual categories. A zero score in any category forces the total score to zero.
Lastly, because the devil is in the details and to avoid
too much granularity in the results, we’ve used the
following table to translate the numerical score into
a letter grade. This also allowed us to compare our
results with the top 1M Website published on
https://www.trustworthyinternet.org
Score
Grade
>= 80
A
>= 65
B
>= 50
C
>= 35
D
>= 20
E
< 20
F
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
SSL Labs grade distribution
Jul. 2015
Jul. 2015
Top 1M Websites
Luxembourg Financial Inst.
A+
2%
A+
2% (3)
A
15%
A
16% (20)
A4%
A10% (12)
Inadequate
security
79%
Inadequate
security
72% (91)
Jul. 2015
Jul. 2015
Top 1M Websites
37%
(46)
32%
21%
Luxembourg Financial Inst.
28%
(35)
24%
23%
22%
(28)
13%
(17)
A
B
C
D
F
A
B
C
D
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
F
5. Survey Findings
Protocol support
There are five protocols in the SSL/TLS family, but not all of them are secure.
The best practice is to use TLS v1.0 as preferred protocol and TLS v1.1 and v1.2 if
they are supported by the server platform. That way, the clients that support
newer protocols will select them, and those that don’t will fall back to TLS v1.0.
You must not use SSLv2 and SSLv3, because it is insecure.
Jul. 2015
Jul. 2015
Top 1M Websites
Luxembourg Financial Inst.
100%
(126)
100%
62%
63%
(79)
64%
36%
25%
(32)
12%
SSLv2
69%
(87)
4%
(4)
SSLv3
TLS 1.0
TLS 1.1
TLS 1.2
SSLv2
SSLv3
TLS 1.0
TLS 1.1
TLS 1.2
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
Cipher Strength
When it comes to data transfer, cipher strength is the measure of the
security of the communication channel. Ciphers weaker than 128 bits
are insecure and must not be used.
Jul. 2015
Jul. 2015
Top 1M Websites
Weak or
Insecure
16%
Luxembourg Financial Inst.
Insecure
4%
Secure
72%
Secure
84%
Weak
24%
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
Certificate Signature Algorithms
The strength of a certificate signature depends on the strength of the hashing
function used to produce it.
Most certificates use SHA1 for hashing, but this function is known to be weak. It is
advisable to use signatures that use SHA256 for hashing.
Jul. 2015
Jul. 2015
Top 1M Websites
SHA1
36%
SHA256
46% (57)
Luxembourg Financial Inst.
SHA1
54% (69)
SHA256
64%
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
Renegotiation Support
In 2009, the renegotiation feature of SSL was found to be insecure. A successful
exploitation of this issue may allow the attacker to impersonate his victims and
extract confidential data.
Jul. 2015
Jul. 2015
Top 1M Websites
Insecure
renegotiation
3%
No support
3%
Secure renegotiation
94%
Luxembourg Financial Inst.
Insecure
renegotiation
2% (2)
No support
7%
Client initiated
secure renegotiation
24% (31)
Secure
renegotiation
67%
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
Strict Transport Security
HTTP Strict Transport Security (HSTS) is an SSL safety net designed to ensure
that security remains intact even in the case of configuration problems and
implementation errors.
Even though HSTS was introduced in 2012, the vast majority of SSL/TLS enabled
websites don’t use it.
Jul. 2015
Jul. 2015
Top 1M Websites
HSTS enabled
4%
HSTS not enabled
96%
Luxembourg Financial Inst.
HSTS enabled
10% (12)
HSTS not enabled
90% (114)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
Forward Secrecy
Forward Secrecy is a protocol feature that protects each connection
individually. It is designed so that it is impossible to compromise connection
security by compromising the server private key.
Jul. 2015
Jul. 2015
Top 1M Websites
Supported in most
browers
17%
Supported in
modern browsers
16%
Some FS suites
enabled
35%
Not supported
32%
Luxembourg Financial Inst.
Supported in most
browers
8% (10)
Supported in
modern browsers
18% (23)
Not supported
48% (60)
Some FS suites
enabled
26% (33)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
BEAST Attack
The BEAST attack is a practical attack based on a protocol vulnerability that was
discovered in 2004. A successful exploitation of this issue will result in a
disclosure of victim's session cookies, allowing the attacker to completely hijack
the application session.
Despite having been addressed in TLS v1.1 in 2006, the problem is still relevant
because most clients and servers do not support newer protocol versions.
Jul. 2015
Jul. 2015
Top 1M Websites
Luxembourg Financial Inst.
Not Vulnerable
15% (19)
Not Vulnerable
14%
Vulnerable
86%
Vulnerable
85% (107)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
4. Survey Findings
TLS Compression / CRIME
As shown in the CRIME attack, TLS compression can be used as a compression
oracle to recover small fragments of encrypted data (e.g. cookie).
Disabling TLS compression is the only effective way to prevent the CRIME attack.
Jul. 2015
Jul. 2015
Top 1M Websites
TLS compression
supported
2% (3)
TLS compression
supported
5%
TLS compression
disabled
95%
Luxembourg Financial Inst.
TLS compression
disabled
98% (123)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
POODLE
The POODLE attack affects SSLv3 but also some TLS implementations that don't
have proper padding checks after decryption. The end result is that an active
network attacker can relatively easily recover small fragments of encrypted
data (e.g., cookies).
Jul. 2015
Jul. 2015
Top 1M Websites
Vulnerable
SSLv3
25% (32)
Vulnerable
SSLv3
36%
Not vulnerable
60%
Vulnerable TLS
4%
Luxembourg Financial Inst.
Not vulnerable
68% (103)
Vulnerable TLS
7% (14)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
Extended Validation Certificates
Extended Validation certificates (EV) are high-assurance certificates that rely
on manual identity validation to establish links between web sites and the
organizations behind them.
Jul. 2015
Jul. 2015
Top 1M Websites
Luxembourg Financial Inst.
Extended Validation
Certificates
10%
No Extended
Validation Certificates
90%
Extended Validation
Certificates
48% (60)
No Extended Validation
Certificates
52% (66)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
5. Survey Findings
Certificate lifetime & Issuer
Jul. 2015
Jul. 2015
Luxembourg Financial Inst.
Luxembourg
41%
(52)
Symantec
36%
(45)
VeriSign
17%
25%
GlobalSign
6%
18%
(23)
Thawte
8%
COMODO
21%
10%
1%
(1)
3 mo
3%
(4)
1%
(1)
1 year 2 years 3 years 4 years 5 years 6 years
LuxTrust
13%
Others (Geotrust, Entrust,
DigiCert, Verizon,
Cybertrust, etc.)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
6. Conclusion
SSL/TLS is a deceptively simple technology
Easy to deploy
Not easy to get properly configured
To ensure that TLS provides the necessary security, extra effort is required:
System Administrators
Developers
 Protect private keys
 Disable SSLv2 and SSLv3
 Encrypt 100% of your Web site / Avoid
mixed content
 Use secure cipher suites
 Secure cookies
 Disable client-initiated renegotiation
 Disable caching of sensitive content
 Avoid SHA1 as certificate signature
 Deploy HTTP strict transport security
 Support forward secrecy (prefer ECDHE)
 Prefer extended validation certificates
 Disable TLS compression
 Consider public key pinning
 Ensure that session resumption works
correctly
Test your Web sites regularly (https://www.ssllabs.com/ssltest/)
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
7. Appendix
Issue
Manual check
Insecure result
Secure result
Comments
SSLv2
openssl s_client -ssl2 -connect host:port
It connects!
It doesn't connect!
OpenSSL <1.0.0
SSLv3
openssl s_client -ssl3 -connect host:port
It connects!
It doesn't connect!
Disable to prevent POODLE attack
TLS > v1.0
openssl s_client -tls1_1 -connect host:port
openssl s_client -tls1_2 -connect host:port
It doesn't connect!
It connects!
OpenSSL >1.0.0
Secure renegotiation
supported
openssl s_client -connect host:port
OpenSSL output reports
"Secure Renegotiation IS
NOT supported"
OpenSSL output reports
"Secure Renegotiation IS
supported"
OpenSSL >0.9.8l
If it's not supported but clientinitiated renegotiation is disabled
then it's not an issue
Client-initiated secure
renegotiation enabled
openssl s_client -connect host:port
HEAD / HTTP/1.0
R
<CRLF>
Renegotation succeeds at R
HTTP response returned
Renegotiation fails at R
OpenSSL >0.9.8l
Add -crlf if HTTP response not
returned
Renegotation succeeds at R
HTTP response returned
Renegotiation fails at R
OpenSSL <0.9.8l (BackTrack 5 R3
had a patched v0.9.8k that worked)
Add -crlf if HTTP response not
returned
OpenSSL output reports
"Server public key is "
<=1024 " bit"
OpenSSL output reports
"Server public key is " >1024
" bit"
openssl s_client -connect host:port
Client-initiated insecure HEAD / HTTP/1.0
R
renegotiation
<CRLF>
Public key size <= 1024bit
OCSP Stapling
openssl s_client -connect host:port
openssl s_client -status -tlsextdebug connect site:port
Cert status: revoked or
unknown (invalid test)
Cert status: good
RFC2560: good means "the
certificate is not revoked, but does
not necessarily mean that the
certificate was ever issued or that
the time at which the response was
produced is within the certificate's
validity interval"
Source: http://www.exploresecurity.com/wp-content/uploads/custom/SSL_manual_cheatsheet.html
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
7. Appendix
Issue
Invalid certificate when
Server Name Indication
(SNI) missing
Manual check
Compare certificate returned from openssl
s_client -connect site:port with and
without -servername <HOSTNAME> option
Insecure result
Secure result
Invalid certificate returned
without -servername option
Valid certificate returned
without -servername option
-ssl3 should show same result as
test without -servername
Connection fails
If successful, this will only prove
that one of possibly many such
ciphers is supported: tools are
more comprehensive
Use just EXPORT to check for
exposure to FREAK
Connection fails
If successful, this will only prove
that one of possibly many such
ciphers is supported: tools are
more comprehensive
Weak cipher suites
openssl s_client -cipher
NULL,EXPORT,LOW,3DES -connect site:port
Connection succeeds with
<128-bit or Triple DES cipher
Anonymous cipher
suites
openssl s_client -cipher aNULL -connect
site:port
Connection succeeds
Server preference
openssl s_client [-ssl2|ssl3|tls1|tls1_1|tls1_2] -cipher <CIPHERS> connect site:port
Change the order of CIPHERS to change
client preference e.g.DEFAULT:+RC4 will
make RC4 ciphers in the default set
the leastpreferred
A preferred cipher will be
selected irrespective of
client's preference
Forward Secrecy
openssl s_client -cipher EDH,EECDH -connect Unsupported
site:port
Supported but not preferred
RC4
openssl s_client -cipher RC4 -connect
site:port
Connection succeeds
Comments
Only insecure if preferred cipher is
weak
Supported and preferred
OpenSSL >=1.0.0 (later versions will
tend to support more ephemeral
ciphers)
Connection fails
If successful, this will only prove
that one of possibly many such
ciphers is supported: tools are
more comprehensive
Source: http://www.exploresecurity.com/wp-content/uploads/custom/SSL_manual_cheatsheet.html
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
7. Appendix
Issue
Manual check
Insecure result
Secure result
Comments
CRIME
openssl s_client -connect site:port
OpenSSL output
"Compression:" line is not
"NONE", e.g. "zlib
compression"
OpenSSL output
"Compression: NONE"
Ensure the OpenSSL version in use
supports compression: check Client
Hello in Wireshark for a list of
Compression Methods
CRIME (SPDY)
openssl s_client -nextprotoneg NULL connect site:port
Examine OpenSSL output "Protocols
advertised by server"
Protocol list includes SPDY
version <4
No "Protocols advertised by
server" or line does not
include SPDY version <4
SPDY version 4 said to address the
problem but not yet released
Heartbeat enabled
openssl s_client -tlsextdebug -connect
site:port
OpenSSL reports "TLS server
extension heartbeat"
Heartbeat disabled
OpenSSL >=1.0.1
Heartbleed
nmap -p 443 --script ssl-heartbleed <target>
Change Cipher Spec
(CCS) flaw
nmap -p 443 --script ssl-ccs-injection <target>
POODLE
For SSL, check for SSLv3 (above)
For TLS, https://github.com/exploresecurity/test_poodle_tls/blob/master/test_poodle_tls.py
TLS_FALLBACK_SCSV
support
openssl s_client -ssl3 -fallback_scsv -connect
site:port
It connects
-ssl3 specifically with POODLE in mind but
it's bigger than that
It fails with "inappropriate
fallback" alert
OpenSSL >=1.0.1j
See my other posts for more info.
Source: http://www.exploresecurity.com/wp-content/uploads/custom/SSL_manual_cheatsheet.html
© Copyright 2015 Seralys. All rights reserved. No part of this presentation in all its property may be used or reproduced in any form without a written permission.
Contact: Philippe Caturegli
Mobile: +352 621 494 692
E-Mail: [email protected]
Website: www.seralys.com