You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Example PEM that OpenSSL rejects, but s2n accepts:
s2n is lenient towards:
The number of dashes required (RFC says exactly 5, but we allow between 1 and 64),
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)
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.
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.
Example PEM that OpenSSL rejects, but s2n accepts:
s2n is lenient towards:
The text was updated successfully, but these errors were encountered: