Segmentation fault in x509_ocsp_response.c:896 about strongswan

[tobiasbrunner]

Thanks for the report. The crash happens if the OCSP response status indicates an error because that skips the function that parses the responseBytes ASN.1 structure, which is where responderId is ensured to be set to at least ID_ANY. I've pushed a possible fix to the 2011-ocsp branch.

However, I wonder why the OCSP server doesn't like the request in the first place. One difference I can see is that the nonce is now 32 bytes long instead of 16. But that's just an ASN.1 OCTET STRING and RFC 6960 doesn't make any restrictions on the length (neither did RFC 2560). You could try if changing it back makes a difference:

strongswan/src/libstrongswan/plugins/x509/x509_ocsp_request.c

Line 33 in 11dbc8e

#define NONCE_LEN 32

[richardschuetz]

Thanks for the report. The crash happens if the OCSP response status indicates an error because that skips the function that parses the responseBytes ASN.1 structure, which is where responderId is ensured to be set to at least ID_ANY. I've pushed a possible fix to the 2011-ocsp branch.

I can confirm that after applying the patch, the OCSP error is now handled gracefully by falling back to the certificate revocation list.

15[CFG] checking certificate status of "C=DE, O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU=DFN-PKI, CN=DFN-Verein Certification Authority 2"
15[CFG]   requesting ocsp status from 'http://ocsp0336.telesec.de/ocspr' ...
15[LIB]   ocsp response status: malformed request
15[CFG] ocsp response verification failed, invalid signature
15[CFG] ocsp response verification failed, invalid signature
15[CFG] ocsp check failed, fallback to crl
15[CFG]   fetching crl from 'http://pki0336.telesec.de/rl/TeleSec_GlobalRoot_Class_2.crl' ...
15[CFG]   using trusted certificate "C=DE, O=T-Systems Enterprise Services GmbH, OU=T-Systems Trust Center, CN=T-TeleSec GlobalRoot Class 2"
15[CFG]   crl correctly signed by "C=DE, O=T-Systems Enterprise Services GmbH, OU=T-Systems Trust Center, CN=T-TeleSec GlobalRoot Class 2"
15[CFG]   crl is valid: until Apr 17 11:23:00 2024
15[CFG] certificate status is good

However, I wonder why the OCSP server doesn't like the request in the first place. One difference I can see is that the nonce is now 32 bytes long instead of 16. But that's just an ASN.1 OCTET STRING and RFC 6960 doesn't make any restrictions on the length (neither did RFC 2560). You could try if changing it back makes a difference:

strongswan/src/libstrongswan/plugins/x509/x509_ocsp_request.c

Line 33 in 11dbc8e

#define NONCE_LEN 32

Reverting the nonce length back to 16 bytes fixes the communication with the affected OCSP responder. But according to RFC 8954, newer clients must use a length of 32 bytes for the nonce, so strongSwan is not to blame here.

[tobiasbrunner]

Thanks for testing. I've force-pushed an alternative fix and some additional patches to the branch.

Reverting the nonce length back to 16 bytes fixes the communication with the affected OCSP responder. But according to RFC 8954, newer clients must use a length of 32 bytes for the nonce, so strongSwan is not to blame here.

True, but I wonder how many other server implementations are around that have a lower limit for nonces in OCSP requests. We could maybe add a setting to specify the nonce length. I've pushed a commit that does so to the same branch. In your case, you could set charon.ocsp_nonce_len to 16 to use this particular OCSP server.

[richardschuetz]

I have successfully tested the alternative fix and the new configuration option.

[tobiasbrunner]

Great, thanks! I've pushed the changes to master and we'll probably release a new version soonish.