Ssh/Tls

Secure Socket Layer and Transport Layer Security

A look at the SSL/TLS Protocol Implementation.

Table of Contents

1 Introduction 3

2 Technology Overview 4

3 Real-World Usage 6

4 Protocol Evolution 9

5 Technological Benefits 9

6 Future Implications 11

7 Conclusion 12

8 References 14

9 Appendix A - SSL Labs Test Grade A 16

10 Appendix B - SSL Labs Test Grade B 20

11 Appendix C - SSL Labs Test Grade C 25

12 Appendix D - SSL Labs Test Grade D 31

13 Appendix E - SSL Labs Test Grade E 32

14 Appendix F - SSL Labs Test Grade F 33

Introduction

In the modern digital age secure online communication has become an integral part of everyday communications and transactions. The Secure Sockets Layer protocol, commonly known as SSL, was originally designed and developed by Netscape in February of 1995. The initial 1.0 version of SSL was never released to the public and SSL 2.0 was released in February of 1995. Identified security flaws in the 2.0 version led to the development of the 3.0 version of SSL which was released in 1996 under RFC 6101. While often used interchangeably in speaking of security (SSL/TLS) Transport Layer Security was defined in RFC 2246 in January of 1999 as an upgrade of SSL version 3.0. While not directly compatible SSL and TLS are able to be configured so that if a client or server does not allow for TLS communications the connection can be downgraded to SSL version 3.0 but this does weaken the secure connection. (The SSL protocol SSL and TLS will be commonly referred to generically as SSL within this paper unless a clear distinction need be made.)

While most computer users understand a secure connection is needed to transact an online purchase, communicate, or transfer sensitive data few understand the methodology and inherent weaknesses that are prevalent in many sites today almost 20 years after the first SSL protocol was developed. The common user understands that they need to see the ‘padlock’ or highlighted green bar in their browser to ensure proper security but their understanding usually ends there. Even amongst system and network administrators it is surprising how many implementations of the SSL protocol are insecure due to certificate, and PKI infrastructure issues. Qualys SSL Labs seeks to bring attention to these sites, weaknesses, and misconfigurations by offering a free service in order to examine the configuration of any SSL server accessible on the Internet through a simple domain check on their website. By simply entering in the domain name of any site which is known to provide SSL communications a user can quickly obtain an overall letter grade ranging from ‘A’ through ‘F’ identifying both strengths and weaknesses in that particular site’s implementation of the SSL protocol.

Technology Overview

Secure Socket Layer and Transport Layer Security (SSL/TLS) are security protocols which operate between the transport layer and application layer of the OSI model. The foundation of the SSL protocol is what is known as the SSL handshake. During normal online communication a web browser communicates using the HTTP protocol typically on port 80. An SSL communication request shifts this communication to port 443 which is indicated by the HTTPS prefix in the URL. During the SSL handshake a client sends a request to the server indicating that it would like to communicate securely and listing the SSL version that it would like to support, its own cipher suite options (RC4128, AES128, AES 256, etc.), session ID and session specific data. The server then responds by sending the client its own SSL version (with the latest commonly agreed-upon version) chooses a cipher option, session specific data, and its own certificate. If the client is requesting a service or resource that requires authentication on its part the server will request the client certificate. The client then utilizes the information sent by the server to successfully authenticate the origins of the committee patient. It is at this point if there is a discrepancy that the user is warned of site and certificate issues within the browser. Upon successful authentication the client creates the premaster secret utilizing the server’s public key and then forward this encrypted premaster secret to the server. During the next step the server uses its own private key to decrypt the premaster secret and generates the session key which is also simultaneously being performed by the client as well. These symmetric keys are used to encrypt and decrypt all information exchange between the client and server during the session providing not only security but message integrity as well. Next both the client and server send each other messages indicating that all future communications from this point on will be encrypted utilizing the generated key which is finalized by the sending of an encrypted message in each direction indicating that the SSL handshake has been completed.

[pic]

http://encyclopedia2.thefreedictionary.com/SSL

Real-World Usage

In recent years SSL and TLS implementations have become widespread due to the proliferation of various attacks on both the client and server-side. Exploits such as the Firesheep extension for the Firefox web browser utilize packet sniffing techniques to take unencrypted cookies for sites such as Twitter and Facebook and enable the attacker to assume the identity of the victim. The severity of Firesheep’s exploit and its ease-of-use highlight the need for increased security for many if not all online communications. One of the ways the Firesheep attack was made possible was due to the lack of a secure end-to-end connection between the user /client and server and highlighted the need for end-to-end security implementation. The proper implementation of an SSL connection between the client and server completely mitigates the Firesheep attack. The Firesheep attack was also mitigated through the use of a secure wireless connection or through the use of a VPN (virtual private network ) but the problem with these two options are that they cannot be controlled or mandated on the part of the provider/server. This leaves SSL as the sole remaining viable option to prevent a user from being victimized. By simply enforcing SSL communications sites such as Facebook and Twitter can protect their users from not only the Firesheep attack but also packet sniffers, man in the middle attacks, and others with ill intent.

