Thorsten Glaser wrote:
> Now for something totally different:
>
> I have always wondered why there is so much trust in Certification
> Authorities, especially considering even Verisign has issued bad
> certificates in the past.
Maybe it's the desire of the human mind to have some things to be able
to depend upon?
We have to trust some CAs up to a certain level. We don't have to
trust all of them blindly, though. If we don't trust CAs we have to
trust each and every certificats manually. Having a small set of CAs
to trust simplifies this. We wouldn't have to check each certificate
but are able to assume that it'll be fine.
This is a difficult situation. On one side there is no guarantee that
a CA is always acting careful when signing a certificate, especially
after reading the rules for certain certificates. You named Verisign
already, there are probably other.
On the other side, requiring users to acknowledge every certificate on
their own adds more complexity to the system which confuses or even
scares users. In the end, many people will blindly accept every
certificate they stomp over. Just like popular EULA agreements...
So, by adding more complexity and a more detailed plus secure
mechanism to accept and also reject certificates the system is more
secure, but at the same time many users will not understand it or will
become so annoyed that they blindly accept everything. At the end of
the day, the global usage is less secure.
(Granted, you could argue that those people who are using Lynx will
most probably have a better understanding of how encryption and
certificates work).
> My suggestion is to create a ~/.etc/known_certs database (or, for
> non-MirOS users¹, ~/.known_certs²) which can _possibly_ be shared
> among SSL (not restricted to HTTPS) users, but will be initiated
> by Lynx. The format is not yet specified, see below for ideas.
I see the benefit, but I see danger at the same time.
> ??? unless someone thinks this would be a good starting point to
> introduce our ~/.etc/ dotfile policy into the non-Mir world
> ??? DOS and VMS of course will differ??? I think I???ll just use the
> existing code for locating the ???lynxrc??? dotfile
Sounds sensible.
> On connections to a ???secure site???, the certificate is checked as
> usual. If it can be validated using normal X.509 means, it will
> just be added to the database unless it exists. However, if it
If you start such a database you should add options for users to trust
certificates differently.
I would suggest:
. certificate is in $CERTFILE and trust level is good -->
certificate is trusted
. certificate is in $CERTFILE and trust level is bad -->
certificate is not trusted and the user is informed && queried
whether to trust the certificate for the current connection and
offer means to alter the trust level
. certificate is not in $CERTFILE -->
the user can (a) add it to the file and define the trust level good/bad
the user can accept/reject it for the current connection and not
add it to the certificate file.
Maybe it would make sense to ad such certificate with trust level
'ask' so that every time such a certificate is found, the user is
queried again until they reconfigure the trust level.
> already exists BUT DIFFERS, a warning will be issued.
> If the certificate cannot be validated (expired, self-signed, CA
> not in the known CA list, bogus certificate), the usual warning
> will be issued on first connection, but the user can not only
> select to continue (???y???) or abort (???n???) the connection, but also
> have the certificate STILL be added to the database (???F???, like
... with a user-specified trust level
> in fsck(8) for the force prompt). Subsequent connections will
> not warn. Error messages will of course have to differ for the
> various scenarios.
>
> As for the format, I think a format similar to the OpenSSH
> known_hosts file (non-hashed) would be useful, except:
>
> We have to store the following fields at least:
> * hostnames, IPv4 addresses, IPv6 addresses
Why would the IPv4/6 addresses be stored?
A certificate must not be trusted blindly anyway, so the regular
validation still needs to apply, i.e. domain_match(cert, url) needs to
evaluate to boolean true.
What would we gain by storing these information?
If, at all, I'd rather store the URL it is used for instead of the
hostname. I may miss something.
> * port number
> * certificate fingerprint
> * certificate subject DN
Did you forget the certificate hostname? Or did you add it to the
subject DN silently?
> The general idea is, that if the certificate subject DN matches
> one already existing in the database, and the port number matches,
> we will check DNS for the hostname we???re connecting to and the
> hostname(s) already in the databases, so that we will not have
> many duplicate entries in the database like OpenSSH does especially
> in connection with servers with multiple hostnames and IP addresses;
:)
> for example, I have two duplicate entries in my known_hosts file at
> the moment: one is dnsalias1+IPv4 address, one is dnsalias2+IPv6
> address. OpenSSH did not detect if they match. (The code for this
> idea will be the most tricky part of it.)
Shouldn't the (hash of the) certificate be the same so that duplicates
could be detected? I guess this code is simply missing in OpenSSH.
>
> Suggested format:
>
> * field: hostname,hostname,1.2.3.4,5.6.7.8,2001:f00:cafe::d00d
> * space
> * field: portnumber,portnumber,???
> * space
> * field: Subject DN, base64 encoded (to minimise effort)
> * space
> * field: Certificate fingerprint (no idea yet about the format,
> possibly base64 or hex encoded)
> * return (LF, preceding CR is ignored)
>
> Comments? Joey, you too since you do the GnuTLS part of it???
I haven't found time to respond earlier, since this is nothing you
could answer in five minutes... Sorry for the delay.
In general, I assume this is a good idea. It probably makes sense to
include developers form other browsers as well, such as w3m, links etc.
Naturally Mozilla developers should be added as well.
Regards,
Joey
--
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi
Please always Cc to me when replying to me on the lists.
_______________________________________________
Lynx-dev mailing list
Lynx-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lynx-dev
