Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice on a DIY computer-hobbyist site.
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from an off-shore beyond-the-law
<ahem>pirate</ahem>copyright-optional paper landfill: sci-hub.io
- The domain is for sci-hub.cc, not sci-hub.io.
Those are, like, two totally different domains!
- The certificate is
- from Comodo.
- expires 2018-03.
- Lets Encrypt offers (free) certificates for any domain.
Ryan Sleev; A History of Hard Choices; On His Blog, at Medium; 2015-12-28.
Ryan Sleev, cross-platform crypto & PKI core, Chromium, Google.
tl;dr → no need to listen to the slacktards, they have never used the extra time to do anything helpful before, and they won’t again this time. They being at least: CloudFlare, Facebook, Twitter, Symantec.
tl;dr → legacy migration, with compatibility, of consumer premises equipment is a very hard problem; it has never ever been done well.
- CA/Browser Forum
- iOS 9/OS X 10.11 apps that do not disable ATS).
- Certificate Validation Levels
- Domain Validation (DV)
- Organization Validation (OV)
- Extended Validation (EV)
<quote>Disclaimer: This posts represents personal opinions and thoughts, and does not represent the views or positions of [Ryan Sleev's] employer, Google.</quote>
And yet, the purpose of the post was to elaborate Google’s perspective as:
<quote>The failures of the CA industry are profoundly important when discussing the LV proposal by Facebook, CloudFlare, and Twitter . The ways in which these companies propose to mitigate risk hinges upon a reliance on CA policies and practices which can neither be independently evaluated nor technically enforced by browsers. Each of the proposed solutions have been tried before, have been violated before, and unfortunately, but undoubtedly, will be violated again. To ignore this historic context is not just short-sighted, but puts billions of users at risk.</quote>
The important contribution
- Stevens, Karpman, and Peyrin announce The SHAppening, a freestart collision attack on SHA-1.
- Rick Andrews, staff, Symantec
- Michael Coates, Trust and Information Security Officer, Twitter.
- Matthew Prince, Chief Executive Officer, CloudFlare.
- Alex Stamos, Chief Security Officer, Facebook.
- App Transport Security (ATS)
- Certificate Authority (CA)
- Legacy Verified (LV)
- Transport Layer Security (TLS)
- TLS v1.2
- Alex Stamos (Facebook); The SHA-1 Sunset; In Their Blog; 2015-12-09.
- CloudFlare’s Chief Executive Officer, Matthew Prince, offered a more detailed breakdown of the 25 countries with the worst
- ollowing their posts, Michael Coates, Trust and Information Security Officer of Twitter, joined in support the proposal, painting the conversation as a dichotomy betwee
- Twitter, joined in support the proposal, painting the conversation as a dich
- such appeals are
- even conflicts with the data published by other large sites.
- and Server Gated Cryptography, as many of the arguments surr
- 1993: den Boer and Bosselaers demonstrate the first proto-attack on MD5, two years after it is first introduced.
- 1996: Dobbertin announces an attack on the compression function of MD5, an event significant enough to cause the cryptographic community to recommend that software switch to other algorithms, such as SHA-1.
- 1997: Microsoft adds support for Server Gated Cryptography to Internet Explorer 3, as a way of working within the US regulatory framework for the export of cryptography. In order to use strong cryptography, websites must obtain a special certificate from a CA that indicates they meet the criteria set forth by the US export controls. Netscape introduces similar support, under the name International Step-Up, which works slightly different under the hood but is conceptually equivalent.
- 2000: Completing a relaxation begun in 1999, US export controls are altered, obsoleting the need for SGC certificates. Internet Explorer 5 no longer has a need for such certificates.
- 2004: A group of researchers demonstrate the first collision in MD5.
- 2005: Lenstra, Wang, and de Weger demonstrate collisions in certificates with different public keys, highlighting the risk of using MD5-based signature algorithms in certificates.
- 2005: The CA/Browser Forum is formed with the goal of developing a set of standards for Extended Validation SSL certificates.
- 2006: Rob Stradling of Comodo, a founding CA member of the CA/Browser Forum, attempts to garner interest in the IETF PKIX working group, which is the group responsible for developing standards related to certificates, for a way to safely and securely support multiple signatures. The responses are largely tepid, with the conclusion seeming to be that PKIX feels it “can afford to wait until the very last minute, i.e. when SHA1 is actually broken, rather than to upgrade to some fix like SHA256 before SHA1 is broken.”
- 2007: The CA/Browser Forum adopts and publishes the first version of the EV SSL guidelines.
- 2008: Stevens, Sotirov, Appelbaum, Lenstra, Molnar, Osvik, and de Weger exploit MD5 to create a fraudulent intermediate certificate by getting a certificate from RapidSSL. This fraudulent certificate allows them to issue certificates for, and thus intercept, any HTTPS website on the Internet.
- ~2008–2009: The Microsoft Root Program Technical Requirements, v1.0, requires that CAs stop issuing MD5 certificates, effective 15 January 2009. CAs are required to make SHA-2 available, on request, effective 31 December 2011. Further, all 1024-bit RSA certificates must expire before 31 December, 2013; Microsoft makes no guarantees that such certificates will keep working after that point.
- 2009: Johnathan Nightingale, then working on Firefox at Mozilla, releases an analysis of MD5 usage of the Alexa top million sites. At the time of publication, 14% of these sites still use MD5 certificates.
- 2009: The Chrome team explores removing support for MD5. Based on their research, removing support for MD5 would affect 6% of users globally.
- 2010: In light of growing concern with SHA-1, Microsoft requires that all CAs participating in their program include 8 bytes (64 bits) of entropy in either the certificate serial number or in the first component of the certificate subject name (i.e. before any attacker-controlled data). In the event that there is absolutely no other way, Microsoft allows CAs to include 6 bytes of random data in the Hour:Minutes:Seconds of the validity period; due to encoding limitations, this only offers 86400 possible values, or around 16 bits of entropy each for the notBefore and notAfter fields.
- February 2010: The authors of the Flame malware exploit an MD5 collision against a Microsoft-operated Certificate Authority to obtain a malicious code-signing certificate.
- May 2010: VeriSign (later acquired by Symantec) announces their 1024-bit root transition plan. Thawte branded certificates will transition on June 2010, GeoTrust in July 2010, VeriSign in October 2010, RapidSSL in December 2010. All new certificates will come off the stronger roots.
- August 2010: Symantec acquires VeriSign.
- October 2010: Mozilla announces that, as of December 31, 2010, CAs must stop issuing any certificate from 1024-bit root certificates, and must stop issuing certificates for RSA key sizes less than 2048 bits. On June 30, 2011, they will stop validating MD5 signatures. Both of these deadlines are missed; in particular, Symantec Corporation indicates to Mozilla they will not comply until 2013, despite having announced a transition plan only 5 months prior.
- October 2011: Apple releases iOS 5, the first mainstream client to disable support for MD5.
- November 2011: The CA/Browser Forum adopts the first version of the Baseline Requirements. This first version includes text that survives to this day, stating that Certificate Authorities SHOULD include at least 20 bits of entropy within the Certificate serial number. The SHOULD language is inherited from RFC 2119, which defines it as “there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.” The Baseline Requirements also indicate that SHA-1 certificates MAY be issued with validity periods extending beyond 31 December 2013, but only until SHA-256 is “supported widely by browsers used by a substantial portion of relying-parties worldwide.”
The Baseline Requirements do not permit the issuance of MD5 certificates.
- December 2011: Chrome disables support for MD5, two years after originally desired. In doing so, reports begin to emerge that a variety of “security” software products are broken, including products from TrendMicro and WebSense products, making Chrome wholly unusable in a variety of environments that were still actively using MD5.
- March 2012: Firefox disables support for MD5, nine months after originally scheduled.
- July 2012: The Baseline Requirements come into effect. According to the Baseline Requirements, all certificates issued after 1 July 2012 should conform to these requirements.
- 2013: Microsoft updates their Root Program Requirements to remove the Validity Period clause for entropy. Entropy MUST now appear within the certificate serial number or first field of the certificate subject.
- February 2013: Mozilla adopts Version 2.1 of their CA Certificate Policy, becoming the first Root Program to require conformance to the Baseline Requirements. However, this requirement only applies to new CAs requesting inclusion; for existing roots, their first audit after February 2013 must be performed to the Baseline Requirements, but the CA is allowed to violate them, provided they document the violation and the audit the following year resolves those violations. For a CA that was audited on January 2013 for the issuance period of 2012, this means that they can continue to issue non-compliant certs throughout 2013, as their first BR audit would be January 2014 and cover the prior year. When they are audited on January 2015, for the issuance period of 2014, they are expected to be compliant.
- May 2013: Stevens describes a set of new attacks on SHA-1 that make chosen-prefix attacks more feasible.
- August 2013: Stevens describes a means of attempting to mitigate the risk of SHA-1 collisions by describing how verification software can attempt to probabilistically detect whether or not there’s a chance of collision.
- August 2013: Microsoft provides a security update, but only for Windows Vista and later, that disables support for MD5 within certificates, over three years after the Flame malware and nearly four years after they forbid issuance of such certificates.
- October 2013: Apple releases OS X 10.9, which removes support for MD5 in certificates, bringing it in line with iOS 5 released two years earlier.
- June 2013: Six months before CAs are required by the Baseline Requirements to stop issuing certificates with RSA keys less than 2048 bits, Rick Andrews of Symantec proposes such issuance be allowed indefinitely, for existing customers, so long as CAs follow a documented process. This proposal is quite similar to the Legacy Verified proposal offered by Facebook and CloudFlare — it relies on specific business processes to prevent misissuance, and includes an OID marker (or, more aptly, the lack thereof) within the Certificate Policies extension as a way to protect modern clients.
- October 2013: Symantec requests that their 1024-bit roots be included indefinitely in Mozilla products, as they have issued and will continue to issue certificates from them in order to support older browsers and enterprises who will be negatively affected.
- November 2013: Microsoft announces that, effective 1 January 2016, CAs must stop issuing SHA-1 certificates. This decision is taken unilaterally, after the CA/Browser Forum is unable to progress on the matter after months of debate.
- January 2014: Symantec notifies Mozilla that they knowingly violated multiple provisions of the Baseline Requirements — issuing a 1024-bit certificate directly off a 1024-bit root, and with the validity period backdated to begin in 2010 — in order to satisfy a customer request.
- August 2014: Mozilla begins the first wave of removals of 1024-bit root certificates.
- October 2014: After nearly a year of debate, the CA/Browser Forum ratifies Ballot 118, which sets the SHA-1 deprecation date to be the same as in the Microsoft policy announced the year prior.
- October 2014: Three years after the Microsoft Root Program required that all CAs make SHA-2 certificates available, Gandi.net, a small CA based in Paris, is finally able to offer SHA-2. They were unable to provide such certificates as the Root CA they partnered with — Comodo — did not offer such certificates. They were not unique; the problems and inability of people to get SHA-2 certificates due to CA issues were widespread.
- January 2015: Mozilla completes the second wave of 1024-bit root certificate removals.
- April 2015: Mozilla attempts to remove the trust bits for the remaining 1024-bit root, the Symantec-operated Equifax root. Due to considerable breakage, this decision is reverted.
- May 2015: Symantec stops attempting to upsell sites into purchasing SGC certificates, 15 years after they were no longer needed.
- September 2015: Apple releases iOS 9 and OS X 10.11, which enables by default a feature called App Transport Security (ATS) for new applications. When enabled, it forces the use of TLS 1.2; if RSA keys less than 2048 bits long are encountered while connecting, the connection will fail — effectively deprecating 1024-bit RSA keys. However, applications can and do disable this for compatibility reasons.
- September 2015: On behalf of the Chief Security Office of AT&T Services, Rick Andrews of Symantec posts a request to postpone the deprecation of SHA-1. In this request, AT&T notes that in 2014, Symantec confirmed “… that we would retain the option to issue SHA-1 certificates in 2016 with expiration no later than 12/31/2016 …” AT&T’s challenges in deployment were, in part, caused by this commitment, as plans and resource allocations were committed to 2016 and could not be advanced sooner.
- October 2015: Symantec proposes a ballot, with the support of Entrust, Microsoft, and TrendMicro, to extend the SHA-1 certificate issuance date for the duration of 2016; Under this proposal, issuance would not cease until 1/1/2017.
- October 2015: Stevens, Karpman, and Peyrin announce “The SHAppening,” a freestart collision attack on SHA-1. Their research indicates that previous estimates about the economic viability of SHA-1 attacks were significantly underestimated, and they recommend transitioning off SHA-1 as soon as possible. Symantec subsequently withdraws their SHA-1 ballot.
- October 2015: Symantec is detected to be routinely misissuing Extended Validation Certificates. These certificates require the most stringent of controls, including manual review and approval at two separate points during the issuance process. After an initial investigation reveals Symantec underestimated the misissuance, it is subsequently determined that Symantec misissued at least 2,600 certificates spanning the course of several years, at all levels of validation (DV, OV, EV).
- November 2015: Symantec finally stops issuing SHA-1 certificates with sequential serial numbers, five years after Microsoft forbade the practice. When pressed for explanation, Symantec indicates they placed entropy in the date fields — two years after Microsoft forbade the practice — and only half the recommended amount.
- December 2015: With only one week’s notice, Symantec requests that a root certificate trusted on billions of devices be revoked, so that Symantec will no longer be obligated to abide by the Baseline Requirements for that root. Without this notice, Symantec’s use of their root in this manner would have been in violation of their agreements with root programs, putting at risk every other root certificate they operate and every single customer of theirs. Yet, even with this notice, it will likely take years to reduce the number of users and devices at risk from certificates issued by Symantec from this root to a something quantified in the tens of millions.
- January 2016: Mozilla is scheduled to complete the removal of Symantec’s last 1024-bit root certificate, two years after originally scheduled.
- MD5, 1024-bit, and SGC, it doesn’t even begin to touch on the challenges of removing support for RC4, removing support for SSLv3, or in removing support for weak Diffie-Hellman keys, all of which have affected the ability of users to get online and accomplish day-to-day tasks, and yet failed to evoke similar hand-wringing concern from those advocating for SHA-1 to continue.
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from a free software distribution shop: krb5-auth-dialog
The Certificate Authority is CAcert
- Which is not trusted by Firefox
- for a variety of historical reasons
- At least because
- the root certificate uses MD5 (
- whereas the host certificate signed by that issuer uses SHA-2 (
- the root certificate uses MD5 (
If you want to install the CAcert Root Certificate … it’s work, and risky, with the MD5 on the root, and all.
- Of course, Firefox uses its own root certificate manager, thus the OS-level one isn’t used.
- HowTo: Import the CAcert Root Certificate into Client Software
New versions of Firefox (as version 39.0 on Linux Ubuntu 14.10) don’t permit importing of the CAcert Root cert (
root.der) as its signing algorithm MD5 is treated as obsolete and not secure. Simply use the add-on stated above.
- CAcert Root Certificate Importer, for Firefox, 2014-04
$ openssl s_client -showcerts -connect honk.sigxcpu.org:443 CONNECTED(00000003) depth=1 O = Root CA, OU = http://www.cacert.org, CN = CA Cert Signing Authority, emailAddress = email@example.com verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/CN=honk.sigxcpu.org i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddressfirstname.lastname@example.org -----BEGIN CERTIFICATE----- MIIHdjCCBV6gAwIBAgIDD375MA0GCSqGSIb3DQEBCwUAMHkxEDAOBgNVBAoTB1Jv b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y dEBjYWNlcnQub3JnMB4XDTE0MDkwNDE4NDUyMloXDTE2MDkwMzE4NDUyMlowGzEZ MBcGA1UEAxMQaG9uay5zaWd4Y3B1Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKsmbtfNuTOJxz4/hW2VhJm95vE+V0KIbnYwKs/jOeLyn+SLchI8 drZbyyFiInRSobWJotV3fzH42t9XaXgiM1OFTTvv26vwoFlK6mYBeqDQUr2y0lJp zjOnbCtZbwhsIKFbr4tLH3EqWwuKwVWMVpAP1eY9QRWo+Suv8Fqcs6otobNXdjTU LuJNo1Qx3bwqGFfyW7Vl2pu8x95pk9WWgkDtj6O5ch9T3+OzwuFtzFT3A3TWljII CimKf7loHuMkwksSTwKLb2cBZybG26bHlmU3QJDw5tcUHqK9Gh5Jhc/T7H6pdu3n OaKR4nbKj+uqwl+jFhQlqsZQvxti2SticPUCAwEAAaOCA2MwggNfMAwGA1UdEwEB /wQCMAAwDgYDVR0PAQH/BAQDAgOoMDQGA1UdJQQtMCsGCCsGAQUFBwMCBggrBgEF BQcDAQYJYIZIAYb4QgQBBgorBgEEAYI3CgMDMDMGCCsGAQUFBwEBBCcwJTAjBggr BgEFBQcwAYYXaHR0cDovL29jc3AuY2FjZXJ0Lm9yZy8wMQYDVR0fBCowKDAmoCSg IoYgaHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5jcmwwggKfBgNVHREEggKW MIICkoIQaG9uay5zaWd4Y3B1Lm9yZ6AeBggrBgEFBQcIBaASDBBob25rLnNpZ3hj cHUub3JnghFob25rNi5zaWd4Y3B1Lm9yZ6AfBggrBgEFBQcIBaATDBFob25rNi5z aWd4Y3B1Lm9yZ4IPd3d3LnNpZ3hjcHUub3JnoB0GCCsGAQUFBwgFoBEMD3d3dy5z aWd4Y3B1Lm9yZ4ILc2lneGNwdS5vcmegGQYIKwYBBQUHCAWgDQwLc2lneGNwdS5v cmeCFGhvbmsuZHluLnNpZ3hjcHUub3JnoCIGCCsGAQUFBwgFoBYMFGhvbmsuZHlu LnNpZ3hjcHUub3JnghBodXBlLnNpZ3hjcHUub3JnoB4GCCsGAQUFBwgFoBIMEGh1 cGUuc2lneGNwdS5vcmeCEGltYXAuc2lneGNwdS5vcmegHgYIKwYBBQUHCAWgEgwQ aW1hcC5zaWd4Y3B1Lm9yZ4IQc210cC5zaWd4Y3B1Lm9yZ6AeBggrBgEFBQcIBaAS DBBzbXRwLnNpZ3hjcHUub3Jngg9naXQuc2lneGNwdS5vcmegHQYIKwYBBQUHCAWg EQwPZ2l0LnNpZ3hjcHUub3JnghB3aWtpLnNpZ3hjcHUub3JnoB4GCCsGAQUFBwgF oBIMEHdpa2kuc2lneGNwdS5vcmeCEmNhbGRhdi5zaWd4Y3B1Lm9yZ6AgBggrBgEF BQcIBaAUDBJjYWxkYXYuc2lneGNwdS5vcmeCE2NhcmRkYXYuc2lneGNwdS5vcmeg IQYIKwYBBQUHCAWgFQwTY2FyZGRhdi5zaWd4Y3B1Lm9yZ4IRbGlzdHMuc2lneGNw dS5vcmegHwYIKwYBBQUHCAWgEwwRbGlzdHMuc2lneGNwdS5vcmcwDQYJKoZIhvcN AQELBQADggIBAIsovvfdYsdedtnV10IZpgoVWS6Iwd/I0BLQd6E457L6xAgJTsfL zPpFc2OqwnTlEywPL6JOOU1GCsV5om0JghDC3GTz0rnwF6lToulKOSb33XNtnUB+ XG6AOMAzt3YW9zsXXeL4xMiFDEuK6wnqyfBmMI8TApQFsybMtZAN7gRY+BKFR5pG NjS5GI3bHx7lxWUFVV3DrYzDWfMR4mnK1oIrZ8N3Yscu5jlC0n8eA3rA9ujytzFl BK/0VCcuO3qXI7CUfNdu50vK+KurZFiAmnLfWDiYM2Q9bLIOKgU9dtH2rkN9WIS5 bwF9IOeCxvu9r9jlMtlVI8xCYcF2icBRoSKwlQl5xrwC7pbb2icR09wE/Qtq9mJt y58htz2ozPevc7f4yBzal1J3jxs2NzbC/LgnhAm9Tb33GJjRH3UmTPNLu4I6Av9Q MMcANLIcDPaKCGurMbkA/Sh76P95k9dSGKBiOF92gPX96XIGejSk6yKt96sJJRuq qD5pf4Y7WTD8nbJQ3TeJNe/NQ15RKX7fGkf7BCPc0hTLweExpC/PNd5AooqXlztz M0IHQtm1SlVhAP1UGP5aTat7DzXy/u3mr2Ple6izhL+2m6hFetO8RPD7z6MbRhTx 8OuSbdAucvvnl620MqlaWklGn6T5CCwMG1eL5Abz7RwlgI4xzxOPVhRu -----END CERTIFICATE----- 1 s:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddressemail@example.com i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddressfirstname.lastname@example.org -----BEGIN CERTIFICATE----- MIIHPTCCBSWgAwIBAgIBADANBgkqhkiG9w0BAQQFADB5MRAwDgYDVQQKEwdSb290 IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNB IENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZzAeFw0wMzAzMzAxMjI5NDlaFw0zMzAzMjkxMjI5NDlaMHkxEDAO BgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEi MCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJ ARYSc3VwcG9ydEBjYWNlcnQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEAziLA4kZ97DYoB1CW8qAzQIxL8TtmPzHlawI229Z89vGIj053NgVBlfkJ 8BLPRoZzYLdufujAWGSuzbCtRRcMY/pnCujW0r8+55jE8Ez64AO7NV1sId6eINm6 zWYyN3L69wj1x81YyY7nDl7qPv4coRQKFWyGhFtkZip6qUtTefWIonvuLwphK42y fk1WpRPs6tqSnqxEQR5YYGUFZvjARL3LlPdCfgv3ZWiYUQXw8wWRBB0bF4LsyFe7 w2t6iPGwcswlWyCR7BYCEo8y6RcYSNDHBS4CMEK4JZwFaz+qOqfrU0j36NK2B5jc G8Y0f3/JHIJ6BVgrCFvzOKKrF11myZjXnhCLotLddJr3cQxyYN/Nb5gznZY0dj4k epKwDpUeb+agRThHqtdB7Uq3EvbXG4OKDy7YCbZZ16oE/9KTfWgu3YtLq1i6L43q laegw1SJpfvbi1EinbLDvhG+LJGGi5Z4rSDTii8aP8bQUWWHIbEZAWV/RRyH9XzQ QUxPKZgh/TMfdQwEUfoZd9vUFBzugcMd9Zi3aQaRIt0AUMyBMawSB3s42mhb5ivU fslfrejrckzzAeVLIL+aplfKkQABi6F1ITe1Yw1nPkZPcCBnzsXWWdsC4PDSy826 YreQQejdIOQpvGQpQsgi3Hia/0PsmBsJUUtaWsJx8cTLc6nloQsCAwEAAaOCAc4w ggHKMB0GA1UdDgQWBBQWtTIb1Mfz4OaO873SsDrusjkY0TCBowYDVR0jBIGbMIGY gBQWtTIb1Mfz4OaO873SsDrusjkY0aF9pHsweTEQMA4GA1UEChMHUm9vdCBDQTEe MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0 IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmeCAQAwDwYDVR0TAQH/BAUwAwEB/zAyBgNVHR8EKzApMCegJaAjhiFodHRw czovL3d3dy5jYWNlcnQub3JnL3Jldm9rZS5jcmwwMAYJYIZIAYb4QgEEBCMWIWh0 dHBzOi8vd3d3LmNhY2VydC5vcmcvcmV2b2tlLmNybDA0BglghkgBhvhCAQgEJxYl aHR0cDovL3d3dy5jYWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQg b3ZlciB0byBodHRwOi8vd3d3LmNhY2VydC5vcmcwDQYJKoZIhvcNAQEEBQADggIB ACjH7pyCArpcgBLKNQodgW+JapnM8mgPf6fhjViVPr3yBsOQWqy1YPaZQwGjiHCc nWKdpIevZ1gNMDY75q1I08t0AoZxPuIrA2jxNGJARjtT6ij0rPtmlVOKTV39O9lg 18p5aTuxZZKmxoGCXJzN600BiqXfEVWqFcofN8CCmHBh22p8lqOOLlQ+TyGpkO/c gr/c6EWtTZBzCDyUZbAEmXZ/4rzCahWqlwQ3JNgelE5tDlG+1sSPypZt90Pf6DBl Jzt7u0NDY8RD97LsaMzhGY4i+5jhe1o+ATc7iwiwovOVThrLm82asduycPAtStvY sONvRUgzEv/+PDIqVPfE94rwiCPCR/5kenHA0R6mY7AHfqQv0wGP3J8rtsYIqQ+T SCX8Ev2fQtzzxD72V7DX3WnRBnc0CkvSyqD/HMaMyRa+xMwyN2hzXwj7UfdJUzYF CpUCTPJ5GhD22Dp1nPMd8aINcGeGG7MW9S/lpOt5hvk9C8JzC6WZrG/8Z7jlLwum GCSNe9FINSkYQKyTYOGWhlC0elnYjyELn8+CkcY7v2vcB5G5l1YjqrZslMZIBjzk zk6q5PYvCdxTby78dOs6Y5nCpqyJvKeyRKANihDjbPIky/qbn3BHLt4Ui9SyIAmW omTxJBzcoTWcFbLUvFUufQb1nA5V9FrWk9p2rSVzTMVD -----END CERTIFICATE----- --- Server certificate subject=/CN=honk.sigxcpu.org issuer=/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddressemail@example.com --- No client certificate CA names sent --- SSL handshake has read 4465 bytes and written 375 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 25CE690DDD33CB1CA47F3860484C79E5F16173F2564D640552E16D907E1DF86E Session-ID-ctx: Master-Key: CFCD36C29D1004673F807021C06253D418BB213E62E45D48DA71BF7C07B8899EFEF0A677D328E8A180C9D607F9DE8B7F Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 9f a6 bb 53 6c 76 a0 75-d5 ba 40 ed 4f 26 83 2b ...Slv.u..@.O&.+ 0010 - 0e 41 7c cc e9 de 7a bb-e0 3d 5d 42 43 da 2b b1 .A|...z..=]BC.+. 0020 - f3 59 7e ff 03 e5 41 00-b3 fb 98 3f 4f 5c 37 e2 .Y~...A....?O\7. 0030 - 74 a4 64 b7 f8 67 dc 0f-9c ea 41 0a 99 b6 1a 21 t.d..g....A....! 0040 - da d2 e0 f8 25 a4 a3 38-50 2b 91 a8 bd 76 5d b2 ....%..8P+...v]. 0050 - da b6 10 01 6d e8 ad 4d-bc d0 42 fd bf f6 99 fd ....m..M..B..... 0060 - 35 e3 50 44 2f d3 b9 d5-55 6a 20 a1 6d 5f 6e bf 5.PD/...Uj .m_n. 0070 - 5d de dd 4b d0 8c d2 2f-f7 0e cc 5a db b5 02 ed ]..K.../...Z.... 0080 - fb 72 b5 29 4c 9e f8 de-c4 cc 17 9d 00 96 b2 63 .r.)L..........c 0090 - aa 2d 57 82 57 22 ba ff-be 69 9a 0e e1 06 99 cc .-W.W"...i...... 00a0 - e7 44 92 86 b4 1e d2 b6-11 d7 d3 40 a5 77 83 ba .D.........@.w.. 00b0 - 5f fb 18 db 57 48 bd 27-eb 4b 16 dc b0 be 1d be _...WH.'.K...... Start Time: 1451065956 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- closed
$ openssl x509 -in cacert_root.crt -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddressfirstname.lastname@example.org Validity Not Before: Mar 30 12:29:49 2003 GMT Not After : Mar 29 12:29:49 2033 GMT Subject: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddressemail@example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:ce:22:c0:e2:46:7d:ec:36:28:07:50:96:f2:a0: 33:40:8c:4b:f1:3b:66:3f:31:e5:6b:02:36:db:d6: 7c:f6:f1:88:8f:4e:77:36:05:41:95:f9:09:f0:12: cf:46:86:73:60:b7:6e:7e:e8:c0:58:64:ae:cd:b0: ad:45:17:0c:63:fa:67:0a:e8:d6:d2:bf:3e:e7:98: c4:f0:4c:fa:e0:03:bb:35:5d:6c:21:de:9e:20:d9: ba:cd:66:32:37:72:fa:f7:08:f5:c7:cd:58:c9:8e: e7:0e:5e:ea:3e:fe:1c:a1:14:0a:15:6c:86:84:5b: 64:66:2a:7a:a9:4b:53:79:f5:88:a2:7b:ee:2f:0a: 61:2b:8d:b2:7e:4d:56:a5:13:ec:ea:da:92:9e:ac: 44:41:1e:58:60:65:05:66:f8:c0:44:bd:cb:94:f7: 42:7e:0b:f7:65:68:98:51:05:f0:f3:05:91:04:1d: 1b:17:82:ec:c8:57:bb:c3:6b:7a:88:f1:b0:72:cc: 25:5b:20:91:ec:16:02:12:8f:32:e9:17:18:48:d0: c7:05:2e:02:30:42:b8:25:9c:05:6b:3f:aa:3a:a7: eb:53:48:f7:e8:d2:b6:07:98:dc:1b:c6:34:7f:7f: c9:1c:82:7a:05:58:2b:08:5b:f3:38:a2:ab:17:5d: 66:c9:98:d7:9e:10:8b:a2:d2:dd:74:9a:f7:71:0c: 72:60:df:cd:6f:98:33:9d:96:34:76:3e:24:7a:92: b0:0e:95:1e:6f:e6:a0:45:38:47:aa:d7:41:ed:4a: b7:12:f6:d7:1b:83:8a:0f:2e:d8:09:b6:59:d7:aa: 04:ff:d2:93:7d:68:2e:dd:8b:4b:ab:58:ba:2f:8d: ea:95:a7:a0:c3:54:89:a5:fb:db:8b:51:22:9d:b2: c3:be:11:be:2c:91:86:8b:96:78:ad:20:d3:8a:2f: 1a:3f:c6:d0:51:65:87:21:b1:19:01:65:7f:45:1c: 87:f5:7c:d0:41:4c:4f:29:98:21:fd:33:1f:75:0c: 04:51:fa:19:77:db:d4:14:1c:ee:81:c3:1d:f5:98: b7:69:06:91:22:dd:00:50:cc:81:31:ac:12:07:7b: 38:da:68:5b:e6:2b:d4:7e:c9:5f:ad:e8:eb:72:4c: f3:01:e5:4b:20:bf:9a:a6:57:ca:91:00:01:8b:a1: 75:21:37:b5:63:0d:67:3e:46:4f:70:20:67:ce:c5: d6:59:db:02:e0:f0:d2:cb:cd:ba:62:b7:90:41:e8: dd:20:e4:29:bc:64:29:42:c8:22:dc:78:9a:ff:43: ec:98:1b:09:51:4b:5a:5a:c2:71:f1:c4:cb:73:a9: e5:a1:0b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 16:B5:32:1B:D4:C7:F3:E0:E6:8E:F3:BD:D2:B0:3A:EE:B2:39:18:D1 X509v3 Authority Key Identifier: keyid:16:B5:32:1B:D4:C7:F3:E0:E6:8E:F3:BD:D2:B0:3A:EE:B2:39:18:D1 DirName:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddressfirstname.lastname@example.org serial:00 X509v3 Basic Constraints: critical CA:TRUE X509v3 CRL Distribution Points: Full Name: URI:https://www.cacert.org/revoke.crl Netscape CA Revocation Url: https://www.cacert.org/revoke.crl Netscape CA Policy Url: http://www.cacert.org/index.php?id=10 Netscape Comment: To get your own certificate for FREE head over to http://www.cacert.org Signature Algorithm: md5WithRSAEncryption 28:c7:ee:9c:82:02:ba:5c:80:12:ca:35:0a:1d:81:6f:89:6a: 99:cc:f2:68:0f:7f:a7:e1:8d:58:95:3e:bd:f2:06:c3:90:5a: ac:b5:60:f6:99:43:01:a3:88:70:9c:9d:62:9d:a4:87:af:67: 58:0d:30:36:3b:e6:ad:48:d3:cb:74:02:86:71:3e:e2:2b:03: 68:f1:34:62:40:46:3b:53:ea:28:f4:ac:fb:66:95:53:8a:4d: 5d:fd:3b:d9:60:d7:ca:79:69:3b:b1:65:92:a6:c6:81:82:5c: 9c:cd:eb:4d:01:8a:a5:df:11:55:aa:15:ca:1f:37:c0:82:98: 70:61:db:6a:7c:96:a3:8e:2e:54:3e:4f:21:a9:90:ef:dc:82: bf:dc:e8:45:ad:4d:90:73:08:3c:94:65:b0:04:99:76:7f:e2: bc:c2:6a:15:aa:97:04:37:24:d8:1e:94:4e:6d:0e:51:be:d6: c4:8f:ca:96:6d:f7:43:df:e8:30:65:27:3b:7b:bb:43:43:63: c4:43:f7:b2:ec:68:cc:e1:19:8e:22:fb:98:e1:7b:5a:3e:01: 37:3b:8b:08:b0:a2:f3:95:4e:1a:cb:9b:cd:9a:b1:db:b2:70: f0:2d:4a:db:d8:b0:e3:6f:45:48:33:12:ff:fe:3c:32:2a:54: f7:c4:f7:8a:f0:88:23:c2:47:fe:64:7a:71:c0:d1:1e:a6:63: b0:07:7e:a4:2f:d3:01:8f:dc:9f:2b:b6:c6:08:a9:0f:93:48: 25:fc:12:fd:9f:42:dc:f3:c4:3e:f6:57:b0:d7:dd:69:d1:06: 77:34:0a:4b:d2:ca:a0:ff:1c:c6:8c:c9:16:be:c4:cc:32:37: 68:73:5f:08:fb:51:f7:49:53:36:05:0a:95:02:4c:f2:79:1a: 10:f6:d8:3a:75:9c:f3:1d:f1:a2:0d:70:67:86:1b:b3:16:f5: 2f:e5:a4:eb:79:86:f9:3d:0b:c2:73:0b:a5:99:ac:6f:fc:67: b8:e5:2f:0b:a6:18:24:8d:7b:d1:48:35:29:18:40:ac:93:60: e1:96:86:50:b4:7a:59:d8:8f:21:0b:9f:cf:82:91:c6:3b:bf: 6b:dc:07:91:b9:97:56:23:aa:b6:6c:94:c6:48:06:3c:e4:ce: 4e:aa:e4:f6:2f:09:dc:53:6f:2e:fc:74:eb:3a:63:99:c2:a6: ac:89:bc:a7:b2:44:a0:0d:8a:10:e3:6c:f2:24:cb:fa:9b:9f: 70:47:2e:de:14:8b:d4:b2:20:09:96:a2:64:f1:24:1c:dc:a1: 35:9c:15:b2:d4:bc:55:2e:7d:06:f5:9c:0e:55:f4:5a:d6:93: da:76:ad:25:73:4c:c5:43 wbaker:wbaker@vast [wbaker wheel users mock bakers source yahoo bakerfamily cameras android] [l2 u0002 ssh] [F19 Schrödingers_Cat] ~/sandbox/cacert.org $ openssl x509 -in honk.sigxcpu.org_host.crt -CA cacert_root.crt -noout -text openssl x509 -in honk.sigxcpu.org_host.crt -CA cacert_root.crt -noout -text Getting CA Private Key unable to load CA Private Key 139828100306848:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: ANY PRIVATE KEY wbaker:wbaker@vast [wbaker wheel users mock bakers source yahoo bakerfamily cameras android] [l2 u0002 ssh] [F19 Schrödingers_Cat] ~/sandbox/cacert.org $ openssl x509 -in honk.sigxcpu.org_host.crt -noout -text openssl x509 -in honk.sigxcpu.org_host.crt -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 1015545 (0xf7ef9) Signature Algorithm: sha256WithRSAEncryption Issuer: O=Root CA, OU=http://www.cacert.org, CN=CA Cert Signing Authority/emailAddressemail@example.com Validity Not Before: Sep 4 18:45:22 2014 GMT Not After : Sep 3 18:45:22 2016 GMT Subject: CN=honk.sigxcpu.org Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:ab:26:6e:d7:cd:b9:33:89:c7:3e:3f:85:6d:95: 84:99:bd:e6:f1:3e:57:42:88:6e:76:30:2a:cf:e3: 39:e2:f2:9f:e4:8b:72:12:3c:76:b6:5b:cb:21:62: 22:74:52:a1:b5:89:a2:d5:77:7f:31:f8:da:df:57: 69:78:22:33:53:85:4d:3b:ef:db:ab:f0:a0:59:4a: ea:66:01:7a:a0:d0:52:bd:b2:d2:52:69:ce:33:a7: 6c:2b:59:6f:08:6c:20:a1:5b:af:8b:4b:1f:71:2a: 5b:0b:8a:c1:55:8c:56:90:0f:d5:e6:3d:41:15:a8: f9:2b:af:f0:5a:9c:b3:aa:2d:a1:b3:57:76:34:d4: 2e:e2:4d:a3:54:31:dd:bc:2a:18:57:f2:5b:b5:65: da:9b:bc:c7:de:69:93:d5:96:82:40:ed:8f:a3:b9: 72:1f:53:df:e3:b3:c2:e1:6d:cc:54:f7:03:74:d6: 96:32:08:0a:29:8a:7f:b9:68:1e:e3:24:c2:4b:12: 4f:02:8b:6f:67:01:67:26:c6:db:a6:c7:96:65:37: 40:90:f0:e6:d7:14:1e:a2:bd:1a:1e:49:85:cf:d3: ec:7e:a9:76:ed:e7:39:a2:91:e2:76:ca:8f:eb:aa: c2:5f:a3:16:14:25:aa:c6:50:bf:1b:62:d9:2b:62: 70:f5 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication, Netscape Server Gated Crypto, Microsoft Server Gated Crypto Authority Information Access: OCSP - URI:http://ocsp.cacert.org/ X509v3 CRL Distribution Points: Full Name: URI:http://crl.cacert.org/revoke.crl X509v3 Subject Alternative Name: DNS:honk.sigxcpu.org, othername:<unsupported>, DNS:honk6.sigxcpu.org, othername:<unsupported>, DNS:www.sigxcpu.org, othername:<unsupported>, DNS:sigxcpu.org, othername:<unsupported>, DNS:honk.dyn.sigxcpu.org, othername:<unsupported>, DNS:hupe.sigxcpu.org, othername:<unsupported>, DNS:imap.sigxcpu.org, othername:<unsupported>, DNS:smtp.sigxcpu.org, othername:<unsupported>, DNS:git.sigxcpu.org, othername:<unsupported>, DNS:wiki.sigxcpu.org, othername:<unsupported>, DNS:caldav.sigxcpu.org, othername:<unsupported>, DNS:carddav.sigxcpu.org, othername:<unsupported>, DNS:lists.sigxcpu.org, othername:<unsupported> Signature Algorithm: sha256WithRSAEncryption 8b:28:be:f7:dd:62:c7:5e:76:d9:d5:d7:42:19:a6:0a:15:59: 2e:88:c1:df:c8:d0:12:d0:77:a1:38:e7:b2:fa:c4:08:09:4e: c7:cb:cc:fa:45:73:63:aa:c2:74:e5:13:2c:0f:2f:a2:4e:39: 4d:46:0a:c5:79:a2:6d:09:82:10:c2:dc:64:f3:d2:b9:f0:17: a9:53:a2:e9:4a:39:26:f7:dd:73:6d:9d:40:7e:5c:6e:80:38: c0:33:b7:76:16:f7:3b:17:5d:e2:f8:c4:c8:85:0c:4b:8a:eb: 09:ea:c9:f0:66:30:8f:13:02:94:05:b3:26:cc:b5:90:0d:ee: 04:58:f8:12:85:47:9a:46:36:34:b9:18:8d:db:1f:1e:e5:c5: 65:05:55:5d:c3:ad:8c:c3:59:f3:11:e2:69:ca:d6:82:2b:67: c3:77:62:c7:2e:e6:39:42:d2:7f:1e:03:7a:c0:f6:e8:f2:b7: 31:65:04:af:f4:54:27:2e:3b:7a:97:23:b0:94:7c:d7:6e:e7: 4b:ca:f8:ab:ab:64:58:80:9a:72:df:58:38:98:33:64:3d:6c: b2:0e:2a:05:3d:76:d1:f6:ae:43:7d:58:84:b9:6f:01:7d:20: e7:82:c6:fb:bd:af:d8:e5:32:d9:55:23:cc:42:61:c1:76:89: c0:51:a1:22:b0:95:09:79:c6:bc:02:ee:96:db:da:27:11:d3: dc:04:fd:0b:6a:f6:62:6d:cb:9f:21:b7:3d:a8:cc:f7:af:73: b7:f8:c8:1c:da:97:52:77:8f:1b:36:37:36:c2:fc:b8:27:84: 09:bd:4d:bd:f7:18:98:d1:1f:75:26:4c:f3:4b:bb:82:3a:02: ff:50:30:c7:00:34:b2:1c:0c:f6:8a:08:6b:ab:31:b9:00:fd: 28:7b:e8:ff:79:93:d7:52:18:a0:62:38:5f:76:80:f5:fd:e9: 72:06:7a:34:a4:eb:22:ad:f7:ab:09:25:1b:aa:a8:3e:69:7f: 86:3b:59:30:fc:9d:b2:50:dd:37:89:35:ef:cd:43:5e:51:29: 7e:df:1a:47:fb:04:23:dc:d2:14:cb:c1:e1:31:a4:2f:cf:35: de:40:a2:8a:97:97:3b:73:33:42:07:42:d9:b5:4a:55:61:00: fd:54:18:fe:5a:4d:ab:7b:0f:35:f2:fe:ed:e6:af:63:e5:7b: a8:b3:84:bf:b6:9b:a8:45:7a:d3:bc:44:f0:fb:cf:a3:1b:46: 14:f1:f0:eb:92:6d:d0:2e:72:fb:e7:97:ad:b4:32:a9:5a:5a: 49:46:9f:a4:f9:08:2c:0c:1b:57:8b:e4:06:f3:ed:1c:25:80: 8e:31:cf:13:8f:56:14:6e
Bob Worrall is Senior Vice President & Chief Information Officer, Juniper.
<quote>During a recent internal code review, Juniper discovered unauthorized code in ScreenOS that could allow a knowledgeable attacker to gain administrative access to NetScreen® devices and to decrypt VPN connections. Once we identified these vulnerabilities, we launched an investigation into the matter, and worked to develop and issue patched releases for the latest versions of ScreenOS.</quote>
- ScreenOS 6.2.0r15 through 6.2.0r18
released “in” 2008.
- ScreenOS 6.3.0r12 through 6.3.0r20.
released “in” 2009.
- ScreenOS 6.2.0r15 through 6.2.0r18
- Not Affected (per Juniper)
- Remote administrator access
- “enabling” VPN decryption (whatever that means)
- Remote administrator access
- In place since 2012.
- source: a tweet
- The compromise in place since 2008.
- source: The Register, speculation.
in archaeological order; derivative effluent on top, more original work below.
- Juniper Firewalls with ScreenOS Backdoored Since 2012; Swati Khandelwal; In The Hacker News; 2015-12-18.
tl;dr → no new material.
- Juniper Finds Backdoor that Decrypts VPN Traffic; Michael Mimoso; In ThreatPost; 2015-12-17.
tl;dr → discursive, Snowden, NSA, ANT, FEEDTHROUGH.
- Juniper hacked: “Unauthorized code” found in ScreenOS; Mike Wheatley; In Silicon ANGLE|; 2015-12-17.
tl;dr → speculation
- ‘Unauthorized code’ that decrypts VPNs found in Juniper’s ScreenOS; Simon Sharwood; In The Register; 2015-12-17.
Teaser: And it may have been there since 2008, making this a late contender for FAIL of the year
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from a free software distribution shop: Get Fedora
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from an advice shop: The Graying of America
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from a research lab: Tech Report (Cyril Labbé, “Ike Antkara, One of the great stars in the scientific firmament,” International Society for Scientometrics and Informetrics Newsletter, 2010 6(2), pages 48-52, hal-00713564).
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from a software theoretician: The Software Engineering Institute at Carnegie Mellon University
tl;dr → server supports DHE_EXPORT ciphers; client willing to accept any directive to downgrade
SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA SSLHonorCipherOrder on
- Adrian et al. (14 authors); Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice; 2015-05-20; 13 pages.
- Logjam Server Test
- Guide to Deploying Diffie-Hellman for TLS
- proof of concept demos
- Any server that supports DHE_EXPORT ciphers.
- Elliptic-Curve Diffie-Hellman Key Exchange.
David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, Paul Zimmermann; Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice; Available at weakdh.org; 2015-05-20; 13 pages.
We investigate the security of Diffie-Hellman key exchange as used in popular Internet protocols and find it to be less secure than widely believed. First, we present a novel flaw in TLS that allows a man-in-the-middle to downgrade connections to “export-grade” Diffie-Hellman. To carry out this attack, we implement the number field sieve discrete log algorithm. After a week-long precomputation for a specified 512-bit group, we can compute arbitrary discrete logs in this group in minutes. We find that 82% of vulnerable servers use a single 512-bit group, allowing us to compromise connections to 7% of Alexa Top Million HTTPS sites. In response, major browsers are being changed to reject short groups.
We go on to consider Diffie-Hellman with 768- and 1024-bit groups. A small number of fixed or standardized groups are in use by millions of TLS, SSH, and VPN servers. Performing precomputations on a few of these groups would allow a passive eavesdropper to decrypt a large fraction of Internet traffic. In the 1024-bit case, we estimate that such computations are plausible given nation-state resources, and a close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break. We conclude that moving to stronger key exchange methods should be a priority for the Internet community.
- System Administration Guide
Remediations (and see below)
- Diffie-Hellman Key Exchange (DHKE) > 1024 bits
- Elliptic Curve Diffie-Hellman (ECDH)
- Elliptic Curve Diffie-Hellman (ECDH)
a pun on Discrete Logarithm
- Logjam: How Diffie-Hellman Fails in Practice; promotional site: weakdh.org.
- HTTPS-crippling attack threatens tens of thousands of Web and mail servers; Dan Goodin; In Ars Technica; 2015-05-20; previously filled.
Teaser: Diffie-Hellman downgrade weakness allows attackers to intercept encrypted data.
Yes, there were references
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from a university academic paper dump: East Central Minnesota: Social and Economic Trends and Implications, Forestry Analysis; James Skurla, Richard Lichty, William Fleischman with Jean Jacobson, Malita Barkataki, Joshua Williams; Labovitz School of Business & Economics, Bureau of Business and Economic Research; 2004-03; 58 pages.
$ openssl s_client -connect lsbe.d.umn.edu:443 CONNECTED(00000003) depth=0 C = US, postalCode = 55455, ST = MN, L = Minneapolis, street = 100 Union Street SE, O = University of Minnesota, OU = Information Technology Systems and Services, CN = lsbe.d.umn.edu verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = US, postalCode = 55455, ST = MN, L = Minneapolis, street = 100 Union Street SE, O = University of Minnesota, OU = Information Technology Systems and Services, CN = lsbe.d.umn.edu verify error:num=27:certificate not trusted verify return:1 depth=0 C = US, postalCode = 55455, ST = MN, L = Minneapolis, street = 100 Union Street SE, O = University of Minnesota, OU = Information Technology Systems and Services, CN = lsbe.d.umn.edu verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=US/postalCode=55455/ST=MN/L=Minneapolis/street=100 Union Street SE/O=University of Minnesota/OU=Information Technology Systems and Services/CN=lsbe.d.umn.edu i:/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO High-Assurance Secure Server CA i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root --- Server certificate -----BEGIN CERTIFICATE----- MIIFYjCCBEqgAwIBAgIQVFzSz3q6sbDzu/pFa7wczjANBgkqhkiG9w0BAQUFADBR MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSW50ZXJuZXQyMREwDwYDVQQLEwhJbkNv bW1vbjEbMBkGA1UEAxMSSW5Db21tb24gU2VydmVyIENBMB4XDTE0MDEwNzAwMDAw MFoXDTE3MDEwNjIzNTk1OVowgc8xCzAJBgNVBAYTAlVTMQ4wDAYDVQQREwU1NTQ1 NTELMAkGA1UECBMCTU4xFDASBgNVBAcTC01pbm5lYXBvbGlzMRwwGgYDVQQJExMx MDAgVW5pb24gU3RyZWV0IFNFMSAwHgYDVQQKExdVbml2ZXJzaXR5IG9mIE1pbm5l c290YTE0MDIGA1UECxMrSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTeXN0ZW1zIGFu ZCBTZXJ2aWNlczEXMBUGA1UEAxMObHNiZS5kLnVtbi5lZHUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDL+BCPttaM47RODcZx6vxCPOksxwBShIJZrXZa 4SZZnaBZz5dAUS1urX6anu6ewgtxlX0UO6oYGIBc1uhRTIEC2g+F36JzRQtfG0Oe Z3XX5Nrkix5Spz0FA9EhVHQZL+FYeB6SwtVjTqyPExzxn2LakxmWWhxkGVyLMQFT vuEsCHLf2wITR3ePXPK94dHnr/qZCNHe0lhfyAot7z/PJoCC+lOmV+BqNE7wjzJ9 cebjRdw4EnJnrmmRjjhTaljGXbVVSUTWXdizZvi8vDkqAKEJwuvKuYNGFOKmdlP+ Ddf6qHzeWziNw7Qz1M5UKNDpV6EeDpy5QHEkRZtarj5EzSqPAgMBAAGjggG1MIIB sTAfBgNVHSMEGDAWgBRIT1r6L0qaXuBQ82t7VaXe9b40XTAdBgNVHQ4EFgQUK3FC LpGZrloJsYFkpxXQ1heUnYEwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAw HQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMGcGA1UdIARgMF4wUgYMKwYB BAGuIwEEAwEBMEIwQAYIKwYBBQUHAgEWNGh0dHBzOi8vd3d3LmluY29tbW9uLm9y Zy9jZXJ0L3JlcG9zaXRvcnkvY3BzX3NzbC5wZGYwCAYGZ4EMAQICMD0GA1UdHwQ2 MDQwMqAwoC6GLGh0dHA6Ly9jcmwuaW5jb21tb24ub3JnL0luQ29tbW9uU2VydmVy Q0EuY3JsMG8GCCsGAQUFBwEBBGMwYTA5BggrBgEFBQcwAoYtaHR0cDovL2NlcnQu aW5jb21tb24ub3JnL0luQ29tbW9uU2VydmVyQ0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5pbmNvbW1vbi5vcmcwGQYDVR0RBBIwEIIObHNiZS5kLnVtbi5l ZHUwDQYJKoZIhvcNAQEFBQADggEBAGOaCsizcFktTmzhzrmOUayqwsNPBFfN9gMO DUAwcU+4yDXIfMHMYwe4EbLBX4xDZwEG6ldUeqfzWK4nk9DPIfkQvUiOoY5/bYdZ crX/LxlosZdJEbQLcbNpYEtTwGHw9n9u1XCTd2Gx9fOj/n0tAltaiDRTUULrG7ke kpIGI4RNjO+cl4n629BFufs9h/n12qhwW2sv20CKyVmxgEvFXEU3tX81J4PqHOC3 z4aVyZKion9zx9LZBg86rsWt6joT8pN20gZ9EO897uhhn+UwmOUkXXNYQip+ydIh JmfBz2+WncmPTh6d2RDbgeILgHSig0DR+NLs4TF+0t4GkwG/8O4= -----END CERTIFICATE----- subject=/C=US/postalCode=55455/ST=MN/L=Minneapolis/street=100 Union Street SE/O=University of Minnesota/OU=Information Technology Systems and Services/CN=lsbe.d.umn.edu issuer=/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA --- No client certificate CA names sent Server Temp Key: DH, 1024 bits --- SSL handshake has read 3543 bytes and written 447 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 75FB051CAEF962ADE2E15544DE1FB5E2CE542314DF5A4DF78A135D6072ABEDD5 Session-ID-ctx: Master-Key: 80A072911AFF35925DA98ED12E2D1D6A94B897DCB9221113FFB0913C4827C89746AF228CFDE1E532E01B238328FD37F8 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket: 0000 - d2 5a 65 ca c9 b9 73 8e-2a 0c 3b 61 71 33 7e d6 .Ze...s.*.;aq3~. 0010 - da 56 18 53 a2 ed cd fd-a1 91 17 69 d8 0c cc 44 .V.S.......i...D 0020 - 8b c0 b8 71 e2 bf 22 5f-d0 d2 de 34 e8 04 a4 ac ...q.."_...4.... 0030 - e3 3c d7 60 b7 5f 20 c6-2e 77 6e a6 59 33 0d d7 .
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from a consumer-focused linkbait purveyor: The Huffington Post.
- PrivDog v18.104.22.168 released; In Malware Tips
- COMOD Security Solutions Inc.
- Advisory; by PrivDog
- Vulnerability Note VU#366544 – Adtrustmedia PrivDog fails to validate SSL certificates
- Vulnerability Note VU#529496 – Komodia Redirector with SSL Digestor fails to properly validate SSL and installs non-unique root CA certificates and private keys
- LavaSoft Ad-Aware Web Companion
- Komodia SSL Digester
- AdAware AdBlocker
- Melih Abdulhayoğlu; Would have been much easier to build an adblocker without caring for Publishers; In His Blog; 2014-01-02.
- Melih Abdulhayoğlu; Comodo Manifesto: Why I Am Doing What I Am Doing; In His Blog; 2008-08-07.
In archaeological order … derivatives on top, more original sources below…
- Superfish uses an SDK from Komodia to do DLL MITM; a gistfile; 2015-02-24.
Exhibits certificates from parental control that uses Komodia’s SDK
- Adware Privdog worse than Superfish; Hanno Böck; In His Blog; 2015-02-23.
- Worse than Superfish? Comodo-affiliated PrivDog compromises web security too; Lucian Constantin; In PC World; 2015-02-23.
- Is PrivDog another Superfish; In Hacker News of Y Combinator from 2015-02-22.
- Windows SSL Interception Gone Wild.; Some individual, perhaps Matt Richard (Fcebook), using the self-asserted identity token Protect the Graph
- In Their Blog; 2016-02-20.
Matt Richard is a Threats Researcher on the Facebook Security Team.
- Filippo Valsorda (CloudFlare); Komodia SuperFish SSL Validation is Broken; In His Blog; 2015-02-20.
Filippo Valsorda is on security detail, CloudFlare, based in London
<quote>their keys can be extracted easily (same password: “komodia”)</quote>
- had issues before
- “Superfish’s mistake was using the same root certificate across all deployments. PrivDog’s mistake is not validating certificates at all.” attributed to Amichai Shulman, CTO of security firm Imperva in PC World.
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from a Security Research Lab: QR Inception: Barcode-in-Barcode Attacks
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice: Dell 28 Ultra HD Monitor – P2815Q
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice: www.opensource.apple.com
Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice: here