Why “It’s over TLS” is not good enough

Why “It’s over TLS” is not good enough
An introduction to TLS with some Do’s and Don’ts to improve TLS
connection security
April 2018

M. Hooper [April 2018, v1.0]
2
Introduction
●
Who am I?
– Matt Hooper
●
https://www.linkedin.com/in/matthewhooper1/
– Software Engineer and Security Advocate
●
Why make these slides?
– This deck is a combination of a few smaller presentations that I’ve merged together with the hopes that it proves useful as both a
learning resource and future point of reference
●
What will I cover?
– Cryptography Primer
– Introduction to TLS
– Certifcates and Public Key Infrastructure (PKI)
– 7 things to remember – Do’s and Don’ts
– Tools and Testing

3
Why should we care?
●
Communication security is hugely important
– Just think of all the Personal, Medical, Financial, Social, IoT, Proprietary and Government communication on the Internet these days
and how it all needs protecting
– “With one in ten adults now falling victim to cyber crime, it is clear that the uptake of connected products and services will only
increase the attack surface” [49]
●
TLS is often used as “the answer” to securing all communications
– It’s the responsibility of the person coding / deploying the TLS enabled service to ensure that it is secure but too often default
confgurations are used which are not hardened
– Many protocols rely completely on the protection of the TLS connection; a good example being OAuth2 [77]
– “It doesn’t matter if we send the password in plain-text; it’s over TLS”
I’ve heard this before and it’s certainly true that TLS can provide a great deal of protection for data “on the wire” but if you’ve
skipped the above hardening step then the resulting connections may not be as secure as you think...

4
Cryptography Primer

5
Cryptography Primer – What is Encryption?
●
What is Encryption?
– “Data encryption translates data into another form, or code, so that only people with access to a secret key (formally called a
decryption key) or password can read it. Encrypted data is commonly referred to as ciphertext, while unencrypted data is called
plaintext. Currently, encryption is one of the most popular and efective data security methods used by organizations. Two main
types of data encryption exist - asymmetric encryption, also known as public-key encryption, and symmetric encryption.” [50]
●
Encryption provides confientiality [52]
●
Two forms
– Symmetric (1 key)
– Asymmetric (2 keys)
●
TLS utilises both Symmetric and Asymmetric encryption
Image: https://www.linkedin.com/pulse/cia-triad-jubran-alloghbi

6
Cryptography Primer – Symmetric Encryption
●
Same key used for both encryption and decryption [1]
– Introduces a key distribution problem
●
Two types – Stream and Block
– Stream ciphers [2] encrypt a stream bit by bit
– Block ciphers [3] take a number of bits and encrypt them as a block
●
Block ciphers can have diferent operating modes
– These modes defne how each block is handled
●
e.g. independently or chained with the previous block
– Common modes
●
Cipher Block Chaining (CBC) [4]
●
Counter Mode (CTR) [5]
●
Counter Mode with CBC-MAC (CCM) [6]
●
Galois-Counter Mode (GCM) [7]
– Form of Authenticated Encryption with Associated Data (AEAD) [8, 39, 76]
●
TLS can use symmetric encryption ciphers for data encryption to provide confdentiality
Image: http://msdn.microsoft.com/en-us/library/f650720.aspx

7
Cryptography Primer – Asymmetric Encryption
●
Also known as Public Key Encryption [9]
●
Uses a key pair – one Public and the other Private
– Encrypt with one, decrypt with the other
– Solves the key distribution problem from symmetric encryption
●
Data encrypted with the Public key can only be decrypted
with the Private key
– Provides confdentiality
– Allows you to publish your Public key and receive secure messages as only you have the
Private key to decrypt them
●
Data encrypted with the Private key can only be decrypted with
the Public key
– Provides proof of authorship but not confdentiality
– As only you have the Private key only you could have encrypted the message
– Does not provide confdentiality as anyone can have your Public key and decrypt the message

8
Cryptography Primer – Asymmetric Encryption
●
Asymmetric ciphers are often slower than symmetric ciphers
●
Keys are typically larger than for symmetric ciphers
– e.g. 3072bit RSA (asymmetric) ≈ 128bit AES (symmetric) [10, 41]
●
TLS can use asymmetric ciphers for authentication and/or key
exchange

9
Cryptography Primer – Digests
●
Also known as a Hash [11]
– e.g. SHA-256 [29]
●
A deterministic, one way function that produces a given output for a given input where a small
change to the input has a large change to the output
●
Typically the output is short and fxed length, regardless of the size of the input
●
A cryptographic digest has 4 signifcant properties
– Easy (but not necessarily quick) to compute the hash value for any given message
– Infeasable to generate a message that has a given hash
– Infeasable to modify a message without changing the hash
– Infeasable to fnd two diferent messages with the same hash; this is known as a collision
●
TLS uses digest algorithms to provide integrity

