Siri sur macOS derrière un proxy d'entreprise

Je gère un proxy Squid pour mon organisation et lorsque j'essaie d'utiliser Siri dans Sierra, les entrées de journal suivantes sont enregistrées :

1474540244.610      0 macos-sierra-host.local TAG_NONE/400 4410 NONE error:invalid-request - HIER_NONE/- text/html

Je ne suis pas tout à fait sûr de ce qu'il demande, donc c'est le moment de sortir le marteau tcpdump je suppose. Je reviendrai si j'ai d'autres informations.

MODIFICATION 1 - 22-Sep-2016 10:58 UTC

On dirait que Siri n'utilise pas une URL valide lorsqu'il demande via un proxy. Voici les en-têtes HTTP de Squid après une tentative de connexion Siri :

HTTP/1.1 400 Requête incorrecte
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

Les détails dans le message d'erreur (envoyé par Squid mais jamais vu par l'utilisateur) sont :

Une erreur de requête invalide a été rencontrée lors de la tentative de traitement de la demande :

&# 22;&# 3;&# 1;

Quelques problèmes possibles sont :

• Méthode de requête manquante ou inconnue.
• Identifiant HTTP manquant (HTTP/1.0).
• La requête est trop grande.
• Longueur du contenu manquante pour les requêtes POST ou PUT.
• Caractère illégal dans le nom d'hôte ; les tirets bas ne sont pas autorisés.
• La fonction Expect: HTTP/1.1 est demandée à partir d'un logiciel HTTP/1.0.

Donc - il semble que je vais devoir utiliser encore plus de tcpdump pour essayer de trouver à quoi ressemble cette demande originale (où elle va, etc.). Restez à l'écoute.

MODIFICATION 2 - 22-Sep-2016 11:16 UTC

Le problème est que Siri utilise TCP/443 mais n'utilise pas HTTPS. Par conséquent, un proxy HTTP comme Squid va bloquer ces connexions. La bonne nouvelle c'est que j'ai identifié que les connexions sortantes de Siri résolvent un enregistrement A pour origin.guzzoni-apple.com.akadns.net puis se connectent à celui-ci sur le port 443. À ce stade, il initie un handshake TLS et le reste est chiffré. Donc, merci Apple de l'avoir chiffré, mais pour utiliser un port réservé pour du trafic non-HTTPS. Sérieusement - quoi ?!

Voici une solution

J'ai fouillé dans de nombreuses (beaucoup) requêtes DNS et il semble qu'elles résolvent toutes origin.guzzoni-apple.com.akadns.net dans la plage d'adresses 17.252.0.0/16 - c'est une partie de la plage plus large d'Apple 17.0.0.0/8. Cela devrait vous permettre d'envoyer tout ce qui est destiné à 17.252.0.0 directement (soit via une configuration de proxy, soit PAC/WPAD). Malheureusement, cela risque également de capturer d'autres trafics que vous ne voulez pas contourner votre proxy aussi :-/

Jusqu'à ce qu'Apple décide d'utiliser un protocole HTTPS réel pour Siri sur Sierra ou d'utiliser un port différent (contrairement à l'actuel détournement de TCP/443 !!!), on est pratiquement fichus.