I'm running into a an issue where Siri can't connect to her servers from behind our corporate proxy connection. What's interesting is that this isn't an issue on our iPhones behind the same proxy.
Ask Different is a question and answer site for power users of Apple hardware and software. It only takes a minute to sign up.Sign up to join this community
I manage a Squid proxy for my organisation and when I try to use Siri in Sierra, the following log entries are recorded:
1474540244.610 0 macos-sierra-host.local TAG_NONE/400 4410 NONE error:invalid-request - HIER_NONE/- text/html
Not entirely sure what it is requesting, so time to break out the tcpdump-hammer I guess. I'll report back if I have any more insights.
EDIT 1 - 22-Sep-2016 10:58 UTC
Looks like Siri isn't using a valid URL when requesting via a proxy. Here's the HTTP headers from Squid after a Siri connection is attempted:
HTTP/1.1 400 Bad Request Server: squid/3.5.20 Mime-Version: 1.0 Date: Thu, 22 Sep 2016 10:42:01 GMT Content-Type: text/html;charset=utf-8 Content-Length: 4064 X-Squid-Error: ERR_INVALID_REQ 0 Vary: Accept-Language Content-Language: en X-Cache: MISS from proxy.local Via: 1.1 proxy.local (squid/3.5.20) Connection: close
The details in the error message (sent from Squid but never seen by the user) are:
Invalid Request error was encountered while trying to process the request:
&# 22;&# 3;&# 1;
Some possible problems are:
- Missing or unknown request method.
- Missing HTTP Identifier (HTTP/1.0).
- Request is too large.
- Content-Length missing for POST or PUT requests.
- Illegal character in hostname; underscores are not allowed.
- HTTP/1.1 Expect: feature is being asked from an HTTP/1.0 software.
So - looks like some more tcpdump-hammer in my future as I try to find what this original requst looks like (where it's going etc). Stay tuned.
EDIT 2 - 22-Sep-2016 11:16 UTC
The problem is Siri is using TCP/443 but not using HTTPS. Consequently, a HTTP proxy like Squid will choke on these connections. The good news is I've identified the outbound connections from Siri are resolving an A record for
origin.guzzoni-apple.com.akadns.net and then connecting to it on port 443. At this point it initiates a TLS handshake and the rest is encrypted. So, thanks Apple for encrypting it, but FU for using a reserved port for non-HTTPS traffic. Seriously - WTF?!
Here's a solution
I've poked around many (many) DNS queries and it seems they all resolve
origin.guzzoni-apple.com.akadns.net in the
188.8.131.52/16 address range - this is a slice of Apple's broader
184.108.40.206/8 range. This should allow you to send anything destined for
220.127.116.11 direct (either via proxy config or PAC/WPAD). Unfortunately, this may also gobble up other traffic that you don't want bypassing your proxy too :-/
Until Apple decide to use a real HTTPS protocol for Siri on Sierra or, use a different port (unlike the current hijacking of TCP/443!!!), we're pretty much screwed.
Not so much an answer as a "where to start looking"...
There's a comprehensive list of port numbers used by Apple at
Apple KB : TCP and UDP ports used by Apple software products
[too much to copy here]
You can also pretty much open the entire 17.x.x.x address space, as it's all owned by Apple.
It claims Siri only needs port 443, https/SSL [which I'd imagine would be open anyway]
I can confirm James' findings at my org: Siri (macOS) only works with proxy disabled. We're using a different proxy product (via PAC file, FYI), but same results. Tested using public release of macOS Sierra 10.12.2 (16C68).
@Tetsujin - Despite the "Jan 8, 2017", Apple has not updated it to include "Siri (macOS)"; they currently only specify "Siri (iOS)". To paraphrase James' comment, "this is not your iPhone's Siri".
Also, if his Squid logs are correct and
origin.guzzoni-apple.com.akadns.net is what Siri (macOS) uses; then the wildcard exemption for Apple's 18.104.22.168/8 would be moot (per the "akadns.net" domain).
Found this solution for the pac file:
if ( (shExpMatch(url, "*guzzoni.apple.com*")) || (shExpMatch(url, "*.guzzoni-apple.com.akadns.net*")) ) return "DIRECT";