Research & DevelopmentWhite Paper

WHP 337

May 2018

HTTPS Configuration for the AMWA NMOS APIsSecuring IP Production Control

S. Rankine

Design & EngineeringBRITISH BROADCASTING CORPORATION

BBC Research & DevelopmentWhite Paper WHP 337

HTTPS Configuration for the AMWA NMOS APIs

Simon Rankine

Abstract

The AMWA NMOS APIs, IS-04 and IS-05, are becoming an increasingly important part of the IPfuture of broadcasting. These HTTP-based APIs are missions critical to the broadcast industry,therefore it is important that they can be trusted, and secure from abuse and interference. Thisdocument recommends protecting HTTP exchanges at the transport layer and provides guidanceon configurations that should be cross compatible between vendors.

Additional key words: SSL, TLS, HTTPS, NMOS, AMWA, APIs, IP Studio

©BBC 2018. All rights reserved.

White Papers are distributed freely on request.

Authorisation of the Chief Scientist or Head of Standards isrequired for publication.

©BBC 2018. Except as provided below, no part of this document may be reproduced in any materialform (including photocoping or storing it in any medium by electronic means) without the priorwritten permission of BBC Research & Development except in accordance with the provisions ofthe (UK) Copyright, Designs and Patents Act 1988.

The BBC grants permission to individuals and organisations to make copies of the entire doc-ument (including this copyright notice) for their own internal use. No copies of this documentmay be published, distributed or made available to third parties whether by paper, electronic orother means without the BBC’s prior written permission. Where necessary, third parties shouldbe directed to the relevant page on BBC’s website at http://www.bbc.co.uk/rd/pubs/whp for acopy of this document.

BBC Research & DevelopmentWhite Paper WHP 337

HTTPS Configuration for the AMWA NMOS APIs

Simon Rankine

1 IntroductionIn a constantly changing security landscape, where attacks on large organisations are the norm,the broadcast industry cannot afford to be left behind when it comes to security.

As we move to an IP future we must be ever mindful as an industry that there are those thatwish to do us harm, and have the means to do so if we do not protect ourselves. The 2015 attackon TV5Monde[1][2] in France should serve as a sobering reminder of the damage these attacks cando.

Good security practice must be multifaceted, and should encompass everything from the de-sign of standards and specifications through to the physical security used in broadcast centres andstudios. Furthermore defences must constantly be adapted in the face of new threats and vulnera-bilities. Designing a system to be secure at the time of release is not sufficient - the rapid pace ofchange of threats means that we must plan for products to be updated throughout their life cycleto protect them as new threats emerge.

It is important to stress this changing nature of security, as the guidance in this documentwill itself be subject to change. The state of the art at the time of writing could well prove to becompromised within a few years, or even months. However, adhering to current best practice willhelp protect against currently known attacks, and shield against possible attack vectors for thefuture.

The Advanced Media Workflow Association (AMWA) Networked Media Open Specifications(NMOS) APIs[3] and many others used by the broadcast industry are based on Hyper Text TransferProtocol (HTTP)[4]. The NMOS APIs may be used for discovery and registration of broadcastdevices on an IP broadcast network, the management of media connections between such devices,and network control. As such these APIs sit at the core of an IP broadcast facility, and theirprotection from interference is of the utmost importance.

HTTP exchanges take the form of request and response messages which are serialized to a wireformat: HTTP/1.1 messages use a text-based encoding, while later versions such as HTTP/2[5]and HTTP over QUIC[6] use a binary encoding1. HTTP messages themselves have no securitycapabilities such as authentication, integrity or confidentially. Whilst the IETF has defined somemethods that provide these capabilities at the HTTP layer, best current practice is to add securityat the transport layer where this is required. Therefore, the focus of this document is on transportlayer protection.

Traditionally, an HTTP server is identified with a URL that uses the ‘http’ scheme. In thisconfiguration, all messages are conveyed in the clear, typically on TCP port 80. This unfortunately

1 HTTP over QUIC is an emerging means of securing HTTP communications. The same http or https URIschemes are used but here, an HTTP/QUIC server is then discovered by the client using HTTP Alternative Services[7]. If an alternative is used, the URL remains unchanged from the perspective of the client user interface. Aclient supporting HTTP over QUIC connects to the alternative server, initiates a TLS 1.3 handshake and checksthe server identity. It then securely exchanges material that is subsequently used to protect QUIC packet payloadsusing Authenticated Encryption and Additional Data (AEAD). All HTTP messages are conveyed inside this payload.Further discussion of HTTP/QUIC is beyond the scope of this document but many of the security and cryptographicprinciples discussed here apply similarly.

1

allows them to be intercepted and altered without detection, which provides the basis for manytypes of attack (Man-in-the-middle, replay etc).

HTTP over TLS (Transport Layer Security)[5] describes a means to protect HTTP messages.An HTTP/TLS server is identified with a URL that uses the ‘https’ scheme. In this configuration,all messages are conveyed inside TLS records, typically on TCP port 443. A client connecting tosuch a server initiates a TLS handshake and checks the server identity. It then securely exchangesmaterial that is subsequently used to cryptographically protect TLS records. Configuration ofsuch endpoints requires careful consideration of a great many variables. Incorrect configuration ofHTTP/TLS can leave systems vulnerable to exactly the kind of attacks that it is intended to protectagainst. One outcome of this is that it gives users a false sense of security; messages thought to besecure are in fact not. Interoperability is also a concern, with client and server implementationsand configurations progressing at different rates. In the worst case, endpoints may not be able tonegotiate a secure session, which may lead to NMOS APIs becoming inaccessible.

HTTP/TLS is the focus of this document. It studies the current IT industry best practice forimplementation and configuration (as of May 2018) and examines the implications on IP broad-casting, with particular emphasis on the AMWA NMOS APIs. As already discussed, following theguidance presented here will not in itself ensure the security of an IP broadcast system, many otheraspects must be considered. Specifically, this document does not consider network security, whichwould consider issues such as controlling access to the network and securing underlying networkprotocols and systems.

The advice in this document will age quickly, making it vital that system designers consult arange of sources. To aid with this suggested resources for further reading are given in Appendix A.There are a range of tools that can be used to check that servers have been configured correctly, aselection of which can be found in Appendix B.

2

2 Basic Cryptography Concepts2.1 Securing ConnectionsWhen using HTTP over TCP all data is sent un-encrypted (“in the clear”), meaning any maliciousactor intercepting the connection is able to read data passing back and forth between a serverand its client. Furthermore this does not provide the client a way of ensuring the server it iscommunicating is owned by the trusted third party they expected. The same is true in reverse -the server may also need to verify the client.

This will allow the malicious actor to do any of the following:

• Steal data in the packets, including usernames, passwords or personal information.

• Impersonate the server to the client, allowing them to (for example) trick the client intodivulging information.

• Record and then replay client requests, causing the server to carry out actions the client hasnot asked for.

Clearly this is not acceptable for applications where secure communication is required. A secureprotocol that is to carry sensitive information across an unprotected channel like The Internet mustthen meet the requirements of confidentiality, identification, integrity and authentication[8][9]:

Confidentiality Data passing between client and server must be unreadable to third parties.

Identification It should be possible for the client and server to check whether the other end ofthe connection is owned by a trusted party.

Integrity It must be clear if packets have been tampered with.

Authentication It should be possible for the client to check if packets actually came from theserver it is talking to, and vice versa.

