lynx-dev
[Top][All Lists]
Advanced

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

Re: [Lynx-dev] SSL known_certs?


From: Stefan Caunter
Subject: Re: [Lynx-dev] SSL known_certs?
Date: Tue, 23 Sep 2008 10:23:06 -0400

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

good idea

> 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

site name or IP is the same, cert is different so warn, like openssl

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

you could "remind" that this site still has cert issues, specifying
cert mismatch, name mismatch

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

just thinking out loud but is a timestamp useful to analyze change behaviour?

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

does the root trust match with DNS, so are we tying into SSL_CERT_DIR
for checking and do we go with that as ultimate authority or negotiate
between this .etc/known_certs and the system cert dir, like /etc/hosts
and DNS works, and does there need to be awareness of this.

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

Stef


---
Stefan Caunter
Skype: stefan.caunter
http://caunter.ca/contact.html




reply via email to

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