[15531] in Athena Bugs
Re: Lynx-SSL gives misleading error on expired server cert
daemon@ATHENA.MIT.EDU (Emil Sit)
Wed Sep 24 15:37:42 1997
To: Jered J Floyd <jered@MIT.EDU>
Cc: bugs@MIT.EDU, cwis-dev@MIT.EDU
From: Emil Sit <sit@MIT.EDU>
Date: 24 Sep 1997 15:38:27 -0400
In-Reply-To: Jered J Floyd's message of Wed, 24 Sep 1997 01:09:10 -0400
Follow-ups should probably be restricted to cwis-dev.
Jered J Floyd writes:
> Lynx-SSL from the infoagents locker gives the following error message
> when one attempts to visit a site with an expired server certificate:
>
> We had some minor errors errors in verifying this certificate. Proceed? (y/n)
>
> This seems suboptimal as an error message. (It's a good sight better
I was not entirely pleased with the error handling mechanisms
implemented in Lynx-SSL. Since someone may want to fix this and I
don't really have time this semester to do very much, below is a
fairly complete description of why we get this error message. Since I
didn't really have a very complete set of design docs at the end of
the project, I figure this might at least be useful.
SSLeay has a call to verify the authenticty of a certificate and
allows you to write a callback which it will consult every time it
finds an error. The callback is given information about which
certificate it is looking at and what SSLeay thinks the error is.
The callback then has the opportunity to decide whether or not wants
to continue. The SSLeay verification method basically constructs the
certificate chain to the best of its ability (i.e. your server cert,
its parents, etc, etc) and then verifies it from the highest level
down.
What Lynx-SSL does is to force the verification procedure all the way
down the list to the bottom, storing information about whatever errors
it got along the way. I've broken up the errors which SSLeay returns
into some levels of severity and basically score the chain:
/*
* Keep track of the most fatal error. They are, in order
* of decreasing severity...
*/
switch (error) {
case X509_V_ERR_CERT_SIGNATURE_FAILURE:
chain_badness += 40;
break;
case X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY:
case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:
case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT:
/* I don't really understand the meaning of
* these two errors */
case X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE:
/* Real bad -- we can't verify the veracity of the signature */
chain_badness += 30;
break;
case X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD:
case X509_V_ERR_CERT_NOT_YET_VALID:
case X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD:
case X509_V_ERR_CERT_HAS_EXPIRED:
/* Sorta bad */
chain_badness += 20;
break;
case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT:
/* weird, but probably ok? */
chain_badness += 10;
break;
case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN:
/* we were provided the entire chain. do we trust it? */
chain_badness += 5;
default:
/* do nothing */
break;
}
At the "bottom", based on the score, an error message is selected:
if (chain_badness > 40)
prompt = "several critical errors";
else if (chain_badness > 30)
prompt = "some serious errors";
else if (chain_badness > 20)
prompt = "some errors";
else if (chain_badness > 0)
prompt = "some minor errors";
[Hrm; I suppose it might be better to use >=.]
There are some problems with this:
* SSLeay doesn't really make it easy to determine the "bottom". At
level 0, the callback might be called several times with different
errors. I have a guess for when we're at the very end of all the
errors, but sometimes it is wrong.
* Users don't get to see the exact error message(s) but instead only
get my opinion of the severity of the error. This is not
particularly customizable.
On the other hand, it had some good points:
* The user is not subjected to a whole bunch of possibly cryptic
messages. Here, the user only has to answer one question which is
asked in pretty simple language.
* I didn't have to completely rip out and reimplement the SSLeay
verification mechanism. (SSLeay does try to make it somewhat easy
to do this, but SSLeay documentation overall sucks.) There
was also some inertia towards not reimplementing it since the
procedure had worked okay in the bottom-up SSLeay-0.6.6 way of
doing things.
Ideally, I think the Lynx would have its own verification method and
not depend on SSLeay's somewhat messed-up and underdocumented
interface. (I have a record of my attempts to understand eay's code,
if anyone is interested.)
--
Emil Sit / Bronx Science '95, MIT '99 -- ESG, SIPB, Athena Consulting
PGP KeyID: 0xE63561E9 / Fingerprint: A68FD0693EDABA19 2671EC1F22498F58
