TLS keys containing other pem blocks proceeding the private key are considered invalid

[mattalberts]

What steps did you take and what happened:
Created a secret whose EC PRIVATE KEY contains EC PARAMETERS. The function validatePrivateKey locates the EC PARAMETERS pem.Block, attempts to validate it as a private key, and rejects the secret as valid.

What did you expect to happen:
I expected the secret to be accepted as valid :)

Anything else you would like to add:
The private key pem struct is something like this

-----BEGIN EC PARAMETERS-----
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----

I did scan, but didn't find a similar issue.

Environment:

• Contour version: v0.15.1 and master
• Kubernetes version: (use kubectl version): N/A
• Kubernetes installer & version: N/A
• Cloud provider or hardware configuration: N/A
• OS (e.g. from /etc/os-release): N/A

[mattalberts]

I already have a patch, just working on a test :)

[jpeach]

Does Envoy accept and use the additional PEM objects?

[mattalberts]

@jpeach The certificates I've been using with contour versions v0.5.0 to v0.14.2 have contained EC PARAMETERS and were valid for both contour and envoy (e.g. I've been terminating TLS with them for ~2 years). I found this while upgrading to v0.15.1.

Technically, there is a similar flaw with the certificate handling (to less detriment). Currently, a secret will be accepted if the first cert in the PEM block is valid

[mattalberts]

@youngnick I think #1707 makes more sense than #1704 (i was trying to keep this very small hoping for a back port .. but the other addresses both the cert and the private key).

[davecheney]

If 0.15.1 broke certificates which envoy previously accepted the we should backport it to 0.15.2 regardless of the cost.

…

On 16 Oct 2019, at 11:03, Matthew Alberts ***@***.***> wrote:  @youngnick I think #1707 makes more sense than #1704 (i was trying to keep this very small hoping for a back port .. but the other addresses both the cert and the private key). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[youngnick]

@mattalberts I agree, I'm going to check out #1707 properly now and, assuming it's all good (which a cursory inspection suggests), then I'll close out #1704.