10
Cryptography Primer – Digital Signatures
Image: https://en.wikipedia.org/wiki/Digital_signature
●
Combination of Asymmetric encryption and Digests [12]
●
Author computes digest of data and then that
digest is encrypted with the authors Private key
to produce the Signature
– Provides proof of authorship as only the author has their Private key
– Provides message integrity as the hash can be verifed by the recipient
●
Recipient decrypts the signature with the authors
Public key resulting in the original digest value which
is then compared with the digest they compute of the
received message
– If the signature decrypts then it must be from the author
– If the digest values match then the message has not been tampered
with

11
Cryptography Primer – Elliptic-Curves
●
Can be used for key agreement, pseudo-random number generation and digital signatures [13]
●
More efcient with equivalent security from smaller keys than traditional algorithms such as
RSA
●
Uses
– Elliptic-Curve Dife-Hellman (ECDH) [31] can be used for key agreement
– Elliptic-Curve Digital Signature Algorithm (ECDSA) [30] for digital signatures
– Elliptic-Curve cryptography combines Elliptic-Curve key agreement and symmetric encryption
●
TLS can use elliptic-curves for key agreement and/or digital signatures

12
Transport Layer Security

13
Introduction to TLS
●
Transport Layer Security [15]
– Often still referred to as Secure Sockets Layer (SSL) for historical reasons
●
Designed for confientiality and integrity
●
TLS is best thought of as an extensible negotiation protocol
– You can negotiate strong encryption
– You can negotiate authentication
– You can negotiate secure key agreement and forward secrecy
– These are all optional
●
Yes, encryption is optional
●
Easy to deploy but harier to ieploy securely
– Complicated protocols and ecosystem with a lot of scope for mistakes leading to a large attack surface

14
Introduction to TLS – Threat Model
Image: https://www.ssllabs.com/downloads/SSL_Threat_Model.png

15
Introduction to TLS – History
●
Before there was TLS, there was SSL
●
SSLv1, Secure Sockets Layer, not released
●
SSLv2 released by Netscape in 1994
– Do NOT use
– Prohibited in RFC6176 [17]
●
SSLv3 (RFC6101 [16]) released in 1995
– Do NOT use
– Deprecated in RFC7568 [18]
Image: https://www.slideshare.net/danrlde/20120418-luedtke-ssltlscbcbeast

16
Introduction to TLS – History
●
TLS, Transport Layer Security, Working Group formed in 1996
●
TLSv1.0 (RFC2246 [19]) released in 1999
– Not compatible with SSL but there is a downgrade mechanism
●
– Added CBC cipher mode improvements, due to the POODLE
attack [22, 23] (explicit initialisation vector), and padding changes
●
– Extensions added
– MD5-SHA1 psuedorandom function replaced with SHA-256
– Signature digest now negotiated
– Added support for AEAD ciphers, such as GCM and CCM modes

17
Introduction to TLS – Present (almost)
●
TLSv1.3 (draft-ietf-tls-tls13-28 [34])
– Prunes “legacy” symmetric algorithms
– “The ciphersuite concept has been changed to separate the authentication and key exchange mechanisms from the record
protection algorithm (including secret key length) and a hash to be used with the key derivation function and HMAC.” [34]
– Static RSA and DH cipher suites removed so all public key based mechanisms now provide forward secrecy
– All handshake messages after the ServerHello are encrypted
●
One advantage is that Certifcates are now protected during the handshake which removes the information leak
– Elliptic-curve algorithms now included in the base specifcation
– Version negotiation has been changed to an explicit list
– 0-RTT handshake option available but at the cost of certain security properties

18
Introduction to TLS – Handshake Protocol
Image: Bulletproof SSL and TLS, Feisty Duck publishing [14]
●
The Handshake Protocol is responsible for negotiating a
session
●
“The TLS Handshake Protocol involves the following
steps:
– Exchange hello messages to agree on algorithms, exchange random
values, and check for session resumption.
– Exchange the necessary cryptographic parameters to allow the client and
server to agree on a premaster secret.
– Exchange certifcates and cryptographic information to allow the client and
server to authenticate themselves.
– Generate a master secret from the premaster secret and exchanged
random values.
– Provide security parameters to the record layer.
– Allow the client and server to verify that their peer has
calculated the same security parameters and that the
handshake occurred without tampering by an attacker.” [21]

19
Introduction to TLS – Handshake Protocol
Image: Bulletproof SSL and TLS, Feisty Duck publishing [14]
●
Keys need to be exchanged / agreed
– Both Client and Server need a symmetric (Master) key but this obviously
can’t be sent plain-text in the handshake
– Enter the Master and PreMaster Secrets…
●
PreMaster Secret
– Secret data exchanged / agreed between client and server
– RSA key exchange
●
When RSA key exchange has been used, the PreMaster Secret is generated
by the client and sent to the server encrypted with the servers public key
– Dife-Hellman
●
When DH key agreement has been used the result of the DH exchange is
used as the PreMaster Secret
●
Master Secret
– Derived from the PreMaster Secret and other data in the
handshake
– Encryption and Hashing keys are generated from the Master
secret

