Disaster nível de proteção de recuperação de auto-avaliação
A maioria Engineering Task Force (IETF) debates Internet passar despercebido, porque eles são muito seco e detalhado. No entanto, a sugestão de que a especificação HTTP 2.0 pode obrigar criptografia - em um mundo pós-Snowden - é muito saborosa a ideia de ir sob o radar.
A sugestão provocou o debate veio de cadeira HTTPbis, Mark Nottingham, que apresentou um resumo de discussão em que ele sugeriu algum tipo de consenso emergente de que HTTP 2.0 deve favorecer https:// para proteger os usuários (até certo ponto) contra espionagem tráfego: "HTTP / 2 para ser usado somente com https:// URIs na" internet aberta ". http:// URIs iria continuar a usar HTTP / 1 (e é claro que ainda seria possível para HTTP mais velho / 1 clientes ainda interoperar com https:// URIs) ", Nottingham escreveu na lista de grupo de trabalho IETF HTTP.
Outras opções ele relatou na reunião IETF Vancouver fosse usar criptografia oportunista para http:// URIs sem autenticação do servidor, ou para adicionar a autenticação do servidor para a sugestão de criptografia oportunista.
É lamentável que a história se transformou em um "W3C quer criptografar HTTP 2.0 por default", porque o que é mais interessante é a força do sentimento que acompanha o debate.
De Nottingham e-mail provocou duas coisas: manchetes, dando a idéia de "SSL-only" um estado mais forte do que ele tem, e um forte debate sobre a lista sobre os méritos da proposta.
Uma vez que o debate em curso é uma clara indicação de que a proposta de Nottingham não houve qualquer tipo de uma posição de consenso, mas sim um resumo das discussões, The Register gostaria de se concentrar em como a lista parece ver os prós e contras da idéia.
Seria "obrigatório" SSL tornar a Internet mais segura?
Obviamente o ponto de partida é que, caso fosse adotada - ou seja, HTTP 2.0 locais padrão para Secure Sockets Layer (SSL) usando segurança da camada de transporte (TLS) como o mecanismo, ele só teria impacto servidores HTTP 2.0 comunicação com navegadores HTTP 2.0. Alguém com um pouso mais velho navegador em uma página http:// vê nenhuma mudança.
Microsoft passou o registro na lista como preferindo incentivar TLS em HTTP 2.0 sem torná-lo obrigatório, enquanto o projeto Chromium é de opinião contrária, e está pensando em apoiar HTTP 2.0 só através de um canal seguro.
O debate destaca as profundas preocupações aqueles que a conhecem - isto é, aqueles que, na verdade, contribuindo para discussões IETF - têm sobre a segurança de TLS, particularmente à luz da crença Snowden-driven que os ataques man-in-the-middle são generalizadas.
No entanto, fazendo TLS vidas mais seguras fora em um grupo de trabalho diferente. Claramente, se um "canal seguro" implementação foram mandatados para HTTP 2.0, ele só pode usar os mecanismos de segurança que estão disponíveis para ele.
O que poderia quebrar?
Uma vez que a preocupação citada pelos participantes da discussão é simplesmente que uma especificação mais restritiva seria inibir a adoção de HTTP 2.0. Rob Rastreamento da Microsoft resumiu: "devemos incentivar fortemente o uso de TLS com HTTP, mas não à custa da criação de um padrão que é tão amplamente aplicável como HTTP 1.1".
Em outras palavras, não há nenhum ponto em ter um padrão "mais segura" se ele acaba sendo aquele que ninguém usa.
Talvez mais espinhoso é o que a proposta faria entre o navegador eo servidor, nos proxies e caches que os ISPs usam para ajudar a gerenciar seu tráfego. Um ISP só pode armazenar em cache uma história popular do The Register, se o conteúdo está em claro. A criptografia torna cada pedaço de olhar o conteúdo como conteúdo exclusivo.
Este tem um longo caminho a percorrer ... ®
Nenhum comentário:
Postar um comentário