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

[Bug]: ClientHello's status_request extension handling issue #7275

Open
SmallTown123 opened this issue Feb 27, 2024 · 13 comments
Open

[Bug]: ClientHello's status_request extension handling issue #7275

SmallTown123 opened this issue Feb 27, 2024 · 13 comments
Assignees
Labels

Comments

@SmallTown123
Copy link

Contact Details

small_town_123@163.com

Version

5.5.1

Description

The wolfssl server appears to be having some issues with the status_request extension of the Clienthello message, specifically:

When the length of this extension is shorter than normal, specifically 1, and the CertificateStatusType value is 0x01, i.e. OSCP, a normal response still exists from the server.

The structure of the status_request extension item as normalized in the RFC6066 document is as follows:

struct {
CertificateStatusType status_type.
select (status_type) {
case ocsp: OCSPStatusRequest.
} request;
} CertificateStatusRequest;

enum { ocsp(1), (255) } CertificateStatusType;

struct {
ResponderID responder_id_list<0..2^16-1>;
Extensions request_extensions;
} OCSPStatusRequest;

opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;

If the CertificateStatusType is OSCP, the length of the extension must be greater than 1.
Therefore, when the above situation occurs, the server should return an Alert response instead of a normal response.

Reproduction steps

No response

Relevant log output

No response

@anhu anhu self-assigned this Feb 27, 2024
@anhu
Copy link
Member

anhu commented Feb 27, 2024

Hi @SmallTown123 ,

This is Anthony Hu again. I helped you on your previous ticket. For this one, I will need some more time to confer with my colleagues. Please stay tuned.

Warm regards, Anthony

@anhu
Copy link
Member

anhu commented Feb 27, 2024

Hi @SmallTown123 , I've assigned @ejohnstown to have a look at this issue. Please stay tuned.

@ejohnstown
Copy link
Contributor

@SmallTown123:

Can you send a Wireshark capture of this happening?

The code is expecting there to be a length of the responder_id_list right after the CertificateStatusType value.

I modified the client side code to put only the CertificateStatusType value in the extension, and I'm getting the error I expect.

@SmallTown123
Copy link
Author

@ejohnstown:

status_request

This is a wireshark screenshot of our test data. status_request is supposed to be 5, but when its length is changed to 1, the last 4 bytes 00 00 00 00 are parsed as server_name without affecting the normal parsing of subsequent extensions.

But should the server respond with an Alert in this case?

@ejohnstown
Copy link
Contributor

But should the server respond with an Alert in this case?

It should and as far as I can tell it does.

First, I tested this running TLSv1.2 and I get the alert. I modified the function TLSX_CSR_Write() to return early only putting the Cert Stats Type value into the extension. My decoded Client Hello looks like your capture. I get the Decode Error Alert. I added some marker prints to TLSX_CSR_Parse() and we are checking the length of the extension and are not reading beyond the end of it into the next extension, we return an error and alert.

Today I'm running with TLSv1.3 with the master branch of our repository. I use the same modification to TLSX_CSR_Write(), and it is modifying the extension for only the single type value. The server is also returning an alert.

I switched back to v5.5.1, and I'm getting the same result. The server is sending an alert.

I configured wolfSSL with the option --enable-all. And I also tried --enable-ocsp --enable-ocspstapling. Same result. We appear to be testing something different. How are you configuring wolfSSL?

@SmallTown123
Copy link
Author

Hi, @ejohnstown:

I configured wolfSSL with the option --enable-ecc --enable-dsa --enable-aesccm --enable-curve25519 --enable-tls13.
The wolfSSL version is 5.5.1.

In fact, the content of the status_request extension should have been 00 05 00 05 01 00 00 00 00.
However, during testing, we artificially changed the extension length from 00 05 to 00 01.
At this point, the first 5 bytes 00 05 00 01 01 are parsed according to the status_request extension structure, the last four bytes 00 00 00 00 are parsed as server_name extension.

Not sure if your test data is consistent with that situation?

@ejohnstown
Copy link
Contributor

I should have asked for your configuration first. Given your configuration, that extension isn't supported and it is skipped, not even looked at. Add --enable-ocspstapling to your configuration.

@ejohnstown
Copy link
Contributor

And I'm actually shortening the extension rather than lying about the length in my test. I see the difference now. I'll take another look at this.

@ejohnstown
Copy link
Contributor

I recreated your failure mode. Looking at a solution.

@SmallTown123
Copy link
Author

Thanks for your reply, I was wondering if it would be possible to parse the extension while considering a safety check on the extension length.

@osevan
Copy link

osevan commented Apr 22, 2024

Im waiting too .-)

@dgarske
Copy link
Contributor

dgarske commented Apr 26, 2024

@anhu or @ejohnstown any update on this?

@lealem47
Copy link
Contributor

Hi @SmallTown123,

This PR #7602 should add the required checks that you brought up.

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

No branches or pull requests

6 participants