Aceleração SSL & Soluções SSL de Descarregamento

Os produtos LoadMaster KEMP altamente acessíveis incluem balanceamento de cargas Layers 4-7, conteúdo com comutação de servidores e persistência de servidor, descarregamento/aceleração SSL, balanceamento de carga WST e persistence com integração de diretório de sessão e capacidades front-end de aplicativo (caching, compressão, sistema de prevenção de intrusão) fornecendo valores de custo/benefício líderes na indústria.

Os processos de descarregamento SSL (troca de chave, setup e desmontagem de conexões SSL e criptografia em massa) são uma operação informática extremamente intensiva e podem ocupar uma porção significativa dos recursos de hardware de um balanceador de carga, que poderiam, caso contrário, ser alocados para suas diversas outras tarefas (tais como balanceamento de carga, check-ups, comutação de conteúdo, persistência, etc...). A fim de minimizar o impacto do processamento SSL no balanceador de carga, a maioria dos fornecedores de high-end SLB utilizam CIAEs especiais (circuitos integrados de aplicação especifica) que são otimizados especificamente para aceleração SSL.

Ler uma descrição detalhada sobre aceleração SSL abaixo.

KEMP, SSL, total: Aceleração SSL que protege o seu website completo, não somente algumas partes.

Se você estiver usando SSL, há a possibilidade de não estar utilizando todo o seu potencial. O SSL é uma tecnologia poderosa que pode ajudar organizações a proteger seus dados e seus usuários. Enquanto a tecnologia por trás do SSL é sólida, as melhores atividades comuns para a sua implementação não aproveitam em sua totalidade os benefícios oferecidos pelo SSL. E isto pode ser inadequado para oferecer segurança ao ambiente do aplicativo moderno de web.

Aceleração SSL 101

Para explicar isto, vamos primeiro rever rapidamente o que a tecnologia SSL oferece à organização em termos de benefícios. Estes benefícios são confiança e privacidade.

A confiança é assegurada através do uso de uma AC (Autoridade de Certificação) tais como VeriSign ou Thawte. Ao apresentar seu certificado SSL assinado por uma AC, ninguém mais pode usar o nome do seu domínio com SSL sem algum tipo de erro.

A privacidade é provida através de criptografia, que embaralha o tráfego de maneira a torná-lo incompreensível para um interceptador em potencial. Com o HTTP regular, informações como nomes de usuário, senhas, informações de cartão de crédito são enviadas pela internet na forma de texto simples. Alguém poderia, em tese, "farejar" este tráfego, o que é o equivalente eletrônico à interceptação de uma conversa. Além disso, este processo pode ser automatizado para ser realizado sem acompanhamento. Um programa fareja automaticamente a rede e retira partes que são programadas para ser interessantes, como senhas e números de cartão de crédito. Portanto, a criptografia é uma das ferramentas mais poderosas utilizadas no comércio virtual.

Aceleração SSL em prática

A habilidade de oferecer confiança e privacidade permite a uma organização proteger informações confidenciais. Atualmente, o SSL é utilizado primeiramente para proteger somente alguns tipos de informação confidencial. Estas consistem em:

  • Senhas (durante o login);
  • Transações de cartão de crédito - o que é um requisito de conformidade da PCI (Indústria dos Cartões de Pagamento).

A maioria dos empregos do SSL podem ser classificados em um destes dois itens. Mas seria este tipo de dado confidencial o único a tirar proveito do SSL? Considere o seguinte:

  • Memorandos sobre estratégia corporativa (web mail);
  • Informações de vendas confidenciais (CRM);
  • Segredos de comércio (portais da web);
  • Identificadores de sessão (no cookie do HTTP).

Com exceção da tecnologia VPN que pode ou não estar alocada, a maioria destas informações não são tipicamente protegidas na maior parte das empresas. É tudo realizado com o comum não SSL HTTP.

E, imagine por um momento, qual tipo de dado que você envia pela internet que não é confidencial? Com quais dados você não se importaria se eles caíssem nas mãos dos competidores ou do público?

Pode até ser que a maioria dos seus dados não seja confidencial, mas alguns deles serão incondicionalmente, então, como você conseguirá saber o que é e o que não é confidencial? Portando, porque não proteger tudo?

Proteção de sessão

Este é outro tipo de dado que os seus usuários podem desejar proteger, mesmo que a maioria não saiba disto. Este tipo de dado é chamado de "cookie de sessão". Quando o protocolo web foi desenvolvido, ele não era inicialmente "apátrida", no sentido de que cada solicitação era dependente uma da outra. Ao passo que a web transformou-se de páginas estáticas para aplicativos interativos, houve a necessidade de criar uma forma de relacionamento entre o usuário e o servidor, onde o aplicativo da web personalizaria respostas específicas para aquele usuário. Isto foi realizado por meio da atribuição de uma sessão de ID ao usuário, normalmente na forma de um cookie HTTP.

Quando um usuário loga em um aplicativo da web, é atribuída a ele uma sessão de ID, comumente uma longa combinação aleatória de letras e números. O usuário, então, envia esta sessão de ID ao servidor todas as vezes que ele faz uma solicitação. O servidor, por sua vez, pode criar, de maneira dinâmica, conteúdo (como um portal personalizado, uma conta de e-mail privada, etc.) para aquele usuário.

