Herman: Shipping Rust in Firefox

Ideally the browser itself would be up front and honest, giving the user an informed choice and the tools to act on it, instead of training them to click through interstitial scare pages. That kind of progress is a pipe dream though.

An X509 certificate, like most real world certificates, is a signed document. In X509 the signature is performed using a combination of a hash function (often SHA-256 today) and a public key algorithm (often RSA). Anyone who knows a public key can do the mathematics on the signature using that public key, get back the hash value and check it is the same as the hash of the certificate they were reading, if it is, this key signed the certificate.

So, every certificate is signed by exactly one key, we sometimes call this the "Issuer" of the certificate for obvious reasons. The contents of the certificate are a serial number, another public key (that of the "Subject" of the certificate), some identifying details for the Issuer (so you know if a public key you have should verify this certificate) together with whatever the Issuer is certifying about that Subject, such as (on the public web) their fully qualified domain name, or IP address and maybe the name of their business, the country in which it is registered and so on; and there will usually be some house-keeping stuff in there, which I'll get back to.

Of course you can sign your own certificate, so that the public key signed is the same one that verifies the signature. But why should anybody trust this certificate? How would anybody know which one is really "your" self-signed key - anybody can state the same ?

In the traditional Web PKI the approach is that a relatively small number of trusted Certificate Authorities either act directly as Issuers, or they certify Issuers and your operating system and/or client software decides which CAs it will accept certificates from. If you don't trust, say, Symantec, too bad you now have no way to verify all the certificates they've issued.

What you're talking about is basically Moxie Marlinspike's "Convergence" in which you the end user ask one or more trusted third parties ("notaries") to check you've got the right certificate, and so anyone can issue any certificates but it won't matter unless the notaries say they're OK. There are some pretty awful problems with Convergence in practice and it is largely moribund.

1. It needs online real time verification. In practice on the web things break, servers go off-line, networks get partitioned. Loads of people who think they have "Internet access" actually don't, there's a middle box and it would of course get 100% carte blanche to lie about Convergence answers, or if it doesn't you need another entire PKI to manage Convergence and Now You Have Two Problems.

1a. The Web PKI already has (switched off) real time verification. OCSP is supposed to be a real time online verification of certificates. But in fact many browsers switch it off completely, others "soft fail", treating a certificate as OK unless they get a "Not OK" answer in a limited amount of time. We ended up with OCSP Stapling to work around that - clients still get an OCSP response, but from the server they were trying to connect to, which must be up for them to succeed anyway. But you can't staple Convergence.

2. The other reason the Web PKI moved away from OCSP: The privacy implications are pretty bad. Your notaries end up knowing exactly what you're looking at, because you have to tell them in order to make use of their services. This is worse than for OCSP because you tell only the OCSP server for a particular certificate (see, housekeeping info) that you saw the certificate, whereas you tell all your trusted notaries for every site with Convergence.

3. Who are all these trusted third parties anyway? So long as Convergence users are just a handful of cryto nerds the reality is that the "trusted third parties" are a bunch of other crypto nerds. But if big players come into the game, they dominate, and soon the "agility" is all gone anyway.

4. In fact, who wants to be a trusted third party in this scenario anyway? End users won't pay you. That's an ugly fact but it's a fact. Ordinary Internet users are very resistant to paying. You and I are LWN subscribers, we're the rare minority. In the CA model the server operators pay to make this work. But in Convergence the reality was nobody pays, and as a result quality goes out the window.

The most viable part of Convergence survived, as HPKP. Key pinning (Marlinspike wanted to call something similar "TACK"). HPKP lets server operators promise that one of Convergence's assumptions is actually true for their site, that either their key, or a key that signed their key, is constant and won't change after your first visit. This is the "Trust on first use" model familiar from SSH. If you visited a HPKP-enabled site once, successfully, and no operators of that site ever make a bad mistake, then you're OK forever.

Now, as most SSH users soon find out, actually operators make a lot of mistakes, all the time. In SSH you work around these mistakes by manually editing a text file, or running an intimidating command-line tool. In HPKP it's much the same, except, how many web browser users do you know who are comfortable manually editing text files? Right. Fools deploying HPKP will effectively "brick" an entire FQDN, by ensuring that thousands or millions of users will only ever see an uncancellable error message when they try to visit it because they lost the key they need to pin the site. A bunch have been bricked already, more happen every day.

HPKP is a great idea for high value sites with a group of competent administrators. Google, Microsoft.com, there are dozens, maybe there are even thousands, but in practice even though anybody _could_ do it, most of us almost certainly shouldn't.

Now, as a result of Certificate Transparency we do actually have a database of (most of) the trusted certificates for the Web PKI. But because of the afore-mentioned network reliability + privacy situation, you definitely shouldn't just insist on examining the CT monitors every time you visit a web site.

I imported that into LibreOffice as a very dirty way of estimating the length - to about 400 pages, and still a work in progress. That does give me a bit of a bad feeling.

An appropriate term for "speculative product promise" is "vapourware", and I wrote a whole blog post about this situation: http://robert.ocallahan.org/2016/06/safe-c-subset-is-vapo...

I sometimes feel that C++ attracts that sort of person though.

> Even from a pure security standpoint?

Yes. Memory problems indicate other errors in the program which can be fixed. An ideal program (which I admit is an extremely rare find) wouldn't care if it were on a GC or some RAII setup with respect to memory. However, the RAII setup allows me to ensure that my program cleans up after itself on the filesystem, over the network, or whatever other resource might be needing managed without issue; a GC setup leaves me back in the world of C's memory management assistance instead for such things. I know D's GC doesn't guarantee destructors are called (genius that, but probably something about undecidablility of the proper call order at program shutdown), but C# and Java don't even *have* destructors for such things.