Avoid HTTPS when possible?

After the recent CA desasters, I wonder if one should avoid HTTPS
whenever possible, in order not to create a false sense of
security. I registered a .NAME domain some time ago and put some
contact information there, including OpenPGP key and e-mail
addresses. I was thinking of putting the URL with 'https' prefix
on my visiting cards. But then I would like to give visitors the
opportunity to check whether the site they are connected to is in
fact run by the person who gave them the visiting card. So I
would put the SSL fingerprint of my webserver on the visiting
card, in order that users can check the fingerprint and then
import the server certificate into their browser. However, this
is in vain if some CA issues false certificates for my domain.

I do not see much that could be done about it.

So I currently tend to only put an e-mail address and my OpenPGP
fingerprint on the visiting card (and maybe the .NAME domain, but
only with 'http' prefix).

What do you think?

I think that it would be best if browsers could be configured to
associate specific server SSL fingerprints with certain URLs and
warn whenever there is a mismatch. But this isn't to become
reality soon, I am afraid.

"Lasse Kliemann" <lasse-usenet-2012@mail.plastictree.net> wrote in message
news:5b6b58.6lp.19.1@news.alt.net...
> After the recent CA desasters, I wonder if one should avoid HTTPS
> whenever possible, in order not to create a false sense of
> security.

Another problem is that browsers tend to force-feed CAs, even infamous
ones such as CNNIC, on users. Removing a CA can be complicated for end
users, and removed CAs may be automatically and silently re-added when the
browser software is updated.

--
Thor Kottelin
http://www.anta.net/

>>>>> Lasse Kliemann <lasse-usenet-2012@mail.plastictree.net> writes:

[...]

> So I would put the SSL fingerprint of my webserver on the visiting
> card, in order that users can check the fingerprint and then import
> the server certificate into their browser. However, this is in vain
> if some CA issues false certificates for my domain.

AIUI, it's not. A CA could indeed issue a false certificate for
the domain name. However, it isn't that easy to make it possess
the same fingerprint, as it's the server's public key that the
fingerprint is computed from.

Actually, the whole point of CA's is to simplify public key
exchange. In a world where everyone is able to just send his or
her own public keys, or (though less secure) their respective
fingerprints, to everyone, there's no need in CA.

Ultimately, yes, I believe that the WoT approach will offer
better security than the current CA's, but that's going to take
a lot of education and responsibility.

[...]

--
FSF associate member #7257

Ivan Shmakov <oneingray@gmail.com> wrote:
>>>>>> Lasse Kliemann <lasse-usenet-2012@mail.plastictree.net> writes:
>
> [...]
>
> > So I would put the SSL fingerprint of my webserver on the visiting
> > card, in order that users can check the fingerprint and then import
> > the server certificate into their browser. However, this is in vain
> > if some CA issues false certificates for my domain.
>
> AIUI, it's not. A CA could indeed issue a false certificate for
> the domain name. However, it isn't that easy to make it possess
> the same fingerprint, as it's the server's public key that the
> fingerprint is computed from.
>
> Actually, the whole point of CA's is to simplify public key
> exchange. In a world where everyone is able to just send his or
> her own public keys, or (though less secure) their respective
> fingerprints, to everyone, there's no need in CA.
>
> Ultimately, yes, I believe that the WoT approach will offer
> better security than the current CA's, but that's going to take
> a lot of education and responsibility.

As far as I have been told, as soon as there is at least /one/ CA
imported into the browser which says OKAY to the server
certificate, no questions will be asked. It is not as with SSH
for example, where any deviation from the 'IP <--> fingerprint'
mapping known at client-side (known_hosts) triggers an alarm.