O site de repente não abre em dispositivos Safari e iOS

Question

Eu tenho este site que estava funcionando bem até recentemente. Agora os usuários estão relatando que ele não abre em seus iPhones e iPads.

Não importa qual navegador você experimente no iOS, ele simplesmente não funcionará. Além disso, não abre no Safari quando navegado em uma máquina Mac. Outros navegadores funcionam bem (apenas Mac OSX, não iOS).

Aqui está a configuração do servidor:

DigitalOcean + Ubuntu 18.04 + Nginx + PHP 7.3 (Laravel) + Vamos criptografar SSL + HTTP2 ativado

Antes de explicar melhor, quero mencionar que usando o mesmo tipo de configuração acima, tenho outro servidor que está funcionando bem e acessível a partir de todos os dispositivos. Eles são quase idênticos (em termos de configuração e configuração), exceto pelo nome de domínio e endereço IP, obviamente.

Outra pequena informação extra que acho que vale a pena mencionar é que meus usuários estão localizados no Irã.

Aqui está uma lista de coisas que verifiquei:

• O domínio pode ser acessado usando o comando ping do iOS e Mac.
• O próprio endereço IP também é acessível e pode ser usado para navegar no site, apenas mostrará um aviso de “certificado SSL inválido”.
• Os DNS usados ​​para o domínio são todos capazes de executar ping no iOS e no Mac.
• Se uma conexão VPN for usada, o site poderá ser acessado. O que é muito estranho porque tudo é tecnicamente acessível, o domínio, o ip e o dns.
• Além de usar uma VPN, o site também pode ser acessível se o SSL estiver completamente desligado/desativado.
• Outros sites públicos que usam Let's Encrypt SSL estão todos acessíveis. Portanto, não pode ser um problema do Let's Encrypt.

Aqui está o que eu tentei até agora:

• Toneladas de pesquisa no Google. Eu até encontrei um usuário com o mesmo tipo de problema emaquieaquieaqui
• Eu tentei desativar o HTTP2.
• Verifiquei novamente as configurações do meu firewall e até tentei desativá-lo.
• Eu tentei desativar o GZIP.
• Fiz um teste SSL em ssllabs.com e não apresentou problemas e é idêntico ao meu servidor em funcionamento.
• Tentei usar keepalive_disable "safari"na configuração do nginx
• Tentei trocar ssl_protocolsvalores, como aceitar apenas TLSv1.3 ou descartar TLSv1.0
• Tentei usarssl_session_cache
• Tentei mudar ssl_ecdh_curvepara autoesecp384r1
• Tentei mudar ssl_cipherspara HIGH:!aNULL:!MD5;eEECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
• Tentei mudar ssl_session_ticketspara oneoff
• Tentei usarStrict-Transport-Security
• Tentei comentar /etc/letsencrypt/options-ssl-nginx.confque é usado pelo certbot
• Tentei diferentes configurações de redirecionamento de HTTP para HTTPS
• Certifiquei-me de usar a guia privada durante o teste para ter certeza de que não estou vendo uma espécie de tentativa defeituosa em cache de acessar o site.
• Eu fiz o serviço nginx recarregar e reiniciar sempre que fazia uma alteração nos arquivos de configuração.
• Fiz muito sudo rebootspara garantir que não fosse um simples problema de reinicialização.

Como último recurso, até tive o trabalho de reinstalar o sistema operacional do zero e configurar o servidor novamente. Ainda não funciona.E não, eu não copiei meus arquivos de configuração, fiz todos os comandos manualmente e modifiquei os arquivos de configuração com cuidado para ter certeza de não trazer nenhum problema da configuração anterior. Isso também significa que fiz uma nova solicitação SSL do Let's Encrypt (usando cerbot). Embora eu não saiba se eles geram um novo ou enviam o da última vez.

EDITAR 1: Quero lançar um pensamento aleatório aqui. Eu realmente não sei sobre redes avançadas, mas talvez algo dos firewalls de censura do Irã esteja interferindo na conexão SSL e fazendo com que os dispositivos Apple não consigam estabelecer a conexão. Ouvi dizer que a Apple é rigorosa à sua maneira e requer uma conexão SSL específica, diferentemente do Chrome e do Firefox. esses 2 podem ignorar um pequeno erro, mas os dispositivos Apple não.

EDITAR 2: verifiquei o Safari enquanto o Wireshark estava tocando. Parece que apenas alguns pacotes são trocados, não importa o que eu faça. Além disso, parece que o Safari está usando TLSv1.0, embora eu o tenha desabilitado na configuração do nginx. Eu realmente não sei como desligá-lo completamente para que o Safari nem tente usá-lo para se comunicar com o servidor.

EDITAR 3: Tentei usar um SSL diferente (usando o programa de teste SSL gratuito de 3 meses da comodo) e o problema ainda persiste... Li algumas pessoas dizendo que resolveram alguns problemas semelhantes após alterar o SSL. Não sei por que não está funcionando para mim.

