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.


Roundup on Onavo Protect VPN used to inform Facebook UX, M&A | Houseparty contra Bonfire, On This Day contra Timehop

In archaeological order…

tl;dr → Onavo is a VPN. Facebook snoops the traffic on it to grok trends. Trends highlights cause cloned features in Facebook UX or deal flow at Facebook M&A.

  • The Washington Post piece goes broad to illustrate the pattern across a wide range of business lines and a long time span.
  • The Wall Street Journal (WSJ) piece goes deep to focus on travel log: group video chat with Facebook’s attempt to acqui-hire Houseparty prior to the launch of Bonfire in 2017-Q4 (“in the Fall”).


  • Onavo
    • Onavo Protect
    • Tel Aviv, Israel
  • Science
    • a startup studio, an incubator, a venture capital shop.
    • Los Angeles.
  • Meerkat
  • Verto Analytics
    • sourced the DAU factoids.
    • Hannu Verkasalo, CEO
  • Sensor Tower.
    • sourced the app popularity factoids
  • Bonfire, Facebook

The Four Dominant Companies

  • Apple
  • Google Alphabet
  • Amazon
  • Facebook



The Misdirection

Onavo does not not state its affiliation with Facebook in T&C on stores.
This is positioned as a sort of misdirective cloaking to consumers. It allows Facebook to observe nominally the VPN traffic flowing over “its” wires.

The Subsumption

Facebook competitor apps become tabs in the Facebook UX.

  • Event scheduling
    Cloning: Meetup
  • Fundraising
    Cloning: Kickstarter, GoFundMe
  • Messaging (WattsApp)
    Cloning: SMS
  • Marketplace
    Cloning: Craigslist
  • Meal delivery
    Cloning: Grubhub, Seamless, Caviar, Postmates.
  • Photo memorabilia (On This Day)
    Cloning: Timehop, Dropbox, Google Drive, iPhone camera (on box?)

The Pattern


  • Quidsi of Diapers.com
  • Something contra Blue Apron


  • Instagram
  • WhatsApp
  • Something contra Snap’s Snapchat.

Google Alphabet

  • Waze for (Google) Maps
  • Something contra Snap’s Snapchat.



  • an app
  • cloned by Facebook


  • an app
    • casual small-group chat by video.
    • Like, but different
      • Meerkat
      • (Google) Hangouts
      • “everyone” has a teen-focused group chat.…
    • Cultures (both)
    • The promotion page uses Flash.
      <snide>Are you kidding me?  In 2017?</snide>
    • Something about a kerfluffle with a change in the Terms & Conditions (T&C)
  • Launched
    • 2016-02.
    • as Life on Air Inc.; renamed Houseparty
  • Location
    • San Francisco, CA
    • Some warehouse; around SOMA
  • Founders
    • Ben Rubin,
      • age 29
    • Sima Sistani
      • age 38
    • Itai Danino
      • exists
  • Funders
    • Greylock Partners

      • Josh Elman, with board representation
    • Sequoia

      • Mike Vernal, with board representation
      • $50M
      • 2016?
  • Staff
    • Employees
      • 25
      • “30% increase” since “then” in 2016.
    • Kinshuk Mishra
      • vice president of engineering, Houseparty
      • ex-Spotify AB
      • hired 2016


  • “Don’t be too proud to copy” attributed to Mark Zuckerberg, Facebook via a leaked memo; in The Wall Street Journal (WSJ).

