SSL_TLS_Deployment_Best_Practices(1).pdf

(314 KB) Pobierz

SSL/TLS Deployment Best Practices

Ivan Ristić

version 1.4 (8 December 2014)

2012-2014 Qualys SSL Labs

Abstract

SSL/TLS is a deceptively simple technology. It is easy to deploy, and it just works… ex-

cept when it does not. The main problem is that encryption is not often easy to deploy

correctly.

To ensure that TLS provides the necessary security, system administrators and

developers must put extra effort into properly conﬁguring their servers and developing

their applications.

In 2009, we began our work on

SSL Labs

because we wanted to understand how TLS

was used and to remedy the lack of easy-to-use TLS tools and documentation. We have

achieved some of our goals through our global surveys of TLS usage, as well as the online

assessment tool, but the lack of documentation is still evident. This document is a step

toward addressing that problem.

Our aim here is to provide clear and concise instructions to help overworked adminis-

trators and programmers spend the minimum time possible to deploy a secure site or

web application. In pursuit of clarity, we sacriﬁce completeness, foregoing certain ad-

vanced topics. The focus is on advice that is practical and easy to follow. For those who

want more information, Section 6 gives useful pointers.

www.ssllabs.com

1. Private Key and Certiﬁcate

The quality of the protection provided by TLS depends entirely on the private key, which

lays down the foundation for the security, and the certiﬁcate, which communicates the

identity of the server to its visitors.

1.1. Use 2048-bit Private Keys

Use 2048-bit RSA or 256-bit ECDSA private keys for all your servers. Keys of this strength

are secure and should stay secure for a considerable amount of time. If you have 1024-

bit RSA keys in production, replace them with stronger keys as soon as possible. If you

believe that you need more than 2048 bits of security, consider using ECDSA keys, which

have better performance characteristics. The drawback is that there is a small number of

clients that don’t support ECDSA and that you might need to deploy RSA and ECDSA

keys in parallel to maintain good interoperability.

1.2. Protect Private Keys

Treat your private keys as an important asset, restricting access to the smallest possible

group of employees while still keeping the arrangements practical. Recommended poli-

cies include the following:

• Generate private keys and

Certiﬁcate Signing Requests

(CSRs) on a trusted com-

puter. Some CAs offer to generate keys and CSRs for you, but that’s inappropriate.

• Password-protect keys to prevent compromise when they are stored in backup sys-

tems. Private key passwords don’t help much in production because a knowledge-

able attacker can always retrieve the keys from process memory. There are hard-

ware devices that can protect private keys even in the case of server compromise,

but they are expensive and thus justiﬁable only by organizations with strict securi-

ty requirements.

• After compromise, revoke old certiﬁcates and generate new keys.

• Renew certiﬁcates every year, always with new private keys.

1.3. Ensure Sufﬁcient Hostname Coverage

Ensure that your certiﬁcates cover all the names you wish to use with a site. For ex-

ample, your main name is

www.example.com,

but you may also have

www.example.net

conﬁgured. Your goal is to avoid invalid certiﬁcate warnings, which will confuse your

users and weaken their trust.

Even when there is only one name conﬁgured on your servers, remember that you can-

not control how your users arrive at the site or how others link to it. In most cases,

you should ensure that the certiﬁcate works with and without the

www

preﬁx (e.g., for

both

example.com

and

www.example.com).

The rule of thumb is this: a secure web server

should have a certiﬁcate that is valid for every DNS name conﬁgured to point to it.

Wildcard certiﬁcates have their uses, but should be avoided if using them means exposing

the underlying keys to a larger group of people, and especially if crossing organizational

boundaries. In other words, the fewer people who have access to the private keys, the

better. Further, be aware that certiﬁcate sharing creates a bond that can be abused to

transfer vulnerabilities from one web site to all other sites that use the same certiﬁcate.

1.4. Obtain Certiﬁcates from a Reliable CA

Select a

Certiﬁcation Authority

(CA) that is reliable and serious about its certiﬁcate busi-

ness and about security. Consider the following criteria when selecting your CA:

Security posture

All CAs undergo regular audits (otherwise they wouldn’t be able to operate as CAs),

but some are more serious about security than others. Figuring out which ones are

better in this respect is not easy, but one option is to examine their security history,

and, more important, how they reacted to compromises and if they learned from

their mistakes.

Substantial market share

A CA that meets this criterion will not likely have all its certiﬁcates easily recalled,

which was the case with some smaller ones in the past.

Business focus

CAs whose activities constitute a substantial part of their business have everything

to lose if something goes terribly wrong, and they probably won’t neglect their

certiﬁcate division by chasing potentially more lucrative opportunities elsewhere.

Services offered

At minimum, your selected CA should provide support for both

Certiﬁcate Revoca-

tion List

(CRL) and

Online Certiﬁcate Status Protocol