EDITAR 4: Decidi alterar os servidores DNS do domínio para ver se é um problema de DNS. Não sei por que e como, mas depois de alterá-los, o Safari pôde carregar o site brevemente. Mas depois de algum tempo parou de funcionar novamente.

EDITAR 5: Não tive sorte em desabilitar códigos de script externos em meu site, como o Google Analytics (porque o serviço deles está meio bloqueado para iranianos). Mais uma vez, li relatos de pessoas sugerindo que alguns resolveram o problema desativando scripts externos.

EDITAR 6: Estou começando a acreditar que este não é um problema de rede ou configuração do servidor da minha parte. Realmente parece que um terceiro está interferindo na solicitação. Não sei sobre a Apple e como ela lida com a rede, mas acho que as negociações de conexão/pacote da Apple estão causando algum tipo de bandeira vermelha, por assim dizer, e isso faz com que a censura/firewall iraniana interrompa a conexão do cliente.

EDITAR 7: Até mudei o datacenter do servidor, com um novo endereço IP. o problema ainda existe :(

EDITAR 8: Esta é a /var/log/nginx/error.logsaída quando está definida como debug. Ele mostra essas linhas quando inicio uma solicitação de um cliente Safari.

Eu tentei desabilitar o php fpm para ter certeza de que não é um problema de gargalo do php. Também tentei ajustar alguns parâmetros aleatórios, como aumentar net.core.somaxconnou 1024aumentar backlogos arquivos de configuração do php fpm. Além disso, quando observo o sistema usando htoptudo, parece normal, sem picos de uso da CPU e nenhum processo específico saltando para o topo da lista.

EDITAR 9: troquei o Nginx pelo Apache2 para verificar se é um problema do servidor web. Bem, não foi.

Answer 1

Já que você duvida do proxy entre você e o site, você pode ignorá-lo usando a opção -L no ssh? Ele fornecerá um túnel seguro entre você e seu site que não pode ser alterado pelo proxy.

Por exemplo, execute isto em sua área de trabalho: ssh -L 2222:127.0.0.1:443[e-mail protegido]

Depois que este comando estiver conectado ao seu servidor, abra o navegador na mesma área de trabalho parahttps://127.0.0.1:2222

Se você vir seu site e seu certificado SSL, tudo está configurado corretamente - há alguém no meio alterando sua conexão SSL quando você não está usando o túnel.

Answer 2

EUencontradouma solução temporária para o meu problema. Acabei de mudar o servidor para uma hospedagem/datacenter diferente!

Atualizar:Na verdade, o problema reapareceu depois de alguns meses... Eu realmente não sei qual problema técnico está causando o problema ou como corrigi-lo.

Atualização 2:Conversei com um especialista em redes de TI e eles me disseram que o problema, na verdade, depende de regras de firewall do governo que detectam meu nome de domínio (censura falsa/errada) e não importa qual configuração de servidor web ou hospedagem web eu uso, ele simplesmente fica bloqueado por firewalls fora do meu alcance.

Answer 3

Pode ser apenas o certificado. Você tem o SubjectAlternativeName configurado corretamente? Somente o uso de SubjectName para o nome DNS está obsoleto. Você usa fixação de certificado, grampeamento OSCP, HSTP e outras configurações TLS relativamente novas? Isso pode causar problemas em redes regulamentadas.

Alguns usuários da Internet precisam usar um proxy com inspeção SSL. Muitos ambientes corporativos usam produtos semelhantes ao IronPort ou Bluecoat para detectar canais secretos e malware como parte de sua política de segurança. A maneira de fazer isso originou-se de um artigo da revista clandestina Phrack 76. Tudo se resume a uma configuração simples onde cada cliente possui um certificado raiz CA adicional do proxy em que confia, o proxy, por sua vez, reinicia as conexões em nome de cada cliente, “abrindo o SSL” pelo MIT, países como o Irã e a China monitoram a Internet em geral. Devido a isso não há PFS, e várias coisas podem falhar que dependem do cliente verificar a criptografia dos servidores, porque ela está alterada ou o SSL foi até completamente removido. Se você não se importa com isso, você pode fazer o downgrade das configurações do certificado do servidor para "qualidade de exportação" removendo as opções mencionadas.

Answer 4

A resposta de @austin-dixon está no caminho certo. Esse teste teria que ser feito no mesmo país em que os usuários estão, o que pode não ser uma opção se você ainda não estiver nesse país.

Você pode pelo menos validar a configuração usando o teste Qualys SSL emhttps://www.ssllabs.com/ssltest/. A pontuação das letras não importa neste caso, basta rolar para baixo até Handshake Simulation e ver como se espera o desempenho dos dispositivos Apple em circunstâncias normais.

De qualquer forma, isso apenas confirma o que você já suspeita: que há algo entre esses usuários e o site. Não há muitas maneiras de um desenvolvedor contornar essa situação, exceto desabilitar completamente o HTTPS. É possível que o intermediário exija alguns dos conjuntos de criptografia mais fracos ou versões TLS inferiores às para as quais o servidor está configurado, mas eu não saberia quais sugerir nesse caso.