Diferenças entre o IE6 e posterior em relação ao manuseio de HTTPS

1

Direto para a pergunta: Alguma coisa tem um bom recurso para detalhes do que mudou entre o IE6 e o IE7, especificamente que poderia tornar o IE6 incapaz de se conectar a recursos HTTPS em servidores da Web baseados em IIS7 (Windows 2008)? Nossa suposição é que os servidores estão aceitando apenas versões / variantes de protocolo mais recentes do que o IE6 não pode lidar, mas não podemos encontrar onde isso pode ser configurado.

Para recortar um conto:

Achamos um problema com alguns servidores da Web executando um aplicativo cliente. Como uma pilha de alterações de diretivas locais e outras configurações do Registro foram alteradas como resultado do cliente ter revisores de penetração revisando a configuração, o Internet Explorer 6 se recusou a se conectar ao site via HTTPS (o erro relatado é o padrão "não é possível localizar servidor ou Erro de DNS "mensagem". IE7 e IE8 são bons, assim como outros navegadores que tentamos (FireFox no Windows, FF no Ubuntu, links, ...) embora isso seja um ponto discutível, já que muitos usuários usam mais ou menos exclusivamente o IE6. O IE6 está feliz em acessar os mesmos recursos nas mesmas instalações do IIS via HTTP.

Examinando as mudanças documentadas, não descobrimos nada de óbvio que tenha feito isso, e mesmo aplicando todas as alterações em um de nossos servidores de teste não cria o problema, uma das mudanças foi em relação a puxar em políticas não locais, então eu suspeito que é daí que vem o problema.

Eu não consegui encontrar nenhuma informação útil pesquisando (muitos sites documentando como executar a configuração SSL mais básica no servidor web e obter certificados confiáveis para os aplicativos clientes e tal, mas nenhuma palavra aparentemente relacionada a isso questão), nem nada óbvio saltou para mim durante a digitalização através da documentação de políticas locais para o servidor web da Microsoft.

Dizer ao cliente para atualizar do IE6, infelizmente, não é uma opção. Eu estou relutante em dizer-lhes para simplesmente reconstruir o (s) servidor (es) da web e ser mais cuidadoso com as caixas de seleção que eles clicam na próxima vez, mas está chegando ao ponto em que essa deve ser nossa recomendação ...

    
por David Spillett 20.07.2009 / 11:04

2 respostas

4

Já cheirou o handshake de cliente para servidor entre o IE6 e as máquinas do IIS? ( link ) Eu suspeito que isso lhe dará a primeira informação sobre o que está errado, especialmente se você comparar o handshake para uma conversa de cliente para servidor com base no IE7. Um aperto de mão incompatível é o meu palpite sobre o que está acontecendo.

Veja o documento "oficial" da Microsoft "muda para HTTPS no IE 7": link

Estou me perguntando sobre a caixa de seleção "Usar TLS 1.0" nas configurações "Avançadas" dos seus clientes do IE6. O IE7 ativa o TLS 1.0 por padrão e o IE6 o desativa. Não está claro se os pentesters do seu Cliente brincaram com as configurações nos servidores, nos clientes ou em ambos. Posso imaginar que, supondo que eles estivessem brincando com os servidores, eles desativaram o SSL v2 nos servidores (consulte link ), mas não disse a ninguém para ativar o TLS 1.0 nos clientes IE6.

Nos servidores, eles teriam alterado / criado o valor DWORD "Habilitado" em "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Protocolos \ SSL 2.0 \ Server" e defini-lo como 0, supondo que eles desativaram SSL v2.

    
por 20.07.2009 / 12:58
0

Como um teste para rastrear a origem do erro: A conexão via o controle webbrowser funciona? Você pode usar, por exemplo, a avaliação de 30 dias do iMacros Browser para este teste. Ele usa o mesmo mecanismo do IE, mas com um invólucro diferente.

    
por 20.07.2009 / 13:27