Hi Oliver
I'm not questing that retrieving the CRL via http is secure. I'm well
aware
of the signatures mechanics, it's more a network design situation and
other
security mechanics that want to reduce the amount of exposed services on
the outside.
And I'm also on your side to get things working properly, that's why
I already opened some pull requests to get missing attributes into the
PKCS7 perl libray on Github.
Anyway. I'll check if I can share the scep/pkcs structure from our test
setup.
best regards
Daniel
Am 2021-10-04 14:04, schrieb Oliver Welter:
Hi Daniel,
well even if it is not commonly used, I want to get it working properly
on OpenXPKI ;)
Besides using HTTP to get a CRL is not "insecure", as the CRL itself is
"secure" in terms of integrity and authenticity you will "just" leak
some information (which indeed can be considered to be a security
risk).
I would appreciate if you can send me the inner PKCS7 structure that
was
used by the router to query the CRL so we can examine what was going
wrong and also use it as a test vector.
best regards
Oliver
Am 04.10.21 um 11:13 schrieb Daniel Hoffend:
Hi Oliver, Carlos,
thanks for pointing me to the right direction in the LibSCEP.xs code.
I was searching within github and the search function was hiding
the block from me. Anyway ...
The fact that the C-Code is exactly accessing issuer_and_serial ->
serial leaves me with questionmarks on my head which part is
return the wrong serial. The wrapper, the pkcs7 parser or what.
Hmmmmm. According to Oliver the GetCRL feature is rarely used in
real production environments, maybe we might wanna skip it too and
propably switch to http instead by either setting up a dedicated
webserver or reuse the cisco internal webserver for crl delivery
to minimize the footprint of servers and services within the
unsecure transportation network.
I'm happy that we came across this problem in our test environment
before we're rolling out the production pki/network. So we still
have a chance to do some minor design changes.
@Oliver: regarding future tests. It depends, personally I'm more
on the server/pki side rather than then cisco guy, but we can I
how things are going.
I'll see how much time I can spend on digging depper
best regards
Daniel Hoffend
Am 2021-10-03 14:47, schrieb Oliver Welter:
Hi Daniel, Carlos,
thank you for this indepth analysis of the code. I must admit that we
have never seen the GetCRL feature somewhere in production and we
tested it only with the "sscep" client which seemed to work but I can
remember that we had a similar (likely the exact same) problem during
development some time ago....
In case there is really something wrong, I am happy to accept a pull
request for a fix. As we are currently investigating to drop LibSCEP
and replace this with our new PurePerl PKCS7 module, I would not put
too much effort in it, in case it is not super urgent to get this
working. In any case I would appreciate Daniels help in testing the
new implementation with your Cisco gear ;)
best regards
Oliver
Am 01.10.21 um 22:18 schrieb Carlos Velasco:
Hi Daniel,
I was curious about this, as I work mostly with Cisco and I didn't
know you could get a CRL check through SCEP. So I took a look at the
codes.
I think the missing part you are looking for is in "LibSCEP.xs" (C
wrapper for perl).
===
SV *
get_getcert_serial(pkiMessage)
Crypt::LibSCEP pkiMessage
PREINIT:
char *ret = NULL;
CODE:
ret = "";
if(pkiMessage->issuer_and_serial != NULL) {
ret = i2s_ASN1_INTEGER(NULL,
pkiMessage->issuer_and_serial->serial);
}
RETVAL = newSVpv(ret, 0);
OUTPUT:
RETVAL
===
I think this is called from
"Service/LibSCEP/Command/PKIOperation.pm"
===
sub __find_cert_issuer_serial : PRIVATE {
my $self = shift;
my $arg_ref = shift;
my $token = $arg_ref->{TOKEN};
my $scep_handle = $arg_ref->{SCEP_HANDLE};
my $requested_serial_dec = $token->command({
COMMAND => 'get_getcert_serial',
SCEP_HANDLE => $scep_handle,
});
...
===
And this is called from "__send_crl" in same file:
===
=head2 __send_crl
Create the response for the GetCRL request by extracting the issuer
and
serial from the request. As we do not support scoped CRLs yet it is
sufficient to check the issuer dn but to catch situations where the
issuer dn
is used over multiple generations we search for both.
=cut
sub __send_crl : PRIVATE {
my $self = shift;
my $arg_ref = shift;
my $scep_handle = $arg_ref->{SCEP_HANDLE};
my $token = $arg_ref->{TOKEN};
my $cert_result = $self->__find_cert_issuer_serial( $arg_ref );
===
But I don't see any error in the logic here.
I *suppose* the C wrapper is taking the serial in the request
through:
i2s_ASN1_INTEGER(NULL, pkiMessage->issuer_and_serial->serial);
Currently I cannot test, but I would look into this serial.
Regards,
Carlos Velasco
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