Anyone who has purchase items on eBay, Amazon, etc., transacted any banking through an online site, or even check e-mail has utilized SSL as it provides the needed security for online transactions. Users commonly see, but seldom pay attention to the padlock or highlighted browser part indicating secure communications according to Min Wu, Robert C. Miller, Simson L. Garfinkel in their report on Do Security Toolbars Actually Prevent Phishing Attacks? The authors conducted a study with participants who were security aware and yet consistently engaged in risky or insecure online behavior. These findings only highlight the need for web, system, and network administrators to properly configure and implement SSL. Even Google and Facebook now default all communications to a secure HTTPS connection regardless of the users request. We need more companies and security minded advocates to save us from ourselves! Qualys SSL Labs provide service for all users seeking to validate the security of a site utilizing SSL/TLS security via a simple domain check on their website. The domain check provides a grade report for users to examine the sites purported security and whether or not they ‘make the grade’ but better yet why they have achieved the grade assigned. According to their SSL Server Rating Guide certain options and parameters within the SSL protocol will either cap the grade given or provide the site with an instant failing grade. Examining the security of an SSL implementation SSL Labs looks to verify that a certificate is valid (including implementation and expiration dates) and trusted. Any site which fails this initial test receives an instant failing grade. Secondly the server configuration is examined looking at protocol support, key exchange support, and finally cipher support. From these results a score is complicated and assigned to the site which results in a corresponding grade. A score of zero in any category instantly forces the total score to zero resulting in an instant failure.

Numerical Score and Corresponding Grade

score >= 80 - A

score >= 65 - B

score >= 50 - C

score >= 35 - D

score >= 20 - E

score < 20 - F

In a SSL implementation quite often the weakest point of the server configuration is the certificate of the server itself. A certificate which is has not been proven trustworthy (i.e. one that has been signed by a common or well-known certificate authority) can lead communications which may not necessarily be relied upon 100% if they may be vulnerable to man in the middle attacks. Certificates which have expired or contain domain name mismatches also result in a failed score. The allowance of SSL version 2.0 communication does not provide a feeling score but potentially good in the future as currently it only results in a grade of 20% if it is allowed in communications. Other factors which may affect the sites overall grade include insecure renegotiation which generates an instant failing grade. Any site utilizing SSL version 3.0 or TLS version 1.0 is vulnerable to the BEAST attack and the resulting grade is capped at a B.

Protocol Evolution

After the initial version 2.0 of SSL was released in 1995 version 3.0 was released in 1996 under RFC 6101. The predecessor to SSL was Transport Layer Security and version 1.0 was released in 1999 under RFC 2246. According to Dierks and Allen in RFC 2246 the differences between SSL version 3.0 and TLS version 1.0 are “not dramatic” but are the differences are significant enough that they are not interoperable. The TLS version 1.0 protocol does allow for a renegotiation down to the SSL 3.0 version if the client does not in fact support TLS version 1.0. TLS version 1.0 remained until April of 2006 when RFC 4346 implemented changes that included protection against cipher block chaining attacks which it is known in theory but a proof of concept did not exist. Two years later in August of 2008 TLS version 1.2 was released in RFC 5246 which included additional cipher suite options and improvements to client server negotiations as to which hash and signature rhythms would be agreed-upon during communications. A later addendum in March of 2011 to TLS version 1.2 specified in RFC 6176 preventing TLS connections to be renegotiated using anything less than SSL version 3.0 connections. This means that the client seeking a secure connection with the server utilizing TLS would at a minimum be renegotiated to SSL version 3.0.

Technological Benefits

In earlier implementations and with holder now legacy hardware security did have a computational ‘price’ placing additional burden on both servers and clients but in today 's modern computing age this is no longer the case. The technological benefits of ubiquitous secure communications are proving themselves on an almost daily basis with new exploits and zero day vulnerabilities being discovered. Kemp Technologies recommends that protect yourself and your website by using SSL for all communications. By utilizing SSL for all communications customers will ultimately have greater faith in a given domain as a whole trusting that all communications are secure. Users also have the added benefit that the site has been validated through a Certificate Authority which can help to identify phishing sites. When properly implemented SSL and TLS can eliminate credit card fraud due to insecure communication with the additional benefit of protecting a user’s logon credentials including password.

