Como proteger um aplicativo do App Engine contra o ataque BEAST

Question

Eu tenho um aplicativo do mecanismo de aplicativos (ambiente padrão) em execução em um domínio personalizado com um certificado SSL. Eu estou tentando ter certeza de que ele está protegido contra um ataque de besta.

Uma verificação SSLyze mostra que meu aplicativo aceita DES-CBC3-SHA 112 bits como criptografia TLS.

Existe alguma maneira de atualizar a configuração do ponto de extremidade do TLS para permitir apenas TLSv1.2 com criptografias mais strongs (por exemplo, chaves mais longas, Diffie-Hellman, etc.)?

Ou existe outra maneira de proteger o aplicativo do meu aplicativo de aplicativo contra um ataque do BEAST?

    

Answer 1

A questão principal com o ataque BEAST decorre de vetores de inicialização sendo facilmente previsível com o TLS 1.0 e abaixo . Para mitigar isso, o cliente e o servidor devem concordar em usar o TLS 1.1 ou 1.2. A arquitetura do Google suportou o TLS 1.2 por algum tempo. O problema restante era que os clientes atualizassem seus sistemas para suportar também o 1.2. Como afirmado por @Michael Hampton, a maneira mais eficaz neste cenário para mitigar o BEAST é atualizar os clientes, pois o Google já oferece o TLS 1.2.

TLS no App Engine

A outra opção é que os servidores limitem as conexões TLS aceitas a > 1.0. Isso pode funcionar, mas tem o lado negativo de potencialmente excluir uma parte significativa da população do lado do cliente. Com a arquitetura atual do Google App Engine, não há como limitar o suporte a TLS a > 1.0 para um aplicativo específico . Se você deseja ver esse recurso implementado para o Google App Engine em situações em que a segurança é crítica, registre uma solicitação de recurso no Rastreador de problemas públicos do Google App Engine e postar um link para ele aqui para que outras pessoas também possam apoiá-lo.

Compute Engine como proxy

Nesse meio tempo, se a segurança for absolutamente essencial, você poderá criar seu próprio front-end de aplicativo com instâncias do Compute Engine (com IPs públicos) e negociá-lo com vigor para TLS > 1.0. Isso é possível, embora envolva a reimplementação de uma parte significativa da arquitetura existente do App Engine, ou seja, o ponto de extremidade e o balanceador de carga do TLS. Isso também arrisca algum gargalo no desempenho, dependendo do tráfego para seu aplicativo e sua implementação.

Se a segurança da camada superior não for absoluta, sua melhor opção seria aconselhar os usuários sobre vulnerabilidades de segurança se você detectar que eles estão usando sistemas conhecidos por não oferecer suporte a TLS > 1.0. Deixando de lado a aplicação, a segurança no fio como um todo é melhorada com movimentos globais em direção a protocolos mais seguros do que com exclusividade.