TLS 1.3 PPC

[GA204]

Update:
Borrowed some time on a friend's Intel Mac and using a copy of OSX 10.6 Server, I updated to Universal PowerPC / X86 / AMD64 binary, which should be compatible with OS X 10.4+ on all 3 machines. I also updated the proxy-roots.pem file to the most recent CA certificate store from Curl (dated Feb 25, 2025).

The program doesn't do AIA chasing, but rather it just relies on the CA's proxy-roots.pem file and fails to load a website if its certificate is not signed by a CA in proxy-roots.pem, and produce an error message in the Terminal window. This gives the user awareness and control over whether they want to trust such a certificate (and manually add it to their proxy-roots.pem file) or not. Fortunately, Curl's CA store is really good and there are not many incomplete chains, such that I have not come across a case.

The program was programmed to be secure by design and have layering, so some of the measures are simply fail-safes. Having the certificate expire in such a short time-frame like 90 days is meant to still offer protection in case the other security measures and protections were to somehow fail and someone were to find a way to forward the port.

As of version 0.2, you can either run A.Proxy from the Terminal or by double clicking; however, if you are switching from using the Terminal to double clicking, it is best to copy both your proxy-ca.pem and proxy-key.pem files to your home directory (or use symbolic linking).

 

[nyteshade]

Update:
Borrowed some time on a friend's Intel Mac and using a copy of OSX 10.6 Server, I updated to Universal PowerPC / X86 / AMD64 binary, which should be compatible with OS X 10.4+ on all 3 machines. I also updated the proxy-roots.pem file to the most recent CA certificate store from Curl (dated Feb 25, 2025).

The program doesn't do AIA chasing, but rather it just relies on the CA's proxy-roots.pem file and fails to load a website if its certificate is not signed by a CA in proxy-roots.pem, and produce an error message in the Terminal window. This gives the user awareness and control over whether they want to trust such a certificate (and manually add it to their proxy-roots.pem file) or not. Fortunately, Curl's CA store is really good and there are not many incomplete chains, such that I have not come across a case.

The program was programmed to be secure by design and have layering, so some of the measures are simply fail-safes. Having the certificate expire in such a short time-frame like 90 days is meant to still offer protection in case the other security measures and protections were to somehow fail and someone were to find a way to forward the port.

As of version 0.2, you can either run A.Proxy from the Terminal or by double clicking; however, if you are switching from using the Terminal to double clicking, it is best to copy both your proxy-ca.pem and proxy-key.pem files to your home directory (or use symbolic linking).

So this is working well. Thank you for this contribution. If you're willing to share the source and build steps it would be great, I'd love to build a GUI around this without having to shell out to run it. Additionally, I'd like to make the port that it uses configurable and provide proper help usage. If you're not ready to share the source, can you at least make the port configurable?

 

[GA204]

Sure, attached is version 0.5.

The default port is still 8080 if you run aproxy without parameters; however, with this version, if you want to use a different port, you can now specify the port number as the first parameter.

For example, to use port 7070 instead, you would now type: aproxy 7070

I've also updated the root certificate store to use the CURL/Firefox 2025-12-02 certificates.

Like the above post, this is a universal PPC/x86/amd64 Mac binary.

Let me know if you would like me to add any other features.

 

[srp]

Sure, attached is version 0.5.

The default port is still 8080 if you run aproxy without parameters; however, with this version, if you want to use a different port, you can now specify the port number as the first parameter.

For example, to use port 7070 instead, you would now type: aproxy 7070

I've also updated the root certificate store to use the CURL/Firefox 2025-12-02 certificates.

Like the above post, this is a universal PPC/x86/amd64 Mac binary.

Let me know if you would like me to add any other features.

This is a seriously under-rated contribution! It works great, it's convenient to set up and use, there's no second device required - just great! The iTunes Store UI still loading and looking normal after all this time is pretty crazy. Unfortunately I wasn't able to use it to get system Mail.app working (wishful thinking I suppose)

I notice that I have to manually approve each incoming SSL handshake, even when I use more up-to-date browsers like Aquafox where there isn't usually a warning. I did trust the root CA and it's the same issue - the root CA is from the destination website e.g. it asks me to trust Apple or Google certs if I go there. Is there something I'm doing wrong on my end for that to happen?

I'd like to keep this as a system level proxy so I'm not sure if that's just a side effect.

 

[Ryan Bremer]

This is a seriously under-rated contribution! It works great, it's convenient to set up and use, there's no second device required - just great! The iTunes Store UI still loading and looking normal after all this time is pretty crazy. Unfortunately I wasn't able to use it to get system Mail.app working (wishful thinking I suppose)

I notice that I have to manually approve each incoming SSL handshake, even when I use more up-to-date browsers like Aquafox where there isn't usually a warning. I did trust the root CA and it's the same issue - the root CA is from the destination website e.g. it asks me to trust Apple or Google certs if I go there. Is there something I'm doing wrong on my end for that to happen?

I'd like to keep this as a system level proxy so I'm not sure if that's just a side effect.

View attachment 2598349

you have fixed the iTunes Store on ppc! let's go!

 

[srp]

Really having fun with some of the revived web-enabled features in Leopard.

iTunes Store won't work for logins or fetching purchases which is to be expected. And sure, in cases where the actual endpoints are dead, TLS 1.3 won't help - but I do like how it provides a higher level of baseline functionality.

Once I can figure out how to stop needing to manually approve each website I connect to, I'll be rocking this as a default on my daily driver Quad.

 

[GA204]

Glad to hear you like my program!