Some of the current disadvantages of SSL and TLS implementations are that not all browsers take advantage of the latest versions, specifically TLS version 1.1 and 1.2. While all of the current popular browsers support TLS version 1.0 the majority do not support TLS version 1.1 and 1.2. Only Internet Explorer versions 8, 9 and 10 within the Windows 7 operating system support TLS version 1.1 and 1.2 but they are disabled by default. This leaves most users vulnerable as they are not familiar enough with configurations to enable them on their own. The only browser to support TLS version 1.1 by default are Chrome versions 22 and above on all modern operating systems. Apple 's Safari version 5 running on iOS version 5 and above support TLS version 1.1 and 1.2 by default and is the only browser to support all three versions of TLS by default.

Certification costs are another drawback to the growth of SSL implementation. Costs range from $50-$1500 when obtained from some of the more well-known Certificate Authorities. This had an added level of capital investment which managers may not see as necessary. As is readily seen in the SSL Labs testing proper server configuration is an absolute must in order to attain true security. Without an understanding of the current vulnerabilities and attacks being waged against SSL and TLS server administrators may have a false sense of security when in truth they may be making themselves more vulnerable due to attacks which are targeted directly against insecure SSL and TLS implementations.

Future Implications

Researcher Daniel Bernstein points out that most attacks will bypass properly implemented cryptography. Does this mean we can rest on our laurels? Absolutely not! While a cipher block chaining attack was known to be theoretically possible for many years the BEAST attack was made public in 2011 making TLS version 1.0 risky to use. There is now a known exploitable weakness in the RC4 TLS 1.0 and SSL implementations with some estimates placing RC4 usage currently at 50% of all TLS traffic. While the current attack is not yet practical to carry out due to the large number of copies of encrypted data needed the utilization of cloud computing or parallel computing technologies may make this exploitable weakness more practical in the very near future. As seen below the current threat model to SSL is quite large and will only grow larger as researchers and hackers find new ways to exploit attacks, both practical and theoretical, against the SSL and TLS protocol.

SSL Threat Model [pic]

Conclusion
SSL and TLS remain the de facto standard for secure online communications today. While there are known exploitable weaknesses across some of the implemented versions system and network administrators as well as users need to be aware of these vulnerabilities and implement proper measures to ensure secure communication. Browser developers need to ensure that TLS versions 1.1 and 1.2 are enabled by default and not leave it up to the user to enable them. Users themselves need to become more aware of what a secure SSL session entails not relying on a ‘padlock’icon or highlighted URL. At a minimum user should check the security of their favorite commerce sites and especially online banking sites utilizing the SSL Server Rating Guide has provided by SSL Labs. Even if a user is not educated enough to read and understand the provided report a simple letter grade should indicate to all users whether or not their site is properly secured. In identifying sites with anything other than a grade of an ‘A’ users can bring attention to administrators whose configurations are lax and need to be configured properly and we can all enjoy the secure communication that SSL and TLS can provide.
Endnotes
1. Chou, W. (2002). Inside ssl: The secure sockets layer protocol. IT Professional, 4(4), 47-532. (Retrieved 06-08-2013)

2. (2009). Tsl server rating guide. Retrieved from https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide_2009.pdf (Retrieved 06-10-2013)

3. Kemp Technologies. (n.d.). SSL Everything: Protect all of your website, not just a few parts. Retrieved from http://www.kemptechnologies.com/files/white-papers/ssl-everything-protect-all-your-website-not-just-few-parts/kemp-ssleverything.pdf (Retrieved 06-10-2013)

4. Security impact of the Rizzo/Duong CBC "BEAST" attack. Educated Guesswork, 2011. http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html (Retrieved 06-09-2013)

5. Bernstein, D. (n.d.). Failures of secret key cryptography . Retrieved from http://cr.yp.to/talks/2013.03.12/slides.pdf (Retrieved 06-09-2013)

6. T. Dierks and C. Allen. The TLS Protocol Version 1.0. RFC 2246 (Proposed Standard), January 1999. Obsoleted by RFC 4346, updated by RFCs 3546, 5746, 6176.

7. T. Dierks and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1. RFC 4346 (Proposed Standard), April 2006.

8. Dan Goodin. Hackers break SSL encryption used by millions of sites. The Register, 2011. http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/ (Retrieved 06-09-2013)

9. Security impact of the Rizzo/Duong CBC "BEAST" attack. Educated Guesswork, 2011. http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html (Retrieved 06-09-2013)

10. Wu, Miller and Simson. (2006). Do security toolbars actually prevent phishing attacks?. Retrieved from http://cs.union.edu/~fernandc/srs200/readings/SecurityToolbars.pdf