Attributed to The Washington Post.

  • <quote>acebook is able to glean detailed insights about what consumers are doing when they are not using the social network’s family of apps, which includes Facebook, Messenger, WhatsApp and Instagram</quote>
  • <quote>Facebook’s use of Onavo is partly borne of need. Because Google and Apple, for instance, control the operating systems in which many apps live, they have access to huge amounts of information about how consumers use their apps. Facebook is more limited. It knows what consumers do within its own apps, and it knows about behavior on apps that work with Facebook — such as for sign-in credentials. Onavo, on the other hand, helps Facebook’s expanding ambitions by offering near real-time access to information about what users do while Onavo is active in the background. Onavo sends anonymized data to Facebook on what apps consumers have installed, how frequently they open those apps, how long they linger inside them, and the sequence throughout the day of consumers’ app usage — information that functions as an early-detection system on whether an app is gaining popularity, according to the people familiar with the company’s activities. This information can be far more valuable, and be available earlier, than waiting for an app or feature to publicly take off.</quote>
  • <quote>Onavo was used to detect the popularity outside the United States of the messaging service WhatsApp, which Facebook purchased for $19 billion in 2014, several months after the Onavo acquisition, according to the people familiar with the company’s activities</quote>

Attributed ot The Wall Street Journal (WSJ)

  • <quote>Facebook uses an internal database to track rivals, including young startups performing unusually well, people familiar with the system say. The database stems from Facebook’s 2013 acquisition of a Tel Aviv-based startup, Onavo, which had built an app that secures users’ privacy by routing their traffic through private servers. The app gives Facebook an unusually detailed look at what users collectively do on their phones, these people say.</quote>
  • <quote>Mr. Elman says he is encouraged that Bonfire is a stand-alone app and that Facebook hasn’t been particularly successful with those. But, he says, if Facebook figures out how to integrate the power of Houseparty “into a property that I’m already using 10 times a day, that would scare the crap out of me.”</quote>
    but that’s sorof the point of launching Bonfire as a separable MVP.


In alphabetical order…

  • Jeffrey P. Bezos
    • CEO, Amazon
    • owner, The Washington Post.
  • Itai Danino
    • founder, Houseparty
    • not featured, quoted, pictured.
  • Josh Elman
    • partner, Greylock Partners
    • investor, director, Houseparty
    • ex-product manager, Facebook.
  • Scott Heiferman, chief executive, Meetup.com.
  • Alfred Lin, partner, Sequoia.
  • Kinshuk Mishra
    • vice president of engineering, Houseparty
    • ex-Spotify AB
  • Roger McNamee
    • founder, Elevation Partners
    • claims on Facebook & Google,
      • reminds us of his prescience as evidenced in his early contribution credit.
      • regret on his early contribution as such participation is no longer politic:
        I helped create the Google-Facebook monster — and I’m sorry; Roger McNamee; an oped; In USA Today; 2017-08-08.
        Teaser: ‘Brain hacking’ Internet monopolies menace public health, democracy, writes Roger McNamee.
  • Peter Pham, co-founder, Science (a vc boutique).
  • Scott Sandell
    • managing partner, New Enterprise Associates
    • ex-product manager, Windows 95, Microsoft.
    • quoted for color, background & verisimilitude;
      a confessional testifying to illegal, abusive & predatory aggressive M&A tactics from “back in the day.”
  • Fidji Simo, “head” of “video efforts”, Facebook.
  • Sima Sistani
    • founder, Houseparty
    • age 38
    • featured, quoted, pictured.
  • Scott Stern
    • professor, management, Massachusetts Institute of Technology (MIT)
    • quoted for color, background & verisimilitude.
      testification that an early exit is good for the investors & good for the founders, and something vague about <quote>might be at the expense of a more competitive landscape</quote>
  • Ben Rubin
    • founder, Houseparty
    • age 29
    • featured, quoted, pictured.
  • Rick Webb, CEO, Timehop.
  • Hannu Verkasalo, CEO, Verto Analytics
  • Mike Vernal
    • partner, Sequoia
    • investor, director, Houseparty
    • ex-”executive,” Facebook.
  • Mark Zuckerberg, CEO, Facebook


The Washington Post

  • Some, surely; they went broad.
  • <quote>Facebook declined to comment but noted [some platitudes]</quote>
  • Not so obviously sourced on deep background & pure gossip & rumor.

