Dark Web vs: Deep Web – 2018 edition

There’s a lot of confusion out there re: dark web vs: deep web — and it’s not going to get any better; I feel that the only way for humanity to move forward on this matter is for both terms to die, or at least diffuse until they are meaningless in much the same way that “cyber” means “network security related” and “cloud” means “other people’s (rented) computers“.

Nonetheless, the question of technical definition still remains, and this is what I hew to:

  • deep web: traditionally: that part of the web which is not findable via popular search engines such as Google; this may be because the content is held behind authentication, or because indexing has been requested-disabled via the “robots.txt” mechanism. The former, of course, includes almost the entirety of Facebook, not to mention your personal email accounts, your bank accounts, and so forth. People who like to hype-up the “deep web” generally neglect to point out these mundanities.
  • dark web: traditionally: that part of the web which is not accessible without “special software”, although the definition of “special” is apt to change with time because at one point a “Graphical Web Browser” like Mosaic was considered to be “special”, since the web at that point was entirely text-based. Generally the speaker is referring to Tor Onion Networking (formerly “Hidden Services”) when they want to talk about the “dark web”, and when they do so it is invariably to scare the listener with tales of evil dark-web websites such as Facebook, ProPublica, and the New York Times, from all of which one may easily purchase drugs and guns by sending them something called “Bitcoin”.
  • deep dark web: accessing your password-protected Facebook account via the Facebook “Onion Site”. Usage: intentionally silly.
  • intellectual dark web: the speaker/writer is alluding to a cabal of intellectual whose opinions he/she does not agree with, or hopes that the reader will be fearful of, in order to promote the lectures/clickbait that the speaker/writer is promoting.

This latter is particularly interesting, because it is a recent (2018?) innovation, and hopefully suggests that “deep web” is already on the path towards post-modern meaninglessness.

Any speaker or writer who illustrates either the “deep web” or the “dark web” with a picture of an iceberg, should not be considered credible.

Irony is a dish best served cold

 

Test Image

Testing 1, 2, 3

Dropsafe is now entirely solid-state…

National Loyalty Card III – China takes it seriously:

https://www.wsj.com/articles/in-sign-of-resistance-chinese-balk-at-using-apps-to-snitch-on-neighbors-1514566110

The “Safe Zhejiang” app enables users to notify authorities of problems ranging from leaky drains and domestic disputes to traffic violations and illegal publications, in text or photographic form, as long as the informants reveal their location and identity.

In exchange, they get perks including discounts at upmarket coffee shops and coupons for taxi-hailing and music-streaming services, as well as for the Alipay online-payment system, run by the financial affiliate of local tech giant Alibaba Group Holding Ltd.

Previously:

Random Snippets of AberMUD-1 Source Code in B

Rebooting Dropsafe: March 6th 2017

Notes:

Well, today would have been Dad’s 98th birthday. I’ll drink a small toast to him, later.

Project Status:

Since I don’t really have a system for posting here at the moment, I think I’ll start with a brief list of everything that I think I am currently doing:

  • Raspberry Pi Rig: currently:
    • 6x RPi 3b in a rack, as a general compute surface
    • 1x RPi 3b in a fan-case, as rig controller/master
    • 1x RPi 3b in a passive case, as backup
  • Mana Project
    • RPi 1 for port of Mana; have finally obtained second wifi adapter
  • Soldering Project
    • RPi ZeroW + Pimoroni “Scroll Phat” dot-matrix display
    • Build & then use for
  • Half-A-Gig Onion
    • On hold, awaiting bandwidth.
  • EOTK
    • Stable, works, is remarkably quick
    • Goal is to ship stable & feature-complete 1.x version then start on 2.0
      • 2.x version will move more rewriting to Lua to reduce dependencies
  • Resurrecting old GPU Rig
    • Inherited 3x Radeon 5870 from JC
    • Unfortunately, Ubuntu stopped loving Radeon in v14 Trusty Tahir
    • Open-source Radeon drivers do not cut the mustard
      • Therefore: adventures in legacy linux and stale proprietary driver code
  • Java Experiments
    • Stalled by EOTK but that’s okay, it needed some thinking-time
  • Garden
    • Total mess.
    • Need to spend a few days sawing and stacking lumber for next winter, to dry out over the summer
    • Also need to push(@compost, shift(@compost)) which will be hard work
  • Work
    • Can wait until after summer.

Setting up on dropsafezeahmyho.onion using EOTK

https://dropsafe.dropsafezeahmyho.onion/

And into its 16th year…

…testing a new server.

An Open Letter to CA/Browser Forum re: Personal Certificates for “.onion”

Ryan, I’d like to take you up on your invitation and request that you forward the following text to the CA/Browser Forum public list, please…


Hi CA/B Forum! I’m a software engineer and one of the authors of RFC 7686; since 2001 I have maintained a personal blog and it’s overdue for a complete software refresh. I want to take advantage of Let’s Encrypt to provide normal HTTPS certificates for the blog, and I want a 100% HTTPS deployment when I am done.

I intend also to provide my blog with an Onion Address, thus my question:

On my blog I do not represent a company – I act purely as an individual; I expect to easily get a “normal” domain-related certificate from Let’s Encrypt, but as an individual I will not be able to get an EV certificate for my Onion Site as mandated by CA/B Forum Ballot 144.

This situation inhibits me from protecting my personal blog’s Onion Site with some form of Onion HTTPS certificate.

It further discriminates against my choice of software deployment as an individual.

Perhaps I could run my blog as HTTP-over-Onion and HTTPS-over-Internet, but this breaks my goal of a 100% HTTPS deployment. Clients of my Onion Site would not have access to HTTPS-only “Secure” cookies and other functionality which browsers today (or will soon) restrict to HTTPS sites, e.g. Camera & Microphone access. This would be an undesirable lack of consistency.

It is not viable to hack the Tor Browser to support an “Onion-only” CA, because only some portion of Tor traffic uses the Tor Browser; non-browser apps which use Tor would not be able take advantage of such a kludge, and thereby would not see the benefit of SSL.

In any case, “.onion” is now an official special-use TLD, and therefore should be supported by official means.

After a hint from Ryan Sleevi – plus referring to the Mozilla CA glossary [1] – I did some research and think that I need either an AV (address validation) or an IV (individual validation) SSL Certificate for my personal blog’s Onion Site.

Discussing likely use cases with Runa Sandvik, we believe that people who use Tor desire (at least) all of privacy, anonymity and integrity. The option that seems most sympathetic to all of these requirements is the AV (address validation) certificate. An AV certificate would provide an Onion Address with an SSL certificate (and thus a form of persistent identity) corresponding simply to an RFC822 email address. This would appear extremely well-suited to users of Onion-backed instant messenger software, such as Ricochet, especially those communicating without reference to “real world” identities.

The alternative of an IV (individual validation) certificate appears closer to the goals of the EV certificate, being a more expensive “absolute identity” certificate that would (per the Glossary) require a Driving License, Passport, or National Identity Card to get. This would be useful for instances where people wish to publicly attest to ownership of what they write / blog / post / publish, but would be less useful e.g. for whistleblowers operating in repressive regimes.

Frankly I see a need for both, and would be (for this case in point) happy to get one of either, but am also open to other alternatives which would not require me to register a company to bootstrap.

So, finally, the question: how may I go about obtaining a suitable, personal, Onion-capable SSL Certificate for my blog, please?

Alec Muffett
London

[1] https://wiki.mozilla.org/CA:Glossary – some extracts follow:

AV (address validation) — Many CAs issue end entity certificates to individuals for use with S/MIME email for which the applicant need only demonstrate that they own and/or control the email address named in the certificate. For example, the owner of the “jdoe@example.com” address could obtain an AV certificate for that address based on their demonstrating to a CA that they owned or controlled the email address in question, e.g., by responding to email addresses sent to an email sent to that address. We can refer to such certificates as address-validated or AV certificates.

More formally we can define AV certificates as certificates containing an emailAddress attribute or Subject Alternative Name extension with a value (or values) apparently corresponding to an RFC 822 email address, for which the CA makes claims (e.g., in the CPS) that it has in some way validated that that address in question is owned and/or legitimately controlled by the cert subscriber, and for which the CA makes no claims as to the validity of any individual identity stored in the Common Name attribute of the certificate. Note that “AV” is not a common industry term, but is newly-coined by analogy with “DV”, “IV”, etc. Some people use the term “DV” loosely to cover this case, but arguably it deserves a term of its own.

…and…

IV (individual validation or identity validation) — Many CAs issue end entity certificates to individuals for email, SSL/TLS client authentication, and other uses, for which the applicant is required to supply some sort of evidence as to their identity (e.g., by presenting themselves in person with a copy of their national identity card). These are commonly referred to as identity-validated or IV certificates.

More formally we can define IV certificates as certificates containing a Common Name (CN) attribute with a value apparently corresponding to an actual named individual, for which the CA makes claims (e.g., in the CPS) that it has in some way validated that that value corresponds to the individual identity of the certificate subscriber. Note that some people use “IV” as a synonym for “OV” when referring to certificates issued to organizations. However it’s arguably more clear to use “IV” to refer only to certificates issued to individuals.

Note that an IV certificate could also contain an email address in addition to the individual identity information. Mozilla policy requires that email address to be validated to the same or greater degree as for a AV certificate.