HTTP over TLS is designed to meet these requirements by encrpting HTTP traffic using anencryption protocol, now Transport Layer Security (TLS), but historically Secure Socket Layer(SSL). As the SSL protocol is now deprecated this document will consider the operation HTTPover TLS. The remaining sections in this chapter will cover the mechanisms used to achieve thesefour principles.

2.2 ConfidentialityThe mechanism used by TLS to provide authentication is based on a technique called public keycryptography, which is an example of asymmetric cryptography. Anyone may encrypt a messageusing someone else’s public key, which may safely be made widely available. Once encrypted, usingan algorithm known as a cipher, the message may only then be un-encrypted again using a privatekey held only by the owner of the key pair. A third party intercepting the message cannot decryptit, even though they know the public key.[10]

This is in contrast to symmetric cryptography, where both ends of the connection must knowabout a shared secret key in advance, which they both use to encrypt and decrypt messages - againusing a cipher. Symmetric key cryptography however is considerably less resource intensive thanasymmetric cryptography, making it better suited for transferring larger amounts of data around.

In order to ensure confidentiality, TLS uses both types of cryptography. During an initial hand-shake asymmetric public key cryptography is used to allow the client and server to confidentiallyestablish a shared secret key between them. This can then be used to encrypt future messagesbetween them using less resource intensive symmetric encryption.[11]

3

Client Server

1 – ClientHello

Cipher suite support list

Protocol support list

2 – ServerHello

Protocol choice

Server certificate

Cipher choice

Server hello done

Server random number

3 – ClientKeyExchange

Encrypted secret key

4 – ChangeCipherSpec

Client asks server to switch to the block cipher

5 – ChangeCipherSpec

Finished

6 - Secure Communication Commences

Figure 1: TLS 1.2 Handshake

There are multiple different algorithms that may be used for both the symmetric and asym-metric encryption. Algorithms vary in complexity, resource requirements, security and adoption.In TLS the asymmetric encryption algorithm is known as the key exchange cipher, whereas thesymmetric encryption algorithm is referred to as the block or stream cipher.

In general clients and servers using TLS will support a selection of different key exchange andblock ciphers. As part of the handshake that begins a TLS connection the ciphers to be used mustbe negotiated - the group of ciphers that will be used for a connection is referred to as a ciphersuite. If agreement cannot be reached because there is no overlap in cipher suite support betweenclient and server a connection cannot be made. Servers and clients will typically support a rangeof suites in order to improve the chances of making a connection.

A simplified TLS handshake is shown in Figure 1. This handshake is representative of usingTLS version 1.2 - the recommended at the present time. Further background will be given inSection 4. Each of the steps is as follows:

1 - ClientHello The client initiates the handshake, and includes information about what proto-cols it can use to establish a secure connection and the cipher suites it supports. This messageis sent un-encrypted.

2 - ServerHello The server responds to the client hello with the protocol and cipher suite it haschosen to use. It also sends its own public key so the client may send it an encrypted messagewith the key. The server also provides a random number which is used as part of the keygeneration process by the client. The server may also provide a certificate to allow the clientto identify it - this is discussed further in Section 2.3.

3 - ClientKeyExchange The client computes the secret key that will be used to communicate

4

using the block cipher. It then encrypts it with the server’s public key and sends it to theserver. Both ends of the connection now have a shared secret.

4 - ChangeCipherSpec The client asks the server to start using the block cipher with the secretkey it sent.

5 - ChangeCipherSpecFinished The server responds to the client using the block cipher. Nowa secure channel has been established encrypted data may now be sent.

2.2.1 Forward Secrecy

It is often important that information shared between a client and server cannot be decrypted,even if the private key used to negotiate the secure session (the “long term key”) is compromisedat some later date. This is not something all key exchange algorithms are able to achieve, howeverit is possible.

An “ephemeral key” can be generated using the long term key for each individual message orsession. This way each message is still protected even if the long term key is later compromised.

It is important to remember that forward secrecy does not protect against cryptographic flawswhich may allow an attacker to decrypt messages without ever knowing the long term key, anddoes not protect against an attacker storing messages until such a time as they become possibleto attack through brute force methods. It is a real possibility that messages sent today could bevulnerable to attack from future machines with much greater power than those currently available,especially with the advent of quantum computing[12].

2.3 IdentificationThere is no point setting up a secure channel in order to securely send your data to someone whoyou do not want to have it. It is therefore important for clients to be able to verify the server theyare connecting to belongs to the entity they expect.

In the second step of the handshake shown in Figure 1 the server sends the client its certificate.This certificate is cryptographically signed by a Certificate Authority (CA), and confirms that theserver is the owner of the public key it is using to establish the connection. The CA is a bodytrusted by both the client and the server. The client will store certificates from CAs that it trusts,and can use them to verify server certificates were genuinely issued by a particular CA throughuse of a Key Authentication Algorithm.

This is an example of what is referred to as “Public Key Infrastructure”. CAs typically take theform of companies specialising in issuing certificates for this purpose, and their CA certificates are“baked in” to browsers and operating systems by manufacturers. CAs may also be large companiesor governments, which act as their own CAs for their internal networks and distribute their ownCA certificates to clients within their organisation.

A server certificate is only secure as long as private keys held by the server and the CA thatsigned the certificate are securely held. As such CAs generally only issue certificates valid for oneor two years, to limit the risk if a server’s private key is compromised. Furthermore the CA mayrevoke certificates that it considers to be compromised - however this does rely on clients regularlychecking against revocation lists.

2.3.1 Intermediate Certificates

The CA certificate is generated and signed by a private key held by the CA itself to generate aroot certificate. These certificates typically last for tens of years, and are distributed to clients.The private key used to generate this certificate must be held extremely securely, and as suchis not used to sign server certificates directly. Instead it is used to sign a limited number of

5

Securely held by server

Presented by server

Distributed to clients

in advance

Securely held by CA

Root CA

Private key

Public key

Root CA Name

Root Signature

Root CA Certificate

Intermediate CA

Private Key

Public key

Root CA Name

Root Signature

Intermediate CA

Certificate

Signs

Verifies

ReferencesCA Name

Server Private Key

Public key

CA Name

CA Signature

Server

Owner s Name

Verifies

References

SignsUsed to

generateSigns

Used to

generate

Used to

generate

Figure 2: A trust chain of signed certificates allows the client to identify the server.

“intermediate certificates”, which are valid for around 10 years. The private keys corresponding tothese intermediate certificates are then used by CAs to sign server certificates.

In order to allow clients to validate their certificates servers must also provide the intermediatecertificate as well as their own. This establishes the “chain of trust”, as show in Figure 2, whichthe client may follow back to the root certificate.

2.4 IntegrityIt is important when communicating securely that what was sent is what is received. This protectsagainst both intentional modification of the data passing over the connection by malicious thirdparties, and also accidental modification of the data caused by the channel.

In order to protect data integrity cipher suites generally contain a third kind of algorithm inaddition to the key negotiation algorithm and block cipher algorithms. The Message AuthenticationCode (MAC) algorithm produces a “tag” that is appended to the packet. Traditionally these havetaken the form of hashing algorithms such as MD5 and SHA. Receivers may check the integrityof data by hashing the received data (either before or after encryption) and comparing it to thechecksum.

2.5 AuthenticationThe previous section on data integrity raises an obvious question - how to prevent malicious attack-ers from generating hashes of their malicious content to make it appear legitimate to a receiver.This is solved by including the shared secret key in the data fed to the MAC algorithm. Thereceiver has this key as well, so can easily include it when validating the MAC tag, but a maliciousattacker, who does not have the key, will not be able to use it to create a valid tag themselves.