The Wall Street Journal

  • <quote>says a person familiar with the contacts.</quote>
  • <quote>Rubin and Elman declined to discuss details of the conversations.</quote>
  • <quote>the person says. Facebook said Ms. Simo declined to comment.</quote>




  • the prominent venture capital firm
  • the investment firm
  • the startup studio
  • the venture-capital firm


  • is nimble
  • forces the best entrepreneurs to be more creative


  • tech giants (contra media giants)
  • Silicon Valley is dominated by a few titans
  • libertarian-leaning Silicon Valley

Previously filled.

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


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

Beyond Public Key Encryption | Matthew Green

Matthew Green; Beyond Public Key Encryption; In His Blog entitled A Few Thoughts on Cryptographic Engineering; 2017-07-02.
Matthew Green, professor, Johns Hopkins University.

tl;dr → overview & history of Identity Based Cryptography and allied arts.


  • Eugen Belyakoff, an artist, The Noun Project (licensed artwork, specifically communicative graphics)
  • Voltage Security, now Hewlett-Packard Enterprise (HPE)
  • IBE systems effectively “bake in” key escrow
  • Christopher Cocks discovered RSA circa five years before RSA did.
    ellisdocdiscovered the RSA cryptosystem
  • Boneh-Franklin Scheme, 2001

    • elliptic curves
    • support efficient bilinear maps (pdf)
  • Attribute-Based Encryption (ABE)
    think: biometric & encryption; record-level & field-level database access encryption

    • Sahai & Waters
    • “threshold gate”.
    • fuzzy IBE, or not.
    • is that a threshold gate can be used to implement the boolean AND and OR gates
    • ciphertext policy
  • Functional Encryption iacr:2010/543
    Concept: embed arbitrary computer programs? in the attributes of ABE, iacr:2013/337, arXiv:1210.5287



  • Attribute-Based Encryption (ABE)
  • Diffie-Hellman Key Exchange (DHKE)
  • Functional Encryption (FE?, <aside>everything gets an acronym</aside>)
  • Identity Based Encryption (IBE); a.k.a. Identity-Based Cryptography
  • Identity-Based Encryption (IBE)
  • Identity-Based Signature (IBS)
  • Key Generation Authority.
  • Master Public Key (MPK)
  • Master Secret Key (MSK)
  • Pretty Good Privacy (PGP)
  • Public Key Encryption (PKE)
  • Public Key Infrastructure (PKI)
  • Shamir-Rivest-Adelman (RSA), a cryptosystem
The Roles
  • Alice
  • Bob
  • Eve
  • Mallory

Key Servers

At GitHub




At arXiv

At Semantic Scholar


In Jimi Wales’ Wiki

Previously filled.

Experience with Let’s Encrypt certbot for Fedora 23 (fails)

At certbot.eff.org with Apache on Fedora 23+

sudo dnf install -y python-certbot-apache
Error: nothing provides python2-augeas needed by python2-certbot-apache-0.8.1-1.fc23.noarch
(try to add '--allowerasing' to command line to replace conflicting packages)


dnf install -y augeas
dnf install -y python-augeas

Therefore: certbot isn’t ready for Fedora 23 yet.

Fedora 22?


wget https://dl.eff.org/certbot-auto

Nope … too big and complicated … it will never work … and they didn’t test it on Fedora anyway.


Prerequisites of python-certbot-apache


Still fails

$ sudo dnf install python2-certbot-apache
Last metadata expiration check performed 2:49:52 ago on Wed Sep 28 04:06:26 2016.
Error: nothing provides python2-augeas needed by python2-certbot-apache-0.8.1-1.fc23.noarch
(try to add '--allowerasing' to command line to replace conflicting packages)


wget https://dl.fedoraproject.org/pub/fedora/linux/updates/23/x86_64/p/python2-certbot-apache-0.8.1-1.fc23.noarch.rpm
sudo rpm --install --nodeps python2-certbot-apache-0.8.1-1.fc23.noarch.rpm

What got installed?

