Justificativa para a Necessidade do Protocolo

Para entender o SSL, é necessário entender o ambiente para o qual ele foi desenvolvido. Mesmo que o SSL seja um protocolo flexível que pode ser utilizado em muitas aplicações diferentes, originalmente ele foi desenvolvido para a internet. Seus inventores precisavam tornar o comércio eletrônico e outras transações pela web mais seguras. Um ambiente de fato muito perigoso. Por exemplo, (THOMAS, 2000) mostra o que acontece quando um usuário em Berlim executa uma compra online em um site de San Jose, Califórnia, na Figura 7.

Figura 7: Caminho, através dos sistemas, de Berlim a San José. Fonte: (THOMAS, 2000).

A Figura 7 mostra todas as rotas de endereçamentos que as mensagens, incluindo dados sigilosos, como número de cartão de crédito, passam até chegar ao receptor ou a quem de fato está sendo solicitado, nesse caso, na Alemanha, passando por diversos países. Desta forma, em meio a esse caminho todo, a mensagem pode sofrer alguma interferência, pois atravessa diversas instalações, as quais algumas pertencem às empresas privadas, muitas das quais não estão sujeitas a uma regulamentação ou a algum tipo de lei que garanta a privacidade das informações que elas transportam. Assim, elas podem

ser “roubadas” em alguma parte dessa viagem.

Pinheiro et al. (PINHEIRO F. V.; VIEIRA; SILVA, 2016) explica da seguinte maneira: Nem o usuário, nem o servidor possuem controle a respeito do caminho que suas mensagens seguirão, também não podem controlar quem irá examinar o conteúdo das mensagens através da rota. É como se o usuário escrevesse o número do seu cartão de crédito em uma carta e a colocasse em uma garrafa. O usuário não tem controle sobre como esta mensagem atingirá o seu destino e qualquer um no caminho pode facilmente ler a sua carta. A Figura 8 mostra bem a descrição feita em Pinheiro et al.

Figura 8: Caminho físico da Califórnia à Alemanha. Fonte: (PINHEIRO F. V.; VIEIRA; SILVA, 2016).

2.6

Surgimento do SSL

Diante da situação crítica que era a grande massa de dados sigilosos sendo compar- tilhada pela web, a área de segurança na internet se tornou uma importante personagem nesse meio. A Netscape Communications já considerava riscos de segurança desde o desen- volvimento do seu primeiro navegador web. Para garantir a segurança nestas transações, a Netscape desenvolveu o Secure Socket Layer protocol. A Figura 9 apresenta um diagrama mostrando a evolução do SSL em paralelo à internet, segundo Thomas (THOMAS, 2000).

Figura 9: SSL foi desenvolvido juntamente com os primeiros navegadores web. Fonte: (THOMAS, 2000) .

O SSL é um protocolo que se utiliza de dois tipos de criptografia (Assimétrica e Simétrica),em que, inicialmente estabelece a conexão com uma criptografia assimétrica. Através desta conexão segura, realiza a troca de chave da criptografia simétrica e, por fim, continua a comunicação dos dados com uma criptografia simétrica. Segundo Stallings (STALLINGS, 2008), este fluxo resolve diversos problemas que se têm utilizando os modelos de criptografia simétrica/assimétrica separadamente.

O SSL foi criado como um protocolo separado para segurança, sendo considerado uma nova camada na arquitetura TCP/IP, conforme demonstrado na Figura 10, no processo de camadas considerando seguro, com o Protocolo inserido.

Figura 10: O protocolo considerado como uma nova camada na arquitetura TCP/IP. Fonte: Elaborada pelo autor (2019).

Essa metodologia permite que o SSL seja utilizado para outras aplicações que não sejam o HTTP, como, por exemplo, FTP, POP3 e SMTP, conforme demostra a Figura 11.

Figura 11: Utilização do SSL por outras tecnologias. Fonte: Elaborada pelo autor (2019).

Segundo Pinheiro et al. (PINHEIRO F. V.; VIEIRA; SILVA, 2016), a Netscape Communi- cations desenvolveu as primeiras três versões do SSL com uma assistência significante da comunidade web. Apesar de o desenvolvimento do SSL ter sido "aberto"e a própria Nets- cape ter encorajado outros da indústria a participar, o protocolo tecnicamente pertence à Netscape (de fato, a Netscape recebeu a patente dos EUA).