Um problema pode ocorrer se um invasor conseguir obter acesso ao valor desta sessão de ID. Eles poderiam, então, desviar a sessão do usuário, passando-se por ele sem nenhum desafio de login do servidor.

Se somente o login inicial e talvez transações de cartão de crédito forem realizadas sem SSL, significa que o valor desta sessão de ID é enviado repetidamente através da rede "de forma legível" (sem criptografia). Isto torna relativamente fácil a interceptação destes dados em particular, porque não há privacidade.

Ou seja, qual é o truque?

Dados os benefícios do SSL e a natureza de muitos dos dados sendo transferidos, porque o SSL não é usado como padrão? Para responder esta questão, nós precisamos analisar a história do SSL e como este uso se desenvolveu.

Ao ser criado inicialmente, a primeira desvantagem do SSL era que ele demandava maior potência em cavalos em termos de recursos do servidor. Criptografar e descriptografar é uma operação intensiva para o CPU. Ainda mais, CPUs de uso comum (como os processadores x86) não são otimizados para esta tarefa. Isto ainda é válido hoje em dia, mesmo para CPUs modernos.

Enquanto você navega por um site que opere com SSL, você não nota este uso acrescido de CPU, necessário para decodificar uma página vinda de um servidor. As poucas conexões abertas de que você dispõe não farão um impacto muito substancial mesmo em sistemas de usuário modernos.

Mas imagine a perspectiva do servidor: Ele está servindo dúzias, centenas ou até milhares de conexões simultâneas. Se o servidor também estiver tentando decodificar tudo, o CPU ficará sobrecarregado.

Os servidores precisam se esforçar muito mais ao servir páginas protegidas com SSL. Imagine que você tenha prateleiras repletas de servidores para servir os seus aplicativos web. Mas ao invés de usar o CPU deles para fornecer os aplicativos, eles gastam uma porção considerável dos recursos disponíveis realizando criptografia e descriptografia. É como ter uma equipe excelente de neurocirurgiões, mas afogá-los com tanta burocracia que eles consigam realizar apenas metade das cirurgias. É um desperdício de recursos valiosos.

Portanto, a forma de se pensar o SSL é uma mentalidade de escassez. Uma vez que os recursos SSL são considerados limitados, somente as porções mais críticas de uma interação de usuário são criptografadas. Após usar o SSL para inserir um número de cartão de crédito ou autenticar uma senha, você é novamente redirecionado para uma porção não SSL do site.

SSL e fornecimento de aplicativo - 101

Para abordar estas limitações no fornecimento de SSL, designers de sistemas desenvolveram uma nova tecnologia - a CIAE SSL (circuitos integrados de aplicação especifica). CIAEs são como processadores típicos, mas ao invés de serem projetados para desempenhar uma variada gama de tarefas (jogos, executar um editor de texto, navegar na internet), os processadores CIAE são extremamente limitados à sua funcionalidade. No caso de um CIAE SSL, eles são limitados a somente executar operações SSL, mas eles são fenomenalmente bons nesta tarefa. Enquanto um CPU x86 possa ser capaz de manejar 20 novas conexões SSL em um segundo, um CIAE SSL poderia ser capaz de lidar com 2.000 novas conexões SSL.

Ironicamente, a própria Intel foi uma das primeiras a desenvolver um acelerador SSL, porque até mesmo ela percebeu que o CPU x86 não era eficiente em altos índices de comunicações SSL.

Os primeiros lugares que receberam o emprego destes processadores especializados de SSL foram os próprios servidores. Um cartão PCL com um CIAE SSL seria instalado e o software de serviço da web usaria estes processadores ao invés do CPU geral para realizar o trabalho SSL. O servidor poderia oferecer os benefícios dos serviços SSL sem castigar o desempenho. No entanto, a desvantagem deste método é que você precisa de um cartão SSL por servidor, e estes custos podem aumentar rapidamente. Se cada cartão custa $700, e exitem 20 servidores, são $14.000 somente para SSL.

Então foram desenvolvidos aparelhos de rede, chamados de aceleradores SSL, e estes foram levados ao mercado. Aceleradores SSL são dispositivos localizados entre um usuário e um servidor, aceitando conexões SSL do usuário e enviando-as decodificadas ao servidor. Dados enviados através de redes públicas são protegidos, e o servidor detecta o tráfego decodificado, assim, nenhum recurso do CPU é utilizado no SSL.

Este modelo mostrou-se muito bem sucedido. Tão bem-sucedido, que os balanceadores de carga foram combinados com os aceleradores SSL e agora operam no mesmo chassis, e esta hibridização é comummente chamada de ADC (Application Delivery Controller).

Uma vez que a sessão SSL é finalizada no ADC, o ADC pode desempenhar as funções Layer 7 idênticas que são realizadas com HTTP não SSL, incluindo comutação de conteúdo, persistência de cookie e detecção/prevenção de invasão (IPS).

