I know. Can I still have it too?
BTW, the IMAP trick didn't work on Outlook, regardless of whether it was used for localhost or the default server setup.
Got a tip for us?
Let us know
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.
- Thread starter Wowfunhappy
- Start date
-
- Tags
- networking software
- Sort by reaction score
BTW, the IMAP trick didn't work on Outlook, regardless of whether it was used for localhost or the default server setup.
A couple of notes on "Notes" as the pattern has more or less taken final shape: in my case, it's added only on the account creation and seems OK at first. However, the System Preferences deselects the service later on. It happens because it treats me as "unauthorized".
And in the "Authentication" tab of the Charles Requests Inspector, it displays my app-generated password. Several posts earlier, DurltazorOSXPower had a similar problem: an app-specific pwd is rejected. Go figure. Could the root cause be similar as well?
Ruby:
Req: POST /setup/login_or_create_account HTTP/1.1
Resp: HTTP/1.1 401 UnauthorizedAnd in the "Authentication" tab of the Charles Requests Inspector, it displays my app-generated password. Several posts earlier, DurltazorOSXPower had a similar problem: an app-specific pwd is rejected. Go figure. Could the root cause be similar as well?
Are you using IMAP or Exchange with Outlook? Exchange is different protocol, it should go through AquaProxy without doing anything special (it's HTTP traffic), but it may still not work with Apple Mail for reasons unrelated to https support. You might try something like https://davmail.sourceforge.net/, but disclaimer, I have not used it.
No, the root cause of his problem was that SMTP (sending mail) was broken in Snow Leopard. I'd tested receiving Mail in 10.6 and sending mail in other operating systems, but not the combination of Snow Leopard + sending mail. My mistake.
I don't really understand what you're asking for. --log-urls should log to the console and --force-mitm should mitm all traffic. But if it doesn't for some reason—well, I don't test the flags extensively in every possible configuration like I do other features, they're intended for debugging. If there's anything else you want to see, all my source code, build scripts, etc is on Github.
I'm writing from Lion. This is what howsmyssl reported when I loaded it in Safari 5.
Safari feels a bit sluggish, indeed. Session Ticket support "improvable".
Apple Mail (10.7.5).I can't set up an iCloud Mail account here, it says "The IMAP server is not responding". I managed to add it in offline mode, but it failed to connect. The Little Snitch Network Monitor shows only Aqua-HTTPS running, no Aqua-IMAP.
I checked the certs. All are installed and trusted; however, I have two copies of DigiCert Global Root G2 and DigiCert Global Root G3 (one copy of each cert is under "System", and the other under "System Roots").
Console:
Update. Alarm call-off. It finally added, but in Lion, the process isn't seamless and straightforward, so much so that the ambiguity caused by it is quite dramatic. Adding the first IMAP account was the hardest. The IMAP proxy kicked into action one hour after I set my iCloud account. I had never touched server settings, so the fact that Apple was slow-witted enough to hide the port field in the server configuration window of Lion's Mail until the setup is complete only stirred my confusion. It takes some time for the inner workings to sort out, and then everything goes swimmingly.
Safari feels a bit sluggish, indeed. Session Ticket support "improvable".
Apple Mail (10.7.5).
I checked the certs. All are installed and trusted; however, I have two copies of DigiCert Global Root G2 and DigiCert Global Root G3 (one copy of each cert is under "System", and the other under "System Roots").
Ruby:
launchctl list | grep -i aquaproxy
-->
- 0 Wowfunhappy.AquaProxy.SyncProxiesWithShell.plist
- 0 Wowfunhappy.AquaProxy.Restarter
269 - Wowfunhappy.AquaProxy.IMAP
270 - Wowfunhappy.AquaProxy.HTTPConsole:
Update. Alarm call-off. It finally added, but in Lion, the process isn't seamless and straightforward, so much so that the ambiguity caused by it is quite dramatic. Adding the first IMAP account was the hardest. The IMAP proxy kicked into action one hour after I set my iCloud account. I had never touched server settings, so the fact that Apple was slow-witted enough to hide the port field in the server configuration window of Lion's Mail until the setup is complete only stirred my confusion. It takes some time for the inner workings to sort out, and then everything goes swimmingly.
Last edited:
I added these lines to my hosts file, but now the iTunes Store connects forever and then aborts with a timeout alert. I suspect it's because
Last edited:
odd, mine complains about an unsafe connection, but then i click accept and the store works! might depend on your version though. im on 9.2.1
Then it changes the perspective: every macOS is tethered to its specific realm of IPs in the AppleNet. I don't need port forwarding for the Store to load, but this annoying security prompt will pore my eyes out over it.
Sorry to ask..but, where did you add these lines so that Snow iTunes works? mine when trying to connect it requests the iTunes update.
You edit a file at /etc/hosts. You should know how to perform basic editing operations in such Unix editors as vim and nano. The latter is easier and more intuitive.
When you enter the editor, put the lines from above so that they conform to the order of an IP (dotted numeric sequences) followed by a space followed by a domain name (i.e., init.itunes.apple.com). Mind the bottom bar of the editor's window for the cues to the editing commands. Each of them should be enforced by pressing the ⏎Enter key. So, for example, "Write Out" is, if I recall correctly, the key shortcutCtrl-X Ctrl-W, then Enter, then another one to exit (forgot the shortcut, Ctrl-X perhaps). Done.
Code:
sudo nano /etc/hostsWhen you enter the editor, put the lines from above so that they conform to the order of an IP (dotted numeric sequences) followed by a space followed by a domain name (i.e., init.itunes.apple.com). Mind the bottom bar of the editor's window for the cues to the editing commands. Each of them should be enforced by pressing the ⏎Enter key. So, for example, "Write Out" is, if I recall correctly, the key shortcut
Last edited:
@Wowfunhappy Good morning man !
I don't know if this would be the best post, but would you know how to tell me a way to login messages on the mountain lion?
I was trying to use the Mavericks method but to no avail.
I don't know if this would be the best post, but would you know how to tell me a way to login messages on the mountain lion?
I was trying to use the Mavericks method but to no avail.
As far as I know iMessage has not worked on Mountain Lion for 5+ years, Mavericks is the minimum.
Sad I'm going to keep M -LON, I don't like Maverick, it has a lot of divergences with its interface, an example is calendar, where it has the flat theme instead of the Skeomorphico.
Hi, can you tell me a bit more about your v2ray/shadowsocks setup? Is this a separate app you install, or something you add in system preferences?
I know that third party VPN apps like Viscosity don't respect your system proxy settings. This is a problem with the app, there's not a lot I can do about it.
For VPNs, the solution is to use a VPN protocol that's natively supported by OS X. Would https://privatevpn.com allow you to get past China's firewall? I know this will work alongside AquaProxy if you follow these setup instructions. This does cost money, but it's not too expensive ($2 per month) provided you buy a bunch of months at once.
I install shadowsocks-libev with macports.Run the client and connect to export server,it will create a local socks5 server.Then I can pass the GFW after set the system socks5 proxy.Regular VPNs stick out like a sore thumb in China. GFW kills them fast. Shadowsocks or V2ray servers are much stealthier,faster and cheaper.
I want to try forward all requests to the local SOCKS5 proxy of shadowsocks running at 127.0.0.1:1080.Both of them may be working
Thanks, so everything is local and you are configuring the proxy in System Preferences. I guess OS X can't use both a SOCKS proxy and an HTTPS proxy at the same time.
Is there any way you can configure your socks proxy to pass traffic to AquaProxy (ie localhost and port 6531)?
Edit: Wait, no, that obviously won't work! Because by the time the traffic has left the SOCKS proxy it's no longer on your network (it's on the "export server"), right?
You need to get the traffic to go to AquaProxy first, and then the SOCKS proxy. I'm sorry, I'm not sure how to do that!
I think your best bet is to configure Aqua Proxy in System Preferences (so OS X apps work, even though they won't bypass China's firewall) and then configure Firefox's proxy settings to use your socks proxy (because Firefox doesn't need Aqua Proxy). I'm sorry I don't have a seamless solution here!
Last edited:
Yes of course, everything is open source!
GitHub - Wowfunhappy/AquaProxy: A mitm proxy which can be used to fix https connection issues in legacy versions of Mac OS X.
A mitm proxy which can be used to fix https connection issues in legacy versions of Mac OS X. - Wowfunhappy/AquaProxy
github.com
Building is a little tricky, you need to modify Go as shown in the readme.
If you're able to e.g. add a command line flag to make AquaProxy send traffic to a SOCKS proxy, please send a pull request!
There are some tools like proxychain-ng which support composing proxies in this way, but the way they do that is subtly different than what I think needs to be done here.
One way to compose proxies (for security/privacy, e.g. "I'm behind 7 proxies") is to chain the proxies against each other so they relay end to end. P1 forms a tunnel with P2, with forms a tunnel with P3, then packets go from p1 -> p2 -> p3. In terms of implementation, this is only possible if the proxy supports establishing a blind tunnel (e.g. HTTP CONNECT) as otherwise there is no way to establish a forwarding tunnel.
The normal HTTP GET proxy protocol always specifies the destination and resource in-band, which causes an issue. If the client tries to send to P1
then P1 will send to P2
which is unfortunately invalid (note the leading slash).
SOCKS proxies also support tunnel, so you can chain those. And I think you can also chain an HTTP CONNECT proxy to a socks proxy or vice-versa (assuming your http proxy doesn't restrict the tunnel to port 443 and 80).
Proxychains and other software can support stuff like this, but they all assume blind forwarding proxies whereas aquaproxy needs to actually inspect and MITM the traffic. So if you want to support generic chaining in this fashion, it needs to be updated to track the outgoing hops on your behalf. This is probably overkill though [^1] compared to just adding an option to have aquaproxy route outgoing requests through another proxy.
[^1] In the "simple" case of chaining HTTP proxies, it needs to handle nested HTTP connect. Currently it assumes that after receiving a HTTP CONNECT the client will perform a TLS handshake, it is not expecting client to send another HTTP CONNECT. (probably if you try it as is, it will error out or something since it's an invalid TLS hello). You'd need to identify these and "pass along" all HTTP connects (since the chain can have many hops). The TLS interception should work as-is though, since eventually when the client has established all the CONNECTS it will send a TLS hello, and that can be intercepted and MITM'd as before.
This gets even more complicated for the case of chaining to a socks proxy, since SOCKS is a lower level protocol and the TLS hello will be wrapped in the SOCKS header. So you'd need to implement your own split logic for that. I see there are some tools that can provide an HTTP proxy front for a SOCKS proxy though so if you use that then everything behaves as before. And conceptually it's not too hard to front a SOCKS proxy with an HTTP connect protocol.
All that to say, either aquaproxy just adds a flag for making outgoing connections using a proxy, or you nuke the mosquito by implementing general HTTP proxy chaining support, combine that with proxychains + a http proxy frontend for socks.
One way to compose proxies (for security/privacy, e.g. "I'm behind 7 proxies") is to chain the proxies against each other so they relay end to end. P1 forms a tunnel with P2, with forms a tunnel with P3, then packets go from p1 -> p2 -> p3. In terms of implementation, this is only possible if the proxy supports establishing a blind tunnel (e.g. HTTP CONNECT) as otherwise there is no way to establish a forwarding tunnel.
The normal HTTP GET proxy protocol always specifies the destination and resource in-band, which causes an issue. If the client tries to send to P1
Code:
GET http://p2-addr/http://macrumors.com HTTP/1.1
Code:
GET /https://www.macrumors.com HTTP/1.1SOCKS proxies also support tunnel, so you can chain those. And I think you can also chain an HTTP CONNECT proxy to a socks proxy or vice-versa (assuming your http proxy doesn't restrict the tunnel to port 443 and 80).
Proxychains and other software can support stuff like this, but they all assume blind forwarding proxies whereas aquaproxy needs to actually inspect and MITM the traffic. So if you want to support generic chaining in this fashion, it needs to be updated to track the outgoing hops on your behalf. This is probably overkill though [^1] compared to just adding an option to have aquaproxy route outgoing requests through another proxy.
[^1] In the "simple" case of chaining HTTP proxies, it needs to handle nested HTTP connect. Currently it assumes that after receiving a HTTP CONNECT the client will perform a TLS handshake, it is not expecting client to send another HTTP CONNECT. (probably if you try it as is, it will error out or something since it's an invalid TLS hello). You'd need to identify these and "pass along" all HTTP connects (since the chain can have many hops). The TLS interception should work as-is though, since eventually when the client has established all the CONNECTS it will send a TLS hello, and that can be intercepted and MITM'd as before.
This gets even more complicated for the case of chaining to a socks proxy, since SOCKS is a lower level protocol and the TLS hello will be wrapped in the SOCKS header. So you'd need to implement your own split logic for that. I see there are some tools that can provide an HTTP proxy front for a SOCKS proxy though so if you use that then everything behaves as before. And conceptually it's not too hard to front a SOCKS proxy with an HTTP connect protocol.
All that to say, either aquaproxy just adds a flag for making outgoing connections using a proxy, or you nuke the mosquito by implementing general HTTP proxy chaining support, combine that with proxychains + a http proxy frontend for socks.