Toggle sidebar Toggle sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Other Aqua Proxy: Fix connection issues on OS X 10.6 – 10.9.

startergo said:
Mavericks Security is actually available in full here
github.com

GitHub - mpdeimos/apple-Security: Git mirror of http://opensource.apple.com/source/Security/

Git mirror of http://opensource.apple.com/source/Security/ - mpdeimos/apple-Security
github.com github.com

I can't find the complete source for Security-55002 (10.6.8 one) so it is harder. Although theoretically most of the headers should be frozen in time.
Click to expand...
That's the source code to the Security framework itself; the problem is that it has build dependencies which Apple has not open sourced. Last time I tried this with the Mavericks version (at least five years ago now), I had to use replacements from projects such as Darling, and in the end I wasn't able to build a working framework.

This is absolutely something I want to eventually try again, now that AI coding tools have expanded the scope of what's feasible. However, there are a few reasons I'm putting it off:
  • AquaProxy now handles more than just TLS—it also adds custom headers (needed for Dictionary) and URL redirects (needed primarily for the Help Center, but useful for e.g. Twitter/Bluesky). Without a proxy, I'm not sure where these fixes would live.
  • AquaProxy supports TLS 1.3. Today, this isn't necessary, but I suspect servers may start requiring it in the near future, so I would need to get it working.
  • I try to avoid working on security sensitive code. I end up needing to do it anyway, but this is literally called the Security framework.
I think it's super cool that you have it (partially?) working on Snow Leopard and I'm only a little jealous! For now, I feel like AquaProxy works across four different operating systems and is reliable.
 
> Without a proxy, I'm not sure where these fixes would live.

Presumably within the apps themselves, e.g. you'd have a SIMBL plugin to intercept things as the cocoa or CF layer and add them (or possibly do it higher up in app logic if necessary)

Given that aquaproxy seems to work though, I don't really know if avoiding this proxy layer is that much of a benefit. Also replacing security.framework is probably going to invalidate code signatures which certain applications with the CS_KILL bit may not like?
 
  • Like
Reactions: Wowfunhappy
Wowfunhappy said:
...why would the iTunes Store only work on a Hackintosh? I think you and @johnjd might be miscommunicating here?

@johnjd Does the iTunes Store not work for you with AquaProxy installed?
Click to expand...
It does not; tried it on 9.0.2, 10.something and the latest supported 11.something.

I did run the AquaProxy post-install script via bash and it gave me green lights on all fronts.
 
Wowfunhappy said:
That's the source code to the Security framework itself; the problem is that it has build dependencies which Apple has not open sourced. Last time I tried this with the Mavericks version (at least five years ago now), I had to use replacements from projects such as Darling, and in the end I wasn't able to build a working framework.

This is absolutely something I want to eventually try again, now that AI coding tools have expanded the scope of what's feasible. However, there are a few reasons I'm putting it off:
  • AquaProxy now handles more than just TLS—it also adds custom headers (needed for Dictionary) and URL redirects (needed primarily for the Help Center, but useful for e.g. Twitter/Bluesky). Without a proxy, I'm not sure where these fixes would live.
  • AquaProxy supports TLS 1.3. Today, this isn't necessary, but I suspect servers may start requiring it in the near future, so I would need to get it working.
  • I try to avoid working on security sensitive code. I end up needing to do it anyway, but this is literally called the Security framework.
I think it's super cool that you have it (partially?) working on Snow Leopard and I'm only a little jealous! For now, I feel like AquaProxy works across four different operating systems and is reliable.
Click to expand...
I am almost done with the project just final verification and cleaning. It is definitely important what this project could bring to complement the Aquaproxy. Few observations correct me if I am wrong:

I am almost done with the project just final verification and cleaning. It is definitely important what this project could bring to complement the Aquaproxy. Few observations correct me if I am wrong:

I am not replacing the framework bundle. I am replacing the Mach-O binary inside a framework that on 10.6 isn't itself signed in a way that gets enforced. CS_KILL applies to a process whose own pages fail validation, and on Snow Leopard the dynamic-library validation that would kill a process for loading an unsigned dylib doesn't exist — that's a later addition. Empirically: the framework has been swapped repeatedly today and Safari, security, sudo authorization, loginwindow, and SecurityAgent all run.

I hand-rolled ECDSA verification today reading 0.9.8 struct layouts through mirrored structs. That works, and it's carefully bounded — full signature verification, explicit validity-window checks, anchor requirement — but it's exactly the code you don't want to get subtly wrong, and a mistake fails open. AquaProxy delegating verification to Go's crypto/x509 plus SecTrustEvaluate is a genuinely better place for that responsibility to live.

This is a TLS 1.2 backport. Adding 1.3 to Snow Leopard's SecureTransport is a different order of effort — new handshake state machine, HKDF, new record layer. AquaProxy gets 1.3 for free because Go does it. If servers start requiring 1.3, the proxy survives and this doesn't.

On headers/redirects — that's not a TLS concern at all, and the SIMBL suggestion is reasonable. But it's real work that AquaProxy already has done.

