Configurando SSL/TLS no JBoss/Tomcat

Segurança sempre soa como uma falácia na maioria dos projetos de software. É como aquele pessoal que não gosta ou não sabe testar: eles sabem que a coisa existe e que é preciso ou muito recomendável a usar, mas no fim das contas dão de ombros e se funcionar funcionou.

Isso acontece muito quando o âmbito é segurança. Qual cliente ou usuário não se preocupa com segurança? Ao menos um controle de acesso com autenticação através de usuário e senha eles sempre exigem. E qualquer desenvolvedor que se preze se preocupa com isso.

Quando pensamos em segurança em aplicações Java temos que conhecer bem como funciona a arquitetura de segurança da plataforma Java, que é bem completa a útil. A divisão se dá em três “áreas” distintas, que são: JCA – Java Cryptography Architecture – Define classes e interfaces que são responsáveis por trabalhar com criptografia e descriptografia de dados e informações; JSSE – Java Secure Socket Extension – Usa a JCA para criar conexões seguras para troca de dados e informações; e JAAS – Java Authentication and Authorization Service – Responsável por autenticação e autorização nas aplicações Java. Neste post vou abordar somente um pouco do JSSE, para saber mais sobre JAAS veja no arquivo do blog.

O SSL (Secure Socket Layer) e o TLS (Transport Layer Security) são protocolos criptográficos usados para garantir a comunicação segura entre serviços de internet. Não vou entrar em detalhes sobre os protocolos e nem nas suas diferenças, para maiores informações sugiro esta leitura.

A necessidade fundamental de uma implementação com SSL é garantir a privacidade e integridade dos dados trafegados entre as aplicações que estão se comunicando. E isso é realizado através da autenticação das aplicações e da utilização de algoritmo criptográfico nos dados que estão sendo trafegados.

Dizer isso é meio bonitinho mas ninguém consegue compreender como isso ocorre de verdade, o que acontece por “por baixo dos panos”. Vamos imaginar um cliente utilizando um browser qualquer para acessar uma aplicação instalada num servidor JBoss, com certificado SSL implantado. Quando a comunicação entre eles é iniciada o servidor envia uma chave pública ao browser, que usa esta chave para criar uma chave privada temporária que é enviada de volta ao servidor. Desta forma as duas partes, servidor e browser, usarão estas chaves para estabelecer uma comunicação segura. Para saber mais sobre chaves públicas, privadas, criptografia simétrica e assimétrica veja a minha apresentação sobre certificação digital.

Vamos então por a mão na massa e configurar a aplicação.

Continue lendo “Configurando SSL/TLS no JBoss/Tomcat”

Um exemplo completo com JAAS

Devido ao um dos últimos posts deste blog, sobre utilização de JAAS com JDBC Realm e a grande procura por exemplos mais completos, com login e logout, por exemplo, resolvi melhorar um pouco a aplicação e disponibiliza-la para download.

Desta vez a aplicação está no meu github, junto com a aplicação do primeiro post sobre JAAS. São elas:

As aplicações possuem um README e alguma explicação, qualquer dúvida fiquem a vontade para lançar perguntas nos comentários, as duas aplicações foram feitas de forma a simplificar o máximo possível a utilização e configuração dos recursos de JAAS.

Autenticação e Autorização: JAAS com JDBC Realm

Recentemente ministrei um curso sobre Segurança em aplicações JavaEE, onde, grande parte do treinamento é a utilização e configuração do JAAS (Java Authentication and Authorization Service) abordando Basic e Form Authentication usando os realms: File, JDBC e LDAP.

Aproveitando o embalo do treinamento e principalmente pela empolgação dos alunos da turma quando viram quão simples e fácil é usar o JAAS, vou mostrar a configuração de autenticação e autorização em uma aplicação JavaEE usando Basic Authentication e JDBC Realm.

O JAAS (Java Authentication and Authorization Service) é a API padrão do Java para controle de acesso e autorização em aplicações JavaEE. Com JAAS é possível autenticar e validar usuários e certificados, bem como controlar a possibilidade de acesso e/ou utilização de recursos na aplicação (arquivos, diretórios, URLs, conteúdo, etc). Resumidamente o JAAS cuida de:

  • Autenticação: deve verificar se um usuário é ele mesmo através de validação de senhas e/ou certificados.
  • Autorização: com base em um usuário identificado, as regras e controles de permissão e acesso serão aplicadas na aplicação/produto e seus recursos.

O exemplo a seguir foi feito usando o Eclipse, Glassfish_v2 e MySQL, e não há nenhum segredo obscuro, simplesmente criaremos um Dynamic Web Project e usaremos o console do Glassfish para criar o realm.

Continue lendo “Autenticação e Autorização: JAAS com JDBC Realm”

Segurança: Ajax X Applets

Ontem recebi um link para um projeto nacional que tem tido muito sucesso, e estava lendo as informações no site e encontrei algo que é um perfeito exemplo de má interpretação de tecnologias, e isso me deixou bastante intrigado, é uma questão sobre a camada de apresentação do projeto, que é feita em Ajax, até aí tudo bem certo? (afinal, o que de novo hoje em dia não usa Ajax?)

