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
>>>
>
--
Protect your environment - close windows and adopt a penguin!
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