A similar technique is also used in preventing replay attacks, where a packet from the connectionis captured by a malicious third party. The packet may then be re-sent causing the client or serverto repeat an action it has already performed. If that packet was, for example, a packet instructing

6

Figure 3: Block diagram showing generation and verification of MAC tags.

a bank to move money between accounts this could be extremely serious, even though the thirdparty could not directly read the contents of the packet it replayed[13][14].

The MAC will typically use the message contents, the shared encryption key and also a sequencenumber to generate the tag[15]. The use of the sequence number ensures that the tag will onlybe valid once, and will not validate if it is replayed. The use of the key ensures that only thoseholding the key (the client and the sender) can know how to generate the tag[16].

A simplified diagram showing the MAC generation and verification process is given in Figure 3.

2.6 Section SummaryIn the previous four sections it has been shown how confidentiality, identification, integrity andauthentication are delivered in TLS as used in HTTP over TLS. It has been shown how fourcomponents, the Key Exchange Algorithm, the Key Authentication Algorithm, the Block cipherand the Message Authentication Code are all required for secure communication.

Inevitably each component can be implemented using a variety of different techniques andalgorithms. The number of different permutations and configurations of these components is vast,and making the wrong choice can lead to systems that are insecure, incompatible and/or inefficient.A detailed examination of each of these components will be presented in the following sections.

7

3 Common AttacksThere are a great many different types of attacks that can be used against TLS, but many of themcan be grouped into a few broad categories. This list is by no means exhaustive, but is useful inunderstanding what causes certain vulnerabilities to become an issue.

3.1 Man in the Middle AttacksA man in the middle attack is any attack that involves intercepting messages between client andserver or vice versa. This may be limited to eavesdropping on the connection, or may includemodify and altering then replaying information in order to mount an attack.

3.2 Replay AttacksA replay attack is a type of man in the middle attack whereby the attacker re-sends a message ithas seen sent before in the hope of getting a recipient to repeat an action.

For example an attacker may intercept a message from a browser instructing a banking websiteto transfer money from one account to another. Unless precautions are taken an attacker maybe able to replay this message to the server and get it to repeat the transaction without theauthorisation of the user.

These attacks can be mounted without the attacker being able to decrypt the actual message,they just need to be able to establish which messages they need to replay.

3.3 Downgrade AttacksA downgrade attack is a form of man in the middle attack whereby the attacker causes a less securemode of protection to be used which has been enabled for backward compatibility.

For example many servers still support use of older encryption methods for backward compati-bility. An attacker may use a downgrade attack to force a client and server that would normally beable to communicate using a more secure method to use a weaker one. The attacker then proceedsto exploit the known weaknesses in the less secure encryption method.

3.4 Plaintext AttacksA plaintext attack is possible where the attacker has some or all of the encrypted message, andis able to use that information to reduce the strength of the encryption. This may allow them todecipher subsequent messages which they do not posses the plaintext for. Note that the plaintextmay simply be a dictionary of common words, and doesn’t necessarily rely on knowledge of theactual message.

In order to avoid such attacks messages are usually combined with random data in some wayduring the encryption process. In modern cryptography an Initialisation Vector (IV) or “nonce”is typically combined with the message prior to encryption to ensure no two encrypted messagesare the same, even if the content never varies. This nonce may safely be transmitted in the clearwithout compromising the encryption.

3.5 Brute Force AttacksBrute force attacks rely on using extremely capable hardware to try every possible key against thecipher text to try and break the encryption. The longer the key used the longer such an attackwill take on average.

Typically keys of 2048 bits are thought to be secure even against state level organisations withextremely powerful computers[17]. However quantum computing may present a mechanism tobrute force encryption much faster in the future.

8

3.6 Exploitation AttacksExploitation attacks use flaws in either the protocols themselves or bugs in their implementationsto compromise security. Exploitation attacks must be protected against both by ensuring theprotocol itself is well designed, but also that code is implemented and tested thoroughly.

9

4 Protocols (SSL/TLS)Secure Socket Layer (SSL) and Transport Layer Security (TLS) are the protocols used for secureconnections on the web. HTTP/TLS defines how HTTP messages can be secured using the TLSrecord layer, but the techniques used to secure the connection are defined by SSL and TLS.

TLS supersedes SSL, and is the only one of the two deemed to still be secure, due to a numberof known vulnerabilities in SSL [18]. TLS and SSL are often conflated, and many tools and librariesthat provide TLS use SSL in their name.

4.1 SSLSSL had three versions, 1.0, 2.0 and 3.0. All three have major security vulnerabilities and shouldno longer be used. The POODLE downgrade attack rendered SSL 3.0 insecure as of 2014[19], andRFC 7568[20] prohibited the use of SSL 3.0. Consequently new technologies and systems shouldnot make use of the protocol, and it will not be considered further in this document.

4.2 TLSTLS has three published versions (1.0[21], 1.1[22], 1.2[23]) and version 1.3 is a draft document atthe time of writing [24]. TLS 1.0 has been prohibited for use by the Payment Card Industry (PCI)Security Standards Council in their Data Security Standard (DSS) [25]. While this guidance isprimarily intended for handling financially sensitive data it represents good industry practice, andas such implementers should not use TLS 1.0 and should ideally use TLS 1.2 as advised in theDSS.

TLS 1.1 lacks support for many of the preferred cipher suites, and TLS 1.1 implementationsare often vulnerable to the attacks outlined in Section 3. Use of TLS 1.1 is generally consideredbad practice, and as such will not be considered further.

4.2.1 TLS 1.2 Support

Despite the known issues with SSL and older versions of TLS many systems still use these protocols.Sometimes this is because the system has not been kept up to date, or has not been carefullyimplemented. In many cases though this is to ensure compatibility with older clients. Olderversions of some browsers do not implement TLS 1.2. Table 1 gives a summary of TLS support indifferent browser versions, and more detailed information can be found in [26] and [27].

Table 1: TLS Browser Support SummaryBrowser TLS SupportGoogle Chrome TLS 1.2 support since version 30 (current version is 64). Still supports

TLS 1.0 and 1.1.Microsoft Edge Has supported all TLS versions since launch.Mozilla Firefox TLS 1.2 support since version 33 (current version is 59). Still supports

TLS 1.0 and 1.1.Microsoft Inter-net Explorer

Internet Explorer has only supported TLS 1.2 since its most recent ver-sion, IE 11. Microsoft has announced it will end support for older ver-sions of the browsers, but as of January 2018 IE 8 still enjoys a marketshare of 1.5%.

Apple Safari Safari has supported TLS 1.2 since version 7 (current version is 11). Stillsupports TLS 1.0 and 1.1.

The most significant barrier to compatibility is the lack of support for TLS in legacy InternetExplorer versions. As of January 2018 Microsoft announced it would end support for these older

10

browsers[28], but as of December 2017 these browsers still represented around 2% of traffic on theweb[29].

Various reasons have been suggested for the continued use of these older browser versions,including the need to support legacy corporate systems not compatible with newer versions, use ofolder operating systems for which these browsers are the default, and failure to upgrade operatingsystems and browsers to the latest version.[30][31]

4.2.2 TLS 1.3

At the time of writing TLS 1.3 is still in draft, but is expected to be published at some point in 2018.Most browsers have some support, although not many have it enabled by default at present. Thewidely used OpenSSL library has added support for TLS 1.3 in a recent Alpha release, although itis not currently suitable for security critical applications.

