WHITE PAPER:

SSL FOR APPS

BEST PRACTICES FOR DEVELOPERS

White Paper

SSL for Apps

Best Practices for Developers

White Paper: SSL for Apps Best Practices for Developers

SSL for Apps Best Practices for Developers

Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chain Building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
End-entity Certificate Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Intermediate Certificate Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

White Paper: SSL for Apps Best Practices for Developers

Introduction
SSL/TLS is a core enabling technology that is critical for securing communications.
For more than a decade, SSL has provided a solid, stable platform for ensuring
security and trust online, enabling the growth of e-commerce and other industries.
SSL is a fundamentally sound technology that provides confidentiality,
authentication, and integrity. The most significant challenge facing the SSL
ecosystem is not a technological flaw or limitation, but rather the way it is being
implemented and the practices around it.
Several University researchers have recently published reports indicating
widespread errors and shortcomings in non-browser applications that act as the
client of an SSL/TLS connection. These issues result from flawed implementations
of SSL in the applications or in SDKs or APIs used by the applications. This is
an issue that needs to be addressed because today more and more services are
offered through non-browser application interfaces. Often but not always these
applications are designed for use on mobile devices. As mobile device adoption
increases, the use of these applications will increase and thus the impact of these
security implementation shortcomings will grow as well.
This paper lists necessary steps to take to create a stronger, more trustworthy
SSL implementation. All SSL Client non-browser applications should follow
all the practices in this document to ensure the high level of authentication,
confidentiality and integrity promised by SSL are achieved.
Chain Building
During the SSL handshake, the server will return one or more certificates to the
client to build a chain of trust. Dont assume that the certificates for this chain are
returned in any particular order. Misconfigured web servers may also return more
certificates than necessary to build a chain, or they may fail to return certificates
that are needed to build a chain. If a certificate contains a caIssuers entry in
its authorityInfoAccess extension, that entry will indicate a protocol and
location where you can obtain the issuing certificate. This information may help
you locate certificates in the chain that are not returned by the server.
Note: If a self-signed root certificate (defined as a certificate whose Issuer Name
is the same as its Subject Name) is returned by the server, it should be ignored. No
certificate should be trusted simply because the server returns it.
Try to build a certificate chain to determine which certificate is the end-entity
SSL certificate. The chain can be built either with authorityKeyIdentifier/
subjectKeyIdentifier (AKI/SKI) extension values (the AKI value in a
certificate should match the SKI value in the certificate that signed it), or with
Issuer Distinguished Name / Subject Distinguished Name values (the Issuer
Distinguished Name value in a certificate should match the Subject Distinguished
Name value in the certificate that signed it).

White Paper: SSL for Apps Best Practices for Developers

Cryptographically verify that the chain from end-entity certificate to trusted

root certificate or intermediate certificate is valid (that is, validate that the
intermediates public key signed the end-entity certificate, the root certificates
public key signed the intermediate certificate, etc.). More information about
building certificate chains can be found in Section 6 of RFC 5280.
Think carefully about which certificates you will ultimately trust. It is quite secure
to require the server to return a particular end-entity SSL certificate; however
the downside to this type of implementation is that your application will break
when the certificate is renewed or replaced. A more convenient practice is to allow
any end-entity SSL certificate that is signed by a particular trusted intermediate
certificate, although at some point even the intermediate certificate will be
renewed or replaced. It is extremely risky to trust all SSL certificates that chain up
to all root certificates in the platforms trust store. Pick only one trusted root, but
avoid trusting all end-entity certificates that chain up to that root. This practice is
risky because it expands the pool of certificates that you will trust, possibly beyond
what you intend. A good compromise would be to require that the end-entity SSL
certificate chains up to a particular trusted root, and is signed by an intermediate
certificate with a specific Common Name.
End-entity Certificate Checks
When comparing strings extracted from certificates, note that they are represented
in the certificate as a byte length, followed by that number of bytes. Do not
assume that the string is null-terminated. Also note that strings may be encoded in
different types, including UTF-8.
For the end-entity SSL certificate, perform these checks:
1. Verify that the fully-qualified domain name or IP address to which the
connection was created appears in either the Common Name field of the
Distinguished Name, or in one of the Subject Alternative Name (SAN)
extension values.
Note:
Newer certificates will not contain a Common Name field at all; rather
they will use SAN values.
Dont assume that the certificate contains a Common Name.
Take into account proper wildcards (*.example.com or *.mail.example.
com, for example).
The certificate should be rejected if it contains more than one Common
Name value, or if the address to which the connection was created does
not match the Common Name or any SAN values.
Take into account International Domain Names (IDNs) (see http://www.
unicode.org/draft/faq/idn.html). IDN certificates should contain a
punycode version of the Unicode domain name in the Common Name
or SAN field.

White Paper: SSL for Apps Best Practices for Developers

2. The current date/time must be greater than the notBefore time in the
certificate, and less than the notAfter time in the certificate. Note that date/
times are represented in GMT. If you cant be sure that your application has an
accurate time source, you may wish to err on the side of caution and accept a
certificate that will not be valid for a few more days, or has just expired in the
last few days.
3. If the certificate contains a basicConstraints extension, the cA flag must be set
to false and the pathLenConstraint must be set to 0.
4. If the certificate contains a keyUsage extension, the digitalSignature
and keyEncipherment bits must be set.
5. If a particular policy is expected, check that it appears in the
certificatePolicies extension.
6. If the certificate contains an extKeyUsage extension, the extension value
must be either the special anyExtendedKeyUsage value, or if it contains
special purpose OIDs, then id-kp-serverAuth must be included.
7. The certificate must contain the crlDistributionPoints extension or the
authorityInfoAccess extension with an AccessMethod value of idad-ocsp. The status of the certificate can be verified by checking CRL, OCSP,
or both (fallback from one method to the other). Verification must result in a
positive determination that the certificate has not been revoked. If the client
application caches CRLs or OCSP responses, these may be used until their
validity end date instead of making another request for a CRL or OCSP response.
8. If any other extension is marked critical, the application must be able to
recognize and understand the value of the extension. The certificate must
be rejected if it contains any critical extensions that the application does
not recognize.
Intermediate Certificate Checks
When comparing strings extracted from certificates, note that they are represented
in the certificate as a byte length, followed by that number of bytes. Do not
assume that the string is null-terminated. Also note that strings may be encoded in
different types, including UTF-8.
For each intermediate CA certificate in the chain, up to and including the
trusted intermediate certificate (if the intermediate is your trust point), perform
these checks:
1. The current date/time must be greater than the notBefore time in the
certificate, and less than the notAfter time in the certificate. Note that date/
times are represented in GMT. If you cant be sure that your application has an
accurate time source, you may wish to err on the side of caution and accept a
certificate that will not be valid for a few more days, or has just expired in the
last few days.
2. The certificate must contain a basicConstraints extension, with the cA flag set
to true.
3. The certificate must contain a keyUsage extension, with the keyCertSign
bit set.

White Paper: SSL for Apps Best Practices for Developers

4. If a particular policy is expected, check that it appears in the

certificatePolicies extension.
5. The certificate must contain the crlDistributionPoints extension or
the authorityInfoAccess extension with an AccessMethod value of
id-ad-ocsp. The status of the certificate can be verified by checking CRL,
OCSP, or both (fallback from one method to the other). Verification must result
in a positive determination that the certificate has not been revoked. If the
client application caches CRLs or OCSP responses, they may be used until their
validity end date instead of making another request for a CRL or OCSP response.
6. If the nameConstraints and/or policyConstraints extensions are
present, the application must process the constraints for all certificates in the
subtree beneath it.
7. If any other extension is marked critical, the application must be able to
recognize and understand the value of the extension. The certificate must
be rejected if it contains any critical extensions that the application does
not recognize.
Conclusion
The SSL/TLS protocol, when properly implemented, provides strong confidentiality
and integrity for communications, as well as authentication of one or both endpoint
identities. Yet unless certain checks are performed, an attacker can intercept and
modify data without detection. All SSL Client non-browser applications should
follow all the practices in this document to insure the high level of authentication,
confidentiality and integrity promised by SSL. The normative reference for this
document is RFC 5280.
SSL has been the key to trust on the Internet for more than a decade, and it will
continue to provide excellent protection against evolving cyber security threats.
Symantec is leading the way with world-class security and authentication practices,
and with what certificate authorities, browser developers, customers, consumers
and all other stakeholders can do to help build a more robust security ecosystem.
By working together as an industry to do the right thing, enforcing rigorous security
practices, maintaining an agile infrastructure, and adopting stronger security
standards, we can ensure that people have the confidence they need to connect
online now and in the future.

White Paper: SSL for Apps Best Practices for Developers

More Information
Visit our website
http://www.symantec.com/ssl
To speak with a Product Specialist in the U.S.
1-866-893-6565 or 1-650-426-5112
To speak with a Product Specialist outside the U.S.
For specific country offices and contact numbers, please visit our website.
About Symantec
Symantec protects the worlds information and is the global leader in security,
backup, and availability solutions. Our innovative products and services protect
people and information in any environment from the smallest mobile device to
the enterprise data center to cloud-based systems. Our industry-leading expertise
in protecting data, identities, and interactions gives our customers confidence
in a connected world. More information is available at www.symantec.com or by
connecting with Symantec at: go.symantec.com/socialmedia.
Symantec World Headquarters
350 Ellis Street
Mountain View, CA 94043 USA
1-866-893-6565
www.symantec.com

Copyright 2013 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo, and the Checkmark Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in
the U.S. and other countries. Other names may be trademarks of their respective owners.
UID: 131/10/13