20
Introduction to TLS – Record Protocol
●
Responsible for chunking messages, bulk data encryption and integrity
●
Base protocol for messaging
– “The Record Protocol takes messages to be transmitted, fragments the
data into manageable blocks, optionally compresses the data, applies a
MAC, encrypts, and transmits the result. Received data is decrypted,
verifed, decompressed, reassembled, and then delivered to higher-level
clients.” [21]
●
Connection states
– “A TLS connection state is the operating environment of the TLS Record
Protocol. It specifes a compression algorithm, an encryption algorithm,
and a MAC algorithm. In addition, the parameters for these algorithms
are known: the MAC key and the bulk encryption keys for the connection
in both the read and the write directions.” [21]
●
Records
– “The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client
message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be fragmented across several records).” [21]

21
Introduction to TLS – Protocol Versions
●
Handshake
– TLS protocol version is negotiated between Client and Server
– ClientHello version
●
Maximum TLS protocol version supported by the client
– e.g. 0x0303 is TLSv1.2
– ServerHello version
●
Selected TLS protocol version number for the negotiation
●
Ideally, the highest common version between Client and Server
●
Records
– The record layer is also versioned so that the Client and Server use the same record format
– Versioning independent of the TLS protocol version

22
Introduction to TLS – Cipher Suites
●
Cipher suites defne which algorithms a connection uses
●
For example, the cipher suite ECDHE-RSA-AES256-GCM-SHA384 (OpenSSL format [54]) can be
read as
– Ephemeral Elliptic-Curve Dife-Hellman (ECDHE) Key Agreement
●
Alternatives include regular Dife-Hellman (DH) and RSA key exchange
– RSA based Authentication
●
Alternatives include Elliptic-Curve Digital Signature Algorithm (ECDSA) and Pre-Shared Keys (PSK)
– AES encryption with a 256bit key (AES256) as the Symmetric Cipher (data encryption scheme)
●
Alternatives include Cammellia, 3DES, AES-128
– Galois-Counter Mode (GCM) as the Symmetric Cipher Mode
●
Alternatives include CBC, CCM
– SHA-384 digest for the Message Authentication Code (integrity protection)
●
Alternatives include SHA-256, AEAD schemes

23
Introduction to TLS – Cipher Suites
●
Examples of available cipher suites from OpenSSL
– Example NULL algorithms highlighted in Red
– Example weak algorithms highlighted in Orange

24
Introduction to TLS – Forward Secrecy
●
“Forward Secrecy or Perfect Forward Secrecy is a property of a cipher suite that ensures
confdentiality even if the server key has been compromised. Thus if trafc has been recorded
it cannot be decrypted even if an adversary has got hold of the server key” [44]
●
Mitigates future key compromise
– e.g. If you’re using RSA keys in your certifcates and a cipher suite that uses RSA key exchange then the pre-master secret is
protected by the RSA key when it is sent over the wire. If the RSA keys are later obtained from the server, previously captured trafc
can be decrypted – you have no forward secrecy
●
Ephemeral Dife-Hellman uses a unique key per session to provide Forwari Secrecy
– Ephemeral Dife-Hellman (EDH or DHE)
– Ephemeral Elliptic-Curve Dife-Hellman (EECDH or ECDHE)
●
Real world problems
– HeartBleed [45] vulnerability
●
A problem with OpenSSLs implementation of the TLS Heartbeat extension
●
Can be exploited to retrieve memory (from client or server)
●
Stolen memory could include private keys allowing decryption of the pre-master secret and therefore any captured trafc

25
Certifcates and Public Key Infrastructure

26
Certifcates and PKI
●
Certifcates are probably the most commonly used form of authentication for TLS connections
– Typically you see the Client authenticate the Server
●
Server sends its certifcate to the client
●
Client authenticates the server using the Public Key in the server’s certifcate
●
The Server doesn’t authenticate the client
– Mutual TLS is where the Server also requests a certifcate from the Client
●
Client authenticates server as before
●
Server requests a certifcate from the client
●
Server receives a certifcate from the client so it can perform authentication too

27
Certifcates and PKI – What is a Certifcate?
●
Certifcates
– The standard for digital certifcates is X.509v3 [48]
– Basically a container for a public key
– Carries meta data about who/what the certifcate was issued to, when it can be used and how
●
Uses include Server, Client, E-mail and Software Signing
– Issuer digitally signs the certifcate as proof of issuance
– Can be used for key exchange, when using RSA keys, but this does not provide Forward Secrecy
●
Certifcates require some management – an issuer, way to revoke, etc. - which is where Public
Key Infrastructure comes into play