TLS versions before 1.3 supported all cipher suites supported in older versions. As some ofthese older suites were compromised it is possible to configure a TLS 1.2 implementation such thatit is not secure. This has resulted in poorly configured TLS 1.2 implementations being vulnerable.TLS 1.3 will only support cipher suites without any known vulnerabilities. This should hopefullyreduce vulnerabilities introduced by incorrect configuration of TLS.

TLS 1.3 also introduces a range of new features intended to protect against attacks. Thisincludes digitally signing the entire TLS handshake to prevent man in the middle attacks, andprotection against downgrade attacks. Downgrade attacks can trick servers into negotiating con-nections using older, less secure, protocols leaving the connection vulnerable.

A detailed discussion of the benefits of TLS 1.3 is beyond the scope of this document, but it issufficient to say that TLS 1.3 will represent the gold standard protocol for use with HTTPS whenreleased.

4.3 Section SummaryThis section has analysed the protocols that may be to secure HTTP. The SSL protocol is depre-cated and insecure, and should not be used when developing new systems. TLS 1.0 and 1.1 areconsidered end of life and are being phased out due to various vulnerabilities, and should also notbe used for new systems.

Use of TLS 1.2 is the current best practice, but requires careful configuration if it is to bedeployed securely. TLS 1.3 is a draft, but will likely represent best security practice once released,and new systems should be designed such that they can easily transition to TLS 1.3 quickly onceit is available.

11

5 Key Exchange AlgorithmsThe first component that must be chosen for a cipher suite is the key exchange algorithm. Beforeany information can be exchanged securely the client and server must negotiate a shared secretin the form of a secret key. Various algorithms are available for achieving this in TLS, only someof which are still deemed to provide an acceptable level of security by the Internet’s governingorganisation the IETF in their best practice document RFC 7525[32].

The different algorithms available will be discussed in terms of their suitability for use, howevera detailed discussion of the mechanics of their operation is beyond the scope of this document.

5.1 RSA (Key Exchange)While Rivest–Shamir–Adleman (RSA) was one of the very first key exchange algorithms it is stillconsidered secure. It can be a suitable fall-back for key exchange where no other secure algorithmis supported by one end of the connection. While it is generally slower than other key exchangealgorithms RSA does not provide forward secrecy, although the use cases concerned with controlprotocols do not require forward security necessarily[33]. However it is generally considered bestpractice to use forward secrecy where possible.

At the time of writing TLS 1.3 does not propose to support RSA key exchange. Given TLS 1.3is approaching approval this is unlikely to change[24].

5.2 ECDHEElliptic-curve Diffie–Hellman Ephemeral (ECDHE) is widely used and adopted, and is secure aslong as used with strong curves, and a key length of at least 256 bits. It is used by many browsersand servers and will be used as part of TLS 1.3. There are some technical cryptographic questionsaround the NSA/NIST curves used by ECDHE, however ECDHE is generally favoured over DHEdue to the difficulties of using long key lengths for DHE in TLS.

5.3 DHEWhile fundamentally secure in and of itself, Diffie-Hellman Ephemeral (DHE) in TLS 1.2 suffersfrom a problem whereby cipher suite negotiation can easily fail, causing the client to revert to aless secure connection unnecessarily. Because mis-configuration with DHE is relatively commonGoogle have decided to remove DHE based cipher suites from Chrome as of mid 2016[34]. DHE hasa few other problems, is typically slower than ECDHE[35] and some clients do not support DHEgroups above 1024 bits making it hard to raise the TLS group size for DHE above 1024 bits[17].At the present time the suggested key length for Diffie Hellman based keys is 2048 bits [32].

It appears that TLS 1.3 will fix these issues with DHE, but for the time being ECDHE is thepreffered algorithm.

5.4 Other AlgorithmsWhile TLS 1.2 does support other key exchange algorithms they are not recommended for useand/or are not widely implemented[17][32].

5.5 Section SummaryKey exchange algorithms should be used in this priority order: ECDHE, DHE, RSA, and it isimportant that the priority order specified by the server is respected. The DHE group size shouldbe set to 1024 bits, and the use of DHE should be kept under review as use with a 2048 bit keywould be preferable. At present it is thought that attacks on DHE with 1024 bit group sizes areonly achievable for state actors.

12

ECDHE should be used with curves of at least 256 bits and is the preferred algorithm choice.Use of RSA should be phased out, but be included for backward compatibility especially if forwardsecrecy is not required. Where used RSA should be used with a key length of at least 2048 bits.

The transition to TLS 1.3 will significantly simplify the choice of key exchange algorithms andparameters, by effectively removing any permutations that are thought to be insecure.

13

6 Key Authentication AlgorithmsThe second component of the cipher suite is its key authentication algorithm. The key authentica-tion algorithm is the part of the cipher suite that is responsible for authenticating that certificatespresented during the TLS exchange genuinely belong to the entity presenting them (be that clientor server). It does this by generating and then later verifying the signature provided in certificates.In order to verify certificates signed by a CA it requires the root certificate of the CA, which isstored on the local machine, and the public key of the server.

6.1 RSA (Key Authentication)Rivest–Shamir–Adleman (RSA) has been used for key authentication for some time on the publicInternet, and is by far the most widely used key authentication algorithm at the present time.However RSA requires longer key lengths than competing alternatives such as ECDSA if it is tobe secure - typically 2048 bit key lengths are recommended for RSA compared to 256 bits forECDSA[36].

Questions have been asked as to how long RSA can remain secure, with some experts predictingthat it could be broken in as little as 5 years.

6.2 ECDSAThe Elliptic Curve Digital Signature Algorithm (ECDSA) uses elliptic-curve cryptography fordigital signature generation instead of factorisation of semi-primes, allowing it to have a shorterkey length than RSA. It is not currently widely adopted, with the vast majority of websites stillpreferring to use RSA, probably due to better client support and familiarity with RSA [36][37].

ECDSA signatures require less CPU time to calculate than a similarly secure RSA signature,but take more CPU time to verify[37][38]. As such they are viewed as being better for serverperformance, but slower for clients.

Many view elliptic curve algorithms such as ECDSA as a likely successor to RSA if it becomesbroken in the future, and as such there is a drive to increase adoption.

6.3 DSAThe Digital Signature Algorithm (DSA) is similar to ECDSA, but uses the same mathematicalproblem of semi-prime factorisation used by RSA, rather than the elliptic curves used in ECDSA.It therefore requires the same key size as RSA, but is not as widely adopted. There is thereforelittle motivation to implement it, and it will not be included in TLS 1.3[39].

6.4 Section SummaryRSA is relatively secure provided key lengths of 2048 bits are used. It is widely implemented, andthis is un-likely to change in the near future. ECDSA is starting to see some use, due to its shorterkey length and reduced server loading, and the fact that it is thought that it is less likely to bebroken in the next few years than RSA. Both RSA and ECDSA are currently proposed for use inTLS 1.3[24]. Ideally devices should support both ECDSA and RSA, as this will help future proofthe devices against the already relatively long RSA keys becoming vulnerable as processors becomemore powerful while maximising backward compatibility.

14

7 Block ciphersThe next component to be selected for a cipher suite is the block cipher. Once the key exchangealgorithm has established a shared secret between the client and server the block cipher can thenbe used to provide a secure channel using symmetric encryption.

7.1 Deprecated Block ciphersA large number of previously used block ciphers in TLS are now deprecated and considered insecure,and should not be used:

• Null (No encryption)

• RC4 - Numerous attacks in existence

• RC2 - Vulnerable to related-key attacks

• DES - 56 bit key size too small for modern use

• IDEA - Prone to possible weak keys, relatively slow

• GOST - Multiple attacks, not theoretically secure

• 3DES - Vulnerable to sweet32 attack

Secure systems should ensure none of these block ciphers are in use.

7.2 AESAdvanced Encryption Standard (AES) is by far and away the most regularly used block ciphersuite at the time of writing, and has no known practical vulnerabilities against it when properlyimplemented, despite extensive research. Current best practice suggests that AES should be theonly block cipher employed for TLS servers, with a key length of at least 128 bit [17][32].

7.3 SEEDWhile cryptographically secure SEED is not widely used or implemented in SSL libraries. It shouldnot be used in TLS 1.2[17], and it will be dropped from TLS is version 1.3[24]. It is unlikely to berequired for backward compatibility outside of South Korea.

7.4 ARIAWhile cryptographically secure its limited implementation mean that it is not widely implementedin clients. ARIA is defined for TLS 1.3, but only when operating in Galois/Counter Mode (GCM)and may yet prove a useful fallback if AES is ever compromised. Block cipher modes such as GCMwill be discussed further in Section 8.

7.5 CamelliaCamellia is similar to ARIA in that, while cryptographically secure, it is implemented by very fewclients, and as such should only really need to be used if there is a very specific use case. Camelliais defined for TLS 1.3 [24].

15

7.6 Section SummarySecure systems should only enable use of the AES block chain cipher unless there is a very clearuse case for use of ARIA or Camellia, in which case these may be enabled. AES should be usedwith a key length of no less than 128 bits. Once again the introduction of TLS 1.3 will simplifycipher suite selection by omitting ciphers that are not secure.

16

8 Block cipher ModesBlock ciphers have a fixed length block that they can encrypt. A block cipher is required to beable to encrypt arbitrary length data. These longer pieces of data need to be encrypted securely,even if multiple blocks are encrypted using the same key.

A block cipher modes should prevent plaintext attacks, by ensuring that repeatedly encryptingthe same input will still produce a different output. This is often achieved through the use ofpadding and random numbers.

8.1 Cipher Block Chaining (CBC)In order to protect against plaintext attacks, CBC takes each block of plaintext and performs anXOR operation with the previous block prior to encryption as show in Figure 4. This process maythen be undone at the other end to recover the plain text. As each encrypted block is dependenton the last, even blocks containing the same data will still differ.

XOR Block Cipher

FIFO Memory

Secret Key

Plaintext Block Cipher

FIFO Memory

Secret Key

XOR Plaintext

Ciphertext

Figure 4: A basic overview of the operation of CBC.

While still effective, and widely used, the nature of this method prevents parallel encryption ofdata which affects the performance of the encryption. Badly implemented chain block ciphers canbe exploited by protocol downgrade attacks (e.g. POODLE) including in some implementations ofTLS.

CBC used with up-to-date and patched TLS implementations is secure, but should be a lowerpreference than GCM modes, which address many of the issues with CBC. CBC will not be includedin TLS 1.3.

8.2 Galois/Counter Mode (GCM)GCM operates very differently to CBC. In GCM blocks are numbered, and this number encryptedwith the encryption algorithm (often AES). The message is then XORed with the result. Galoismultiplication is then used to combine the cipher text with an authentication code to produce a tagfor verifying the integrity of the data [40]. The encrypted text then contains the initialisation vector,cipher text and authentication code. When using GCM it is essential that a different InitialisationVector (IV) is used for each session. An illustration of this process is given in Figure 5.

Correctly implemented GCM is considered secure, and is parallelisable meaning it is moreperformant than CBC. As a result GCM is generally seen as the preferred block cipher mode formodern encryption.

17

Figure 5: A basic overview of the operation of GCM.

8.3 Counter with CBC MAC (CCM)CCM is similar to GCM, but authentication is done on the plaintext rather than the cipher text,and it cannot be parallelised. Both these properties make it desirable to use GCM for mostapplications.

8.4 Section SummarySecure systems should prioritise use of GCM block cipher mode, but may also support CBC whereit is required for backward compatibility. It should be noted that CBC will not be available in TLS1.3, and care should be taken to use up to date TLS implementations if using CBC.

18

9 Message Authentication Code AlgorithmsMessage authentication codes are used to verify data integrity. It should be possible to verify datausing the data and the hash, but it should be impossible to recover the original data from the hashalone.

9.1 SHA-256/384Defined in SHA-3 these are currently the preferred hashing algorithms for TLS 1.2[17]. It is possiblethat these algorithms may be replaced with AEAD ciphers in TLS 1.3, but are currently preferablein TLS 1.2 for backward compatibility reasons.

9.2 AEADUsing AEAD the MAC is produced as part of the encryption process. The benefit of using AEADover a Secure Hashing Algorithm (SHA) is principally in its simplicity of configuration, however itis often not supported in older clients.

9.3 Deprecated AlgorithmsSeveral of the MAC algorithms included in TLS 1.2 have been compromised, and should not beused.

MD5 Has been found to be less secure than previously thought, and has multiple cryptographicfailings. It should only be used to protect against unintentional data corruption, and not forsecure applications[41].

SHA-0 Has been conclusively broken, and should not be used for secure applications[42].

SHA-1 Has been reduced in strength[43]. Migration to SHA-256 is encouraged[17].

9.4 ConclusionSecure technologies support SHA-256/384, and should not use older hashing algorithms such asSHA-1 unless essential for legacy client support. Where this is done two certificates should bepresented, so that clients that support newer hashing algorithms may still make still make use ofthem[44].

19

10 Other Server SettingsThe configuration of TLS does not just depend on the choice of cipher suite. A range of otherconfiguration options are available, some of which can substantially impact on security. Thissection provides a discussion of some of the most significant of these settings, some of whichenhance security, others of which may weaken it.

10.1 HTTP Strict Transport Security (HSTS)This should be enabled to protect against protocol downgrade attacks and cookie hijacking. HSTSallows the server to declare to clients that it will only ever communicate with clients using secureHTTP, not plaintext HTTP. This should of course only be implemented where it is anticipatedthat the server will only ever use secure HTTP to communicate with clients. HSTS is specified inRFC 6797 [45], and its use is considered best practice in secure environments[46].

10.2 Server Name Indication (SNI)SNI is defined in RFC 3546[47] and is a technique used on servers running multiple virtual hosts,which share an IP address. In this situation a server may provide all the certificates for the virtualhosts it operates, and let the client decide which should be used.

While this does not directly impact on security it is a useful extension to TLS when implement-ing with virtual hosts, and is useful to be mindful of if a server appears to return some certificateswhich does not match the domain when it has presented multiple certificates.

10.3 Certificate Common Name (CN) and Subject Alternative Name (SAN)sA Common Name (CN) is a field on the certificate presented to the client by the server and isdefined in RFC 3280[48]. This field normally contains the fully qualified DNS name of the serverthe certificate applies to. Only one domain or sub-domain can be specified in this field, meaningthat a separate certificate would be needed for each domain and sub-domain the server operates.

As a result use of the CN field on certificates has been deprecated in favour of the SubjectAlternative Name (SAN) extension, which is defined in RFC 5280[49]. This field may list all thedomains and sub-domains presented by the server, and may make use of wild-cards for sub-domains.

Current best practice as defined in RFC 6125[50] is to move away from use of the CommonName field, and instead use the subjectAlternative field, but not to use wild-card operators. Inpractice it is sensible to list the primary domain for a server in the Common Name field for backwardcompatibility but also ensure it appears in the SAN list for newer clients. Similarly clients shouldfirst check the SAN list where available, and only if no match for the domain can be found in thatlist then check for a Common Name field.