11. Ristic, I. (2013). Ssl/tls deployment best practices. Retrieved from https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.1.pdf. (Retrieved 06-09-2013)

Appendix A – SSL Labs Test (Grade A)

SSL Report: linux.com (140.211.167.50)
Assessed on: Mon Jun 10 23:16:32 UTC 2013 | Clear cache
[pic]

Authentication
[pic]
|Server Key and Certificate #1 |
|Common names |*.linux.com |
|Alternative names |*.linux.com linux.com |
|Prefix handling |Both (with and without WWW) |
|Valid from |Wed Oct 05 02:51:42 UTC 2011 |
|Valid until |Sun Oct 05 02:51:42 UTC 2014 (expires in 1 year and 3 months) |
|Key |RSA 2048 bits |
|Weak key (Debian) |No |
|Issuer |Starfield Secure Certification Authority |
|Signature algorithm |SHA1withRSA |
|Extended Validation |No |
|Revocation information |CRL, OCSP |
|Revocation status |Good (not revoked) |
|Trusted |Yes |

[pic]
|Additional Certificates (if supplied) |
|Certificates provided |2 (2699 bytes) |
|Chain issues |None |
|#2 |
|Subject |Starfield Secure Certification Authority |
| |SHA1: 7e1874a98faa5d6d2f506a8920ff22fbd16652d9 |
|Valid until |Mon Nov 16 01:15:40 UTC 2026 (expires in 13 years and 5 months) |
|Key |RSA 2048 bits |
|Issuer |Starfield Technologies / Starfield Class 2 Certification Authority |
|Signature algorithm |SHA1withRSA |

[pic]
|Certification Paths |
|Path #1: Trusted |
|1 |Sent by server |*.linux.com |
| | |SHA1: cada52b83a9d2a65c62c6c8ed498359d99ebe216 |
| | |RSA 2048 bits / SHA1withRSA |
|2 |Sent by server |Starfield Secure Certification Authority |
| | |SHA1: 7e1874a98faa5d6d2f506a8920ff22fbd16652d9 |
| | |RSA 2048 bits / SHA1withRSA |
|3 |In trust store |Starfield Technologies / Starfield Class 2 Certification Authority |
| | |SHA1: ad7e1c28b064ef8f6003402014c3d0e3370eb58a |
| | |RSA 2048 bits / SHA1withRSA |

Configuration
[pic]
|Protocols |
|TLS 1.2 |Yes |
|TLS 1.1 |Yes |
|TLS 1.0 |Yes |
|SSL 3.0 |Yes |
|SSL 2.0 |No |

[pic]
|Cipher Suites (SSLv3+ suites in server-preferred order, then SSLv2 suites where used) |
|TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) |128 | |
|TLS_RSA_WITH_RC4_128_SHA (0x5) |128 | |
|TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) |256 | |
|TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) |256 | |
|TLS_RSA_WITH_AES_256_CBC_SHA (0x35) |256 | |
|TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) |256 | |
|TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) |168 | |
|TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) |128 | |
|TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) |128 | |
|TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) |128 | |

[pic]
|Protocol Details |
|Secure Renegotiation |Supported |
|Secure Client-Initiated Renegotiation |No |
|Insecure Client-Initated Renegotiation |No |
|BEAST attack |Not vulnerable |
|Compression |No |
|RC4 |Yes PROBLEMATIC (more info) |
|Next Protocol Negotiation |No |
|Session resumption |Yes |
|Session tickets |Yes |
|OCSP stapling |No |
|Strict Transport Security |No |
|Long handshake intolerance |No |
|TLS extension intolerance |No |
|TLS version intolerance |0x0304: 0x303, 0x0399: 0x303, 0x0499: fail |
|SSLv2 handshake compatibility |Yes |

[pic]
|Miscellaneous |
|Test date |Mon Jun 10 23:15:20 UTC 2013 |
|Test duration |35.836 seconds |
|HTTP status code |200 |
|HTTP server signature |nginx |
|Server hostname |load1d.linux-foundation.org |
|PCI compliant |Yes |
|FIPS-ready |No |

SSL Report v1.2.63
Appendix B – SSL Labs Test (Grade B)

SSL Report: obsproject.com (173.236.101.35)
Assessed on: Mon Jun 10 23:22:35 UTC 2013 | Clear cache

[pic]