28
Certifcates and PKI – What is PKI?
●
“A public key infrastructure (PKI) is a set of roles, policies, and procedures needed to create,
manage, distribute, use, store, and revoke digital certifcates and manage public-key
encryption” [78]
●
PKI revolves around a trusted third party model
– If a client trusts the third party then it trusts any certifcates and revocation information issued by
that third party
– Third party roles
●
Registration Authority (RA)
– Responsible for ensuring the binding between user identity and public key
– Should perform enough checks to stop an attacker obtaining a certifcate for
someone elses domain
– Usually rolled into the Certifcate Authority
●
Certifcate Authority (CA)
– Responsible for issuance, handling and revocation of certifcates
– Primary role of a CA is to digitally sign and publish the public key bound to a user
– CA uses it's own private key for signing
– Trust of certifcate relies upon the trust of the CA

29
Certifcates and PKI – Certifcate Chains
●
Certifcate Authorities issue certifcates to the end entity (i.e.
user or server)
– Common practice not to issue from the Root CA and to segment issuance through the
use of subordinate CAs
– In this example, the Root CA has sub-CAs for diferent geographic regions and they in
turn have sub-CAs for organisational departments
– Here the end entity certifcate is issued by the Engineering CA in the USA
●
To verify a certifcate you need to follow the chain back to the
Root CA
– Ensure that each certifcate is valid and correctly signed by its parent
– If you successfully reach the Root and you trust the Root CA then you can trust the
certifcate you’re verifying
– Note that this verifcation is a tad more complicated in real life!
Image: https://docs.oracle.com/cd/E19316-01/820-2765/gdzeb/index.html

30
Certifcates and PKI – Expiration and Revocation
●
Certifcates have expiration dates but can also be revoked
– Revoking a certifcate marks it as untrusted
– Useful in cases where the keys or CA have been compromised long before the certifcate is due to expire
– When a certifcate is revoked it can no longer be trusted; if it is a CA certifcate this also holds true for all the certifcates that it has
issued (i.e. everything lower in the chain)
●
Note that it’s the responsibility of the device that’s verifying a certifcate to also check revocation status
●
Two revocation mechanisms
– Certifcate Revocation Lists (CRL)
– Online Certifcate Status Protocol (OCSP)

31
●
Certifcate Revocation List (CRL) [72]
– File containing a list of serial numbers for revoked certifcates
●
Includes details of when the certifcates were revoked and a reason
– Designed for ofine processing by the device performing certifcate verifcation (e.g. a browser connecting to a web server)
– CRLs are issued by a CA for certifcates that it has revoked
– CRLs are signed by the CA so that they can be verifed as authentic
– CRLs have an expiration date
●
To fail secure, when you have a CRL as your revocation checking mechanism but it has expired then you should treat all certifcates from
the CA as revoked – you don’t know what has changed since your CRL fle is out of date

32
●
Online Certifcate Status Protocol (OCSP) [73]
– Online mechanism consisting of an OCSP Responder, hosted by the CA, and a client verifying a certifcate
– Client sends the certifcate to the OCSP Responder and gets a valid/invalid response
– Responses are signed by the CA so that they can be verifed as authentic
– Adds a dependency on a network service
●
Risk of connectivity issues to the OCSP Responder
●
Information leak as the OCSP Responder is being informed about each certifcate you are verifying
– Techniques such as OCSP Stapling [74, 75] aim to resolve this

33
Recommendations

34
Recommendation 1 – Defence in Depth
●
DO
– Do produce a Threat Model [32, 33, 65]
●
Helps to identify threats and aides in determining appropriate mitigations
●
Will help you decide on your level of risk
●
Will help you determine where it’s appropriate to use TLS
– Do layer your defences
●
Don’t trust a single technology; just in case
●
Raises cost and efort for an attacker
●
DO NOT
– Do not rely solely upon TLS
●
e.g. Don’t send passwords in plain-text; consider a scheme that ofers some protections of it’s own
– Do not assume that the other end will “do the correct thing”
●
You may be talking to a poor implementation of TLS
●
You may be the victim of a Man-in-the-Middle (MitM) attack [35]

35
Recommendation 2 – Protocol Versions
●
DO
– Do use a modern protocol version
●
Recommend ≥ TLSv1.1
– Avoid DROWN [36], POODLE [21, 22], BEAST [37] and other attacks against older versions
●
TLSv1.2 supports more modern cipher suites
– Do explicitly confgure protocol version requirements
●
Ensure that you’ve disabled versions you don’t want to use explicitly for your socket/service/package/OS
●
DO NOT
– Do not use old protocol versions [38]
●
Avoid known protocol vulnerabilities; this also means updating regularly
●
Do not use SSL
●
Avoid TLSv1.0 as it has drawbacks
– Allows fallback to SSLv3
– Do not “ofer everything” and rely upon the other end to make the decision
●
You may not be able to trust the other end