Entretanto, em 1996, o desenvolvimento do SSL se tornou responsabilidade de uma organização internacional de padrões, a Internet Engineering Task Force (IETF). O IETF desenvolve muitos dos protocolos padrões para a internet, incluindo, por exemplo, TCP/IP.

Para evitar qualquer imparcialidade em relação a alguma empresa em particular, o IETF renomeou SSL para Transport Layer Security (TLS).

Ainda em Pinheiro et al. (PINHEIRO F. V.; VIEIRA; SILVA, 2016),afirma-se que, atual- ment, todos os navegadores e servidores web suportam o SSL. Pode-se observar o prefixo "HTTPS": para uma URL segurada pelo SSL. Alguns navegadores também exibem um pequeno ícone para indicar segurança, ou seja, o SSL funciona sem que o usuário se preo- cupe com o que está acontecendo, apenas tendo a certeza de que os seus dados estão sendo compartilhados com confidencialidade, autenticação, segurança e integridade através da internet.

2.7

Arquitetura, Propriedades e Funcionamento

O protocolo SSL é utilizado principalmente sobre o modelo Cliente-Servidor. Esta distinção é muito importante, porque o SSL exige que cada um dos sistemas se comporte de forma diferente e única. Stalling (STALLINGS, 2008) considera o cliente como sendo o sistema que inicia a comunicação segura, enquanto o servidor responde ao pedido do cli- ente. No modo mais comum de aplicação do SSL, a navegação Web segura, os navegadores (Firefox, iExplorer, Chrome, etc.) são os cliente e o site é o servidor. Estes dois papéis se empregam em todas as aplicações que usam o SSL.

Para o SSL, Pinheiro et al. (PINHEIRO F. V.; VIEIRA; SILVA, 2016) afirma que as dis- tinções mais importantes entre cliente e servidor são suas ações durante a negociação dos parâmetros de segurança. Logo que o cliente inicia a comunicação, ele tem a responsabi- lidade de propor ao servidor um grupo de opções que dizem respeito aos algoritmos de criptografia e funções hash a serem utilizados durante toda a comunicação. O servidor verifica a melhor (mais segura) opção de algoritmos e funções hash entre ele e o cliente e então decide o que será utilizado.

Sem a utilização do SSL, uma conexão é estabelecida com o seguinte fluxo:

1. Handshake TCP 8

2. O cliente e o servidor iniciam o processo normal definido pelo protocolo de camada de aplicação (HTTP, SMTP, FTP, POP3 e outros)

Com a utilização do SSL, uma conexão é estabelecida com o seguinte fluxo:

1. Handshake TCP

2. Processo de autenticação e encriptação

3. O cliente e o servidor iniciam o processo normal definido pelo protocolo de camada de aplicação (HTTP, SMTP, FTP, POP3 e outros)

Segundo, (ROCHA; PEDROSO; JUNIOR, 2003), dentre suas propriedades, o protocolo SSL proporciona: segurança criptográfica, interoperabilidade, escalabilidade e eficiência.

• Segurança criptográfica: O SSL deve ser usado para estabelecer uma conexão segura em duas partes;

• Interoperabilidade: Programadores independentes podem desenvolver aplicações utilizando o SSL que, então, será capaz de trocar parâmetros criptográficos sem o conhecimento de um outro código;

• Escalabilidade: SSL provê que novos métodos de criptografia possam ser adicio- nados, se necessários. Isso se faz para evitar a criação de um novo protocolo, alé, do risco de ter que implementar uma nova aplicação segura e, com isso, anular o risco de uma falha;

• Eficiência: Operações criptográficas costumam usar intensivamente o CPU e, par- ticularmente, operadores de chave pública. Por essa razão, o SSL tem incorporado o sistema de cachê de sessão para reduzir o número de conexões que necessitam ser estabilizadas desde o começo. Além do mais, um cuidado muito especial tem sido tomado para reduzir a atividade de rede.

Estabelecendo uma comunicação