Authentication
[pic]
|Server Key and Certificate #1 |
|Common names |obsproject.com |
|Alternative names |obsproject.com www.obsproject.com |
|Prefix handling |Both (with and without WWW) |
|Valid from |Sat Nov 24 00:00:00 UTC 2012 |
|Valid until |Sun Nov 24 23:59:59 UTC 2013 (expires in 5 months and 16 days) |
|Key |RSA 2048 bits |
|Weak key (Debian) |No |
|Issuer |PositiveSSL CA 2 |
|Signature algorithm |SHA1withRSA |
|Extended Validation |No |
|Revocation information |CRL, OCSP |
|Revocation status |Good (not revoked) |
|Trusted |Yes |

[pic]
|Additional Certificates (if supplied) |
|Certificates provided |2 (2540 bytes) |
|Chain issues |None |
|#2 |
|Subject |PositiveSSL CA 2 |
| |SHA1: 94807b1c788dd2fcbe19c8481ce41cfab8a4c17f |
|Valid until |Sat May 30 10:48:38 UTC 2020 (expires in 6 years and 11 months) |
|Key |RSA 2048 bits |
|Issuer |AddTrust External CA Root |
|Signature algorithm |SHA1withRSA |

[pic]
|Certification Paths |
|Path #1: Trusted |
|1 |Sent by server |obsproject.com |
| | |SHA1: 26067101f07b72b7af25d3bb20fd6cc4d90d8063 |
| | |RSA 2048 bits / SHA1withRSA |
|2 |Sent by server |PositiveSSL CA 2 |
| | |SHA1: 94807b1c788dd2fcbe19c8481ce41cfab8a4c17f |
| | |RSA 2048 bits / SHA1withRSA |
|3 |In trust store |AddTrust External CA Root |
| | |SHA1: 02faf3e291435468607857694df5e45b68851868 |
| | |RSA 2048 bits / SHA1withRSA |
|Path #2: Trusted |
|1 |Sent by server |obsproject.com |
| | |SHA1: 26067101f07b72b7af25d3bb20fd6cc4d90d8063 |
| | |RSA 2048 bits / SHA1withRSA |
|2 |Sent by server |PositiveSSL CA 2 |
| | |SHA1: 94807b1c788dd2fcbe19c8481ce41cfab8a4c17f |
| | |RSA 2048 bits / SHA1withRSA |
|3 |Extra download |AddTrust External CA Root |
| | |SHA1: 53845e9fd070b7aa36976f536ff1441c578c63d2 |
| | |RSA 2048 bits / SHA1withRSA |
|4 |In trust store |UTN - DATACorp SGC |
| | |SHA1: 58119f0e128287ea50fdd987456f4f78dcfad6d4 |
| | |RSA 2048 bits / SHA1withRSA |

Configuration
[pic]
|Protocols |
|TLS 1.2 |No |
|TLS 1.1 |No |
|TLS 1.0 |Yes |
|SSL 3.0 |Yes |
|SSL 2.0 |No |

[pic]
|Cipher Suites (SSLv3+ suites in server-preferred order, then SSLv2 suites where used) |
|TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH 256 bits (eq. 3072 bits RSA) |256 | |
|TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) |256 | |
|TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88) DH 1024 bits (p: 128, g: 1, Ys: 128) |256 | |
|TLS_RSA_WITH_AES_256_CBC_SHA (0x35) |256 | |
|TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) |256 | |
|TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH 256 bits (eq. 3072 bits RSA) |168 | |
|TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 1024 bits (p: 128, g: 1, Ys: 128) |168 | |
|TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) |168 | |
|TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH 256 bits (eq. 3072 bits RSA) |128 | |
|TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128) |128 | |
|TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 1024 bits (p: 128, g: 1, Ys: 128) |128 | |
|TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) |128 | |
|TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) |128 | |

[pic]
|Protocol Details |
|Secure Renegotiation |Supported |
|Secure Client-Initiated Renegotiation |No |
|Insecure Client-Initated Renegotiation |No |
|BEAST attack |Vulnerable INSECURE (more info) |
|Compression |No |
|RC4 |No |
|Next Protocol Negotiation |Yes spdy/2 http/1.1 |
|Session resumption |Yes |
|Session tickets |Yes |
|OCSP stapling |Yes |
|Strict Transport Security |No |
|Long handshake intolerance |No |
|TLS extension intolerance |No |
|TLS version intolerance |0x0304: 0x301, 0x0399: 0x301, 0x0499: fail |
|SSLv2 handshake compatibility |Yes |

[pic]
|Miscellaneous |
|Test date |Mon Jun 10 23:22:04 UTC 2013 |
|Test duration |30.711 seconds |
|HTTP status code |200 |
|HTTP server signature |nginx/1.4.1 |
|Server hostname |io.r1ch.net |
|PCI compliant |No |
|FIPS-ready |No |

SSL Report v1.2.63

Appendix C – SSL Labs Test (Grade C)