10.4 HTTP Public Key Pinning (HPKP)HPKP is an HTTP header defined in RFC 7469[51] that allows a server to declare that it will alwaysuse a particular public key. The intention behind this is that an attacker cannot impersonate awebsite without holding its private key.

HPKP has received criticism in the security community for being too easy to mis-configure, oftenwith the disastrous result of clients refusing to connect to the server in future[52][53]. Furthermorea malicious attacker could permanently prevent clients accessing a server by publishing fake HPKPheaders.

This is not just a hypothetical issue: visitors to website Smashing Magazine recently sawsecurity warnings in their browsers after visiting the site after website administrators mis-configuredHPKP headers [54]. As a result of these concerns Google Chrome (the only major desktop browserto have implemented the spec) has deprecated it as of Chrome 67. [55].

20

As a result of these issues use of HPKP should be avoided.

10.5 Disabling Session TicketsEstablishing a TLS session, and the corresponding handshake, is quite resource intensive. As aresult TLS defines a method that allows a client to hold a session ticket, which it may use to resumea previous session with the server without the server having to hold any state. This is defined inRFC 5077 [56].

Disabling session tickets ensures forward secrecy, but will impact on the performance of TLSconnections. As clients will not be able to resume TLS sessions with this disabled there will begreater client and server side CPU load, and requests will take longer to complete.

Implementers should take a decision on whether guaranteed forward security or performanceshould be optimised - for many use cases in the broadcast industry performance may be preferred.

10.6 SSL CompressionSSL compression can be exploited by the CRIME attack[57], and should be turned off to protectusers using older browsers. Given the restricted protocol support suggested it is unlikely this willaffect many users[17].

10.7 HTTP/2 ConsiderationsHTTP/2 (RFC 7540)[5] places certain constraints on TLS. Implementations must use TLS 1.2 orhigher and must support SNI. Where TLS 1.2 is used the following also applies:

• Compression must be disabled.

• Renegotiation must be disabled.

• This can impact the use of client authentication.

• Limits on minimum key exchange sizes must be implemented.

• Implementations should not use any cipher suites included in the black list.

• Implementations that do not satisfy the above criteria may cause interoperability problemsif using HTTP/2.

21

11 Considerations for Resource Limited Devices11.1 Resource ConstraintsMany of the algorithms discussed in this document require significant extra resources comparedto using plain HTTP[58]. For traditional IT hardware running large web servers on the publicInternet this overhead represents a relatively small proportion of the server’s resources. Howeverfor compute constrained embedded devices commonly found in the broadcast industry this extraoverhead can present a significant challenge.

RFC 7925[59] gives guidance for use of TLS with resource constrained devices. While itsfocus is on Internet of Things (IoT) devices its guidance is still relevant here. It suggests use ofTLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as defined in RFC 7251[60]. This offers aslightly reduced level of security compared to the other cipher suites supported, so should only beused where one of both devices have significant resource constraints (e.g. embedded devices).

The load on an embedded device can be reduced further by the pre-sharing of a secret betweenclient and server, preventing the need for the resource intensive key exchange step. This wouldhowever require a bootstrapping process out-of-band before any secure communication could takeplace.

Other solutions for overcoming the resource constraints may include increasing the processingpower available, either through use of more or faster CPUs, using hardware acceleration for certaincryptographic functions or reducing the overhead of other components such as the web server.

11.2 Random Number GenerationGood cryptography is reliant on the generation of high quality random numbers. Use of predictablenumbers leaves the communication vulnerable. Embedded devices and virtual machines in par-ticular lack many of the sources of randomness typically relied on for generating randomness ingeneral purpose computers. For example a general purpose computer may use mouse movementsor the timing of keystrokes to generate randomness.

RFC 7925 suggests the possibility of using dedicated crypto chips for generating randomness[59]. In the case of FPGAs it is possible to use meta-stability [61] or clock jitter[62] as a goodsource of randomness.

22

12 Conclusion and RecommendationsThis document has undertaken a detailed analysis of the methods available for securing HTTPcommunications using TLS. NMOS HTTP-based APIs would benefit from the good practice out-lined in the previous chapters. In order to ensure secure and widely compatible deployments, thisreport provides the below recommendations for the use of HTTP/TLS, considered best practice asof May 2018.

Note that the state of the art is constantly changing to adapt to new threats, and the informationhere may only be relevant for a relatively short period. Good security practice should always includemaintaining an awareness of threats and innovations. To assist with this, suggested further readingresources are provided in Appendix A.

When setting up a server to use TLS there are a number of tools that may be used to ensurethat the configuration used meets the latest security best practice. A selection of such tools isgiven in Appendix B.

12.1 Protocol RecommendationsSecure NMOS APIs should only offer connections using TLS 1.2 at the present time and be readyto implement TLS 1.3 as soon as practical. Indications are that TLS 1.3 will provide a dramaticsimplification for the TLS protocol, making it far harder to provide a connection using TLS thatis insecure.

APIs should not use TLS versions 1.1 or 1.0, and should not use the SSL protocol at all.

12.2 Cipher Suite RecommendationsBased on the findings in the report, API servers and clients should support the following ciphersuites, with the following server priority, unless they are heavily constrained by resources:

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8

Devices heavily constrained by resources could omit RSA certificate based TLS. This does notcompromise security, but does reduce backward compatibility. It is important to ensure that thedevice will be operating in an environment where ECDHE certificates are available, which may notbe the case for all corperate certificate authorities. This gives a list of suites as follows:

23

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8

Where resources are extremely limited, NMOS APIs could choose to support the followingcipher suite only. If this is permitted all NMOS APIs would need to support this cipher suite.

• TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8

12.3 Server Setting RecommendationsServers hosting secure NMOS APIs should:

• Disable SSL Compression

• Use HSTS where appropriate (i.e secure HTTP is always in use)

• Not use Public Key Pinning

• Consider Disabling Session Tickets

24

AcknowledgementsThis document has benefitted from significant peer review, both from within and outside of theBBC. The author would like to thank the following for their contributions:

Those outside the BBC who have reviewed this document, including Richard Cartwright at Stream-punk Media and Arne Bönninghoff, Jasper Peeters and Vasileios Tachtsidis at Riedel Communica-tions.

BBC Head of Production Architecture Mike Ellis and the BBC Information Security team, in par-ticular Gemma Adams and Peter Gilfillan.

Finally to colleagues in BBC R&D including Andrew Bonney, Peter Brightwell, Dave Butler, ChrisNorthwood, Lucas Pardue, Chris Poole, Phil Tudor and Rob Wadge.

25

GlossaryAES Advanced Encryption Standard.

AMWA Advanced Media Workflow Association.

CA Certificate Authority.

CBC Cipher Block Chaining.

CCM Counter with CBC MAC.

CN Common Name.

DHE Diffie-Hellman Ephemeral.

DSA Digital Signature Algorithm.

DSS Data Security Standard.

ECDHE Elliptic-curve Diffie–Hellman Ephemeral.

ECDSA Elliptic Curve Digital Signature Algorithm.

GCM Galois/Counter Mode.

HPKP HTTP Public Key Pinning.

HSTS HTTP Strict Transport Security.

HTTP Hyper Text Transfer Protocol.

HTTPS Hyper Text Transfer Protocol Secure.

IETF Internet Engineering Task Force.

IV Initialisation Vector.

MAC Message Authentication Code.

NMOS Networked Media Open Specifications.

OWASP Open Web Application Security Project.

PCI Payment Card Industry.

RFC Request For Comments.

RSA Rivest–Shamir–Adleman.

SAN Subject Alternative Name.