36
Recommendation 3 – Cipher Suites
●
DO
– Do explicitly confgure cipher suite requirements
●
Ensure that you’ve disabled any cipher suites you’re not happy to use for your socket/service/package/OS
– Do use cipher suites that provide Forward Secrecy [40]
●
Ensures that data is encrypted with an ephemeral key, protecting it from future key compromises
●
E.g. cipher suites using Ephemeral Elliptic-Curve Dife-Hellman for key agreement
– Do use Authenticated Encryption with Additional Data (AEAD) [8, 39] cipher suites
●
Requires TLSv1.2
– Do use algorithms and key sizes that provide ≥ 128bit security
●
Note that this is not the same as the key size
●
128bit security ≈ 3072bit RSA ≈ 256bit Elliptic Curves ≈ AES-128 ≈ SHA-256 [41, 42]
●
Remember that the cipher suite is only as strong as the weakest link

37
Recommendation 3 – Cipher Suites
●
DO NOT
– Do not use NULL cipher suites
●
No encryption / authentication
– Do not use EXPORT cipher suites
●
They are ludicrously weak [58]
●
U.S. export regulations in the 1990s limited cryptography
– Do not use known weak or bad algorithms [38]
●
Sounds obvious but you may be ofering/accepting them if you haven’t explicitly disabled them
●
e.g. RC4 [56, 70], DES, 3DES, MD5, SHA-1 [57]

38
Recommendation 4 – Key Agreement
●
DO
– Do use cipher suites providing ECDH/EDH based key agreement
– Do use Ephemeral ECDH/DH
●
Provides Forward Secrecy
– Do use a DH key with ≥ 2048bit prime [46]
●
Remember to code/confgure these DH parameters
– Do use a ECDH curve of ≥ 256bit
●
Remember to code/confgure these ECDH parameters
– Do prefer ECDH over DH [47]
●
Stronger protection against precomputation attacks [46]
●
Faster
●
Smaller keys means smaller packets

39
Recommendation 4 – Key Agreement
●
DO NOT
– Do not use Anonymous Dife-Hellman
●
Not authenticated so suceptible to Man-in-the-Middle (MitM) attacks
– Do not use a DH key with a prime ≤ 1024bit
●
Broken [46, 47]
– Do not use RSA key exchange
●
Does not provide forward secrecy
●
Your implementation may be vulnerable to ROBOT [55] which would allow attackers to passively record trafc and later decrypt
it

40
Recommendation 5 – Certifcates and PKI
●
DO
– Do verify the Subject Alternative Name (SAN) and Common Name (CN) felds
●
They contain the details of who/what the certifcate was issued to
●
Ensures that you have received a certifcate that claims to be from what you’re connecting to
– Do check validity time stamps (up to the root)
●
Certifcates contain Begin and End times and should not be trusted outside of these times
– Do check signatures (up to the root)
●
Verifes issuance and integrity
– Do check constraints and policies (up to the root)
●
End entity certifcates should never be marked as a Certifcate Authority (CA)
●
All certifcates in the chain above the end entity certifcate must be marked as CA certifcates
– i.e. they’re actually allowed to issue and sign certifcates
●
Certifcates should only be used based upon their key usage attribiates
– e.g. an e-mail certifcate should not be used to authenticate a web server

41
●
DO
– Do check revocation status (up to the root)
●
Don’t trust revoked certifcates
●
If a CA is revoked, don’t trust anything that it has issued
– i.e. don’t trust anything below in the chain
– Do only trust the minimum number of Certifcate Authorities
●
Reduces the risk of compromised CAs or accidental certifcate issuance by trusting only the ones you absolutely need
●
Ideally, use your own trust store
– Using the trust store from the platform allows other applications, which you may not control, to impact your trust list
– Do use Certifcate Pinning [79], if possible
●
Explicitly defne the acceptable certifcates or CA for your deployment and “pin” them so that they’re the only certifcates accepted
– e.g. if you have a client that only connects to your infrastructure it only needs to trust the certifcates from your servers
– Be aware that this requires some planning and maintenance to ensure that you update your pins before any expirations
– Do protect the Private Keys
●
Remember to protect Private keys as their compromise allows an attacker to impersonate you or your service
●
Hardware Security Modules (HSMs) [67] are one approach to securing keys

42
●
DO NOT
– Do not ship or hard code private keys
●
They’re called private for a reason!
– Do not use short keys
●
e.g. RSA < 2048bit
– Do not use weak signature schemes
●
e.g. MD5 or SHA-1
– Do not share private keys
●
It may be tempting to share a certifcate around your servers
●
Increases exposure as there are more places the private key can be stolen
– Do not use long lived certifcates
●
Longer life certifcates mean longer exposure window if compromised
●
Not everybody checks revocation information, sadly

