[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