lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lynx-dev] SSL known_certs?


From: Thorsten Glaser
Subject: [Lynx-dev] SSL known_certs?
Date: Tue, 23 Sep 2008 10:23:05 +0000 (UTC)

Thomas Dickey dixit:

> patches of course, are welcome...

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.

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.

① 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

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
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
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
 * port number
 * certificate fingerprint
 * certificate subject DN

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.)

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…

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
        -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc




reply via email to

[Prev in Thread] Current Thread [Next in Thread]