Launching in 2015: A Certificate Authority to Encrypt the Entire Web

It would be nice to have support for ECDSA certificates. I've not found a CA yet who'll provide one of these, despite the fact that many clients to already support them. Unfortunately, after a brief look through client.py I can't see any support for this. Is there any good way of filing an RFE or contributing a patch?

ECDSA certs are much cheaper to decrypt, and there's still some places (especially mobile) where TLS is a noticeable overhead - it'd be great to have a CA that provides them.

Whatever happened to http://www.cacert.org/?

> Nothing can be man-in-the-middled passively, that makes no sense. That isn't what a MitM is. It requires active involvement by its very nature.

By this I mean record all form submissions done through HTTP.

>> In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used.

> I genuinely don't understand what you're trying to say.

The default thing we're trying to prevent is someone close to the server MITMing every request, recording each post, and reenacting them so that they are not discovered.

> If the MitM originates from a specific location (e.g. a single Starbucks, a single hotel, an airport, etc) it would never be detected by that method.

That is true for the example I gave which is just a proof-of-concept, but not true for a better method, like decentralization + public key signing.

What I'm fundamentally saying is that Cert + HTTPS is more secure, but it is not fully secure, since you have to trust the cert provider. Just in the same way, HTTPS without cert is not fully secure, but it is (much) more secure than HTTP.

It's not enough to keep the snoops out - you need to KNOW you're keeping the snoops out. That's what SSL helps with. A certificate is just a key issued by a public (aka trusted) authority. Sites can also choose to verify the certificate: if this is done, even if a 3rd party can procure a fake cert, if they don't have the same cert the web server uses, they can't snoop the traffic.

Site: Here's my public key. Use it to verify that anything I sent you came from me. But don't take my word for it, verify it against a set of trusted authorities pre-installed on your machine.

Browser: Ok, your cert checks out. Here's my public key. You can use it for the same.

Site: Ok, now I need you to reply this message with the entire certificate chain you have for me to make sure a 3rd party didn't install a root cert and inject keys between us. Encrypt it with both your private key and my public key.

Browser: Ok, here it is: ASDSDFDFSDFDSFSD.

Site: That checks out. Ok, now you can talk to me.

This is what certificates help with. There are verification standards that apply, and all the certificate authorities have to agree to follow these standards when issuing certain types of SSL certificates. The most stringent, the "Green bar" with the entity name, often require verification through multiple means, including bank accounts. Certificate authorities that fail to verify properly can have their issuing privileges revoked (though this is hard to do in practice, it can be done).

But note that only works if the manufacturer can choose the name without an issue from the customer. For things like network appliances in larger companies that aren't going to want [generic number]manufacturer.com but want [my name].corp.[my company].com, you're stuck.