Aqui é onde as séries LoadMaster de ADCs da KEMP Technologies entram. Um LoadMaster KEMP é instalado em frente a um grupo de servidores e fornece aceleração SSL bem como balanceamento de carga e comutação de conteúdo inteligente.

Mentalidade de abundância

Com esta nova tecnologia, agora é viável o emprego de SSL na estrutura inteira do seu website. Os processadores SSL lidam com o SSL e os servidores empregam o seu tempo realizando o melhor de suas funções. Isso libera recursos do servidor para ocupar-se de outras tarefas.

Então, por que isso não é mais comum? Parte da razão é que o SSL foi equiparado com alta utilização de CPU por muito tempo e este pensamento não mudou. Mas está na hora de mudá-lo.

O poder do hardware

O LoadMaster 2500 e o LoadMaster 3500 incluem processadores SSL integrados. O LoadMaster 2500 pode manejar 1.000 TPS (transações por segundo), e o LoadMaster 3500 pode manejar 3.000 TPS.

Mas isso é suficiente? Isso corresponde a cavalos-vapor o suficiente para movimentar não somente as senhas e cartão de crédito SSL no LoadMaster, mas o site inteiro também? E como o TPS SSL equivalem-se a outras métricas de web mais familiares? Para responder estas perguntas, vamos dar uma olhada nos já bem compreendidos parâmetros de tamanho de página e largura de banda.

Primeiro vamos falar sobre o que significa TPS. O "T" em TPS se refere à conexão inicial SSL. Este é, de longe, a parte mais intensiva do CPU do processo todo. A conexão inicial é onde a maioria do trabalho é feito e onde é realmente mais vantajoso possuir um acelerador SSL.

Ao considerar uma dada página e um pouco de matemática, você pode ter uma ideia da largura de banda que um dado nível de TPS pode pressionar. Como exemplo, nós vamos utilizar uma página do tamanho de 100 quilobytes (incluindo HTML e imagens, o que é uma média de tamanho da página). Com um tamanho de página de 100 quilobytes, quanto de largura de banda o TPS 100 irá criar? Nós estamos assumindo HTTP 1,1, de forma que todos os 100 quilobytes de objetos sejam requisitados dentro de uma conexão simples (e, portanto, uma única transação SSL). 100 quilobytes são iguais a 800 quilobits, ou 80.000 bits. Mutiplique por 1.000 e nós teremos 80.000.0000 bits possíveis em um segundo. Isso equivale a 800 megabits. Isto é uma quantidade de tráfego imensa. Mais do que o que você precisaria para o LM-2500. Porém, o TPS 3.000 disponível no LM-3500 equivale a mais de um gigabit, o que é mais do que o necessário. Tamanhos de páginas diferentes e comportamentos de navegação de usuários irão afetar estes números, claro, mas eles são bons indicadores do tipo de desempenho que você pode esperar. A conclusão: O nível de TPS disponível no LM-2500 e LM-3500 é mais daquilo o que você precisaria, então o TPS não será um fator limitante. Há bastante potência de SSL para todos pequenas e médias empresas (PME) virtuais. E com as licenças SSL inclusas, o custo adicional para "proteger de forma SSL" o seu site inteiro é zero, ao contrário da adição de cartões SSL individuais para cada servidor.

Uma escolha fácil

Com processadores SSL baseados em hardware e sua habilidade de descarregar trabalho SSL para infraestruturas da web inteiras sem diminuição do desempenho e da capacidade e sem custos adicionais (comparado ao não SSL), por que não adaptar o SSL em tudo? Você recebe todos os benefícios e nenhuma desvantagem.

Com a potência dos processadores SSL integrados ao controlador de fornecimento de aplicativo sem nenhum custo adicional, não há motivos para não instalar SSL no seu site todo. O custo é zero, riscos potenciais são mínimos, e os seus usuários, caso eles notem alguma diferença, irão perceber o melhor.

Sobre a KEMP Technologies

A KEMP Technologies é líder em controladores de fornecimento de aplicativos economicamente eficientes e dispositivos de balanceamento de carga de servidores customizados para atender as necessidades das pequenas e médias empresas (PME) que se apoiam na internet para comércio virtual e aplicativos críticos de negócio. A KEMP ajuda as PMEs a aumentar rapidamente seus negócios com disponibilidade 24/7, melhor desempenho de infraestrutura de web, escalabilidade e operações seguras - enquanto racionaliza os custos de TI.

Milhares de produtos LoadMaster KEMP estão em uso atualmente para aperfeiçoar a satisfação dos clientes por meio da aceleração do acesso do usuário a aplicativos web críticos de negócios. Provedores gerenciados de serviço ainda se apoiam nos produtos KEMP para permitir um rápido prazo de comercialização e operações para serviços de gestão novos e já existentes.

Os produtos LoadMaster KEMP altamente acessíveis incluem balanceamento de cargas Layers 4-7, conteúdo com comutação de servidores e persistência de servidor, descarregamento/aceleração SSL, balanceamento de carga WST e persistence com integração de diretório de sessão e capacidades front-end de aplicativo (caching, compressão, sistema de prevenção de intrusão) fornecendo valores de custo/benefício líderes na indústria.