$ rpm -q -l -p ./python2-certbot-apache-0.8.1-1.fc23.noarch.rpm  | grep -v test

You also have to install


. It will list, but fails to create, the directories /etc/letsencrypt and /var/lib/letsencrypt

$ sudo dnf install certbot
Last metadata expiration check performed 0:18:54 ago on Wed Sep 28 07:09:29 2016.
Dependencies resolved.
 Package               Arch                 Version                     Repository             Size
 certbot               noarch               0.8.1-2.fc23                updates                20 k

Transaction Summary
Install  1 Package

Total download size: 20 k
Installed size: 20 k
Is this ok [y/N]: y
Downloading Packages:
certbot-0.8.1-2.fc23.noarch.rpm                                      42 kB/s |  20 kB     00:00    
Total                                                                16 kB/s |  20 kB     00:01     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : certbot-0.8.1-2.fc23.noarch                                                     1/1 
  Verifying   : certbot-0.8.1-2.fc23.noarch                                                     1/1 

  certbot.noarch 0.8.1-2.fc23                                                                       

$ rpm -q -l certbot
$ rpm -q -l certbot | xargs ls -ld
ls: cannot access /etc/letsencrypt: No such file or directory
ls: cannot access /var/lib/letsencrypt: No such file or directory
-rwxr-xr-x. 1 root root   302 Jul  6 06:42 /usr/bin/certbot
lrwxrwxrwx. 1 root root    16 Jul  6 06:42 /usr/bin/letsencrypt -> /usr/bin/certbot
drwxr-xr-x. 2 root root  4096 Sep 28 07:28 /usr/share/doc/certbot
-rw-r--r--. 1 root root   362 Jun 14 16:46 /usr/share/doc/certbot/CHANGES.rst
-rw-r--r--. 1 root root   604 Jun 14 16:46 /usr/share/doc/certbot/CONTRIBUTING.md
-rw-r--r--. 1 root root  7702 Jun 14 16:46 /usr/share/doc/certbot/README.rst
drwxr-xr-x. 2 root root  4096 Sep 28 07:28 /usr/share/licenses/certbot
-rw-r--r--. 1 root root 11456 Jun 14 16:46 /usr/share/licenses/certbot/LICENSE.txt
$ certbot plugins
An unexpected error occurred:
OSError: [Errno 13] Permission denied: '/etc/letsencrypt'
Please see the logfile 'certbot.log' for more details.

You have to do it yourself:

sudo mkdir /etc/letsencrypt /var/lib/letsencrypt

Pretty much, RSA is your only reasonable, reliable & compatible option in OpenSSH


  • DSA is deprecated in OpenSSH 7.0
  • ECDSA is not supported by GNOME Keyring.
  • Ed25519 is not supported by GNOME Keyring.


Via SSH Keys, in Arch Linux Wiki



  • As of July 10, 2015, GNOME Keyring does not handle ECDSA[4] and Ed25519[5] keys. Users will have to turn to other SSH agents or stick to RSA keys.
  • These keys are used only to authenticate you; choosing stronger keys will not increase CPU load when transferring data over SSH.


Via How to save an SSH key passphrase in gnome-keyring? in Stack Exchange for Unix & Linux

cd $HOME/.ssh
/usr/lib/seahorse/seahorse-ssh-askpass my_key


In Arch Linux Wiki


Testimonial Experience With [Attempting to Evade] the Great Firewall of China | Marc Bevand

Mark Bevand; My Experience With the Great Firewall of China; In His Blog; 2016-01-14.

tl;dr → Google employee visits CN; trolls the firewall with some consumer-grade tunnel schemes.


Secure Messaging Scorecard | EFF


  • Julia Angwin, ProPublica
  • Joseph Bonneau, Center for Information Technology Policy, Princeton University
  • staff, Electronic Frontier Foundation (EFF)


  • ChatSecure + Orbot
  • Cryptocat
  • Off-the-Record Messaging [for Windows] Plugin for Pidgin
  • Signal / Redphone
  • Silent Phone
  • Silent Text
  • Telegram, subfeature Secret Chats
  • TextSecure