43
●
DO NOT
– Do not use wild card certifcates
●
Increases exposure as the same certifcate can be used to impersonate many systems – more damaging if compromised
●
Makes the certifcate more valuable to an attacker
– Do not assume ASCII
●
Certifcates can be UTF-8 and include NULL characters
– Rremember this when parsing!
– Do not use the “needle in haystack” approach when parsing SAN/CN entries
●
Leaves you open to attack so match on the whole string
– e.g. Consider receiving this CN when connecting to example.com: example.com.attacker.org

44
Recommendation 6 – Implementation
●
Lots of third-party code and libraries already implement TLS
– They may not have the default behaviour you expect
– They may have APIs or confguration that encourages mistakes
– It’s up to you to use them securely

45
Recommendation 6 – Implementation
●
DO
– Do read the documentation for the package/library/OS
– Do keep the package/library/OS up to date but watch the change logs for things that will impact you
– Do explicitly specify permitted protocol versions and cipher suites
●
The defaults may not be what you require
– Do compile out what you don’t want
●
You can’t accidentally use something by mistake if it’s not present
●
e.g. if you compile out SSL support then you can’t accidentally negotiate a SSLv3 connection
●
DO NOT
– Do not assume
●
Default behaviour is often not what you want or expect
●
Many libraries default to an “allow all” approach where client code ofers everything supported and server code accepts anything

46
Recommendation 7 – Entropy
●
Encryption relies upon entropy
– i.e. randomness
●
Good sources of entropy (random data) are important
– Without high entropy you can generate some really bad keys
●
Gaining entropy can be difcult
– Embedded, IoT and Virtualised devices can have difculty gaining entropy
– Consider entropy source when designing systems

47
Recommendation 7 – Entropy
●
DO
– Do use a good source of entropy
– Do consider adding hardware random number generators to your architecture
●
Some CPUs include this capability
●
DO NOT
– Do not generate keys whilst your entropy pool is low / empty
●
Predictable encryption keys and initialisation data are not good!
Image: https://imgs.xkcd.com/comics/random_number.png

48
Tools and Testing

49
Tools and Testing
●
OpenSSL [63]
– The OpenSSL command line is a useful resource for testing and verifcation of connection parameters
– cipher
●
Displays information on supported ciphers and the meaning of cipher strings on the platform
●
Note that the behaviour is dependent upon version, compile options and other factors so results will vary between systems
●
e.g. openssl cipher -V ‘ALL’
– s_client
●
Confgurable TLS client
●
Useful for testing connections to a TLS server
●
e.g. openssl s_client -connect address:port -cipher ‘AES’ -tls1_2
– s_server
●
Confgurable TLS server
●
Useful for testing connections from a TLS client
●
e.g. openssl s_server -port 8443 -cert cert.pem -key privkey.pem -no_ssl3 -no_tls1 -cipher 'EECDH'
Image: https://www.openssl.org/

50
Tools and Testing
●
SSLyze [60]
– “SSLyze is a Python library and a CLI tool that can analyze the SSL confguration of a server by connecting to it. It is designed to be
fast and comprehensive, and should help organizations and testers identify mis-confgurations afecting their SSL/TLS servers.”
– Good CLI tool that’s also a handy Python library for building your own test tools
– Supports testing for vulnerabilities, protocol support and cipher suite support
●
Nmap [71]
– Nmap is much more than just a port scanner, particularly when its scripting engine is enabled
– Scripts exist for retrieving certifcate information, enumerating and evaluating support protocol versions and cipher suites
– e.g. nmap -vvvv -sS --script ssl-cert,ssl-enum-ciphers google.com

51
Tools and Testing
●
Qualys SSL Labs Client Test [51]
– Tool for testing web clients capabilities
– Provides data on the
●
protocols supported
●
cipher suites supported
●
susceptibility to known vulnerabilities

52
Tools and Testing
●
Qualys SSL Labs Server Test [51]
– Tool for testing web servers capabilities
– Provides data on the
●
protocols supported
●
cipher suites supported
●
susceptibility to known vulnerabilities
●
certifcate chain
●
supported extensions
– Simulates diferent common clients to help
determine interoperability
– Provides overall score and details on how the
score is calculated with advice on how to
improve

53
Tools and Testing
●
BadSSL [68]
– Tool for testing client capabilities
– Provides testing for
●
certifcate parsing
●
key exchange
●
protocol versions
●
HTTP Extensions
●
cipher suites
– Can be downloaded from GitHub and used ofine
●
Useful for building into your test pipelines
Image: https://letsencrypt.org/

54
Tools and Testing
●
LetsEncrypt [61]
– “Let’s Encrypt is a free, automated, and open Certifcate Authority.”
– CA providing free server certifcates to all
– Tooling provided for automated deployment and renewal
– Trusted by major OS and Browser versions
– Trusted by the Electronic Frontier Foundation [62]
Image: https://letsencrypt.org/

