[Lynx-dev] Re: SSL known_certs?

[Thorsten Glaser]

Joey Schulze dixit:

>  . certificate is in $CERTFILE and trust level is good -->
>    certificate is trusted

What is "trust level"?

A server certificate can have three states (as of now):
* signed by a CA in /etc/ssl/certs (or $CERTFILE) and valid
* signed but invalid (includes "lesser" cases such as expired)
* self-signed or signed by an unknown CA

The certificate itself should never appear in $CERTFILE.

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

Lynx cannot add to /etc/ssl/certs, but the proposal is to add
server certificates to a certificate cache upon first encounter,
no matter if they are signed/valid, signed/invalid or unsigned.

If a certificate is signed/valid, it will always be accepted,
no matter what, currently. Otherwise, it defaults to "ask".

With my proposal, if an IP/port tuple encounters a DIFFERENT
certificate than the one cached on connect, it's forcefully
set to "ask" as well.

With my proposal, you can also set signed/invalid or unsigned
certificates (yes, even these whose CN and subjectAltName dif-
fers from the vhost) to "don't ask". Rationale:
* some sites just don't get their subjects right: dev.openwrt.org
* some sites have self-signed certificates: symlink.ch
* this is not a notion of "trust", but rather a notion of "if I
  connect the second time, I get what I had the first time, be
  it the real peer or an impostor" (reliability, reproducability)

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

See above. I am sure you know the saying "we sell rope" ;)
The user will be given enough rope to han^Wallow certificates that
do NOT pass the X.509v3 validation, *as long as* they are tied to
a specific (IP, port) tuple and do not change. (Note that this is
only "part 2" of my proposal; the other part is that EVEN THESE
THAT PASS can be forced "down" to the "ask" state if they DO change.)

>If, at all, I'd rather store the URL it is used for instead of the
>hostname.  I may miss something.

The SSL server certificate exchange is tied to IP+port; there
is a different method, but Lynx does not support it.

>Did you forget the certificate hostname?  Or did you add it to the
>subject DN silently?

The hostname is part of the DN or an X.509v3 subjectAltName ex-
tension, but not relevant. We just need some means to uniquely
identify a certificate. With sendmail /etc/mail/access, the key
criteria are issuer and subject DN, which is why I came up with
the idea. Maybe add the certificate serial number. And a hash is
needed because we do not require entries in said cache/database
to be validatable against some CA.

The status of an entry will need special care, because we want
an entry to be automatically degraded from ok to ask if it no
longer validates (e.g. expiry time passed), but still be able
to force them up to ok by the user manually.

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

Yes, because the certificate presented is identical, even bitwise.
But on the other hand, you can use a certificate for two servers,
or even just two ports on the same server, and then decide to just
switch one of them. This should not degrade the entry for the other.

>I haven't found time to respond earlier, since this is nothing you
>could answer in five minutes...  Sorry for the delay.

Yeah, no worries. I have way too many pet projects running anyway...
and sometimes get distracted (hacked wchar_t support for pcc) or
tend to the real life.

>In general, I assume this is a good idea.

Thanks.

>It probably makes sense to
>include developers form other browsers as well, such as w3m, links etc.

Maybe, but Lynx is the only one out of these which does proper
certificate validation, to the best of my knowledge.

>Naturally Mozilla developers should be added as well.

No.


bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"