In Their Blog entitled DeepLinks

in Jimi Wales’ Wiki

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.


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


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


  • 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


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

On the path to the deprecation, abandonment & refusal to honor SHA-1 signatures


  • Chrome will completely stop supporting SHA-1 certificates, soon
    • on or before 2017-01-01 (after 2016-12-31).
    • but maybe 2016-07-01 (after 2016-06-30).
  • Chrome will exhibit a warning if

    • a site presents a certificate
    • the site’s certificate

      • is signed with a SHA-1-based signature
      • is issued on or after 2016-01-01 (after 2015-12-31)
      • chains to a public CA.
  • Chrome 48
    due “early in 2016″.


  • Lucas Garron, Chrome security team, Google.
  • David Benjamin, Chrome’s networking group, Google.



  • Ryan Sleev; A History of Hard Choices; On His Blog, at Medium; 2015-12-28; separately noted.
    Ryan Sleev, cross-platform crypto & PKI core, Chromium, Google.


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


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)


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


$ openssl s_client -showcerts -connect honk.sigxcpu.org:443
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
 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
Server certificate
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
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 25CE690DDD33CB1CA47F3860484C79E5F16173F2564D640552E16D907E1DF86E
    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)

$ openssl x509 -in cacert_root.crt -noout -text
        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
            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)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
            X509v3 Authority Key Identifier: 
                DirName:/O=Root CA/OU=http://www.cacert.org/CN=CA Cert Signing Authority/emailAddress=support@cacert.org

            X509v3 Basic Constraints: critical
            X509v3 CRL Distribution Points: 

                Full Name:

            Netscape CA Revocation Url: 


            Netscape CA Policy Url: 


            Netscape Comment: 
                To get your own certificate for FREE head over to http://www.cacert.org
    Signature Algorithm: md5WithRSAEncryption
wbaker:wbaker@vast [wbaker wheel users mock bakers source yahoo bakerfamily cameras android] [l2 u0002 ssh] [F19 Schrödingers_Cat]
$ 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]
$ openssl x509 -in honk.sigxcpu.org_host.crt -noout -text
openssl x509 -in honk.sigxcpu.org_host.crt -noout -text
        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
            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)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
            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:

            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

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>


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


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

Via: backfill.


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

Why Do Nigerian Scammers Say They Are From Nigeria? | Herley

Cormac Herley (Microsoft); Why do Nigerian Scammers Say They are from Nigeria?; In Workshop on the Economics of Information Security (WEIS); 2012; 14 pages; landing.


False positives cause many promising detection technologies to be unworkable in practice. Attackers, we show, face this problem too. In deciding who to attack true positives are targets successfully attacked, while false positives are those that are attacked but yield nothing.

This allows us to view the attacker’s problem as a binary classification. The most profitable strategy requires accurately distinguishing viable from non-viable users, and balancing the relative costs of true and false positives. We show that as victim density decreases the fraction of viable users than can be profitably attacked drops dramatically. For example, a 10× reduction in density can produce a 1000× reduction in the number of victims found. At very low victim densities the attacker faces a seemingly intractable Catch-22: unless he can distinguish viable from non-viable users with great accuracy the attacker cannot find enough victims to be profitable. However, only by finding large numbers of victims can he learn how to accurately distinguish the two.