SSL Report: gao.gov (161.203.16.77)
Assessed on: Tue Jun 11 20:18:37 UTC 2013 | Clear cache

[pic]

Authentication
[pic]
|Server Key and Certificate #1 |
|Common names |www.gao.gov |
|Alternative names |www.gao.gov |
|Prefix handling |Not valid for "gao.gov" CONFUSING |
|Valid from |Mon Jul 16 00:00:00 UTC 2012 |
|Valid until |Thu Aug 14 23:59:59 UTC 2014 (expires in 1 year and 2 months) |
|Key |RSA 2048 bits |
|Weak key (Debian) |No |
|Issuer |VeriSign Class 3 International Server CA - G3 |
|Signature algorithm |SHA1withRSA |
|Extended Validation |No |
|Revocation information |CRL, OCSP |
|Revocation status |Good (not revoked) |
|Trusted |Yes |

[pic]
|Additional Certificates (if supplied) |
|Certificates provided |3 (4193 bytes) |
|Chain issues |None |
|#2 |
|Subject |VeriSign Class 3 International Server CA - G3 |
| |SHA1: b18d9d195669ba0f7829517566c25f422a277104 |
|Valid until |Fri Feb 07 23:59:59 UTC 2020 (expires in 6 years and 7 months) |
|Key |RSA 2048 bits |
|Issuer |VeriSign Class 3 Public Primary Certification Authority - G5 |
|Signature algorithm |SHA1withRSA |
|#3 |
|Subject |VeriSign Class 3 Public Primary Certification Authority - G5 |
| |SHA1: 32f30882622b87cf8856c63db873df0853b4dd27 |
|Valid until |Sun Nov 07 23:59:59 UTC 2021 (expires in 8 years and 4 months) |
|Key |RSA 2048 bits |
|Issuer |VeriSign / Class 3 Public Primary Certification Authority |
|Signature algorithm |SHA1withRSA |

[pic]
|Certification Paths |
|Path #1: Trusted |
|1 |Sent by server |www.gao.gov |
| | |SHA1: 578e7432c00e680cbc1ecd99e329c0c4782f93d0 |
| | |RSA 2048 bits / SHA1withRSA |
|2 |Sent by server |VeriSign Class 3 International Server CA - G3 |
| | |SHA1: b18d9d195669ba0f7829517566c25f422a277104 |
| | |RSA 2048 bits / SHA1withRSA |
|3 |In trust store |VeriSign Class 3 Public Primary Certification Authority - G5 |
| | |SHA1: 4eb6d578499b1ccf5f581ead56be3d9b6744a5e5 |
| | |RSA 2048 bits / SHA1withRSA |
|Path #2: Not trusted (Algorithm constraints check failed: MD2withRSA) |
|1 |Sent by server |www.gao.gov |
| | |SHA1: 578e7432c00e680cbc1ecd99e329c0c4782f93d0 |
| | |RSA 2048 bits / SHA1withRSA |
|2 |Sent by server |VeriSign Class 3 International Server CA - G3 |
| | |SHA1: b18d9d195669ba0f7829517566c25f422a277104 |
| | |RSA 2048 bits / SHA1withRSA |
|3 |Sent by server |VeriSign Class 3 Public Primary Certification Authority - G5 |
| | |SHA1: 32f30882622b87cf8856c63db873df0853b4dd27 |
| | |RSA 2048 bits / SHA1withRSA |
|4 |In trust store |VeriSign / Class 3 Public Primary Certification Authority |
| | |SHA1: 742c3192e607e424eb4549542be1bbc53e6174e2 |
| | |RSA 1024 bits / MD2withRSA |
|Path #3: Trusted |
|1 |Sent by server |www.gao.gov |
| | |SHA1: 578e7432c00e680cbc1ecd99e329c0c4782f93d0 |
| | |RSA 2048 bits / SHA1withRSA |
|2 |Sent by server |VeriSign Class 3 International Server CA - G3 |
| | |SHA1: b18d9d195669ba0f7829517566c25f422a277104 |
| | |RSA 2048 bits / SHA1withRSA |
|3 |Sent by server |VeriSign Class 3 Public Primary Certification Authority - G5 |
| | |SHA1: 32f30882622b87cf8856c63db873df0853b4dd27 |
| | |RSA 2048 bits / SHA1withRSA |
|4 |In trust store |VeriSign / Class 3 Public Primary Certification Authority |
| | |SHA1: a1db6393916f17e4185509400415c70240b0ae6b |
| | |RSA 1024 bits / SHA1withRSA |

Configuration
[pic]
|Protocols |
|TLS 1.2 |No |
|TLS 1.1 |No |
|TLS 1.0 |Yes |
|SSL 3.0 |Yes |
|SSL 2.0 |Yes N |
|(*) N next to protocol version means the protocol has no cipher suites enabled | |

