Sprint 4 - TLS Certificates and CSP

Another week of research! This week my focus has been on stagnant issues from the past. I even discovered some new bugs during the process. Starchart React hydration errors (Link) This was a happy accident. A while ago I was looking into how to secure my home server, and came across HTTP Observatory by Mozilla. It's a service that scans the HTTP headers of your website and gives you feedback on security practices. Here, among other things, I learned about Content Secure Policy or CSP for short. It's an HTTP header that dictates where the website is allow to retrieve each type of content, like scripts, images, stylesheets, etc. This issue on Starchart was posted by Uday last week. But when I looked at the screenshots, I saw some very familiar errors in the console: A good security practice with CSP is to restrict the loading of scripts to only 'self' or an nonce value, which is exactly how it's configured here. I suspect that maybe some code related to styling isn't very stable and get the nonce value wrong. Of course, more investigation is still needed, but it's a good start! Investigate Let's Encrypt certificate chain change (Link) I've been wanting to look into this one for a while. The TLS protocol is always something that fascinates me and I've been learning it in my own time, both for my home server and for personal interest. The issue here is related to TLS certificates. The Starchart project requests certificates from Let's Encrypt, and last year there was a change in their chain of trust. So we want to know what impact it had to our project. After spending some time renewing my knowledge of TLS, I looked into the official blog from Let's Encrypt There they outlined a few situations where this could be a problem: Never downloading the chain at all and only serving the end-entity certificate Never downloading the chain and instead serving a hard-coded chain Only downloading the chain at first issuance and not re-downloading during renewals. Please ensure that your client does not fall into any of these buckets. Looking into out code, we always get the full chain from Let's Encrypt and then split it into an end entity certificate and an intermediate chain: // fullChain is the public certificate + the intermediate certificate(s) for Let's Encrypt const fullChain = await this.#client.getCertificate(this.#order); // certificate is the public certificate, chain is the intermediate certificate(s) for Let's Encrypt const [certificate, ...chainArray] = acme.crypto.splitPemChain(fullChain); const chain = chainArray.join(''); It seems like we are able to mitigate the issue on the server side. However, if someone is still using the old certificates, they would not continue to work. But I don't think there's much we can do here. Incorrect content in downloaded certificates (Link) I noticed this during my research the previous one: The download buttons on the certificate managements page give you the wrong certificates. It's a problem in the development build as well as the already deployed production build! I'm genuinely surprised it has gone unnoticed for as long as it has! To be more specific, there seems to be something wrong with how the server handles intermediate chain for downloads. Although everything shows up under the hidden section just fine, the file always excludes the intermediate CA certificates. Hurl New Issue (Link) This week I haven't been focusing on Hurl that much, but I had my name assigned on this new issue. Here I'll be working on a new query which returns the specs of HTTP redirections. Similar to my IP address query feature, you should be able to use these specs in Asserts and Capture. New Release! Earlier today they made a new release of v6.1.0. And this release contains everything I've worked on since last year! Now everyone can finally use those features (and think of me while they do

Mar 13, 2025 - 16:14

Another week of research! This week my focus has been on stagnant issues from the past. I even discovered some new bugs during the process.

Starchart

React hydration errors (Link)

This was a happy accident. A while ago I was looking into how to secure my home server, and came across HTTP Observatory by Mozilla. It's a service that scans the HTTP headers of your website and gives you feedback on security practices.

Here, among other things, I learned about Content Secure Policy or CSP for short. It's an HTTP header that dictates where the website is allow to retrieve each type of content, like scripts, images, stylesheets, etc.

This issue on Starchart was posted by Uday last week. But when I looked at the screenshots, I saw some very familiar errors in the console:

A good security practice with CSP is to restrict the loading of scripts to only 'self' or an nonce value, which is exactly how it's configured here.

I suspect that maybe some code related to styling isn't very stable and get the nonce value wrong. Of course, more investigation is still needed, but it's a good start!

Investigate Let's Encrypt certificate chain change (Link)

I've been wanting to look into this one for a while. The TLS protocol is always something that fascinates me and I've been learning it in my own time, both for my home server and for personal interest.

The issue here is related to TLS certificates. The Starchart project requests certificates from Let's Encrypt, and last year there was a change in their chain of trust. So we want to know what impact it had to our project.

After spending some time renewing my knowledge of TLS, I looked into the official blog from Let's Encrypt There they outlined a few situations where this could be a problem:

Never downloading the chain at all and only serving the end-entity certificate
Never downloading the chain and instead serving a hard-coded chain
Only downloading the chain at first issuance and not re-downloading during renewals. Please ensure that your client does not fall into any of these buckets.

Looking into out code, we always get the full chain from Let's Encrypt and then split it into an end entity certificate and an intermediate chain:

    // fullChain is the public certificate + the intermediate certificate(s) for Let's Encrypt
    const fullChain = await this.#client.getCertificate(this.#order);

    // certificate is the public certificate, chain is the intermediate certificate(s) for Let's Encrypt
    const [certificate, ...chainArray] = acme.crypto.splitPemChain(fullChain);
    const chain = chainArray.join('');

It seems like we are able to mitigate the issue on the server side. However, if someone is still using the old certificates, they would not continue to work. But I don't think there's much we can do here.

Incorrect content in downloaded certificates (Link)

I noticed this during my research the previous one: The download buttons on the certificate managements page give you the wrong certificates. It's a problem in the development build as well as the already deployed production build! I'm genuinely surprised it has gone unnoticed for as long as it has!

To be more specific, there seems to be something wrong with how the server handles intermediate chain for downloads. Although everything shows up under the hidden section just fine, the file always excludes the intermediate CA certificates.

Hurl

New Issue (Link)

This week I haven't been focusing on Hurl that much, but I had my name assigned on this new issue. Here I'll be working on a new query which returns the specs of HTTP redirections. Similar to my IP address query feature, you should be able to use these specs in Asserts and Capture.

New Release!

Earlier today they made a new release of v6.1.0. And this release contains everything I've worked on since last year! Now everyone can finally use those features (and think of me while they do