Two possibilities come to mind regarding the prompting:

The most likely is that the proxy-ca.pem certificate (which shows up as "localhost" in Keychain Access) may have either been imported to a different certificate store or have the wrong trust settings. Aproxy uses this certificate to sign its session certificates, which will cause Safari/etc. to prompt for each URL unless proxy-ca.pem is imported as a Root CA. By default, Aproxy tries to take care of this itself by asking to import the certificate whenever it generates a new one (which happens whenever proxy-ca.pem is missing or expires).

Another possibility is that I've found when doing early testing (before releasing version 0.1 or 0.2) that occasionally if you have more than one "localhost" certificate in Keychain Access which is not close to expiry, Safari (and likely iTunes) seems to get confused for some reason. This only happened once or twice, but it was easy to fix by deleting the older certificate, and so Aproxy will check if proxy-ca.pem has expired before generating a new proxy-ca.pem certificate (however, if you manually generate/import your own certificate file for proxy-ca.pem, or have other programs with certificates labelled "localhost", this could be a mild potential snag which can be fixed).

Nonetheless, both of these should be reasonably straightforward to fix:

First, open Keychain Access (in Applications > Utilities), search the appropriate Certificate store on the left-hand (e.g. X509Anchors on Tiger) and then find any certificates labelled as "localhost". On most people's computers, these should only be the ones generated by Aproxy for signing temporary/session certificates, and it should be safe to delete them. (If you want to be extra cautious, you can look at the date of issue, which should be roughly the same as the creation date / timestamp for the files proxy-ca.pem and proxy-key.pem)

After doing this, you can either manually re-import the certificate proxy-ca.pem into Keychain as a CA root, or simply delete the files proxy-ca.pem and proxy-key.pem and let Aproxy generate and import a new signing certificate. On Tiger, be sure to select the X509Anchor store on the prompt which comes up.

If that doesn't work, one other thing to try is going to the "localhost" certificate in Keychain Access, double clicking on it, scrolling down to "Trust Settings" and then changing each one to "Always Trust" and seeing if that happens to fix the problem.

 

[srp]

Glad to hear you like my program!

Two possibilities come to mind regarding the prompting:

The most likely is that the proxy-ca.pem certificate (which shows up as "localhost" in Keychain Access) may have either been imported to a different certificate store or have the wrong trust settings. Aproxy uses this certificate to sign its session certificates, which will cause Safari/etc. to prompt for each URL unless proxy-ca.pem is imported as a Root CA. By default, Aproxy tries to take care of this itself by asking to import the certificate whenever it generates a new one (which happens whenever proxy-ca.pem is missing or expires).

Another possibility is that I've found when doing early testing (before releasing version 0.1 or 0.2) that occasionally if you have more than one "localhost" certificate in Keychain Access which is not close to expiry, Safari (and likely iTunes) seems to get confused for some reason. This only happened once or twice, but it was easy to fix by deleting the older certificate, and so Aproxy will check if proxy-ca.pem has expired before generating a new proxy-ca.pem certificate (however, if you manually generate/import your own certificate file for proxy-ca.pem, or have other programs with certificates labelled "localhost", this could be a mild potential snag which can be fixed).

Nonetheless, both of these should be reasonably straightforward to fix:

First, open Keychain Access (in Applications > Utilities), search the appropriate Certificate store on the left-hand (e.g. X509Anchors on Tiger) and then find any certificates labelled as "localhost". On most people's computers, these should only be the ones generated by Aproxy for signing temporary/session certificates, and it should be safe to delete them. (If you want to be extra cautious, you can look at the date of issue, which should be roughly the same as the creation date / timestamp for the files proxy-ca.pem and proxy-key.pem)

After doing this, you can either manually re-import the certificate proxy-ca.pem into Keychain as a CA root, or simply delete the files proxy-ca.pem and proxy-key.pem and let Aproxy generate and import a new signing certificate. On Tiger, be sure to select the X509Anchor store on the prompt which comes up.

If that doesn't work, one other thing to try is going to the "localhost" certificate in Keychain Access, double clicking on it, scrolling down to "Trust Settings" and then changing each one to "Always Trust" and seeing if that happens to fix the problem.

Thanks for the response! I did go ahead and clear out the old certificate, added a new one, imported into the System keychain and then set the trust settings to "Always Trust". It wasn't explicitly set to "Always Trust" before so I was hoping that was the issue.

Unfortunately, as soon as I set aproxy as my system proxy and attempt to load the iTunes Store as a test, I still get a warning about not being able to verify a secure connection and I have to manually allow before continuing.

With modern browsers like Aquafox and Powerfox, it complains about the website requiring HSTS, and therefore I'm not able to add an exception at all.

So it seems that I can use aproxy to restore some OS level network functionality and it works (with consent) for system services, but breaks any kind of page loading with modern web browsers that have their own certificate lists.

 

[Matias_]

So it seems that I can use aproxy to restore some OS level network functionality and it works (with consent) for system services, but breaks any kind of page loading with modern web browsers that have their own certificate lists.

You can configure Mozilla derived browsers to not use the system proxy in their settings.

 

[GA204]

You can configure Mozilla derived browsers to not use the system proxy in their settings.

@Matias_ that's along the same lines of how I use Aproxy on my machine. Because Aquafox already supports TLS 1.3 and has its own up-to-date certificate store, I just let it do its thing and mostly save Aproxy for the programs I use which cannot access the modern web without it (e.g. Safari/Webkit/etc.)

@srp if you try using either Leopard Webkit or Safari to access a website, such as apple.com, does Webkit prompt in the same manner?