It’s Time to Encrypt the Entire Internet

Or, as others have stated, use one of the dynamic dns mapping services.

>[big description of how the internet works]

As has been pointed out elsewhere in this thread, the internet was designed from day 1 to be decentralized. None of your examples count as "centralization" at the society level. There are millions of DHCP servers etc. The exception is DNS, which was a centralized replacement for the original decentralized mechanism of hosts files - an understandable decision as software techniques for decentralized consensus were unknown at the time. Fortunately we can now correct this, with Namecoin or similar.

>All the devices on the internet would be constantly communicating, trying to find consensus, trying to update routes, trying to search distributed rings (my personal favorite topology) to find peers, connect services, authenticate trust relationships, query data, update indexes

You seem to have a very detailed idea of how a "decentralized" internet would work at the technical level. Sounds like you're describing a global meshnet, as imagined today. Obviously we do not currently have the tools to develop an efficient global meshnet. However, just because you cannot personally imagine one doesn't mean it isn't possible.

>FDIC-insured bank

Must have missed something - what's Facebook's FDIC equivalent? I wasn't aware that coughcloudcough services had a regulatory body that would compensate me if they failed to do their job.

>It's just a really dangerous idea to put data you care about in a place that's easily available to thieves

I agree. How exactly is a hard drive in my basement more accessible to thieves than a data center (a much juicier target) run by people of unknown competence and ethics? Of course, if you're paranoid about your house burning down, there's nothing stopping you from putting an encrypted, uuencoded zip of your files on pastebin.

>the very idea of decentralized services is contrary to high-availability data

Bittorrent: Faster, cheaper, and more robust than a central server.

>we put a man on the moon with centralized services

Really? I thought we did it by funding a whole bunch of aerospace companies to design and build different pieces. Sounds pretty decentralized. "But the funding came from the government!" The funding came from taxes, which came from millions of people, who would not have had that money were it not for the economy! Now there's a whopping great decentralized system for you. Shall we switch to a planned economy? Would that be more efficient?

The best way to make a system do what you want is design its ground rules from the get-go such that it self-organizes that way.

The current implementation is far from perfect, but that is more than a tad strong.

And it need not be as bad as it is, we just need to find the right changes to the process and get everyone to agree on them...

Don't tar all PKI based solutions with the same overly large brush.

> You mean the one with a terrible user interface

I'll not disagree with you there. Though for free are you expecting perfection? It at least does the job.

> who charge 25$ to regenerate a cert?

Pro tip: backups.

If you properly protect your keys and certificates you only need to pay if you need the old cert revoked (this is annoying if something beyond your control makes you need a full resign rather than a reissue, but things like heartbleed that necessitate this are hardly common).

It's a racket in its implementation. The PKI model used nowadays is rotten and exploitative. Renewals which exist as a pure profit vehicle for CAs (upwards of $100 to run some code and generate a hash? Fkn seriously?), the implementation in every browser which treats a self-signed certificate as coming from a known bad guy, or the slightest misconfiguration as same.

But every single user out there has it drilled into their head to look for the little lock (or nowadays, the much more expensive by a factor of ten or so green bar) before shopping, and every browser out there throws really scary looking errors (Chrome's red screen of doom) for something so much as an expiration date. The CA's can effectively say "Gee, that's a nice commerce website you have there, would be a shame if something were to happen to it and all your customers got scared off since you didn't pay your protec^H^H^H^H renewal fee" - Some basically do, especially around renewal time.

Charging to regenerate or revoke a certificate (again, completely automated processes with zero human interaction required) is just rent-seeking dick behavior of the highest order.

Why do I have to pay upwards of $100 for a wildcard certificate? They don't cost the CA anymore to issue or handle, it's identical to any other certificate except the CN field is written slightly differently. No, the fuckers expect me to either pay for a massively overpriced bit of hashed code or pay lots of times for slightly different overpriced bits of hashed code. Either way, i'm getting screwed. All so people who visit my website don't get scary and misleading warnings.

Doing this en-masse would be a much better system than we have right now. Example: Have a random internet user visit a site and note down the details of the certificate they get (automatically). Repeat a few thousand times. Compare notes. Wait a sec, why do I have a different certificate than 99% of the other visitors? Hmm. Throw alerts.

The chances of the average user being the target of a MITM is utterly minuscule, so this system ensures that you as the bad guy either have to own the service provider directly by installing a certificate you have keys for, or every single user that hits the site simultaneously to prevent the others from being alerted.

Pinning on steroids, basically. No CA's required.

>but having a self-signed cert proves nothing at all.

..other than the connection being encrypted, the CN on the cert matching the domain name, and it not being expired. This is the same data that the lowest level certificates from every CA provides.

I believe that the past decade or so has shown that CAs do not deserve the level of trust they're implicitly given. I certainly don't trust them. We know they can be coerced by the bad guys with guns to generate certs anyways. QED, they are not trustworthy.

>Renewals exist because certificates expire. Certificates expire because an infinitely valid certificate is potentially dangerous because the revokation process can not be relied upon in many cases.

Then re-generate the bloody certificate and don't charge me money for the privilege of giving me exactly what I had before with a different date on it!

>f your e-commerce site finds $7/year or the hassle of using StartSSL's interface for free (or $120/y or $70/y respectively for EV certs) a problem, then it isn't much of a profit making e-commerce site...

Ah yes, the old "It's not that expensive, so why are you complaining?" canard. A dime here, a nickel there. It's nothing.

Why just a little of a bad thing remains bad is left as an exercise to the reader.

>Automated processes that rely on infrastructure that someone needs to create, monitor, and maintain. If you so strongly believe that this is a complete and utter rip-off and that you could do it so much cheaper, why not do so? If you can do it as well while charging less (or nothing) then people will flock to your service. One man's margin is another's opportunity.

Why are there no serious community CAs? Why is every single one of them a large corporation? Larger infrastructure projects exist that are community, free/donationware efforts, after all. Is it really that hard, or is there some other reason?

I'll wager that one of the reasons is that entrenched players (the VeriSigns and Comodos and Thawtes of the world) get to set the standard for the market. For audits (e.g. Webtrust) that cost tens-to-hundreds of thousands of dollars to complete.

De-facto regulatory capture, except the regulations are more of a consensus than top-down legislating.

>The scary warnings are not misleading in the worse cases. If a DNS hijack passes your bank's traffic through a server that has a self-signed certificate would you want your browser to warn you or just carry on because self-signed certificates are fine usually?

I have no way to prove this, but I would be willing to bet large and ridiculous amounts of money that 99 out of 100 SSL warnings an average computer user sees is going to be the result of either misconfiguration (a badly set CN is common) or expiration. The connection is still encrypted and the certificate was still generated by a "trusted" CA so we know that the identity is valid (what are the chances that the owner of bar.com doesn't know of the existence of foo.bar.com?) - yet we still cry wolf like something is very definitely wrong.

And I say "cry wolf" for a reason. With the majority of SSL warnings being bogus (bogus as in they fail part of some validation test, instead of bogus as in the user was in some actual danger), we're training users to override the annoying warning every time.

And you can't override parts of the validation - it's all or nothing. If I know a certain website has an expired cert, and everything else is still valid, why can't I just override the expiration check? Being N+1 days out of date doesn't reduce the security of anyone concerned. - Instead I have to completely except the cert from all checks and then I won't get warned if say, the issuer changes or the CN doesn't match or some other data point, which when taken together, might add up to a different whole.