Excellent. While they're at it, maybe they should stop marking self-signed SSL as more of a security risk than plaintext HTTP.
The only thing separating a self signed cert
from one obtained from a CA is that the CA
has some of your contact info
it wouldn't take a whole lot of effort to
bypass their checks
The CA system as it is isn't good, because we have to trust so many different CAs for it to work, but if CAs were widely issuing certs to the wrong parties we'd hear about it more.
A non-plaintext connection is still more secure than a plaintext connection, so it shouldn't ever get a worse warning than a plain-text connection.
It's substantially stronger than ordinary certificate authorities without certificate pinning in many ways. (Namely, an entity out of your control (a certificate authority) being compromised / exploited / coerced doesn't also compromise you.)
The weak point is at initial connection (i.e. before you have the certificate pinned, or if the certificate changes legitimately and you have no way of confirming that fact). However, even in this case it is no worse than without pinning.
(I wish that HTTPS had a certificate-passing mechanism. I.e. if the given certificate doesn't match the pinned one you contact a site that you have the certificate for already and ask it to give you the certificate it believes is for the site. Do this for the same website with multiple sites and you'll have a good idea if someone is not trying to MITM you. You'd have to have rate limiting, etc, etc, but it would in many ways solve this problem. Unfortunately, it's something that would have to be built into the protocol, or else it would be blocked often enough to not be useful. (ICMP and firewalls, for example))
You should do the same to those certificates that you did to TURKTRUST, just throw the US CAs out.
VeriSign and GoDaddy, which the NSA frequently uses for MitM?
Simply specify an explicit algorithm if you want to get a certificate using that. For example, if you do:
$ openssl req -new -sha256 -newkey rsa:4096 -keyout foo.key -nodes
and give them that CSR, you will get back a SHA-256 certificate.
EDIT: They also have a SHA-256 root (in most browsers, though you don't need a second-preimage-resistant digest algorithm for a /root certificate/) and SHA-256 intermediates at https://startssl.com/certs/ - go to the relevant class directory and there is a sha2 directory inside that.
I had to install a CA cert in order to be able to just BROWSE the CCC website last month. Chrome's aggressiveness on Self Signed Certs wouldn't even give me to option to accept the risk. I want to browse one website- not add a whole new fucking signing authority to my browser.
Google's behavior on this topic makes me feel like half of their security team is manic and regularly falls off their meds. Their company's business model is about monetizing personal details of their users, and they act like they own the only privacy opinion that is right.
I think there is a possible fix for this issue that won't put grandma's banking account at any greater risk. Put the requested level of security in the URL. So if the resource is httpq:// (or whatever) it means that we don't care if we are subject to MITM attacks and self signed certs are OK. Then when grandma goes to a https;// site and the identity of the site is questionable we can forbid the connection entirely. She could use the httpq:// form if she wanted but the bank could forbid that from their end by simply not accepting such connections (it would likely be implemented as a separate port). Other sites that are willing to trust their user's judgment would just allow both connections.
The root problem here is that the current system does not accurately take into account the intent of either the user or the provider. So the browser can not be entirely sure and then has to ask obscure/awkward questions after the fact.
Edit: Dunno if there is an easy way for a bank to stop someone from deliberately switching the URL to httpq:// in a MITM situation. So the intent would only be accurately represented for the user sometimes.
Instead we have a system where we do nothing when you access a page that is not secure, and put up an obnoxious warning when you access a page that is somewhat more secure.
As opposed to: Never do email unless unless the address bar is green, except when: - It's the first time you visit the web site - You use another browser - You bought a new computer/tablet/phone, reinstalled your computer etc. - You accidentally cleared your browser history - You are on a public wifi the very first time you visit a web site. - The website changed their certificate since last time you used it. - You happen to be unlucky and even at home you are under a MITM-attack the very first time you visit the page.
The last bullet is especially troublesome because even a programmer would have a hard time to judge that one.
Heck, why not mark HTTP as insecure, don't mark self-signed HTTPS, and mark CA HTTPS as 'secure'?
Of course, CA HTTPS is not really secure at all, but that's another discussion entirely.