Não, não quero colocar aqui o projeto e o link para o site pois não quero que esse post soe como uma crítica direto ao projeto, pois não é, é apenas uma crítica a forma em que uma questão em particular foi encarada, o que não tira os méritos do projeto.

IMHO, o problema foi o modo com que isso foi exposto e, até de certa forma, usado como motivo para justificar a adoção ao Ajax. No site do projeto existem claramente duas seções: Ajax e Não Utiliza Applets. A categoria Ajax é simples e mostra algumas vantagens de se utilizar Ajax na apresentação de aplicações Web. Já a categoria “Não Utiliza Applets” possui uma série de divagações das quais não concordei muito, e vou dizer o porque.

Começando:

Applets … …. além de serem mais lentos e inseguros…

Lentos eu até concordo quando comparados com utilitários bem escritos com JavaScript, mas isso não quer dizer que sempre será mais lento, não é difícil escorregar e perder a linha gerando na aplicação vários (ou até dezenas) Mega Bytes de JavaScript que serão tão lentos quanto um applet para carregar e poderão sacrificar o cliente como qualquer aplicação desktop repleta de memory leaks (quem nunca viu o Firefox sugando seus ~400Mb++ de memória?).

E a segurança, a não ser que o cliente esteja utilizando uma versão antiga da JVM (cujos bug já são conhecidos e possuem correção, geralmente em versões mais novas) eu concordo que possa haver problemas com segurança, mas ainda não concordo que a segurança de um applet seja inferior à de algum componente escrito em JavaScript. Podemos começar falando de vulnerabilidade ao cliente, com o applet, ou o cilente tem a JVM ou não tem, portanto, ou o applet irá funcionar ou não irá, já com o JavaScript, o controle de funcionar ou não, não é como um ON/OFF, o usuário tem diversas formas de bloquear e desbloquear determinadas operações, sem contar as formas existentes de interferir no fluxo normal de processamento do JavaScript, com o GraseMonkey, por exemplo, é fácil escrever códigos que se integram (inicialmente à apresentação) ao código JavaScript de qualquer página. Sem contar as possíveis formas de se utilizar de XSS para explorar falhas no DOM, HTML/Scripts injection, etc.

Em relação ao Javascript, os applets são mais lentos de processar alem de possuir espaço muito delimitado na página onde se executam

Essa parte de integração com os demais objetos da página realmente é um ponto fraco, muito fraco, quando utilizamos applets. Já a questão de velocidade de processamento, é fácil confundir o tempo de processamento gasto numa determinada funcionalidade com a quantidade de operações que cada funcionalidade realmente executa, mas como eu nunca fiz esse tipo de teste – de escrever um applet e um javascript que façam a mesma coisa – não irei muito além, apesar de não acreditar que possam haver diferenças tão grandes, afinal, tudo é executado no cliente, com os mesmos recursos.

todos os recursos são feitos sem a utilização de Applets (com eufemismo – isso não tem no site :D), os sistemas são baseados principalmente no AJAX, o que garante velocidade e segurança, além de que não é necessária a instalação da JVM na máquina do cliente

Pois é, antes que arremessem as pedras, não estou aqui defendendo o uso de applets frente a componentes Ajax, muito pelo contrário, eu já trabalhei bastante com applets e sei o quanto é chato, em todos os aspectos, e também já trabalhei, trabalho e pretendo trabalhar por um bom tempo com componentes Ajax bem escritos, a razão pela qual escrevi este post foi para, de certa forma, criticar o modo com que foi exposto o motivo para usar Ajax, não acho que seja necessário dizer: “- Uso Ajax pois Applets são lentos, inseguros, gordos e feios.”; afinal de contas, não é bem assim.

Efetividade: Gerenciando senhas

Um post meio off-topic, porém útil. Eu acompanho diariamente o ótimo trabalho do Augusto Campos nos blogs BR-Linux e Efetividade.net, ambos de excelente qualidade e de apresentação dispensável, o BR-Linux a muitos anos e o Efetividade.net mais ou menos a quase um ano, desde quando começou e este tem me ajudado muito, muito mesmo com pequenas dicas rápidas e de simples execução que ajudam bastante no dia-a-dia. Hoje segue um quote de um post que eu gostei bastante e que me tem sido bastante útil, senti isso semana passada depois de um incidente onde um certo indivíduo conseguiu acesso a uma senha minha que eu usava em alguns outros serviços também.

Clipperz – uma alternativa on-line para gerenciamento das suas senhas pessoais

Dando continuidade ao assunto iniciado no artigo anterior (”Segurança: Uma senha diferente para cada serviço ou site, sem anotar nem esquecer“), quero compartilhar com vocês uma solução alternativa para apoio ao gerenciamento de senhas: o Clipperz.

Toda solução de armazenamento de senhas busca um delicado equilíbrio entre comodidade e segurança, e elas têm diferenciais importantes entre si. As vantagens do Clipperz são várias: ele preserva sua privacidade (não é necessário nem mesmo informar seu e-mail), usa algoritmos de criptografia considerados bastante seguros (como o AES, SHA-2 e ECC), está disponível onde quer que você tenha um navegador, e gerencia inclusive logons automáticos em sites cuja senha você tenha armazenado no sistema, com um método bem mais seguro do que o adotado por serviços similares embutidos em navegadores modernos.

Continue…