O protocolo SSL foi desenvolvido pela Netscape em 1994, e permite aos clientes (normalmente os navegadores Web) e servidores HTTP comunicarem-se sobre uma conexão segura. O SSL oferece encriptação, autenticação e integridade dos dados no intuito de proteger a informação trocada em redes públicas inseguras. Há várias versões do SSL, a saber:

• SSL 2.0: possui algumas fraquezas de segurança, não sendo muito utilizado atualmente;
• SSL 3.0: é universalmente suportado;
• Tranport Layer Security (TLS): é um melhoramento do SSL 3.0, tem sido adotado como um padrão na Internet e amplamente suportado por quase todos os softwares recentes.

A encriptação protege dados contra uso não autorizado, utilizando algoritmos criptográficos, antes da transmissão. O dado é criptografado em um lado (cliente ou servidor), transmitido, decifrado pelo outro lado e, então, processado.

A autenticação é um método para verificar a identidade do remetente. A primeira vez que um navegador Web ou outro cliente tenta se comunicar com um servidor Web sobre uma conexão segura, o servidor apresenta ao cliente um conjunto de credenciais na forma de um certificado.

Como o próprio nome indica (Camada de Socket Seguro), conexões SSL agem como sockets conectados por TCP. Portanto, podemos pensar em conexões SSL como conexões TCP seguras desde que o lugar do SSL na pilha de protocolos é imediatamente acima do TCP e logo abaixo da camada de aplicação, como mostra a Figura 2-1.


Figura 2.1 - SSL e a pilha de protocolos TCP/IP (Fonte: [1]).

2.1 SSL e Tomcat

É importante salientar que a configuração do Tomcat para fazer uso do protocolo SSL somente é necessária quando o Tomcat está rodando como um servidor stand-alone.


Quando o Tomcat estiver rodando unicamente como um servlet contêiner sobre um servidor web dedicado, como Apache ou Microsoft IIS, geralmente é necessário configurar o servidor web primário para tratar as conexões SSL dos usuários.

O servidor primário negociará com os clientes e então redirecionará as requisições destinadas ao Tomcat após tê-las descriptografado. Da mesma forma, o Tomcat responderá ao servidor primário que irá criptografar a resposta gerada pelo Tomcat antes de enviá-la ao cliente. Neste contexto, o servidor Tomcat não participa do processo criptográfico. A Figura 2-2 e a Figura 2-3 representam os dois cenários de comunicação segura apresentados anteriormente.


Figura 2.2 - Tomcat como servidor stand-alone.


Figura 2.3 - Tomcat rodando sobre o servidor web Apache.

Neste trabalho, o cenário abordado é apresentado na Figura 2-2, onde o servidor Tomcat roda como um servidor stand-alone.

2.2. Certificados

Para implementar SSL, um servidor deve possuir um certificado digital associado a cada interface de rede (endereço IP) que aceitará conexões seguras. Um certificado digital serve para, na Internet ou em uma rede local, verificar se uma pessoa ou servidor é quem ela/ele realmente diz ser. Pode-se dizer que um certificado digital é uma carteira de identidade virtual. Em um certificado digital há informações pessoais da pessoa ou servidor, mas a principal informação presente em um certificado é a sua chave pública.

A criptografia usada na Internet se baseia no sistema de chaves. O algoritmo usado na criptografia faz com que sejam geradas duas chaves, uma pública e outra privada (também chamada de secreta). A chave pública, que está presente no certificado digital, é usada para criptografar dados a serem enviados ao dono do certificado. Já a chave privada, que só o dono do certificado conhece, serve para descriptografar a informação que foi criptografada com a sua chave pública. É importante notar que não é possível descriptografar a informação sem ter a chave privada e não é computacionalmente fácil deduzir a chave privada, através da chave pública.

Certificados são emitidos e validados por autoridades confiáveis conhecidas como Autoridades Certificadoras (CAs). Um certificado representa a identidade da chave pública de uma pessoa/servidor. É um documento assinado que tem por finalidade dizer: "Eu certifico que a chave pública presente neste documento pertence à entidade nomeada neste documento. Assinado CA". Algumas CAs bastante conhecidas são a Verisign.

• http://www.verisign.com.br

e Entrust:

• http://www.entrust.com

Neste contexto, é necessário criar um certificado que possa ser utilizado pelo Tomcat. As próximas subseções descrevem como isto pode ser feito.