Skip to content
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

Decide if we should be as lenient as OpenSSL's PEM Parser #700

Open
alexw91 opened this issue Jan 30, 2018 · 3 comments
Open

Decide if we should be as lenient as OpenSSL's PEM Parser #700

alexw91 opened this issue Jan 30, 2018 · 3 comments

Comments

@alexw91
Copy link
Contributor

alexw91 commented Jan 30, 2018

Related to: #647

Both s2n and OpenSSL accept everything that follows RFC 7468.

This issue is tracking how strict s2n should be at enforcing the RFC, and how it should handle messy PEM files that are invalid according to the RFC. Currently s2n essentially follows the RFC, but is lenient towards most whitespace/newline issues since those don't affect the base64 encoding of the PEM contents. The above fuzz tests are currently able to generate PEM files that s2n rejects, but that OpenSSL accepts.

Example PEM that OpenSSL accepts, but s2n rejects:

s2n currently rejects the following example PEM due to the incomplete BEGIN line at the start, but OpenSSL skips the line, keeps going, and is able to parse the valid Certificate that comes after it. There are probably many other examples, but this is one of the easier ones to demonstrate.

-----BEGIN
-----BEGIN CERTIFICATE-----
...valid PEM contents here...
-----END CERTIFICATE-----

Example PEM that OpenSSL rejects, but s2n accepts:

s2n is lenient towards:

  1. The number of dashes required (RFC says exactly 5, but we allow between 1 and 64),
  2. Whitespace and newlines in the PEM contents. (RFC says exactly 64 Base64 chars per line except last line, but we allow any number of non-dash chars per line)
---BEGIN CERTIFICATE---
...valid PEM contents here...
---END CERTIFICATE---
@raycoll
Copy link
Contributor

raycoll commented Jan 30, 2018

From #647, one idea I had is to try a full handshake with the certificate. If Openssl successfully completes a handshake with the certificate but s2n fails to parse/load/handshake the same cert, that is an interesting input.

@andrewhop
Copy link
Contributor

Centos 7 includes comments in it's default trust store. These comments can include dashes which causes s2n's PEM parser to fail.

# CA name with spaces-and-dashes
-----BEGIN CERTIFICATE-----
...valid PEM contents here...
-----END CERTIFICATE-----

# CA with ----BEGIN CERTIFICATE----? 
-----BEGIN CERTIFICATE-----
...valid PEM contents here...
-----END CERTIFICATE-----

@anishnath
Copy link

There is a useful online version of the PEM parser https://8gwifi.org/PemParserFunctions.jsp with different configuration usefull

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants