El sitio web de repente no se abre en dispositivos Safari e iOS

Question

Tengo este sitio web que funcionaba bien hasta hace poco. Ahora los usuarios informan que no se abre en sus iPhones y iPads.

No importa qué navegador pruebes en iOS, simplemente no funcionará. Además, no se abre en Safari cuando se navega en una máquina Mac. Sin embargo, otros navegadores funcionan bien (solo Mac OSX, no iOS).

Aquí está la configuración del servidor:

DigitalOcean + Ubuntu 18.04 + Nginx + PHP 7.3 (Laravel) + Let's Encrypt SSL + HTTP2 activado

Antes de seguir explicando, quiero mencionar que usando el mismo tipo de configuración anterior, tengo otro servidor que funciona bien y es accesible desde todos los dispositivos. Son casi idénticos (en términos de configuración y configuración), aparte del nombre de dominio y la dirección IP, obviamente.

Otra pequeña información adicional que creo que vale la pena mencionar es que mis usuarios se encuentran en Irán.

Aquí hay una lista de cosas que he verificado:

• Se puede acceder al dominio mediante el comando ping desde iOS y Mac.
• La dirección IP en sí también es accesible y se puede usar para navegar por el sitio; solo mostrará una advertencia de "certificado SSL no válido".
• Todos los DNS que se utilizaron para el dominio son aptos para hacer ping desde iOS y Mac.
• Si se utiliza una conexión VPN, se puede acceder al sitio. Lo cual es realmente extraño porque técnicamente todo es accesible, el dominio, la ip y el dns.
• Además de utilizar una VPN, también se puede acceder al sitio si SSL está completamente desactivado/desactivado.
• Se puede acceder a otros sitios web públicos que utilizan Let's Encrypt SSL. Entonces no puede ser un problema de Let's Encrypt.

Esto es lo que he probado hasta ahora:

• Toneladas de búsquedas en Google. Incluso me encontré con un usuario con el mismo tipo de problema enaquíyaquíyaquí
• Intenté deshabilitar HTTP2.
• Revisé dos veces la configuración de mi firewall e incluso intenté deshabilitarlo.
• Intenté desactivar GZIP.
• Hice una prueba SSL en ssllabs.com y no muestra ningún problema y es idéntico a mi servidor en funcionamiento.
• Intenté usarlo keepalive_disable "safari"en la configuración de nginx
• Intenté intercambiar ssl_protocolsvalores, como aceptar solo TLSv1.3 o eliminar TLSv1.0.
• Intenté usarssl_session_cache
• Intenté cambiar ssl_ecdh_curvea autoysecp384r1
• Intenté cambiar ssl_ciphersa HIGH:!aNULL:!MD5;yEECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
• Intenté cambiar ssl_session_ticketsa onyoff
• Intenté usarStrict-Transport-Security
• Intenté comentar /etc/letsencrypt/options-ssl-nginx.conflo que utiliza certbot
• Probé diferentes configuraciones de redireccionamiento de HTTP a HTTPS
• Me aseguré de usar la pestaña privada al realizar la prueba para asegurarme de no estar viendo una especie de intento defectuoso en caché para acceder al sitio.
• Realicé el servicio de recarga y reinicio de nginx cada vez que realizaba un cambio en los archivos de configuración.
• Hice muchas cosas sudo rebootspara asegurarme de que no fuera un simple problema de reinicio.

Como último recurso, incluso me tomé la molestia de reinstalar el sistema operativo desde cero y configurar el servidor nuevamente. Todavía no funciona.Y no, no copié mis archivos de configuración, hice todos los comandos manualmente y modifiqué los archivos de configuración cuidadosamente para asegurarme de no traer ningún problema de la configuración anterior. Esto también significa que hice una nueva solicitud SSL de Let's Encrypt (usando cerbot). Aunque no sé si te generan uno nuevo o te envían el de la última vez.

EDITAR 1: Quiero incluir un pensamiento aleatorio aquí. Realmente no sé acerca de las redes avanzadas, pero tal vez algo de los cortafuegos de censura de Irán esté interfiriendo con la conexión SSL y eso haga que los dispositivos Apple no puedan establecer la conexión. Escuché que Apple es estricto a su manera y requiere una conexión SSL específica a diferencia de Chrome y Firefox. esos 2 pueden ignorar un pequeño error, pero los dispositivos Apple no.

EDITAR 2: Revisé Safari mientras Wireshark estaba tocando. Parece que solo se intercambian unos pocos paquetes, sin importar lo que haga. También parece que Safari está usando TLSv1.0 aunque lo deshabilité en la configuración de nginx. Realmente no sé cómo desactivarlo por completo para que Safari ni siquiera intente usarlo para comunicarse con el servidor.

EDITAR 3: Intenté usar un SSL diferente (usando el programa de prueba gratuito de SSL de 3 meses de Comodo) y el problema persiste... Leí que algunas personas dijeron que resolvieron algunos problemas similares después de cambiar su SSL. No sé por qué no me funciona.

EDITAR 4: Decidí cambiar los servidores DNS del dominio para ver si se trata de un problema de DNS. No sé por qué ni cómo, pero después de cambiarlos, Safari pudo cargar el sitio brevemente. Pero después de un tiempo dejó de funcionar nuevamente.

EDITAR 5: No tuve suerte al deshabilitar códigos de secuencias de comandos externos en mi sitio, como Google Analytics (porque su servicio está un poco bloqueado para los iraníes). Nuevamente, leí informes de personas que implicaban que algunos solucionaron su problema desactivando scripts externos.

EDITAR 6: Estoy empezando a creer que esto no es un problema de configuración de red o del servidor de mi parte. Realmente parece que un tercero interfiere con la solicitud. No sé acerca de Apple y cómo maneja las redes, pero creo que las negociaciones de conexión/paqueteo de Apple están provocando algún tipo de señal de alerta, por así decirlo, y eso hace que la censura/cortafuegos iraní cancele la conexión del cliente.

EDITAR 7: Incluso cambié el centro de datos del servidor, con una nueva dirección IP. el problema sigue existiendo :(

EDITAR 8: Este es el /var/log/nginx/error.logresultado cuando está configurado en debug. Muestra estas líneas cuando inicio una solicitud desde un cliente Safari.

Intenté deshabilitar php fpm para asegurarme de que no sea un problema de cuello de botella de php. También intenté modificar algunos parámetros aleatorios, como aumentar net.core.somaxconno 1024aumentar backloglos archivos de configuración de php fpm. Además, cuando observo el uso del sistema, htoptodo parece normal, no hay picos de uso de la CPU y ningún proceso específico salta a la parte superior de la lista.

EDITAR 9: Cambié Nginx a Apache2 para comprobar si se trata de un problema del servidor web. Bueno, no lo fue.

Answer 1

Dado que dudas sobre el proxy entre tú y el sitio web, ¿puedes evitarlo usando la opción -L en ssh? Proporcionará un túnel seguro entre usted y su sitio web que el proxy no puede modificar.

Por ejemplo, ejecute esto en su escritorio: ssh -L 2222:127.0.0.1:443[correo electrónico protegido]

Una vez que este comando haya iniciado sesión en su servidor, inicie el navegador en el mismo escritorio parahttps://127.0.0.1:2222

Si ahora ve su sitio y su certificado SSL, todo está configurado correctamente: hay alguien en el medio alterando su conexión SSL cuando no está usando el túnel.

Answer 2

Iencontróuna solución temporal a mi problema. ¡Acabo de mover el servidor a un hosting/centro de datos diferente!

Actualizar:En realidad, el problema volvió a aparecer después de unos meses... Realmente no sé qué problema técnico está causando el problema o cómo solucionarlo.

Actualización 2:Hablé con un experto en redes de TI y me dijeron que el problema en realidad se debe a que las reglas gubernamentales de firewall detectan mi nombre de dominio (censura falsa/incorrecta) y que no importa qué configuración de servidor web o alojamiento web utilice, simplemente se sigue bloqueando. por cortafuegos fuera de mi alcance.

Answer 3

Podría ser simplemente el certificado, ¿tienes SubjectAlternativeName configurado correctamente? Está obsoleto el uso únicamente de SubjectName para el nombre DNS. ¿Utiliza fijación de certificados, grapado OSCP, HSTP y otras configuraciones TLS relativamente nuevas? Eso podría causar problemas en las redes reguladas.

Algunos usuarios de Internet necesitan utilizar un proxy con inspección SSL. Muchos entornos corporativos utilizan productos similares a IronPort o Bluecoat para detectar canales encubiertos y malware como parte de su política de seguridad. La forma de hacer esto se originó en un artículo de la revista clandestina Phrack 76. Se reduce a una configuración simple en la que cada cliente tiene un certificado raíz de CA adicional del proxy en el que confía, el proxy a su vez reinicia las conexiones en nombre de Cada cliente, "abriendo el SSL" por parte del MIT, países como Irán y China monitorean Internet en general. Debido a esto, no hay PFS y pueden fallar varias cosas que dependen de que el cliente verifique la criptografía de los servidores, ya que se altera o incluso se elimina por completo el SSL. Si no le importa, puede degradar la configuración del certificado de su servidor a "calidad de exportación" eliminando las opciones mencionadas.

Answer 4

La respuesta de @ austin-dixon va por buen camino. Esa prueba tendría que realizarse desde el mismo país en el que se encuentran los usuarios, lo que puede no ser una opción si aún no estás en ese país.

Es posible que pueda al menos validar la configuración utilizando la prueba Qualys SSL enhttps://www.ssllabs.com/ssltest/. La puntuación de la letra no importa en este caso, simplemente desplácese hacia abajo hasta Simulación de apretón de manos y vea cómo se espera que funcionen los dispositivos Apple en circunstancias normales.

De cualquier manera, eso simplemente confirma lo que ya sospechas, que hay algo entre esos usuarios y el sitio. No hay muchas formas para que un desarrollador solucione esa situación excepto deshabilitar HTTPS por completo. Es posible que el hombre del medio requiera algunos de los conjuntos de cifrado más débiles o versiones de TLS inferiores a las que está configurado el servidor, pero no sabría cuáles sugerir en ese caso.