SHA Secure Hashing Algorithm.

SNI Server Name Indication.

SSL Secure Socket Layer.

TLS Transport Layer Security.

26

References[1] BBC News Online. How France’s TV5 was almost destroyed by ’Russian hackers’. 2016. url:

http://www.bbc.co.uk/news/technology-37590375.[2] The Register. TV5Monde was saved from airtime-KO hack by unplugging infected box. 2016.

url: https://www.theregister.co.uk/2016/10/10/tv5monde_hack/.[3] Advanced Media Workflows Association. Network Media Open Specifications webpage. 2018.

url: https://www.nmos.tv/.[4] Roy T. Fielding and Julian Reschke. Hypertext Transfer Protocol (HTTP/1.1): Message

Syntax and Routing. RFC 7230. June 2014. doi: 10.17487/RFC7230.[5] Mike Belshe, Roberto Peon, and Martin Thomson. Hypertext Transfer Protocol Version 2

(HTTP/2). RFC 7540. May 2015. doi: 10.17487/RFC7540.[6] Mike Bishop. Hypertext Transfer Protocol (HTTP) over QUIC. Internet-Draft draft-ietf-quic-

http-12. Work in Progress. Internet Engineering Task Force, May 2018. 38 pp.[7] Mark Nottingham, Patrick McManus, and Julian Reschke. HTTP Alternative Services. RFC

7838. Apr. 2016. doi: 10.17487/RFC7838.[8] IBM Corporation. How SSL and TLS provide identification, authentication, confidentiality,

and integrity. 2014. url: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10670_.htm.

[9] Microsoft Corporation. How TLS/SSL Works. 2003. url: https://technet.microsoft.com/en-gb/library/cc783349(v=ws.10).aspx.

[10] Jonathan Katz. “Public-Key Cryptography”. In: Handbook of Information and Communica-tion Security. Ed. by Peter Stavroulakis and Mark Stamp. Berlin, Heidelberg: Springer BerlinHeidelberg, 2010, pp. 21–34. isbn: 978-3-642-04117-4. doi: 10.1007/978-3-642-04117-4_2.

[11] IBM Corporation. An overview of the SSL or TLS handshake. 2014. url: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10660_.htm.

[12] Michael A Nielsen and Isaac L Chuang. Quantum computation and quantum information.Cambridge University Press, 2010.

[13] Microsoft Corperation. Replay Attacks. 2017. url: https://docs.microsoft.com/en-us/dotnet/framework/wcf/feature-details/replay-attacks.

[14] P. Syverson. “A taxonomy of replay attacks [cryptographic protocols]”. In: Proceedings TheComputer Security Foundations Workshop VII. June 1994, pp. 187–191. doi: 10.1109/CSFW.1994.315935.

[15] Ron Rivest. Unconditionally Secure Authentication. 1997. url: http://web.mit.edu/6.857/OldStuff/Fall97/lectures/lecture3.pdf.

[16] Alan O. Freier, Philip Karlton, and Paul C. Kocher. The Secure Sockets Layer (SSL) ProtocolVersion 3.0. RFC 6101. Aug. 2011. doi: 10.17487/RFC6101.

[17] Open Web Application Security Project. Transport Layer Protection Cheat Sheet. Mar. 2017.url: https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet.

[18] David Wagner and Bruce Schneier. “Analysis of the SSL 3.0 Protocol”. In: Proceedings of the2Nd Conference on Proceedings of the Second USENIX Workshop on Electronic Commerce -Volume 2. WOEC’96. Oakland, California: USENIX Association, 1996, pp. 4–4.

[19] Bodo Möller, Thai Duong, and Krzysztof Kotowicz. “This POODLE bites: exploiting theSSL 3.0 fallback”. In: Security Advisory (2014).

[20] Richard Barnes et al. Deprecating Secure Sockets Layer Version 3.0. RFC 7568. June 2015.doi: 10.17487/RFC7568.

27

[21] Christopher Allen and Tim Dierks. The TLS Protocol Version 1.0. RFC 2246. Jan. 1999.doi: 10.17487/RFC2246.

[22] Tim Dierks and Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1.RFC 4346. Apr. 2006. doi: 10.17487/RFC4346.

[23] Eric Rescorla and Tim Dierks. The Transport Layer Security (TLS) Protocol Version 1.2.RFC 5246. Aug. 2008. doi: 10.17487/RFC5246.

[24] Eric Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3. Internet-Draftdraft-ietf-tls-tls13-24. Work in Progress. Internet Engineering Task Force, Feb. 2018. 155 pp.

[25] Requirements and Security Assessment Procedures. Online. Data Security Standard, Apr.2016.

[26] Salesforce. TLS support status by web browser. url: https : / / help . salesforce . com /articleView?id=000220586%5C&language=en_US%5C&type=1.

[27] Wikipedia. Transport Layer Security: Web Browsers. url: https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers.

[28] Microsoft Corperation. Support for older versions of Internet Explorer ended. url: https://www.microsoft.com/en-us/windowsforbusiness/end-of-ie-support.

[29] Awio Web services LLC. W3 Counter Trends. url: https://www.w3counter.com/trends.[30] Ed Bott. Who’s still using Internet Explorer? And why won’t they upgrade? Dec. 2015. url:

http://www.zdnet.com/article/whos-still-using-internet-explorer-and-why-wont-they-upgrade/.

[31] Alex Hern. RIP IE: Older versions of Microsoft’s browser lose support next week. Jan. 2016.url: https://www.theguardian.com/technology/2016/jan/07/internet-explorer-older-versions-microsofts-browser-lose-support-next-week.

[32] Yaron Sheffer, Ralph Holz, and Peter Saint-Andre. Recommendations for Secure Use of Trans-port Layer Security (TLS) and Datagram Transport Layer Security (DTLS). RFC 7525. May2015. doi: 10.17487/RFC7525.

[33] Qualys inc. SSL Labs: Deploying Forward Secrecy. June 2013. url: https://blog.qualys.com/ssllabs/2013/06/25/ssl-labs-deploying-forward-secrecy.

[34] David Benjamin. DHE-based cipher suites. Nov. 2015. url: https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/dYyhKHPnrI0.

[35] L. S. Huang et al. “An Experimental Study of TLS Forward Secrecy Deployments”. In: IEEEInternet Computing 18.6 (Nov. 2014), pp. 43–51. issn: 1089-7801. doi: 10.1109/MIC.2014.86.

[36] Nick Sullivan. ECDSA: The digital signature algorithm of a better internet. Mar. 2014. url:https://blog.cloudflare.com/ecdsa- the- digital- signature- algorithm- of- a-better-internet/.

[37] Rick Andrews. Symantec’s View of the Current State of ECDSA on the Web. 2015. url:https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryptography-standards/documents/presentations/session2-andrews-rick.pdf.

[38] Nicholas Jansma and Brandon Arrendondo. “Performance comparison of elliptic curve andrsa digital signatures”. In: nicj. net/files (2004).

[39] Sean Turner. [TLS] consensus: remove DSA from TLS 1.3. 2015. url: https://www.ietf.org/mail-archive/web/tls/current/msg17680.html.

[40] David McGrew and John Viega. “The Galois/counter mode of operation (GCM)”. In: sub-mission to NIST Modes of Operation Process 20 (2004).

28

[41] Xiaoyun Wang and Hongbo Yu. “How to Break MD5 and Other Hash Functions”. In: Ad-vances in Cryptology – EUROCRYPT 2005. Ed. by Ronald Cramer. Berlin, Heidelberg:Springer Berlin Heidelberg, 2005, pp. 19–35. isbn: 978-3-540-32055-5.

