0

Question

What kinds of technical nastiness/attacks should I look for in a Certificate Request (CSR) ?

Assume the ASN1 parser is secure on the CA. I'm strictly concerned with the process of validating the data of the CSR.

More information

Suppose the CA recieves the following CSR

-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwgYkxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMR8w
HQYDVQQLExZJbmZvcm1hdGlvbiBUZWNobm9sb2d5MRcwFQYDVQQDEw53d3cuZ29v
Z2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApZtYJCHJ4VpVXHfV
IlstQTlO4qC03hjX+ZkPyvdYd1Q4+qbAeTwXmCUKYHThVRd5aXSqlPzyIBwieMZr
WFlRQddZ1IzXAlVRDWwAo60KecqeAXnnUK+5fXoTI/UgWshre8tJ+x/TMHaQKR/J
cIWPhqaQhsJuzZbvAdGA80BLxdMCAwEAAaAAMA0GCSqGSIb3DQEBBQUAA4GBAIhl
4PvFq+e7ipARgI5ZM+GZx6mpCz44DTo0JkwfRDf+BtrsaC0q68eTf2XhYOsq4fkH
Q0uA0aVog3f5iJxCa3Hp5gxbJQ6zV6kJ0TEsuaaOhEko9sdpCoPOnRBm2i/XRD2D
6iNh8f8z0ShGsFqjDgFHyF3o+lUyj+UC6H1QW7bn
-----END CERTIFICATE REQUEST-----

The CA will strip out the "begin/end" headers and footers and parse the data. Humans can achieve a similar effect here.

As you can see there are a set of OIDs that have corresponding printable string values.

My goal is to prevent privilege escalation, or impersonation attacks that could arise with a malformed CSR.

  • I assume you are asking as a CA who wants to validate CSRs? I mean, as a CA, you are responsible for validating all of the information before issuing the certificate; that's the primary function of the CA. Are asking "what kinds of technical nastiness/attacks should I look for?" – John Deters Feb 9 '17 at 15:52
  • @JohnDeters - yes, just rephrased. One example could be duplicated OIDs, missing OIDs, wrong datatype, XSS in certain fields, XSS reflection, bad punycode, bad UTF8/32 if supported, any attempt to include an EKU reserved for the server to apply... – technology_is_overrated Feb 9 '17 at 15:59
  • I also assume you're validating it fully conforms to RFC5280. Check the Security section of the document, it addresses some of the character encoding concerns you raised. tools.ietf.org/html/rfc5280#page-100 Also consider looking at the referenced RFCs; many of them go into specific details (their relevant text seems to have been carried into 5280, but some have additional sections like Security.) – John Deters Feb 9 '17 at 16:26
0

CA's usually don't use the originally provided CSR and just sign it. Instead they extract and verify only the information they want to include in the certificate from the CSR (i.e. public key, subject..), add some additional information like expiration, CRL distribution point, OCSP URL etc and then they sign this newly created CSR. This way the CA does not need to deal with OID or similar it does not understand since these information are not included in the generated certificate anyway. It only needs to understand and verify the parts it will include from the original CSR, i.e. only few parts. And these parts usually have a well known syntax which can be enforced, for example a domain name.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.