-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apply URL encoding/unencoding to OCSP Get requests #18938
Apply URL encoding/unencoding to OCSP Get requests #18938
Conversation
stevendpclark
commented
Feb 1, 2023
- Missed this during development and sadly the unit tests were written at a level that did not expose this issue originally, there are certain combinations of issuer cert + serial that lead to base64 data containing a '/' which will lead to the OCSP handler not getting the full parameter value.
- When this happens we return a 400 error with a malformed request static OCSP response.
- Do as the spec says, this should be treated as url-encoded data.
- Missed this during development and sadly the unit tests were written at a level that did not expose this issue originally, there are certain combinations of issuer cert + serial that lead to base64 data containing a '/' which will lead to the OCSP handler not getting the full parameter. - Do as the spec says, this should be treated as url-encoded data.
@stevendpclark Did you want to write more tests that expose this behavior by any chance? |
Yeah, I was gonna rely on the ENT tests, but it makes sense to add them here. Done. |
* Apply URL encoding/unencoding to OCSP Get requests - Missed this during development and sadly the unit tests were written at a level that did not expose this issue originally, there are certain combinations of issuer cert + serial that lead to base64 data containing a '/' which will lead to the OCSP handler not getting the full parameter. - Do as the spec says, this should be treated as url-encoded data. * Add cl * Add higher level PKI OCSP GET/POST tests * Rename PKI ocsp files to path_ocsp to follow naming conventions * make fmt
* Apply URL encoding/unencoding to OCSP Get requests - Missed this during development and sadly the unit tests were written at a level that did not expose this issue originally, there are certain combinations of issuer cert + serial that lead to base64 data containing a '/' which will lead to the OCSP handler not getting the full parameter. - Do as the spec says, this should be treated as url-encoded data. * Add cl * Add higher level PKI OCSP GET/POST tests * Rename PKI ocsp files to path_ocsp to follow naming conventions * make fmt Co-authored-by: Steven Clark <[email protected]>
- This fix was incorrect as now the tests and program are double URL encoding the OCSP GET requests, so the base64 + characters when using Vault proper are becoming space characters.
- This fix was incorrect as now the tests and program are double URL encoding the OCSP GET requests, so the base64 + characters when using Vault proper are becoming space characters. Co-authored-by: Steven Clark <[email protected]>
return nil, fmt.Errorf("failed to unescape base64 string: %w", err) | ||
} | ||
|
||
return base64.StdEncoding.DecodeString(unescapedBase64) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
StdEncoding
is not URL-safe, should this have been base64.URLEncoding
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@awnumar No, that is the problem. See RFC 6960, Appendix A:
GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}
Note that is not:
base64.URLEncoding.EncodeString(...)
That is:
url.QueryEscape(base64.StdEncoding.EncodeString(...))