What this project actually offers:

Apps that don't honor the HTTPS proxy setting. Non-HTTP TLS. Anything calling SSLHandshake directly — the project docs cite iTunes specifically, and note it uses a different code path than Safari. And apps that see the server's real certificate rather than a generated one, which matters if anything inspects or pins it. Also no per-interface configuration, and it works before any user-level process starts.

That's a narrower value proposition than "better than a proxy." It's complementary: the proxy handles the browsing case broadly across four OSes; this fixes the platform for the cases a proxy can't reach.

Let me know what you think.
 
startergo said:
I am almost done with the project just final verification and cleaning. It is definitely important what this project could bring to complement the Aquaproxy. Few observations correct me if I am wrong:

I am not replacing the framework bundle. I am replacing the Mach-O binary inside a framework that on 10.6 isn't itself signed in a way that gets enforced. CS_KILL applies to a process whose own pages fail validation, and on Snow Leopard the dynamic-library validation that would kill a process for loading an unsigned dylib doesn't exist — that's a later addition. Empirically: the framework has been swapped repeatedly today and Safari, security, sudo authorization, loginwindow, and SecurityAgent all run.

I hand-rolled ECDSA verification today reading 0.9.8 struct layouts through mirrored structs. That works, and it's carefully bounded — full signature verification, explicit validity-window checks, anchor requirement — but it's exactly the code you don't want to get subtly wrong, and a mistake fails open. AquaProxy delegating verification to Go's crypto/x509 plus SecTrustEvaluate is a genuinely better place for that responsibility to live.

This is a TLS 1.2 backport. Adding 1.3 to Snow Leopard's SecureTransport is a different order of effort — new handshake state machine, HKDF, new record layer. AquaProxy gets 1.3 for free because Go does it. If servers start requiring 1.3, the proxy survives and this doesn't.

On headers/redirects — that's not a TLS concern at all, and the SIMBL suggestion is reasonable. But it's real work that AquaProxy already has done.

What this project actually offers:

Apps that don't honor the HTTPS proxy setting. Non-HTTP TLS. Anything calling SSLHandshake directly — the project docs cite iTunes specifically, and note it uses a different code path than Safari. And apps that see the server's real certificate rather than a generated one, which matters if anything inspects or pins it. Also no per-interface configuration, and it works before any user-level process starts.

That's a narrower value proposition than "better than a proxy." It's complementary: the proxy handles the browsing case broadly across four OSes; this fixes the platform for the cases a proxy can't reach.

Let me know what you think.
Click to expand...

Pretty please don't just copy and paste what the AI wrote, it's pretty obvious. If something is technically over your head, put what the AI wrote in quotes and say where it came from.

It's super cool that you updated the Security framework! I don't think it changes what I said in my last post about it.
 
Last edited:
Wowfunhappy said:
Pretty please don't just copy and paste what the AI wrote (it's pretty obvious), you can certainly quote it but mark where it came from.

I think this is super cool! I don't think it changes what I said in my last post about it.
Click to expand...
If there is nothing it can add to Aquaproxy I will leave it as it is.
 
johnjd said:
It does not; tried it on 9.0.2, 10.something and the latest supported 11.something.

I did run the AquaProxy post-install script via bash and it gave me green lights on all fronts.
Click to expand...

Any of you guys know what I could do to fix this? The aquaproxy service is running and listening on 6351-6353. My network settings have the HTTPS proxy set to localhost:6351.
 
startergo said:
If there is nothing it can add to Aquaproxy I will leave it as it is.
Click to expand...

I don't think there's a reason to use both an updated SecureTransport and a proxy server together. When you're using AquaProxy, the built-in TLS library is essentially rendered inert.
 
Last edited:
johnjd said:
Any of you guys know what I could do to fix this? The aquaproxy service is running and listening on 6351-6353. My network settings have the HTTPS proxy set to localhost:6351.
Click to expand...
Also, Mail.app won‘t let me log into my iCloud account with the imap.mail.me.com and smtp.mail.me.com servers because they just timeout.

I have tried both an app-specific password and my normal password.
 
Why not create a GitHub project then maybe a GitHub page or site for the Aqua proxy?
You can also create a GitHub project for Mavericks forever!
 
chris1111 said:
Why not create a GitHub project then maybe a GitHub page or site for the Aqua proxy?
Click to expand...
Because Aqua Proxy already lives on a website, MavericksForever.com. If I had multiple different websites, I would need to remember to update all of them. Documentation for Aqua Proxy is included in the download; you should have everything you need.

Aqua Proxy does have a Github repository here: https://github.com/wowfunhappy/aquaproxy. The Github repository is intended for developers as opposed to users.
 
Last edited:
  • Like
Reactions: chris1111
Alright, managed to fix most of my problems!

iTunes 11.4 is the version that lets you at least sign and visit the Store - and download artwork.
Buying songs, downloading purchased songs, etc. will not work. I think it’s related to the authorization of the Mac, which prompts for your Apple password but won’t actually succeed as you don’t get a login prompt on your other devices.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back