[pic]
|Cipher Suites (sorted by strength; server has no preference) |
|TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3) WEAK |40 | |
|TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6) WEAK |40 | |
|TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8) WEAK |40 | |
|TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x14) DH 512 bits (p: 64, g: 1, Ys: 64) WEAK |40 | |
|TLS_RSA_EXPORT1024_WITH_RC4_56_MD5 (0x60) WEAK |56 | |
|TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 (0x61) WEAK |56 | |
|TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x62) WEAK |56 | |
|TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x64) WEAK |56 | |
|TLS_RSA_WITH_RC4_128_MD5 (0x4) |128 | |
|TLS_RSA_WITH_RC4_128_SHA (0x5) |128 | |
|TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) |128 | |
|TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128) |128 | |
|TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) |168 | |
|TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 1024 bits (p: 128, g: 1, Ys: 128) |168 | |
|TLS_RSA_WITH_AES_256_CBC_SHA (0x35) |256 | |
|TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) |256 | |

[pic]
|Protocol Details |
|Secure Renegotiation |Supported |
|Secure Client-Initiated Renegotiation |Supported DoS DANGER (more info) |
|Insecure Client-Initated Renegotiation |No |
|BEAST attack |Vulnerable INSECURE (more info) |
|Compression |No |
|RC4 |Yes PROBLEMATIC (more info) |
|Next Protocol Negotiation |No |
|Session resumption |No (IDs empty) |
|Session tickets |No |
|OCSP stapling |No |
|Strict Transport Security |No |
|Long handshake intolerance |No |
|TLS extension intolerance |No |
|TLS version intolerance |0x0304: 0x301, 0x0399: 0x301, 0x0499: fail |
|SSLv2 handshake compatibility |Yes |

[pic]
|Miscellaneous |
|Test date |Tue Jun 11 20:18:05 UTC 2013 |
|Test duration |31.930 seconds |
|HTTP status code |200 |
|HTTP server signature |Apache |
|Server hostname |- |
|PCI compliant |No |
|FIPS-ready |No |

SSL Report v1.2.63
Appendix D – SSL Labs Test (Grade D)

No sites receiving a grade of “D” were observed during testing.
Appendix E – SSL Labs Test (Grade E)

No sites receiving a grade of “E” were observed during testing.
Appendix F – SSL Labs Test (Grade F)

SSL Report: tdameritrade.com (184.86.159.5)
Assessed on: Mon Jun 10 20:55:04 UTC 2013 | Clear cache
[pic]

Authentication
[pic]
|Server Key and Certificate #1 |
|Common names |www.tdameritrade.com |
|Alternative names |media.tdameritrade.com www.tdainstitutional.com edgetest-www.tdameritrade.com |
| |edgetest-www.tdainstitutional.com betas.ameritrade.com edgetest-betas.ameritrade.com |
| |www.tdameritrade.com |
|Prefix handling |WWW only, but DNS not configured for access |
|Valid from |Fri Dec 21 00:00:00 UTC 2012 |
|Valid until |Sun Dec 22 23:59:59 UTC 2013 (expires in 6 months and 14 days) |
|Key |RSA 2048 bits |
|Weak key (Debian) |No |
|Issuer |VeriSign Class 3 Secure Server CA - G3 |
|Signature algorithm |SHA1withRSA |
|Extended Validation |No |
|Revocation information |CRL, OCSP |
|Revocation status |Good (not revoked) |
|Trusted |Yes |

[pic]
|Additional Certificates (if supplied) |
|Certificates provided |2 (3038 bytes) |
|Chain issues |None |
|#2 |
|Subject |VeriSign Class 3 Secure Server CA - G3 |
| |SHA1: 5deb8f339e264c19f6686f5f8f32b54a4c46b476 |
|Valid until |Fri Feb 07 23:59:59 UTC 2020 (expires in 6 years and 7 months) |
|Key |RSA 2048 bits |
|Issuer |VeriSign Class 3 Public Primary Certification Authority - G5 |
|Signature algorithm |SHA1withRSA |

[pic]
|Certification Paths |
|Path #1: Trusted |
|1 |Sent by server |www.tdameritrade.com |
| | |SHA1: ce9f8f3a75a6f2dc96b640189d5cffcebce3dc9b |
| | |RSA 2048 bits / SHA1withRSA |
|2 |Sent by server |VeriSign Class 3 Secure Server CA - G3 |
| | |SHA1: 5deb8f339e264c19f6686f5f8f32b54a4c46b476 |
| | |RSA 2048 bits / SHA1withRSA |
|3 |In trust store |VeriSign Class 3 Public Primary Certification Authority - G5 |
| | |SHA1: 4eb6d578499b1ccf5f581ead56be3d9b6744a5e5 |
| | |RSA 2048 bits / SHA1withRSA |

