Siri en MacOS detrás de un proxy corporativo

Gestiono un proxy Squid para mi organización y cuando intento utilizar Siri en Sierra, se registran las siguientes entradas de registro:

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

No estoy del todo seguro de lo que está solicitando, así que es hora de sacar el martillo tcpdump, supongo. Voy a informar si tengo más ideas.

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

Parece que Siri no está usando una URL válida cuando solicita a través de un proxy. Aquí están las cabeceras HTTP de Squid después de que se intente una conexión con Siri:

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

Los detalles del mensaje de error (enviado desde Squid pero nunca visto por el usuario) son:

Se ha encontrado un error de solicitud no válida al intentar procesar la solicitud:

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

Algunos posibles problemas son:

• Método de solicitud ausente o desconocido.
• Falta el identificador HTTP (HTTP/1.0).
• La solicitud es demasiado grande.
• Falta la longitud del contenido en las solicitudes POST o PUT.
• Carácter ilegal en el nombre de host; los guiones bajos no están permitidos.
• HTTP/1.1 Esperar: se está pidiendo la función desde un software HTTP/1.0.

Así que - parece que hay más tcpdump-hammer en mi futuro mientras trato de encontrar lo que este requst original parece (donde va etc). Permanezcan atentos.

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

El problema es que Siri utiliza TCP/443 pero no utiliza HTTPS. En consecuencia, un proxy HTTP como Squid se ahoga en estas conexiones. La buena noticia es que he identificado que las conexiones salientes de Siri están resolviendo un registro A para origin.guzzoni-apple.com.akadns.net y luego conectarse a él en el puerto 443. En este punto se inicia un handshake TLS y el resto está encriptado. Así que, gracias Apple por encriptarlo, pero FU por usar un puerto reservado para el tráfico no HTTPS. En serio - ¡¿WTF?!

He aquí una solución

He husmeado en muchos ( muchos ) consultas DNS y parece que todas se resuelven origin.guzzoni-apple.com.akadns.net en el 17.252.0.0/16 gama de direcciones: se trata de una porción de la gama más amplia de Apple 17.0.0.0/8 gama. Esto debería permitirle enviar cualquier cosa destinada a 17.252.0.0 directo (a través de la configuración del proxy o del PAC/WPAD). Desafortunadamente, esto también puede engullir otro tráfico que no quieres que pase por tu proxy también :-/

Hasta que Apple no decida utilizar un protocolo HTTPS real para Siri en Sierra o, utilizar un puerto diferente (¡¡¡a diferencia del actual secuestro de TCP/443!!!), estamos bastante jodidos.