Conforme descrição anterior, todas as comunicações utilizam o protocolo Handshake. É negociada uma conexão segura entre o Cliente e o Servidor, através de uma série de passos, em que são decididos os algoritmos que vão ser utilizados e a geração dos segredos, que são geralmente números aleatórios, nos seguintes passos:

• Negociação dos algoritmos a serem utilizados; • Troca de chaves (segredos) e autenticação;

As quatro etapas a seguir foram sugeridas na leitura de (PINHEIRO F. V.; VIEIRA; SILVA, 2016), (STALLINGS, 2008) e (THOMAS, 2000). Na primeira fase, cliente e servidor decidem quais os algoritmos suportados por ambos que serão utilizados na comunicação (RSA, DAS, ECDSA). O cliente faz o pedido a um servidor que suporte o protocolo SSL por uma conexão segura e lhe envia uma lista com os algoritmos disponíveis para a encriptação e a autenticação dos dados.

Na segunda fase, o servidor recebe o pedido e escolhe dentre os algoritmos da lista do cliente o mais forte; ele também possui esse algoritmo, e o avisa desta decisão. Ambos trocam chaves e realizam a autenticação - são utilizados algoritmos de chave pública (RSA, Diffie-Hellman, etc). Para sua autenticação, o servidor envia sua identificação na forma de um certificado digital. Este certificado normalmente contém o nome do servidor, a Autoridade Certificadora para verificação e sua chave pública.

Na terceira fase, as mensagens são autenticadas por códigos gerados por funções hash HMAC-MD5 ou HMAC-SHA. Daí em diante as mensagens são trocadas com integridade, segurança e autenticação depois de passarem pelo SSL Record Protocol. Na maioria dos casos, a autenticação do servidor é feita através de uma Autoridade Certificadora (AC). Dessa maneira, o cliente utiliza uma chave pública da própria AC para validar sua assi- natura no site do servidor. A AC deve estar na lista de AC’s confiáveis para ter certeza de que o servidor é quem ele diz ser, como demostra a Figura 12.

Figura 12: Estabelecimento de uma conexão segura com SSL. Fonte:(PINHEIRO F. V.; VIEIRA; SILVA, 2016).

Record Protocol, Handshake Protocol, Alert Protocol e Change Cipher Spec.

• Record Protocol:

Segundo Thomas (THOMAS, 2000), a comunicação do protocolo SSL se dá através da comunicação de pacotes, que encapsulam os dados que estão sendo trocados. O Record Protocol funciona realizando o tratamento dessa comunicação e na entrada e saída de dados da camada. Recebendo os dados das camadas superiores, encap- sula, encripta e/ou adiciona Message Authentication Codes (MACs) para garantir a segurança, a integridade e a autenticação das mensagens e as envia ao destinatário, que deve fazer o processo inverso, o que prova que ele (o Record Protocol) possui independência em relação aos protocolos de aplicação.

• Alert Protocol:

Thomas (THOMAS, 2000) explica que o Alert Protocol foi desenvolvido para a troca de mensagens que dizem respeito ao funcionamento e à transmissão de dados na conexão, em que cada mensagem deste protocolo é composta por dois bytes, sendo o primeiro para indicar seu caráter (que pode ser dos tipos "warning" ou "fatal"). Quando algum dos lados da comunicação recebe um alerta de caráter fatal, a trans- missão de dados é interrompida imediatamente. O segundo byte da mensagem car- rega o código definido referente ao alerta ou erro ocorrido.

• Change Cipher Spec:

Ainda em Thomas (THOMAS, 2000), o mais simples de todos é o Change Cipher Spec, pois consiste em somente uma mensagem. Esta mensagem significa que a sessão será passada para um estágio fixo e que a partir deste momento toda comunicação será criptografada de acordo com as negociações no Hello Protocol. Esta mensagem deve ser enviada tanto pelo cliente quanto pelo servidor. Após a troca das mensagens, a sessão é considerada aberta e todas as mensagens de dados ou qualquer outro protocolo serão transferidos utilizando o Record Protocol.

• Handshake Protocol:

Como vimos anteriormente, ele negocia uma conexão segura entre o cliente e o servidor, através de uma série de passos, em que é decidido quais algoritmos vão ser utilizados e como será feita a geração dos segredos, que são geralmente números aleatórios.