On Tue, May 28, 2013 at 03:29:20PM -0400, Suresh Krishnaswamy wrote:
> > This library's (latest 2.0 release) implementation of certificate
> > usage 2 is rather broken none of the "2 x y" cases are implemented
> > correctly.
> >
>
> Yep, the implementation of usage 2 in the 2.0 release is quite
> broken. However, the svn version should be better
> (https://www.dnssec-tools.org/svn/dnssec-tools/trunk/dnssec-tools/validator/libval/val_dane.c).
>
> Feedback is always welcome.
This version is much better, it does not handle "IN TLSA 2 1 0",
where only the public key is in DNS, and the chain omits the
corresponding TA certificate (it starts with a certificate signed
by the TLSA public key). It is also somewhat inefficient, since
it repeats the checks in X509_verify_cert() performed during the
handshake. Doing this via a verify callback rather than via a
post-handshake function is more natural.
Also the result of val_dane_check() does not distinguish between
usage 2 (which requires name checks on the leaf cert) and usage 3
(which does not!). Neither require PKIX checks, so usage 2 is still
insecure since applications will likely skip all further checks.
This interface likely needs to take of name checks.
>
> > More fundamentally, this library is (as evidenced by the curl patch)
> > intended to be used after a permissive SSL verification callback
> > which ignores all errors (or equivalently with any callback and
> > SSL_VERIFY_NONE set). This will ignore parent-child signature
> > errors and expiration problems in the certificate chain.
> >
> > Since applications generally expect PKIX validation to performed
> > during the handshake, application code that runs post-handshake
> > rarely if ever performs a complete set of PKIX checks.
> >
>
> I agree with you that we'd normally want the DANE checks to occur
> during the SSL hand-shake itself for all the reasons you've given
> above. In the case of libcurl, though, it appears that the application
> performs its own set of certificate checks in ossl_connect_step3().
> Now, I'm by no means an expert in the libcurl code-base and could
> still be way wrong, but a quick test seemed to confirm that expired
> TLS certs are in fact caught even with the patch applied.
Curl only looks at the expiration times of the leaf certificate,
not the intermediate certificates, much more importantly it does
not check that any of the certificates in the chain are actually
signed by the certificate one layer deeper in the chain. Therefore,
with the 2.0 release, certificate usage 0 is trivially forged by
a MITM attack. With usage 1, the PKIX checks are not correctly
applied, and it is no stronger than 3.
The version 2.0 code is unsafe for most certificate usages and
should be withdrawn.
Designing a robust library extension to OpenSSL that handles the
needs of multiple applications is non-trivial. Since And Polyakov
of OpenSSL has started this work, perhaps the dnsval features for
this should be withdrawn rather than extended/improved further.
I know that some of the issues I'm reporting here apply equally to
the OpenSSL git version, but with luck those will be fixed, and in
time should obviate the need for add-on libraries. Though it may
take some time, my view is that in the interim "no code" is better
than "some code", when "some" means incomplete and likely insecure.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