(OCSP) revocation and pro-

vide an OCSP service with good performance. They should offer both domain-val-

idated and

Extended Validation

(EV) certiﬁcates, ideally with your choice of public

key algorithm. (Most web sites use RSA today, but ECDSA may become important

in the future because of its performance advantages.)

Certiﬁcate management options

If you need a large number of certiﬁcates and operate in a complex environment,

choose a CA that will give you good tools to manage them.

Support

Choose a CA that will give you good support if and when you need it.

1.5. Use Strong Certiﬁcate Signature Algorithms

Certiﬁcate signature security depends on the strength of the signing private key and the

strength of the used hashing function. Today, most certiﬁcates use the SHA1 hashing

function, which is considered weak and borderline insecure. The industry is currently

moving away from SHA1, which a process that must be completed by the end of 2016.

After that SHA1 certiﬁcates won’t be accepted any more.

However, because Google Chrome warns about SHA1 certiﬁcates that expire even before

the ultimate deadline,

you should immediately replace all your SHA1 certiﬁcates if they

expire after 2015. Alternatively, you could move straight away to certiﬁcates that rely on

the SHA2 algorithm family. But, before you do that, check that enough of your user base

supports SHA2. Some older clients, for example IE6 running on Windows XP Service

Pack 2 (still heavily used in some countries and organizations) don’t.

2. Conﬁguration

With correct TLS server conﬁguration, you ensure that your credentials are properly

presented to the site’s visitors, that only secure cryptographic primitives are used, and

that all known weaknesses are mitigated.

2.1. Deploy with Valid Certiﬁcate Chains

In most deployments, the server certiﬁcate alone is insufﬁcient; two or more certiﬁcates

are needed to establish a complete chain of trust. A common problem is conﬁguring the

server certiﬁcate correctly but forgetting to include other required certiﬁcates. Further,

although these other certiﬁcates are typically valid for longer periods of time, they too

expire, and when they do, they invalidate the entire chain. Your CA should be able to

provide you with all the additional certiﬁcates required.

An invalid certiﬁcate chain renders the actual server certiﬁcate invalid and results in

browser warnings. In practice, this problem is sometimes difﬁcult to diagnose because

some browsers can deal with these problems and reconstruct a complete correct chain,

and some can’t.

SHA1 Deprecation Policy

(Windows PKI blog, 12 November 2013)

Gradually Sunsetting SHA-1

(The Chromium Blog, 5 September 2014)

2.2. Use Secure Protocols

There are ﬁve protocols in the SSL/TLS family: SSL v2, SSL v3, TLS v1.0, TLS v1.1, and

TLS v1.2. Of these:

• SSL v2 is insecure and must not be used.

• SSL v3 is insecure when used with HTTP and weak when used with other proto-

cols. It’s also obsolete, which is why it shouldn’t be used.

• TLS v1.0 is largely still secure; we do not know of major security ﬂaws when they

are used for protocols other than HTTP. When used with HTTP, it can

almost

made secure with careful conﬁguration.

• TLS v1.1 and v1.2 are without known security issues.

TLS v1.2 should be your main protocol. This version is superior because it offers impor-

tant features that are unavailable in earlier protocol versions. If your server platform (or

any intermediary device) does not support TLS v1.2, make plans to upgrade at an accel-

erated pace. If your service providers do not support TLS v1.2, require that they upgrade.

In order to support older clients, you need to continue to support TLS v1.0 and TLS v1.1

for the time being. With some workarounds (explained in subsequent sections), these

protocols can still be considered secure enough for most web sites.

2.3. Use Secure Cipher Suites

To communicate securely, you must ﬁrst ascertain that you are communicating directly

with the desired party (and not through someone else who will eavesdrop), as well as

exchanging data securely. In SSL and TLS, cipher suites are used to deﬁne how secure

communication takes place. They are composed from varying building blocks with the

idea of achieving security through diversity. If one of the building blocks is found to be

weak or insecure, you should be able to switch to another.

Your goal should be thus to use only suites that provide authentication and encryption

of 128 bits or stronger. Everything else must be avoided:

• Anonymous Difﬁe-Hellman (ADH) suites do not provide authentication.

• NULL cipher suites provide no encryption.

• Export key exchange suites use authentication that can easily be broken.

• Suites with weak ciphers (typically of 40 and 56 bits) use encryption that can easi-

ly be broken.

Plik z chomika:

musli_com

Inne pliki z tego folderu:

2008_Return_Oriented_Programming(2).pdf (4147 KB)
2009_debugging_buffer_overruns_freebsd_kernel(1).pdf (338 KB)
2010_gdb(1).pdf (1957 KB)
2010_memory_corruption_attacks(2).pdf (3883 KB)
2010_ROP(1).pdf (208 KB)

SSL_TLS_Deployment_Best_Practices(1).pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: