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" _______________________________________________ Lynx-dev mailing list Lynx-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/lynx-dev