Servidor IIS 8.5 não aceitando uma conexão TLS 1.0 do Windows Server 2003

Question

(Se você está se perguntando por que estou tentando habilitar conjuntos de criptografia que estão obsoletos, a resposta curta é que é para poucas pessoas que realmente não podem usar nada mais recente porque estão presas no Windows Server 2003, nem nós nem eles podemos fazer nada a respeito e não queremos que o serviço que fornecemos pare de funcionar se pudermos ajudá-lo.)

Eu usei IIS Crypto para ativar vários protocolos, cifras, hashes, trocas de chaves e conjuntos de cifras (< um href="http://pastebin.com/sxRFmk4p"> aqui é uma listagem completa ) que deve abranger o que é necessário para o nosso produto se conectar a este servidor através do TLS 1.0 considerando os recursos do Schannel no Windows Server 2003. ( O servidor foi reinicializado desde que as alterações foram aplicadas no IIS Crypto.

No entanto, o servidor descarta a conexão e o documenta com as duas entradas de log de eventos a seguir, postadas pelo Schannel no log de eventos do Sistema:

"Um pedido de conexão TLS 1.0 foi recebido de um aplicativo cliente remoto, mas nenhum dos conjuntos de criptografia suportados pelo aplicativo cliente é suportado pelo servidor. A solicitação de conexão SSL falhou." - identificação do evento 36874

seguido por

"Um alerta fatal foi gerado e enviado para o endpoint remoto. Isso pode resultar no encerramento da conexão. O código de erro fatal definido pelo protocolo TLS é 40. O estado de erro do Windows SChannel é 1205." - identificação do evento 36888

Usando o Wireshark no cliente, posso ver que ele está tentando negociar os seguintes conjuntos de criptografia:

            Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
            Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
            Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
            Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
            Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
            Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)
            Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
            Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
            Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
            Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
            Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063)

dos quais estes:

TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_3DES_EDE_CBC_SHA

estão incluídos no que habilitei com o IIS Crypto. Ainda assim, o servidor não quer tocar nesses conjuntos de criptografia e permitir que uma conexão seja feita. Ele simplesmente desconecta a conexão, como evidenciado por esta tentativa de se conectar usando o OpenSSL .

Por que o IIS ou o Schannel não permitem o uso desses pacotes de criptografia quando, até onde eu sei, os configurei para usá-los independentemente dos padrões?

    

Answer 1

TL; DR: Deu e usou o Linux e o Nginx .

Eu nunca encontrei a resposta para o que estava faltando. Além do servidor Windows Server 2012 R2 mencionado, eu configurei um servidor Windows Server 2008 R2 e o atualizei completamente e usei o IIS Crypto da mesma maneira, e parece-me que houve algum tipo de switch RC4 implantado em alguma atualização ao longo a linha que não pode ser desativada da maneira documentada, especialmente porque outro servidor Windows Server 2012 R2 que não tenha sido desativado para correção não faz a mesma coisa.

Como não posso viver com medo de executar o Windows Update, tive que recorrer à configuração de um servidor Ubuntu executando Nginx, manipulando a terminação TLS e invertendo o proxy para o servidor em HTTP simples no servidor que agora eu não fiz. tem que expor publicamente. A falta de documentação exaustiva e precisa da Microsoft e o desejo de mudar drasticamente o comportamento em pequenas atualizações mostram desprezo por seus clientes e seus negócios, e eles fariam bem em procurar por seus concorrentes para aprenderem como se preocupar com a segurança de seus clientes enquanto ainda confiam neles. com seu próprio julgamento.

    

Answer 2

Eu sei que isso é antigo, mas no caso de alguém querer saber mais, há também locais dentro do registro para isso. Meu pensamento é que talvez o TLS 1.0 seja Enabled = 0 ou DisabledByDefault = 1?

SSL / TSL:

Local do registro: \ HKey_Local_Machine \ System \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Protocolos

Se houver chaves na pasta de registro Protocolos com subchaves de Cliente e Servidor e DWORDS dentro delas de DisabledByDefault e Enabled, então é isso que está configurando. O estado padrão para o Win 2012 (r1) era o TLS1 permitido e permitido por padrão. (Se não, você pode adicioná-los)

(Observe que o servidor é para conexões de entrada e o cliente para saída).

Referências:

• link
• link

Cifras:

Local do registro: \ HKey_Local_Machine \ System \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers

Nós também usamos o IIS Crypto, depois de pesquisar bastante e descobrir que todo mundo usa esse programa. (Isso nos liberou de ter um limite de 1023 caracteres na lista do Conjunto de Cifras no Editor de Políticas de Grupo.)

(Além disso: o Win XP perderá toda a conectividade com HTTPS se 3DES (DES triplo) for selecionado)

Referências:

• link
• link

Answer 3

A maioria das organizações seguirá as diretrizes de proteção do IIS 8 aqui: link

O que eu sugiro que você verifique é os valores definidos aqui: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft.NETFramework \ v4.0.30319 SchUseStrongCrypto

A ativação do Strong Crypto desativa automaticamente o suporte RC4 e não é algo que a ferramenta IIS Crypto toque.