55
Closing
●
Thanks for spending the time looking at these slides, hopefully they proved informative
●
If you have any comments, questions or spot a mistake please leave a comment

56
Appendix
●
128bit Symmetric encryption security comparison
– Diferent organisations have calculated comparative strengths; remember that the connection is as strong as the weakest link
https://www.keylength.com/en/compare/

57
Appendix
●
256bit Symmetric encryption security comparison
– Diferent organisations have calculated comparative strengths; remember that the connection is as strong as the weakest link

58
Appendix
●
U.S. Commercial Top Secret Recommendations
– If you are building products / services for the U.S. Government then FIPS140 [53] and these standards are worth knowing
https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classifed/algorithm-guidance/commercial-national-security-algorithm-suite-factsheet.cfm

59
References
[1] Wikipedia – Symmetric encryption
https://en.wikipedia.org/wiki/Symmetric-key_algorithm
[2] Wikipedia – Stream ciphers
https://en.wikipedia.org/wiki/Stream_cipher
[3] Wikipedia – Block ciphers
https://en.wikipedia.org/wiki/Block_cipher
[4] Wikipedia – Cipher Block Chaining Mode
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_Block_Chaining_(CBC)
[5] Wikipedia – Counter Mode
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)
[6] Wikipedia – Counter Mode with CBC-MAC
https://en.wikipedia.org/wiki/CCM_mode
[7] Wikipedia – Galois-Counter Mode
https://en.wikipedia.org/wiki/Galois/Counter_Mode
[8] Wikipedia - Authenticated Encryption with Associated Data
https://en.wikipedia.org/wiki/Authenticated_encryption

60
References
[9] Wikipedia – Asymmetric encryption
https://en.wikipedia.org/wiki/Public-key_cryptography
[10] NIST Special Publication 800-57: Recommendation for Key Management
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf
[11] Wikipedia – Message Digest
https://en.wikipedia.org/wiki/Cryptographic_hash_function
[12] Wikipedia – Digital Signature
https://en.wikipedia.org/wiki/Digital_signature
[13] Wikipedia – Elliptic-Curve Cryptography
https://en.wikipedia.org/wiki/Elliptic-curve_cryptography
[14] Bulletproof SSL and TLS
https://www.feistyduck.com/books/bulletproof-ssl-and-tls/
[15] Wikipedia – Transport Layer Security
https://en.wikipedia.org/wiki/Transport_Layer_Security
[16] RFC6101 - The Secure Sockets Layer (SSL) Protocol Version 3.0
https://datatracker.ietf.org/doc/rfc6101/

61
References
[17] RFC6176 - Prohibiting Secure Sockets Layer (SSL) Version 2.0
[18] RFC7568 - Deprecating Secure Sockets Layer Version 3.0
[19] RFC2246 - The TLS Protocol Version 1.0
[20] RFC4346 - The Transport Layer Security (TLS) Protocol Version 1.1
[21] RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2
[22] Qualys - SSL 3 is dead, killed by the POODLE attack
https://blog.qualys.com/ssllabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack
[23] US-CERT - SSL 3.0 Protocol Vulnerability and POODLE Attack
https://www.us-cert.gov/ncas/alerts/TA14-290A
[24] Wikipedia – RC4 cipher
https://en.wikipedia.org/wiki/RC4

62
References
[25] Salsa20
https://cr.yp.to/snufe.html
[26] Wikipedia – IDEA cipher
https://en.wikipedia.org/wiki/International_Data_Encryption_Algorithm
[27] Schneier on Security – The Blowfsh Encryption Algorith
https://www.schneier.com/academic/blowfsh/
[28] NIST FIPS197 – Advanced Encryption Standard (AES)
https://csrc.nist.gov/csrc/media/publications/fps/197/fnal/documents/fps-197.pdf
[29] NIST FIPS180-4 – Secure Hash Standard
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
[30] NIST FIPS186-4 – Digital Signature Standard
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
[31] Wikipedia – Elliptic-Curve Dife-Hellman
https://en.wikipedia.org/wiki/Elliptic-curve_Dife%E2%80%93Hellman
[32] Microsoft – Threat Modelling
https://msdn.microsoft.com/en-us/library/f648644.aspx

63
References
[33] OWASP – Application Threat Modelling
https://www.owasp.org/index.php/Application_Threat_Modeling
[34] Draft-ietf-tls-tls13 - The Transport Layer Security (TLS) Protocol Version 1.3
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
[35] OWASP – Man in the Middle Attack
https://www.owasp.org/index.php/Man-in-the-middle_attack
[36] DROWN Attack
https://drownattack.com/
[37] BEAST Attack
http://blog.zoller.lu/2011/09/beast-summary-tls-cbc-countermeasures.html
[38] RFC7457 - Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)
[39] RFC5116 - An Interface and Algorithms for Authenticated Encryption
[40] TLS and Perfect Forward Secrecy
https://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy

64
References
[41] Cryptographic Key Length Comparison
[42] Cisco - Next Generation Encryption
https://www.cisco.com/c/en/us/about/security-center/next-generation-cryptography.html
[43] Wikipedia – Dife-Hellman
https://en.wikipedia.org/wiki/Dife%E2%80%93Hellman_key_exchange
[44] Applied Crypto Hardening
https://bettercrypto.org/static/applied-crypto-hardening.pdf
[45] The Heartbleed Bug
http://heartbleed.com/
[46] Weak Dife-Hellman and the Logjam Attack
https://weakdh.org/
[47] Imperfect Forward Secrecy: How Dife-Hellman Fails in Practice
https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf
[48] Internet X.509 Public Key Infrastructure Certifcate and Certifcate Revocation List (CRL) Profle

65
References
[49] U.K. Government Deparment Digital, Culture, Media and Sport - Secure by Design: Improving the cyber security of consumer Internet of Things Report
https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/fle/686089/Secure_by_Design_Report_.pdf
[50] What Is Data Encryption?
https://digitalguardian.com/blog/what-data-encryption
[51] Qualys SSL Labs Projects
https://www.ssllabs.com/projects/index.html
[52] InfoSec Institute – CIA Triad
http://resources.infosecinstitute.com/cia-triad/
[53] NIST FIPS140-2
https://csrc.nist.gov/publications/detail/fps/140/2/fnal
[54] OpenSSL Ciphers
https://www.openssl.org/docs/man1.0.2/apps/ciphers.html
[55] ROBOT attack
https://robotattack.org/
[56] Attack of the week: RC4 is kind of broken in TLS
https://blog.cryptographyengineering.com/2013/03/12/attack-of-week-rc4-is-kind-of-broken-in/

66
References
[57] Google - Announcing the frst SHA1 collision
https://security.googleblog.com/2017/02/announcing-frst-sha1-collision.html
[58] Portcullis Labs - SSL and Export Ciphers: Logjam and FREAK
https://labs.portcullis.co.uk/blog/ssl-and-export-ciphers-logjam-and-freak/
[59] Future of SSL in doubt? Researcher Marlinspike unveils alternative to certifcate authorities
https://www.infosecurity-magazine.com/news/future-of-ssl-in-doubt-researcher-marlinspike/
[60] SSLyze
https://github.com/nabla-c0d3/sslyze
[61] LetsEncrypt
https://letsencrypt.org/
[62] Electronic Frontier Foundation
https://www.ef.org/
[63] OpenSSL
https://www.openssl.org/
[64] Decrypting TLS Browser Trafc With Wireshark – The Easy Way! (Windows)
https://jimshaver.net/2015/02/11/decrypting-tls-browser-trafc-with-wireshark-the-easy-way/

67
References
[65] OWASP Threat Dragon
https://www.owasp.org/index.php/OWASP_Threat_Dragon
[66] Oracle - Certifcate-based Authentication
https://docs.oracle.com/cd/E19316-01/820-2765/gdzeb/index.html
[67] Wikipedia - Hardware security module
https://en.wikipedia.org/wiki/Hardware_security_module
[68] BadSSL
https://badssl.com/
[69] On the (provable) security of TLS: Part 1
https://blog.cryptographyengineering.com/2012/09/06/on-provable-security-of-tls-part-1/
[70] Attack of the week: RC4 is kind of broken in TLS
https://blog.cryptographyengineering.com/2013/03/12/attack-of-week-rc4-is-kind-of-broken-in/
[71] Nmap
https://nmap.org/
[72] RFC5280 - Internet X.509 Public Key Infrastructure Certifcate and Certifcate Revocation List (CRL) Profle

68
References
[73] RFC6960 - X.509 Internet Public Key Infrastructure Online Certifcate Status Protocol – OCSP
[74] Transport Layer Security (TLS) Extensions: Extension Defnitions
[75] OCSP Stapling: How CloudFlare Just Made SSL 30% Faster
https://blog.cloudfare.com/ocsp-stapling-how-cloudfare-just-made-ssl-30/
[76] How to choose an Authenticated Encryption mode
https://blog.cryptographyengineering.com/2012/05/19/how-to-choose-authenticated-encryption/
[77] RFC6749 - The OAuth 2.0 Authorization Framework
[78] Wikipedia - Public key infrastructure
https://en.wikipedia.org/wiki/Public_key_infrastructure
[79] OWASP - Certifcate and Public Key Pinning
https://www.owasp.org/index.php/Certifcate_and_Public_Key_Pinning

Why “It’s over TLS” is not good enough

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Why “It’s over TLS” is not good enough

Similar to Why “It’s over TLS” is not good enough (20)

Recently uploaded

Recently uploaded (20)

Why “It’s over TLS” is not good enough