Protegendo a privacidade e a visualização da Netflix em escala
agosto 9, 2016 6:00 pm Publicado por major Deixe um comentário
Atualmente, muitas aplicações têm problemas com escalabilidade e segurança. Cada desenvolvedor e empresa sabe onde o calo aperta. É sempre bom poder discutir novas formas de resolver os problemas, por mais que não seja a solução específica para o nosso, essas discussões sempre trazem insights significativos.
E essa discussão com a comunidade, os testes e as aberturas de código são coisas frequentemente encontradas no techblog da Netflix. Lá eles têm trabalhado fortemente em maneiras de melhorar a escalabilidade e manter a segurança do seu serviço de streaming.
No time Open Connect da Netflix, eles têm o objetivo de sempre melhorar o hardware e o software nos aparelhos Open Connect (OCASs), que têm o propósito de armazenar e fornecer conteúdo de vídeo Netflix. Você pode entender melhor isso se visitar este link no blog da empresa.
Desde o início do programa Open Connect, a Netflix tem aumentado significativamente a eficiência dos OCAs. Eles conseguiram melhorar a entrega de 8 Gbps de taxa de transferência de um único servidor em 2012 para mais de 90 Gbps de um único servidor em 2016. A forma como eles deram sua contribuição para esse esforço foi no lado do software, otimizando todos os aspectos do software para o seu caso em particular. Eles trabalharam com foco no sistema operacional open source FreeBSD e o servidor web NGINX que executa sobre OCAs.
Este case será apresentado em uma sessão técnica sobre o tema durante o Intel Developer Forum (IDF 16), em San Francisco, este mês. Aqui abordaremos um pouco do que este artigo fala.
Adicionando TLS aos Video Streams
Atualmente na Internet, temos a necessidade de nos concentrar não apenas na eficiência das aplicações, mas também na segurança. Para isso, existem muitos mecanismos de segurança em vigor que são utilizados na Netflix, e que estão inclusive no estado da arte. Entre eles estão criptografia Transport Level Security (TLS) das informações dos clientes, consultas de pesquisa e outros dados confidenciais. A Netflix sempre contou com um pre-encoded Digital Rights Management (DRM) para proteger o seu fluxo de vídeo. Durante o ano passado, começaram a utilizar o HTTP (HTTP sobre TLS ou HTTPS) para criptografar o transporte do conteúdo de vídeo também. Isso ajudou a proteger a privacidade dos usuários, especialmente quando a rede é insegura – o que garante que seus membros estejam a salvo de espionagem por qualquer um que possa querer gravar seus hábitos.
O Netflix Open Connect serve uma incrível média de mais de 125 milhões de horas de conteúdo por dia, em todo o mundo. Dado o tamanho dessa escala, e adicionando a sobrecarga de cálculos de criptografia TLS para o transporte de stream de vídeo, eles tinham o potencial de reduzir significativamente a eficiência da sua infraestrutura global. Assim, eles são obrigados a levar a eficiência muito a sério. Para que isso fosse possível, eles tiveram que encontrar formas criativas para melhorar o software em seus OCAs.
A Netflix descreve seu trabalho nestas três áreas principais:
Determinar a cifra ideal para criptografia em massa;
Encontrar a melhor implementação da cifra escolhida;
Explorar formas de melhorar o caminho de dados de e para a implementação de cifra.
Avaliação da cifra
Aqui foram avaliadas cifras disponíveis e aplicáveis e, então, eles decidiram usar principalmente a cifra Advanced Encryption Standard (AES) em Galois/Counter Mode (GCM), disponível a partir de TLS 1.2. Foi escolhido o AES-CGM em relação ao método Cipher Block Chaining (CBC), que tem um custo computacional superior. O algoritmo de criptografia AES-GCM criptografa e autentica a mensagem simultaneamente – em oposição a AES-CBC, que requer uma passagem adicional sobre os dados para gerar a keyed-hash de código de autenticação de mensagens (HMAC). Isso não exclui o CBC, que ainda pode ser usado como uma alternativa para os clientes que não podem suportar o método escolhido.
Todas as revisões de aparelhos Open Connect também têm CPUs Intel que suportam AES-NI, a extensão ao conjunto de instruções x86 projetado para melhorar o desempenho da criptografia e da descriptografia.
Havia, entretanto, a necessidade de determinar a melhor implementação de AES-GCM com o conjunto de instruções AES-NI, por isso foi feita uma pesquisa das alternativas ao OpenSSL, incluindo BoringSSL e a biblioteca inteligente da Intel Storage Aceleration (ISA-L).
Netflix e NGINX já haviam trabalhado em conjunto antes com o intuito de melhorar a requisição de cliente HTTP e tempo de resposta através da utilização de chamadas sendfile. Assim, eles conseguiam executar um fluxo de dados de zero-copy do armazenamento (HDD ou SSD) à tomada de rede, mantendo os dados no espaço de endereço de memória do kernel e aliviar um pouco da carga da CPU. Em seguida, a equipe Netflix, especificamente, adicionou a capacidade de fazer as chamadas sendfile assíncronas – reduzindo ainda mais o caminho de dados e permitindo conexões mais simultâneas.
No entanto, a funcionalidade TLS, que exige que os dados sejam passados para a camada de aplicação, era incompatível com a abordagem sendfile.
Para manter os benefícios do modelo sendfile ao adicionar funcionalidade TLS, foi elaborado um esquema de TLS híbrido em que o gerenciamento de sessão permanece no espaço de aplicação, mas a criptografia em massa é inserida no pipeline de dados sendfile no kernel. Isso amplia o sendfile para suportar dados criptografia para conexões TLS/SSL.
Além disso, a Netflix fez algumas correções importantes para a antiga implementação no caminho de dados que eles possuíam. Isso incluiu eliminar as necessidades de listas mbuf, ligadas repetidamente às transversais para obter endereços para criptografia.
Para chegar a uma conclusão científica, foram testadas as implementações BoringSSL e ISA-L AES-GCM com as melhorias SENDFILE contra uma base de OpenSSL (sem alterações SENDFILE), sob condições típicas de tráfego Netflix em três tipos de hardware OCA diferentes. As mudanças em ambas as situações, BoringSSL e teste ISA-L, aumentaram significativamente tanto a utilização da CPU e largura de banda sobre a baseline quanto o desempenho em até 30%, dependendo da versão do hardware OCA. Então, eles optaram pelo ISA-L cypher implementation, que teve resultados ligeiramente melhores. Com essas melhorias, foi possível continuar o processo de adicionar TLS aos fluxos de vídeo para clientes que o suportam, sem sofrer acertos de desempenho proibitivos.
Leia mais detalhes sobre este artigo aqui. A Netflix continuamos a investigar abordagens novas e inovadoras para fazer da segurança e do desempenho de uma realidade.