Siri on macOS behind a corporate proxy

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.

Any ideas?

Solution 1:

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 17.252.0.0/16 address range - this is a slice of Apple's broader 17.0.0.0/8 range. This should allow you to send anything destined for 17.252.0.0 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.

Solution 2:

Found this solution for the pac file:

if (
   (shExpMatch(url, "*guzzoni.apple.com*")) ||
   (shExpMatch(url, "*.guzzoni-apple.com.akadns.net*"))
)
return "DIRECT";

Source: http://blog.mansshardt.net/siri-ios-macos-hinter-squid-proxy-zum-laufen-bringen/