Configuration
[pic]
|Protocols |
|TLS 1.2 |Yes |
|TLS 1.1 |Yes |
|TLS 1.0 |Yes |
|SSL 3.0 |Yes |
|SSL 2.0 INSECURE |Yes |

[pic]
|Cipher Suites (sorted by strength; server has no preference) |
|TLS_RC4_128_EXPORT40_WITH_MD5 (0x20080) WEAK |40 | |
|TLS_RC2_128_CBC_EXPORT40_WITH_MD5 (0x40080) WEAK |40 | |
|TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x3) WEAK |40 | |
|TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x6) WEAK |40 | |
|TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x8) WEAK |40 | |
|TLS_DES_64_CBC_WITH_MD5 (0x60040) WEAK |56 | |
|TLS_RSA_WITH_DES_CBC_SHA (0x9) WEAK |56 | |
|TLS_RC4_128_WITH_MD5 (0x10080) |128 | |
|TLS_RC2_128_CBC_WITH_MD5 (0x30080) |128 | |
|TLS_IDEA_128_CBC_WITH_MD5 (0x50080) |128 | |
|TLS_RSA_WITH_RC4_128_MD5 (0x4) |128 | |
|TLS_RSA_WITH_RC4_128_SHA (0x5) |128 | |
|TLS_RSA_WITH_IDEA_CBC_SHA (0x7) |128 | |
|TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) |128 | |
|TLS_DES_192_EDE3_CBC_WITH_MD5 (0x700c0) |168 | |
|TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) |168 | |
|TLS_RSA_WITH_AES_256_CBC_SHA (0x35) |256 | |

[pic]
|Protocol Details |
|Secure Renegotiation |Supported |
|Secure Client-Initiated Renegotiation |No |
|Insecure Client-Initated Renegotiation |No |
|BEAST attack |Vulnerable INSECURE (more info) |
|Compression |No |
|RC4 |Yes PROBLEMATIC (more info) |
|Next Protocol Negotiation |No |
|Session resumption |Yes |
|Session tickets |No |
|OCSP stapling |No |
|Strict Transport Security |No |
|Long handshake intolerance |No |
|TLS extension intolerance |No |
|TLS version intolerance |0x0304: 0x303, 0x0399: 0x303, 0x0499: fail |
|SSLv2 handshake compatibility |Yes |

[pic]
|Miscellaneous |
|Test date |Mon Jun 10 20:54:45 UTC 2013 |
|Test duration |19.670 seconds |
|HTTP status code |301 |
|HTTP forwarding |http://www.tdameritrade.com |
|HTTP server signature |Apache vFabric |
|Server hostname |a184-86-159-5.deploy.akamaitechnologies.com |
|PCI compliant |No |
|FIPS-ready |No |

SSL Report v1.2.63

2. Invalid configuration

In some cases, the certificate chain does not contain all the necessary certificates to connect the web server certificate to one of the root certificates in our trust store. Less commonly, one of the certificates in the chain (other than the web server certificate) will have expired, and that invalidates the entire chain.

3. Unknown Certificate Authority

In order for trust to be established, we must have the root certificate of the signing Certificate Authority in our trust store. SSL Labs does not maintain its own trust store; instead we use the store maintained by Mozilla.
If we mark a web site as not trusted, that means that the average web user 's browser will not trust it either. For certain special groups of users, such web sites can still be secure. For example, if you can securely verify that a self-signed web site is operated by a person you trust, then you can trust that self-signed web site too. Or, if you work for an organisation that manages its own trust, and you have their own root certificate already embedded in your browser. Such special cases do not work for the general public, however, and this is what we indicate on our report card.

4. Interoperability issues

In some rare cases trust cannot be established because of interoperability issues between our code and the code or configuration running on the server. We manually review such cases, but if you encounter such an issue please feel free to contact us. Such problems are very difficult to troubleshoot and you may be able to provide us with information that might help us determine the root cause.
SSL Report v1.2.63

References: 2. (2009). Tsl server rating guide. Retrieved from https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide_2009.pdf (Retrieved 06-10-2013) 3 4. Security impact of the Rizzo/Duong CBC "BEAST" attack. Educated Guesswork, 2011. http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html (Retrieved 06-09-2013) 5 6. T. Dierks and C. Allen. The TLS Protocol Version 1.0. RFC 2246 (Proposed Standard), January 1999. Obsoleted by RFC 4346, updated by RFCs 3546, 5746, 6176.