Finally, this approach suggests an answer to the question in the title. Far-fetched tales of West African riches strike most as comical. Our analysis suggests that is an advantage to the attacker, not a disadvantage. Since his attack has a low density of victims the Nigerian scammer has an over-riding need to reduce false positives. By sending an email that repels all but the most gullible the scammer gets the most promising marks to self-select.


  • a theoretical treatment
  • Receiver Operator Characteristic (ROC)
  • Optimal Operating Point (OOP)
  • Attacker Model
    • Targeted Attacker with per-user effort.
    • Scalable Attacker with per-population effort.
  • 419 Fraud
    • advance funds fraud
  • Advanced Persistent Threat (APT)


  • Fraud at potifos.com [some blog?].
  • 419 Eater.
  • A. Odlyzko. Providing Security With Insecure Systems. In Proceedings of WiSec, 2010.
  • L. Ahn, M. Blum, N. Hopper, J. Langford. Captcha: Using Hard AI Problems For Security. In Proceedings of the 22nd International Conference on Theory and Applications Of cryptographic Techniques, pages 294–311. Springer-Verlag, 2003.
  • S. Axelsson. The base-rate fallacy and the difficulty of intrusion detection. In ACM Transactions on Information and System Security (TISSEC), 3(3):186–205, 2000.
  • C. Dwork, M. Naor. Pricing via Processing or Combatting Junk Mail. In Proceedings of Crypto, 1992.
  • D. Florêncio, C. Herley. Is Everything We Know About Password-stealing Wrong? In IEEE Security & Privacy Magazine. To appear.
  • D. Florêncio, C. Herley. Sex, Lies and Cyber-crime Surveys. In Proceedings of WEIS, 2011, Fairfax.
  • D. Florêncio, C. Herley. Where Do All the Attacks Go? In Proceedings of WEIS, 2011, Fairfax.
  • Ford R., Gordon S. Cent, Five Cent, Ten Cent, Dollar: Hitting Spyware where it Really Hurt$. In Proceedings of NSPW, 2006.
  • D. Geer, R. Bace, P. Gutmann, P. Metzger, C. Pfleeger, J. Quarterman, B. Schneier. Cyber insecurity: The cost of monopoly. Computer and Communications Industry Association (CCIA), Sep, 24, 2003.
  • J. Grossklags, N. Christin, J. Chuang. Secure or insure?: a game-theoretic analysis of information security games. In Proceedings of WWW, 2008.
  • H. R. Varian. System Reliability and Free Riding. In Economics of Information Security, 2004.
  • C. Herley. The Plight of the Targeted Attacker in a World of Scale. In Proceedings of WEIS 2010, Boston.
  • J. Sunshine, S. Egelman, H. Almuhimedi, N. Atri, L. F. Cranor. Crying Wolf: An Empirical Study of SSL Warning Effectiveness. In Proceedings of Usenix Security, 2009.
  • L.A. Gordon, M.P. Loeb. The Economics of Information Security Investment. In ACM Transactions on Information and System Security, 2002.
  • N. Fultz, J. Grossklags. Blue versus Red: Toward a Model of Distributed Security Attacks. In Proceedings of Financial Crypto, 2009.
  • R. Anderson. Why Information Security is Hard. In In Proceedings of ACSAC, 2001.
  • R. Anderson. Security Engineering. second edition, 2008.
  • R. Boehme, T. Moore. The Iterated Weakest-Link: A Model of Adaptive Security Investment. In Proceedings of WEIS, 2009.
  • S. Schechter, M. Smith. How Much Security is Enough to Stop a Thief? In Proceedings of Financial Cryptography, pages 122–137. Springer, 2003.
  • H. L. van Trees. Detection, Estimation and Modulation Theory: Part I. Wiley, 1968.

Via: backfill.

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.

Disabling the use of RC4 in Firefox

This is for client-side disablement within your span of control within your client web-reading affordance (firefox):

  1. about:config
  2. search for rc4
  3. disable


With context about why RC4 ought to be disabled at all.



$ openssl ciphers -V 'ALL:!ADH:!RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT' | grep RC4
      0xC0,0x11 - ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
      0xC0,0x07 - ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
      0xC0,0x16 - AECDH-RC4-SHA           SSLv3 Kx=ECDH     Au=None Enc=RC4(128)  Mac=SHA1
      0xC0,0x0C - ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
      0xC0,0x02 - ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
      0x00,0x8A - PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1