Siri en macOS detrás de un proxy corporativo

Me encuentro con un problema por el que Siri no puede conectarse a sus serveres desde detrás de nuestra connection proxy corporativa. Lo que es interesante es que este no es un problema en nuestros iPhones detrás del mismo proxy.

¿Algunas ideas?

  • ¿Debo save los files .dmg en mi computadora?
  • ¿Hay alguna manera de preservar el formatting de las imágenes en línea en los correos electrónicos en Outlook para Mac?
  • Problemas con la actualización de security de Apple 2011-005 (León)?
  • OSX: window de Affix para no moverse en el interruptor de espacios
  • Al intentar save un .jpg o .jpeg, ¿Safari intenta forzar la extensión .dms hasta el final?
  • Cómo instalar OS X 10.9 en una nueva Mac mini cargada con OS X 10.11
  • Siri dice "habla como quieras"; ¿Hay algo mal con mi teléfono?
  • Condiciones para la reparación en Apple Store
  • ¿Cómo puedo evitar que Finder me avise cada vez que elimino algo de una unidad de networking?
  • cambiar el foco entre dos vistas en vista dividida
  • localhost / userdir en macOS Sierra
  • ¿Qué es "fotoanálisis" y por qué usa el 77% de mi CPU?
  • 5 Solutions collect form web for “Siri en macOS detrás de un proxy corporativo”

    Administro un proxy Squid para mi organización y cuando trato de usar Siri en Sierra, se registran las siguientes inputs de logging:

    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 tcpdump-hammer, supongo. 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 los encabezados HTTP de Squid después de intentar una connection 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 en el post de error (enviados desde Squid pero nunca vistos por el usuario) son:

    Se encontró un error de request inválida al intentar procesar la request:

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

    Algunos posibles problemas son:

    • Método de request faltante o desconocido.
    • Falta el identificador HTTP (HTTP / 1.0).
    • La request es demasiado grande.
    • Content-Length que falta para las requestes POST o PUT.
    • Carácter ilegal en el nombre de host; los subrayados no están permitidos.
    • HTTP / 1.1. Espera: la function se está solicitando desde un software HTTP / 1.0.

    Entonces, parece que habrá más tcpdump-hammer en mi futuro cuando trato de encontrar cómo se ve este requisito original (hacia dónde va, etc.). Manténganse al tanto.

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

    El problema es que Siri usa TCP / 443 pero no usa HTTPS. En consecuencia, un proxy HTTP como Squid se ahogará en estas conexiones. La buena noticia es que identifiqué que las conexiones salientes de Siri están resolviendo un logging A para origin.guzzoni-apple.com.akadns.net y luego se conectan a él en el puerto 443. En este punto, inicia un saludo de TLS y el rest está encriptado Entonces, gracias a Apple por encriptarlo, pero a FU por usar un puerto reservado para tráfico no HTTPS. En serio, ¿WTF?

    Aquí hay una solución

    He buscado muchas ( muchas ) consultas de DNS y parece que todas resuelven origin.guzzoni-apple.com.akadns.net en el 17.252.0.0/16 direcciones 17.252.0.0/16 – esta es una porción del 17.0.0.0/8 más amplio de 17.0.0.0/8 distancia. Esto debería permitirle enviar cualquier cosa destinada a 17.252.0.0 directo (ya sea a través de proxy config o PAC / WPAD). Desafortunadamente, esto también puede engullir otro tráfico que no desea omitir su proxy también: – /

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

    No tanto una respuesta como un "por dónde empezar a search" …

    Hay una list completa de numbers de puerto utilizados por Apple en
    Apple KB: puertos TCP y UDP utilizados por los productos de software de Apple
    [Demasiado para copyr aquí]

    También puede abrir prácticamente todo el espacio de direcciones 17.xxx, ya que todo es propiedad de Apple.

    Afirma que Siri solo necesita el puerto 443, https / SSL [que me imagino que estaría abierto de todos modos]

    Puedo confirmar los hallazgos de James en mi organización: Siri (macOS) solo funciona con el proxy desactivado. Estamos usando un producto proxy diferente (a través de un file PAC, FYI), pero con los mismos resultados. Probado usando el lanzamiento público de macOS Sierra 10.12.2 (16C68).

    @Tetsujin – A pesar del "8 de enero de 2017", Apple no lo ha actualizado para include "Siri (macOS)"; actualmente solo especifican "Siri (iOS)". Parafraseando el comentario de James, "este no es el Siri de tu iPhone".

    Además, si sus loggings de Squid son correctos y origin.guzzoni-apple.com.akadns.net es lo que Siri (macOS) usa; entonces la exención de comodín para el 17.0.0.0/8 de Apple sería irrelevante (por el dominio "akadns.net").

    Me las arreglé para hacerlo funcionar al poner privoxy frente al calamar. No tengo idea de por qué funciona, pero te funciona de manera confiable. Puedo compartir files de configuration si lo desea. Probé con WPAD / PAC anteriormente, pero Siri no cumple y, de todos modos, sigue con el calamar.

    Encontré esta solución para el file pac:

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

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

    Loving Apple Products like poisoning (iPhone, iPad, iMac, Macbook, iWatch).