[42] Xiaoyun Wang, Hongbo Yu, and Yiqun Lisa Yin. “Efficient Collision Search Attacks on SHA-0”. In: Advances in Cryptology – CRYPTO 2005. Ed. by Victor Shoup. Berlin, Heidelberg:Springer Berlin Heidelberg, 2005, pp. 1–16. isbn: 978-3-540-31870-5.

[43] Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu. Collision search attacks on SHA1. 2005.[44] Ivan Ristic. SHA1 Deprecation: What you need to know. Sept. 2014. url: https://blog.

qualys.com/ssllabs/2014/09/09/sha1-deprecation-what-you-need-to-know.[45] Jeff Hodges, Collin Jackson, and Adam Barth. HTTP Strict Transport Security (HSTS). RFC

6797. Nov. 2012. doi: 10.17487/RFC6797.[46] Aijayanti Korde. https://blog.qualys.com/securitylabs/2016/03/28/the-importance-of-a-proper-

http-strict-transport-security-implementation-on-your-web-server. 2016. url: https://blog.qualys.com/securitylabs/2016/03/28/the-importance-of-a-proper-http-strict-transport-security-implementation-on-your-web-server.

[47] Simon Blake-Wilson et al. Transport Layer Security (TLS) Extensions. RFC 3546. June 2003.doi: 10.17487/RFC3546.

[48] Russ Housley et al. Internet X.509 Public Key Infrastructure Certificate and Certificate Re-vocation List (CRL) Profile. RFC 3280. May 2002. doi: 10.17487/RFC3280.

[49] Sharon Boeyen et al. Internet X.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile. RFC 5280. May 2008. doi: 10.17487/RFC5280.

[50] Peter Saint-Andre and Jeff Hodges. Representation and Verification of Domain-Based Ap-plication Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX)Certificates in the Context of Transport Layer Security (TLS). RFC 6125. Mar. 2011. doi:10.17487/RFC6125.

[51] Chris Evans, Chris Palmer, and Ryan Sleevi. Public Key Pinning Extension for HTTP. RFC7469. Apr. 2015. doi: 10.17487/RFC7469.

[52] Scott Helme. I’m giving up on HPKP. Apr. 2017. url: https://scotthelme.co.uk/im-giving-up-on-hpkp/.

[53] Ivan Ristic. Is HTTP Public Key Pinning Dead? Sept. 2016. url: https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-key-pinning-dead.

[54] Matt Miilmann. https://www.smashingmagazine.com/be-afraid-of-public-key-pinning/. Oct.2016. url: https://www.smashingmagazine.com/be-afraid-of-public-key-pinning/.

[55] Chris Palmer. Intent To Deprecate And Remove: Public Key Pinning. Oct. 2017. url: https:/ / groups . google . com / a / chromium . org / forum / # ! msg / blink - dev / he9tr7p3rZ8 /eNMwKPmUBAAJ.

[56] Pasi Eronen et al. Transport Layer Security (TLS) Session Resumption without Server-SideState. RFC 5077. Jan. 2008. doi: 10.17487/RFC5077.

[57] Yaron Sheffer, Ralph Holz, and Peter Saint-Andre. Summarizing Known Attacks on TransportLayer Security (TLS) and Datagram TLS (DTLS). RFC 7457. Feb. 2015. doi: 10.17487/RFC7457.

[58] Cristian Coarfa, Peter Druschel, and Dan S. Wallach. “Performance Analysis of TLS WebServers”. In: ACM Trans. Comput. Syst. 24.1 (Feb. 2006), pp. 39–69. issn: 0734-2071. doi:10.1145/1124153.1124155.

[59] Hannes Tschofenig and Thomas Fossati. Transport Layer Security (TLS) / Datagram Trans-port Layer Security (DTLS) Profiles for the Internet of Things. RFC 7925. July 2016. doi:10.17487/RFC7925.

29

[60] Dr. David A. McGrew et al. AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suitesfor TLS. RFC 7251. June 2014. doi: 10.17487/RFC7251.

[61] K. H. Tsoi, K. H. Leung, and P. H. W. Leong. “Compact FPGA-based true and pseudo ran-dom number generators”. In: 11th Annual IEEE Symposium on Field-Programmable CustomComputing Machines, 2003. FCCM 2003. Apr. 2003, pp. 51–61. doi: 10.1109/FPGA.2003.1227241.

[62] S. H. M. Kwok and E. Y. Lam. “FPGA-based High-speed True Random Number Generatorfor Cryptographic Applications”. In: TENCON 2006 - 2006 IEEE Region 10 Conference.Nov. 2006, pp. 1–4. doi: 10.1109/TENCON.2006.344013.

30

Appendix A Useful SourcesAs highlighted in this report, good security practice is constantly changing and it is importantto actively monitor the latest developments. During the compilation of this report the followingsources were found to be of particular help in establishing current best practice, and may helpothers wishing to do the same.

A.1 IETF RFCsA great deal of the information contained in this report is based on Request For Comments (RFC)documents produced by the Internet Engineering Task Force (IETF). These documents are carefullymanaged - and checking back against important ones can be a useful way of checking for revisionswhich may have security implications. Where used these have been referenced, but of particularnote are:

RFC 5246 [23] - documents TLS 1.2

RFC 7525 [32] - documents best practice for use of TLS.

IETF Draft 13-24 [24] - the latest TLS 1.3 draft at the time of writing. In time this should linkto the full TLS 1.3 RFC when published.

A.2 OWASPThe Open Web Application Security Project (OWASP) is a charitable organisation dedicated toproviding best practice and promote open security standards impartially and for free. Their websiteas a whole merits exploration (www.owasp.org), however of particular help when compiling thisreport is the OWASP TLS cheat sheet[17] which gives a quite extensive reference of best practicefor setting up servers with TLS.

A.3 Qualys BlogQualys are one of the largest and oldest providers of IT security solutions in the world, and arewidely respected in the Internet security community. Their blog (https://blog.qualys.com/) makesexcellent reading and highlights important security issues as they arise.

A.4 Google Security BlogGoogle have campaigned consistently for widespread adoption and strict implementation of TLSacross the web. While much of their security blog (security.googleblog.com) focuses on their ownproducts there are also many articles that have wider implications.

A.5 Security BloggersThe web security community is extremely active, with a number of security researchers bloggingabout their work. They can often be a rich source of information and advice, and are generallyvery active on social media. Of particular interest when compiling this report were Scott Helme(scotthelme.co.uk) and Troy Hunt (troyhunt.com). Following researchers such as these can provideimportant background and context to the changing security landscape.

31

Appendix B TLS Verification ToolsAs this document demonstrates, setting up a server to use TLS can be a complex task that caneasily be done incorrectly. Furthermore the rapid pace of change in best practice makes regularchecking of compliance important.

There are several free tools available for checking the configuration of servers. A few of themare listed below.

B.1 SSL Server Testhttps://www.ssllabs.com/ssltest/An extremely powerful tool that gives a security rating for sites based on a very detailed set ofparameters. It also offers guidance for improving security in its reports where required. Howeverit is only suitable for checking internet facing servers.

B.2 testssl.shhttps://testssl.sh/testssh.sh is an open source command line script for testing the confiugration of TLS/SSL servers.Un-like SSL Server Test it is run on the user’s machines, meaning it is suitable for machines on alocal network, and results are known only to the user.

B.3 Mozilla Observatoryhttps://observatory.mozilla.org/A similar tool to SSL Server Test, but uses a slightly different set of criteria.

32