whatcounts.com | Your connection is not secure

Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice on a DIY computer-hobbyist site.


Explanation

sci-hub.io | This Connection is Untrusted

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



Explanation

  • 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.

A History of Hard Choices (managing the PKI across MD5, SHA-1 and on to SHA-2) | Ryan Sleev (of Google, not speaking for Google)

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.

Mentions

  • 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)

Context

<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>

Timeline

The important contribution

Referenced

  • Stevens, Karpman, and Peyrin announce The SHAppening, a freestart collision attack on SHA-1.

Who

  • Rick Andrews, staff, Symantec
  • Michael Coates, Trust and Information Security Officer, Twitter.
  • Matthew Prince, Chief Executive Officer, CloudFlare.
  • Alex Stamos, Chief Security Officer, Facebook.

Principals

  • CloudFlare
  • Comodo
  • Facebook
  • Google
  • Microsoft
  • Mozilla
  • PayPal
  • Symantec
  • Twitter

Argot

  • App Transport Security (ATS)
  • Certificate Authority (CA)
  • Legacy Verified (LV)
  • MD5
  • Transport Layer Security (TLS)
    • TLS v1.2
  • SHA-1
  • SHA-2
    • SHA-256
    • SHA-512

Referenced

  • 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.

honk.sigxcpu.org | This Connection is Untrusted

Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from a free software distribution shop: krb5-auth-dialog



Explanation

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 (md5WithRSAEncryption)
    • whereas the host certificate signed by that issuer uses SHA-2 (sha256WithRSAEncryption)

Remediation

If you want to install the CAcert Root Certificate … it’s work, and risky, with the MD5 on the root, and all.

Actualities

$ 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 = support@cacert.org
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/emailAddress=support@cacert.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/emailAddress=support@cacert.org
   i:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.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/emailAddress=support@cacert.org
---
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/emailAddress=support@cacert.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/emailAddress=support@cacert.org
        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/emailAddress=support@cacert.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/emailAddress=support@cacert.org
        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

Juniper’s ScreenOS source code base was hacked, backdoors were installed, code was deployed everywhere, for years

Important Announcement about ScreenOS®; Bob Worrall (Juniper); 2015-12-17.
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>

Mentions

  • patches
  • Affected
    • ScreenOS 6.2.0r15 through 6.2.0r18
      released “in” 2008.
    • ScreenOS 6.3.0r12 through 6.3.0r20.
      released “in” 2009.
  • Not Affected (per Juniper)
    • SRX
    • Junos
  • Effect
    • Remote administrator access
      • SSH
      • Telnet
    • “enabling” VPN decryption (whatever that means)

Folklore

  • In place since 2012.
    • source: a tweet
  • The compromise in place since 2008.
    • source: The Register, speculation.

Promotions

in archaeological order; derivative effluent on top, more original work below.

Via: backfill.

Actualities

hal.inria.fr | This Connection is Untrusted

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).

sei.cmu.com | This Connection is Untrusted

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
https://sei.cmu.edu/news/article.cfm?assetid=77817&article=268&year=2013

bugzilla.linux-nfs.org | This Connection is Untrusted

Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice from a core technology provider: Linux NFS

226Bug in idmapd incorrectly maps uids in read vs write; At Linux NFS; 2012-03-12 → 2014-01-29.

The Logjam Attack: How Diffie-Hellman Fails in Practice

Logjam: How Diffie-Hellman Fails in Practice

tl;dr → server supports DHE_EXPORT ciphers; client willing to accept any directive to downgrade

Remediation

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

Referenced

Mentioned

  • Any server that supports DHE_EXPORT ciphers.
  • Elliptic-Curve Diffie-Hellman Key Exchange.

Who

Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice | Adrian et al. (+13 others) weakdh.org

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.

Abstract

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.

Mentions

  • weakdh.org
  • System Administration Guide
    Remediations (and see below)

    • Diffie-Hellman Key Exchange (DHKE) > 1024 bits
    • Elliptic Curve Diffie-Hellman (ECDH)
  • Elliptic Curve Diffie-Hellman (ECDH)
  • Logjam
    a pun on Discrete Logarithm

Remediations

Summarization of the Guide to Deploying Diffie-Hellman for TLS from weakdh.org

Promotions

References

Yes, there were references

 

lsbe.d.umn.edu | This Connection is Untrusted

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   .

PrivDog

PrivDog

Vendors

Browsers

  • Chromodo
  • Dragon
  • IceDragon

Advisories

  • Advisory; by PrivDog
  • Vulnerability Note VU#366544Adtrustmedia PrivDog fails to validate SSL certificates
  • Vulnerability Note VU#529496Komodia Redirector with SSL Digestor fails to properly validate SSL and installs non-unique root CA certificates and private keys

Who

Melih Abdulhayoğlu

Announcing PrivDog
Announcing Comodo

 Melih Abdulhayoğlu

Summarizations

In archaeological order … derivatives on top, more original sources below…

Mentions

  • 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.

Materials

Actualities

www.privdog.com; Screenshot from 2015-02-24 19:02:14PrivDog Secure Connection Inspector CA
Bank of America MITM
Via: backfill

accessories.dell.com | This Connection is Untrusted

Nothing says “The Web is Misconfigured” quite like a low-level security protocol failure notice: Dell 28 Ultra HD Monitor – P2815Q