regina@cryptoid.com.br

Estamos em novo endereço. Encontre-nos lá!

Faça parte desse projeto você também!

Conteúdo

O objetivo desse Blog é apresentar essa fantástica e importante tecnologia, de forma simples, para que pessoas que não dominam aspectos técnicos também possam acompanhar a evolução da adoção da Certificação Digital e o universo que gira ao seu redor:

Certificado Digital para Assinatura e Sigilo, Certificado de Atributo, Carimbo do Tempo, Documentos Eletrônicos, Processos Eletrônicos, Nota Fical Eletrônica, TV Digital, Smart Card, Token, Assinador de Documento, Gerenciador de Identidades etc..

Este Blog publica matérias e artigos extraídos da mídia que expressam a opinião dos respectivos autores e artigos escritos por mim que expressam, exclusivamente, minha opinião pessoal sem vínculo a nenhuma organização.

Matérias organizadas por data de publicação

Mostrando postagens com marcador certificados SSL. Mostrar todas as postagens
Mostrando postagens com marcador certificados SSL. Mostrar todas as postagens

sexta-feira, 12 de julho de 2013

Comissão aprova critérios para registro de domínio na internet


Projeto incompleto?

O projeto não deveria ser mais abrangente? Porque? Por que pelo menos à alguns sites, por exemplo de comércio eletrônico, portais de notícias, segmentos financeiros e outros específicos deveriam ter atrelado ao registro de domínio um certificado digital SSL ICP Brasil para dar transparência aos visitantes na identificação inequívoca de sua identidade e segurança as informações através do protocolo SSL/TLS emitido com a chancela do governo brasileiro.

Veja, se até os ambulantes como por exemplo, um pipoqueiro que para vender seu saquinho de pipoca de R$2,00 na esquina precisa exibir aos clientes suas credenciais, porque em relação ao comércio eletrônico o Estado não segue os mesmos critérios?

A internet não é mais uma coisa a parte do cotidiano do usuários e o Brasil tem uma estrutura de chaves públicas que suportaria a emissão desse "Alvará digital". 

As Autoridades Certificadoras que emitem os certificados no âmbito da ICP Brasil são credenciadas pelo governo brasileiro e sofrem auditorias constantes do órgão regulador que é o ITI - Instituto Nacional de Tecnologia da Informação.   Para comercializar via internet e emitir nota fiscal a empresa deveria seguir uma série de procedimentos para garantir aos seus clientes a identificação inequívoca e a proteção dos dados.

Isso separaria o joio do trigo  e resguardaria os portais sérios que hoje ficam misturados aos aventureiros desse mundo online.


No mais, leia a matéria  divulgada pela Agencia Câmara sobre os novos critérios para registro de domínio na internet

O texto aprovado é o substitutivo da Comissão de Desenvolvimento Econômico, Indústria e Comércio ao Projeto de Lei 835/11, do deputado Claudio Cajado (DEM-BA), que proíbe o registro de nomes de domínio de internet nas categorias sob o domínio ".br" idênticos ou bastante similares a nomes de marcas, de empresas ou de pessoas previamente conhecidas, sem autorização do titular. 

De acordo com o que foi aprovado, o registro de um nome de domínio será concedido ao primeiro requerente que atender às exigências do Comitê Gestor da Internet no Brasil (CGI.br), e implementado pelo órgão executor indicado pelo CGI.br. 

O relator na Comissão de Ciência e Tecnologia, deputado Ariosto Holanda (PSB-CE), defendeu a aprovação do substitutivo argumentando que ele traz à lei as atribuições do CGI.br, órgão instituído por meio do Decreto 4.829/03, com o objetivo de coordenar e integrar todas as iniciativas de serviços de internet no País. 

“Este decreto estabelece que uma das atribuições do CGI.br é estabelecer diretrizes para a organização das relações entre o Governo e a sociedade, na execução do registro de Nomes de Domínio, na alocação de endereço IP e na administração pertinente ao Domínio de Primeiro Nível, ".br", no interesse do desenvolvimento da internet no País”, destacou Holanda. 

Tramitação 

O projeto tramita em caráter conclusivo e ainda será analisado pela Comissão de Constituição e Justiça e de Cidadania. 


Agência Câmara

quinta-feira, 1 de novembro de 2012

e-Commerce recorre a selos para atestar segurança aos clientes

Assista neste link o Vídeo com a entrevista a Paulo Kulikovsky: e-Commerce recorre a selos para atestar segurança aos clientes


Paulo Kulikovsky
O comércio eletrônico está cada dia mais presente na vida de todos nós.

Provavelmente, aqueles que ainda não experimentaram comprar online têm uma mesma justificativa: insegurança!



O mesmo vale para operações bancárias na internet.


Problemas com a autenticidade dos sites e segurança das informações espantam o consumidor. Mas esse cenário vem mudando.


Nos principais sites de bancos, e-commerce e serviços como e-mail e redes sociais, três selos garantem a segurança do internauta. São basicamente três tipos: o selo de site seguro, o selo de qualidade de serviço e o selo de vulnerabilidade. Cada um deles tem uma determinada certificação.

O selo de qualidade de serviço é obtido através de uma pesquisa sobre avaliação dos usuários a respeito de determinado serviço; o selo de vulnerabilidade assegura que o site não tem qualquer malware ou vírus que possa infectar ou danificar sua máquina; já o selo de site seguro identifica o site e protege os dados do usuário.

"O selo tem duas funções hoje em dia: identificar o site e criptografar as informações que transitam por aquele lá. O que isso quer dizer? Entre o momento em que você digita na tela aquelas informações recebidas pelo servidor das empresas, ninguém vai conseguir roubar os dados neste caminho", explica Paulo Kulikovsky, vice-presidente da Certisign.

Hoje existem dezenas de selos criados por diversas empresas mundo afora; todas bastante sérias. Só para o selo de site seguro, existem mais de 10 empresas que oferecem esse tipo de certificado. E ao contrário do que muita gente pode imaginar, nenhum site ou serviço “ganha” ou “recebe” estes selos por mérito ou qualquer outro motivo.


"O 'site seguro' é um servico adquirido em que as empresas precisam entrar em contato com uma das autoridades admistradoras, que trabalhem com esse certificado digital, para fazer a validação. Isto é a identificação inequívoca de que aquela pessoa que está pedindo é ela mesma, para que ela possa então expor o selo no site dela", completa Paulo Kulikovsky.

Ou seja, se você tem um site de e-commerce ou oferece qualquer outro serviço da web, vale a pena correr atrás e certificar sua página; isso é garantia de segurança do usuário e, consequentemente, mais visitas e mais vendas.

Do outro lado dessa história, o consumidor precisa tomar certos cuidados antes de sair comprando em qualquer site. E, principalmente, em sites de bancos. A primeira coisa a ser feita é procurar este selo de autenticação e segurança; normalmente, eles ficam no rodapé da página. Atenção: não basta o selo estar ali, estampado... clique sobre ele para abrir a validação dessa informação.

A segunda dica é ainda mais importante; atenção à barra do seu navegador ao acessar qualquer site de compras ou que peça seus dados pessoais. No endereço do site, o “HTTPS” significa que aquele endereço é seguro; mais do que isso, ao clicar na imagem que aparece à esquerda do endereço, você abre as informações de autenticidade daquele serviço. E tem ainda uma terceira forma de se certificar...

 
"Existe hoje uma tecnologia que várias empresas têm e que faz com que essa barra mude de cor. Então, hoje, quando a gente compra ela está branquinha, transparente. O que o selo faz - e vários navegadoras já fazem isso - é que a partir de certo momento a barra fica verde; e se ela fica verde,  sabe que tem um selo por trás que identificou aquele site. Se ela estiver branca, significa que pode não ter. Se ela estiver vermelha, pode ser que tenha algum problema com aquele certificado: está num endereço, mas com o certificado de outra pessoa", explica Paulo Kulikovsky, vice-presidente da Certisign.

Se você é mais um adepto das compras online, aproveite para conhecer nossa cartilha para aproveitar as promoções dos sites de compras coletivas sem cair em roubadas. Acesse os links acima e confira dicas preciosas que podem evitar grandes dores de cabeça no futuro. E tem uma última dica para quem usa serviços de banco online. Não use o .com.br. No lugar, digite .b.br. Ou seja, o nome do seu banco.b.br. Essa é uma maneira de garantir que a página que você está acessando é mesmo a página do seu banco. Fique ligado e boas compras... sempre seguras!

Fonte: Olhar Digital : Central de Vídeos :

sexta-feira, 27 de janeiro de 2012

SSL: Verificação de ID ainda é falha

Ericka Chickowski | Dark Reading
Segurança | 26 de janeiro de 2012

Com o lançamento da exploração Beast e a subsequente luta dos fornecedores de navegadores para encerrar vulnerabilidades contra autenticação SSL, muitas das discussões dos últimos meses sobre acreditação de rede são focadas nas fraquezas do protocolo SSL/TLS.

Mas como explicam alguns profissionais de TI, alguns dos maiores problemas não estão relacionados à tecnologia, e sim, às más práticas.

Segundo algumas pessoas, a culpa deve ser atribuída às autoridades de certificação (CAs), que deveriam fazer um melhor trabalho ao confirmar  propriedade de  identidade do certificado  para reforçar a credibilidade.

Segundo Bill Home, que dirige a William Warren Consulting,  “o SSL foi sobrecarregado com falhas processuais, e não técnicas”. A questão é simples no conceito e complicada na execução. A verificação de um usuário não pode ser feita de forma confiável por uma máquina. Em algum momento, a pessoa que tenta convencer o usuário de rede que seu certificado PKI é válido deve se aventurar no mundo real. Isto para se mostrar, antes de uma terceira parte neutra, que ele, ou sua empresa, pode utilizar o que está em seu certificado X.509 PKI.

Chet Wisniewski, conselheiro sênior de segurança da Sophos, é da mesma opinião de Horne, afirmando que  não acredita que o protocolo SSL é falho, além do fato de sua dependência em se apoiar no modelo antiquado de contar com as centrais CAs.

“Os métodos usados para verificar sua identidade são uma piada. É possível conseguir um certificado SSL para qualquer coisa. Por US$ 19  eles validam domínios, o que não significa muita coisa. Claro que possuir os certificados é melhor do que nada porque protege a pessoa contra coisas como o Firesheep [extensão do Mozilla Firefox que intercepta cookies não encriptados ]Mas deveriam ser gratuitas, e o fato de validarem quem são (no caso os proprietários do certificado) é pura bobagem”.

Segundo Horne, muitos CAs escolheram fingir que é possível automatizar o passo crítico de verificação de certificado de propriedade“É impossível, mas dá mais lucro fingir que é possível. Em suma: pagar humanos para verificar as identidades dos proprietários de certificado é caro, mas não há outra maneira confiável de fazê-lo”.

De fato, as CAs perceberam o tempo e fontes necessárias para realizar a o proceso de forma mais meticulosa: Foi daí que veio a ideia do certificado Extend Validation SSL. Quando foi lançado, há alguns anos, a ideia era cobrar mais para uma verificação mais extensa e oferecer um código “barra verde”, apresentado no endereço do navegador, para indicar que a URL tem um nível maior de confiabilidade.  “Quando você usa a validação estendida, ganha uma fantástica barra verde em seu navegador . O processo é um pouco mais rigoroso, mas ainda assim, não é a prova de falhas”, pontuou, por sua vez, Wisniewski.

Por exemplo, o custo para esses certificados EV-SSL ainda são altos e podem levar a problemas de “conteúdo misturado”, onde algumas páginas de um site podem estar protegidas com o certificado EV-SSL, umas com certificados normais e outras não codificadas. Esse é um problema que frequentemente leva a vulnerabilidades e mostra que tanto o CAs quanto os proprietários de sites têm responsabilidade no complicado ecossistema SSL.

Tradução: Alba Milena, especial para o IT Web | Revisão: Adriele Marchesini

Fonte: IT WEB

Excelente artigo que ressalta a fundamental importância da diferenciação entre as Autoridades Certificadoras e seus símbolos de confiança.


terça-feira, 17 de janeiro de 2012

Certificados digitais SSL expirados: um desafio de gestão

Autoridades certificadoras como DigiNotar e Comodo estão sempre nas manchetes, mas há uma ameaça maior à espreita da sua empresa.


..A falta de comprometimento das autoridades de certificado digital (CAs, da silga em inglês) com a segurança, como o da DigiNotar e da Comodo, tem levado alguns especialistas do setor a questionar a validade de certidões em geral.

Mas um relatório de pesquisa do Gartner identifica um risco mais difundido para as empresas: os certificados que expiram porque a organização faz um trabalho pobre para manter o controle dos mesmos. Um certificado expirado leva o acesso bloqueado para um servidor, website ou outro programa que, se é um serviço interno, resulta em dor de cabeça e tempo de inatividade. Caso seja um serviço externo, a organização pode ter a sua reputação manchada.

“A confiança é o elemento chave para tudo que fazemos em nosso mundo digital”, disse Eric Ouellet, analista do Gartner e coautor do relatório “X.509 Gerenciamento de certificado: evitando prejuízo e danos da marca”. X.509 é o formato padrão da indústria para criar certificados digitais, o quais ele comparou com um passaporte ou uma carteira de motorista.

Os certificados falham porque há muitos deles dentro de uma organização e os gerentes muitas vezes têm de verificar manualmente uma planilha para identificá-los, determinar as respectivas datas de vencimento e ativamente renová-los para que eles não expirem. O relatório diz ainda que os certificados de rastreamento podem se tornar complicados caso haja 200 ou mais deles dentro de uma organização.

Os certificados podem ser difíceis de controlar caso alguém crie um certificado e não diga nada a ninguém, segundo Ouellet. Um exemplo pode ser um desenvolvedor que cria um certificado de teste ao escrever uma aplicação e, simplesmente, deixa o certificado de lado enquanto implanta o aplicativo. Em outras situações, o desenvolvedor, a unidade de negócios, um integrador de sistemas ou uma pessoa de segurança de TI apontam o dedo um ao outro para passar a responsabilidade pelo certificado.

“Você precisa mapear os certificados, especialmente os de face externa, porque se você não acompanhá-los eles podem expirar sem que se perceba”, conta Ouellet.

O rastreamento manual também pode falhar se as Cas não forem identificadas, acrescenta o analista. Este problema, em particular, tem afetado os usuários da DigiNotar, na Holanda. Em 2011, 531 certificados foram roubados da DigiNotar, colocando em perigo sites populares como Google, Facebook, Twitter e Skype, assim como serviços de inteligência do governo, como a CIA ( Estados Unidos), MI6 (Grã-Bretanha) e Mossad (Israel).

O resultado é que a DigiNotar saiu do negócio e todos os certificados emitidos por ela foram imediatamente invalidados, afirmou Ouellet. Além disso, todos os líderes de navegadores Web, como o Internet Explorer, Google Chrome e Firefox foram modificados para bloquear os certificados da DigiNotar.

A autoridade certificadora Comodo também foi violada em 2011, porém a violação foi mais contida do que a da DigiNotar, assim os certificados da Comodo ainda são válidos. Mas, se uma organização não acompanhar a emissão de certificado da CA, ela pode ter certificados inválidos sem que possa perceber.

Existem sistemas automatizados de gerenciamento para descobrir os certificados em uma rede, identificar quem os emitiu, determinar sua validade e, em alguns casos, automaticamente renová-los.

O relatório do Gartner identifica as Venafi Director Series, o Certificado Trustwave Lifecycle Manager e o Centro de Inteligência Verisign como exemplos. No entanto, enquanto o Venafi e a Trustwave oferecem gerenciamento de certificados, independentemente da CA que lhes forneceu, o serviço Verisign apenas gerencia os certificados emitidos por ela mesma, empresa cujo certificado foi adquirido pela Symantec em 2010.

No Brasil, a  CERTISIGN comercializa os certificados SSL da Verisign e oferece gerenciamento dos seus Certificados SSL através do serviço de MPKI SSL.

A MPKI SSL é uma console  de administração dos certificados SSL que através de um certificado digital  de administrador a organização acessa remotamente centro de controle dos certificados da Certisign.

As empresas validam seus certificados de uma só vez e esses ficam disponíveis para a emissão no momento em que for necessário. Através dessa console o administrador dos certificados visualizam todas as informações  sobre os certificados, como data de emissão, expiração etc. E emitem e refogam os certificados sem que seja necessario a interação com a Autoridade Certificadora.

Outro ponto importante  sobre o controle de certificados expirados está ligado diretamente  a LCR e a OCSP.

A Certisign, por exemplo, administra as listas de certificados inválidos em tempo real, OCSP (Online Certificate Status Protocol), ou Protocolo Online de Status de Certificados.  tanto da hierarquia da Verisign quanto os certificados SSL emitidos na hierarquia da ICP BRASIL.

As demais Autoridades Certificadoras fazem essa verificação através da LCR (Lista de Certificados Revogados) e a periodicidade de atualização dessas listas chega a até 30 dias de acordo com a DPC – Declaração de Práticas de Certificação Digital, de cada Autoridade Certificadora.

Se vc administra mais de três certificados SSL, vale uma pesquisa em relação ao gerenciamento.


Fonte: itweb \complemento Blog Certificação Digital.

sexta-feira, 18 de novembro de 2011

Projeto do Google para driblar falsos certificados SSL

Google lança sua loja de música online ».Impressão Digital em cabeçalhos HTTP – projeto do Google para driblar falsos certificados SSL

Para melhor proteger os acessos web contra a distribuição de certificados falsos, uma extensão do cabeçalho HTTP que contém uma impressão digital de seus certificados está sendo projetada e testada. Esta abordagem, que foi parcialmente testada no Chrome, foi apresentada por Ian Fette, gerente sênior de produtos do Google, em uma reunião da Internet Engineering Task Force (IETF), em Taipei.

Fette disse que, após o hackeamento da DigiNotar, outras empresas pediram ao Google uma forma de proteger-se contra os certificados falsos. Como existem inúmeras CAs, a possibilidade de emissão de certificados ilegítimo ainda permanece, explicou o desenvolvedor. No entanto, Fette disse que a incorporação desta nova política poderia resolver isso.
A solução do cabeçalho HTTP que eles descreveram em um rascunho, envolve um hash do campo SubjectPublicKeyInfo (SPKI) de um certificado X.509 que seriam enviados para os usuários como um “PIN de cabeçalho”. Fette disse que hashes incluiriam os certificados que são válidos para a página atual, assim como os CAs raiz para a página. Durante o período de validade estipulado, os pedidos deveriam ser examinados para ver se existe pelo menos um PIN correto e um PIN de back-up estaria disponível.

sexta-feira, 23 de setembro de 2011

Golpe com certificados digitais falsos leva DigiNotar à falência



Por Computerworld/EUA

 Autoridade de certificação digital entrou com pedido de falência um mês após admitir que hackers geraram certificados SSL de forma ilegal.

A autoridade holandesa de certificação digital DigiNotar entrou com pedido de falência na segunda-feira (19/9). A informação foi confirmada na terça-feira (20/9) pela empresa controladora Vasco, dos EUA.

 
Em agosto, a DigiNotar admitiu que hackers tinham gerado vários certificados SSL de forma ilegal, incluindo um para o site google.com. Mais tarde, descobriu-se que o certificado foi utilizado para espionar cerca de 300 mil iranianos por meio de suas contas de Gmail.

A DigiNotar admitiu ter detectado a invasão em 19 de julho, mas manteve o caso em segredo por mais de um mês, deixando de avisar seus clientes - entre eles, o próprio governo da Holanda. Uma investigação revelou que os invasores puderam criar mais de 500 certificados.

 
A Vasco comprou a DigiNotar em janeiro, por 13,1 milhões de dólares. Na terça-feira, a empresa afirmou que ainda não avaliou o custo do fechamento da DigiNotar, mas expressou confiança de que alguns dos direitos de propriedade intelectual da subsidiária ainda poderiam ter algum valor.



quinta-feira, 2 de junho de 2011

SSL & TLS

SSL &TLS

Redes de Computadores I. GTA UFRJ

Autores
Fernando Venancio Pinheiro
Gabriel Serafim Vieira
Leonardo Gonçalves Da Silva


Já no ano 2000 a Dell vendia aproximadamente $18 milhões em equipamentos pela internet. Em 1999, 9 milhões de americanos já negociavam ações equivalentes a um terço de todo o mercado varejo de ações. 

Nesta mesma época, mais de 200 mil sites já aceitavam transações via e-commerce. Até hoje, as negociações realizadas na internet vêm crescendo de forma desenfreada. Até mesmo os mais desconfiados já realizam compras pela rede ou simplesmente acessam sua conta bancária através de portais dos grandes Bancos (Internet Banking). Pra se ter uma idéia, em 2010, só no Brasil

O faturamento através do e-commerce atingiu cerca de R$ 13 bilhões! [10]. 

Quase todos nós fazemos transações financeiras, pagamos contas e fazemos compras através da rede, trocando todo dia informações sensíveis através da internet. Estas informações sensíveis variam desde um simples e-mail pessoal até números de cartão de crédito.

Devido a esta quantidade absurda de dados sigilosos sendo compartilhada a todo o momento pela internet, a segurança se tornou um ponto cada vez mais crítico para os negócios, para as organizações e até para os cidadãos comuns. Para suprir esta necessidade existe um protocolo extremamente efetivo e amplamente utilizado. 


Este protocolo é o Secure Socket Layer, mais conhecido como SSL. 

O protocolo SSL juntamente com o seu sucessor, o Transport Layer Security (TLS), são o tema deste trabalho.

Abordaremos o surgimento do SSL, mostrando seu desenvolvimento, arquitetura e funcionamento e, então, mostraremos como foi derivado o TLS, uma solução gratuita para o protocolo da Netscape, explicando todos os seus protocolos.

SSL Tentativa de solução para segurança

Serviços de segurança específicos são necessariamente efetivos apenas contra riscos específicos; eles podem ser inapropriados para outras ameaças. Para entender o SSL, portanto, é 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, a motivação original para seu desenvolvimento foi a internet. 


Os inventores de protocolos precisavam assegurar o comércio eletrônico e outras transações pela Web. Um ambiente de fato muito perigoso. Considere, por exemplo, o que acontece quando um usuário em Berlim executa uma compra online em um site de San Jose, California.

A Tabela 1 lista os sistemas através dos quais as mensagens do usuário terão que passar:


Servirá 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. 

Tabela 1 Caminho, através dos sistemas, de Berlim a San Jose. [9]


A Figura 1 mostra que a mensagem enviada pelo usuário contendo informações sensíveis, como número de cartão de crédito, pode percorrer um caminho complexo da Alemanha à Califórnia, atravessando diversos países, permeando muitas redes diferentes, através de instalações variadas. Algumas destas instalações podem pertencer a 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.

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


O comércio eletrônico não pode estar à mercê de um ambiente tão inseguro. Informações sensíveis têm de ser mantidas confidenciais enquanto atravessam a rede.


Figura 1 – Caminho físico da Alemanha à Califórnia.

Espionagem não é a única ameaça para os usuários da Web. É teoricamente possível desviar mensagens para um site falso. Tal site falsificado pode prover informação maliciosa, coletar dados como o número de um cartão de crédito com impunidade, ou causar algum outro prejuízo. A internet precisa de um modo de garantir a identidade dos seus usuários.

O desafio final encarado pelos usuários da Web é a integridade das mensagens. Um usuário operando online no mercado financeiro certamente não vai gostar que suas instruções sejam alteradas (De forma intencional ou não) a tal ponto de que a mensagem "Venda quando o preço atingir R$200" seja recebida como "Venda quando o preço atingir R$20". Neste caso, a pequena falha representada por um 0 pode causar um estrago na fortuna de alguém.

SSL – Surgimento e desenvolvimento

De frente a esta situação crítica que é a massa de dados sensíveis sendo compartilhada, a segurança na internet, sem dúvidas, se tornou um fator crucial. Felizmente, engenheiros estiveram pensando a respeito deste ponto crítico desde o início da Web. 

A Netscape Communications já considerava riscos de segurança desde o desenvolvimento do seu primeiro navegador Web. Para garantir o sossego em relação às nossas preocupações, a Netscape desenvolveu o Secure Socket Layer protocol.

Abaixo, um diagrama mostrando a evolução do SSL em paralelo à internet:



Figura 2 - SSL foi desenvolvido juntamente com os primeiros navegadores Web. [9]

SSL é um protocolo que permite a transmissão de informações através da internet de forma criptografada. O SSL garante que a informação seja enviada, sem alterações e exclusivamente para o servidor para o qual pretende enviar. Os sites de compras online com freqüência utilizam esta tecnologia para proteger suas informações, como dados de cartão de crédito.

O protocolo SSL foi originalmente desenvolvido pela Netscape para garantir a segurança dos dados transportados através das camadas de aplicação HTTP, LDAP e POP3. O intuito inicial foi utilizar o protocolo TCP como a camada de comunicação para prover uma conexão fim-a-fim, segura e autenticada, confiável entre dois pontos na rede. 

Mesmo assim, o SSL pode ser utilizado para proteção de informação em trânsito em situações relacionadas a qualquer serviço de rede. É utilizado principalmente em servidores HTTP e aplicações do cliente. Hoje, praticamente todos os servidores HTTP suportam uma sessão SSL.



Figura 3 - SSL entre os protocolos de aplicações e a camada TCP/IP. [1]

A Netscape Communications desenvolveu as primeiras três versões do SSL com uma assistência significante da comunidade Web. Apesar do desenvolvimento do SSL ter sido "aberto" e a própria Netscape 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 – 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).

Hoje em dia praticamente 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 preocupe com o que está acontecendo, apenas tendo a certeza de que está executando o seu trabalho com confidencialidade, autenticação, segurança e integridade através da internet.

Os principais objetivos do SSL são:
  1. Autenticar o cliente e o servidor entre si;  
  2. Garantir a integridade dos dados: Durante uma transmissão, dados não podem ser alterados (seja de forma intencional ou não); 
  3. Segurar a privacidade dos dados: As informações trocadas entre cliente e servidor devem ser protegidas de interceptação e só devem ser lidas apenas pelo destinatário. Este pré-requisito é necessário tanto para os dados associados ao protocolo propriamente dito, quanto para os dados do aplicativo que é enviado durante a sessão. SSL não é apenas um protocolo único, mas sim um conjunto de protocolos que podem ser divididos em duas camadas:  
O protocolo para garantir a segurança e integridade dos dados: Esta camada é composta pelo SSL Record Protocol;

    Os protocolos que visam estabelecer uma conexão SSL: Três protocolos são utilizados nesta camada. O SSL Handshake Protocol, o SLL ChangeCipher SpecProtocol e o SSL Alert Protocol;

    SSL – Arquitetura e funcionamento

    O protocolo SSL define dois papéis diferentes para as partes na comunicação: Cliente e Servidor. Esta distinção é muito importante, porque o SSL exige que cada um dos sistemas se comporte de forma ímpar.

    O Cliente é o sistema que inicia uma comunicação segura; O servidor responde ao pedido do cliente. No modo mais comum de aplicação do SSL, a navegação Web segura, o navegador (Firefox, iExplorer, Chrome, etc...) é o cliente e o site é o servidor. Estes dois papéis se aplicam a todas as aplicações que usam o SSL.

    Para o SSL, propriamente dito, as distinçõ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 responsabilidade de propor ao servidor um grupo de opções do SSL para utilizar na negociação. 

    O servidor escolhe dentre as opções do cliente, decidindo qual dos sistemas utilizarão realmente. Apesar de a decisão final ser tomada pelo servidor, este tem que escolher entre as opções dadas pelo cliente.

    Quando o cliente e o servidor se comunicam, eles o fazem trocando mensagens. 

    Abaixo listaremos todas as possíveis mensagens em uma comunicação SSL:
    1. Alerta – Informa à outra parte de uma possível brecha na segurança ou falha de comunicação.
    2. ApplicationData – Informação real que as duas partes irão trocar entre si, que é criptografada, autenticada e/ou verificada por SSL.
    3. Certificate – Uma mensagem que carrega o certificado da chave pública do remetente.
    4. CertificateRequest – Uma solicitação do servidor para que o cliente forneça seu certificado da chave pública.
    5. CertificateVerify – Uma mensagem do cliente que verifica que ele conhece a chave privada correspondente à sua chave pública certificada.
    6. ChangeCIpherSpec – Um indicador para começar a utilizar serviços de segurança acordados.
    7. ClientHello – Uma mensagem do cliente indicando os serviços de segurança que ele deseja e que ele é suporta.
    8. ClientKeyExchange – Uma mensagem do cliente carregando as chaves criptográficas para as comunicações.
    9. Finished – Uma indicação de que todas as negociações iniciais estão completas e uma comunicação segura foi estabelecida.
    10. HelloRequest – Um pedido do servidor para que o cliente inicie (Ou reinicie) o processo de negociação.
    11. ServerHello – Uma mensagem do servidor indicando os serviços de segurança que serão utilizados para a comunicação vigente.
    12. ServerHelloDone – Uma indicação do servidor de que ele completou todos os seus pedidos para o cliente para estabelecer a comunicação.
    13. ServerKeyExchange – Uma mensagem do servidor carregando as chaves criptográficas para a comunicação.

    Estabelecendo uma comunicação

    O processo de comunicação do SSL é ilustrado na Figura 4, logo abaixo:


    Figura 4 – Comunicação com o SSL. [9]

    1. Cliente envia a mensagem ClientHello propondo as opções de SSL.

    2. O servidor responde com a mensagem ServerHello dizendo quais opções serão utilizadas naquela comunicação.

    3. O Servidor envia sua chave pública.

    4. O Servidor conclui sua parte da negociação.

    5. O Cliente envia as informações da chave de sessão (Criptografada com a chave pública do servidor).

    6. O cliente envia a mensagem ChangeCipherSpec para ativar as opções negociadas para as mensagens seguintes.

    7. Cliente envia a mensagem Finished.

    8. Servidor envia a mensagem ChangeCipherSpec para ativar as opções negociadas para as mensagens seguintes.

    9. Servidor envia Finished.

    TLS – Um sucessor


    Como dito anteriormente, a partir de 1996 o TLS foi o nome adotado pela IETF para desenvolver um protocolo de segurança padronizado baseado no SSL 3.0.

    Existem algumas pequenas diferenças entre SSL e TLS. Entretanto, o protocolo permanece substancialmente o mesmo – tanto é verdade que o protocolo TLS 1.0 é por vezes identificado como SSL 3.1. É muito comum encontrar aplicações que suportam ambos (SSL/TLS). Os dois protocolos não inter-operam (somente um deve ser escolhido no momento da negociação).

    Em projetos relacionados a servidores, especialmente de opensource, o protocolo TLS está substituindo o SSL. Para os clientes, o protocolo SSL3 é praticamente um padrão (normalmente, o TLS é padrão, mas rotineiramente ele tem que se rebaixar ao SSL).

    Quando se trata de aplicações web utilizando um navegador, na maioria das vezes o TLS funciona unilateralmente. Ou seja, somente o servidor é autenticado. É feito assim pela funcionalidade e pelo tipo de negócio de que se trata. Normalmente é o usuário que precisa saber da autenticidade do servidor para compras on-line. Mesmo assim, o TLS também suporta o modo bilateral de conexão, no qual os dois lados são autenticados e têm certeza de com quem estão "falando". Este modo é chamado de autenticação mútua.

    TLS – Funcionamento


    O início de uma comunicação TLS compreende basicamente três fases, que chamamos de Handshake Protocol:
    1. Negociação dos algoritmos a serem utilizados
    2. Troca de chaves (segredos) e autenticação
    3. Encriptação simétrica e autenticação de mensagens

    Na primeira fase, cliente e servidor decidem quais os algoritmos suportados por ambos que serão utilizados na comunicação (RSA, DAS, ECDSA). Na segunda fase ambos trocam chaves e, realizando a autenticação – são utilizados algoritmos de chave pública (RSA, Diffie-Hellman, etc). 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 TLS Record Protocol.

    Na maioria dos casos, a autenticação do servidor é feita através de uma Autoridade Certificadora (AC). Neste caso, o cliente utiliza uma chave pública da própria para validar a assinatura da AC 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.

    TLS – Protocolos


    O TLS é dividido nos seguintes protocolos: Record Protocol, Handshake Protocol, Alert Protocol, e Change Cipher Spec.


    Record Protocol:

    O TLS se comunica através de pacotes, que encapsulam os dados que estão sendo trocados. O Record Protocol funciona de maneira a tratar essa comunicação na entrada e saída de dados da camada. Ele recebe os dados das camadas superiores, encapsula, encripta e/ou adiciona Message Authentication Codes (MACs) para garantir a segurança, integridade e autenticação das mensagens e as envia ao destinatário que deve fazer o processo inverso. Assim vemos que possui independência em relação aos protocolos de aplicação.

    Handshake Protocol:

    Toda comunicação começa através do Handshake Protocol. O cliente e o servidor negociam uma conexão segura através de uma série de passos, nos quais devem decidir os algoritmos a serem usados e gerar segredos, que são geralmente números aleatórios. 
    Baseia-se nas seguintes etapas:
    1. O cliente faz o pedido a um servidor que suporte o protocolo TLS por uma conexão segura e já envia uma lista com os algoritmos disponíveis para a encriptação e autenticação dos dados. 
    2. O servidor recebe o pedido e escolhe o mais forte dentre os algoritmos da lista do cliente e que ele também possui e avisa o cliente desta decisão.  
    3.  O servidor envia ao cliente 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.

    Assim feito, o cliente pode verificar com a AC sobre a autenticidade do servidor e continuar a comunicação.

    Alert Protocol:

    Em construção...

    Change Cipher Spec:

    Em construção...

    Conclusão

    Fonte: I. GTA UFRJ

    quinta-feira, 5 de maio de 2011

    Como conectar seu iPad à rede da empresa com segurança?

    Utilizar uma VPN em ambiente corporativo ajuda a proteger os dados da companhia de acessos indevidos; processo no tablet da Apple não é complicado

    Há várias maneiras de proteger seu iPad e seus dados contra ataques maliciosos, e uma delas é de interesse específico de usuários corporativos: a rede privada virtual (VPN).

    Em seu modo padrão, sem nenhum programa adicional, o iPad suporta três tipos de VPNs: L2TP (Layer 2 Tunneling Protocol), PPTP (Point-To-Point Tunneling Protocol) e Cisco IPSec (Internet Protocol Security). Todos eles fazem a mesma coisa, mas de maneiras diferentes. O tipo de VPN que você configura em seu iPad depende inteiramente da tecnologia que está estabelecida na rede em que você se conecta.

    O tablet da Apple também possui suporte para as chamadas VPNs SSL, que utilizam os mesmos protocolos  usados pelos sites quando eles querem proteger a conexão para que você possa enviar dados sensíveis, sem se preocupar com outra pessoa mexendo nesses dados. O iPad suporta VPNs SSL da Juniper, Cisco e F5, apesar de você precisar baixar clientes deles na App Store. Também é possível criar sua própria configuração de VPN SSL, se assim desejar.

    Configure


    Como não é possível neste espaço fornecer detalhes de todas as configurações possíveis de uma VPN, vamos explicar como configurar uma usando o Cisco IPSec, que é relativamente comum. Para qualquer outro tipo, siga os procedimentos gerais.

    Comece indo em Ajustes, Redes e toque em VPN. Selecione Adicionar Configurações de VPN e então IPSec.  Será preciso preencher uma tela de configuração com os detalhes a seguir:
    - Servidor (o endereço de IP ou nome DNS do roteador VPN)

    - Conta (também conhecida como nome de usuário)
    - Senha
    - Um certificado (que será fornecido para o seu iPad pelo administrador da VPN) ou (em um campo abaixo) um segredo (uma espécie de segunda senha que fornece outra camada de autenticação; ao contrário da sua senha, o Segredo não é específico para o usuário).
    - Nome de Grupo/Group Name (usado para designar privilégios de acesso apropriados para diferentes tipos de usuários; por exemplo, seu grupo de TI provavelmente possui diferentes tipos de acesso comparado ao setor de Vendas).

    Antes de ter o trabalho de digitar tudo isso manualmente, verifique com seu departamento de TI. Eles podem estar habilitados a usar o Utilitário de Configuração do iPhone (iPhone Configuration Utility) para criar um perfil de configuração, que você instala no iPad e então configura a rede VPN para você.

    vpnipad01.jpg
    Tablet da Apple suporta três tipos de VPN
     

    Como usar

    Uma vez que a rede VPN esteja configurada, é simples usá-la. Quando quiser se conectar a ela,, basta abrir novamente Ajustes, tocar em VPN, selecionar a configuração que queira usar (se tiver mais de uma) e acionar a VPN na chave de on/off. Digite uma senha (se já não estiver salva em suas configurações) e alguns segundos depois já estará conectado.

    Nesse ponto, é possível conectar-se a sua rede e fazer o que precisar, que ela deve funcionar corretamente. O único sinal visível de que você está usando uma VPN é o pequeno ícone no canto superior esquerdo da tela. Quando terminar, volte às configurações da VPN, mude a chave para off e ela será encerrada.

    Se estiver usando uma VPN SSL, pode tirar vantagem da opção “VPN sob demanda”. Assim não é nem preciso acioná-la. Sempre que tentar acessar um site ou um recurso atrás de uma VPN, ela iniciará automaticamente e será fechada quando você terminar.

    Fonte:MacWorld

    segunda-feira, 25 de abril de 2011

    Sinal verde identifica sites seguros também no Brasil


    Já reparou? Todas as vezes que você usa o Twitter, via interface Web, uma sinalização em verde aparece antes da URL, envolvendo o nome do serviço, ali na caixa de endereços do browser, como nas imagens abaixo.

    Screen shot 2011-04-19 at 6.50.31 PM
    Screen shot 2011-04-19 at 8.45.14 AM
    Isso é sinal que você navega em um ambiente seguro. Um sinal bem mais aparente e fácil de identificar do que o prefixo https:// na URL, ou o cadeado fechado no pé da página.
    Clicando na área colorida, o navegador abre uma janela com informações detalhadas sobre o certificado de autenticidade do site, como nas imagens abaixo, feitas no Firefox e no Chrome, respectivamente.
    Screen shot 2011-04-19 at 6.52.45 PM
    Screen shot 2011-04-19 at 6.53.45 PM
    “A cor verde na barra de endereços eletrônicos indica que o site possui o chamado Certificado para Servidor Web EV SSL, o padrão mais elevado do setor de segurança da Internet para autenticação de sites”, explica Júlio Cosentino, vice-presidente da Certisign, que já começou a oferecer os certificados da Verisign no Brasil.

    “Isso significa que a empresa responsável pelo domínio passou por um rigoroso processo de autenticação de identidade e que a página não está hackeada. Portanto, o usuário pode confiar nas informações transmitidas, e também que as transações online estarão protegidas. O site é seguro, com validação estendida, em inglês, EV de extended validation”, continua Cosentino.

    Clientes da Certsign aqui no Brasil, como o Bradesco, já usam a novidade. O UOL também, para serviços como o PagSeguro. E, mais recentemente, até a Organização Humanitária Médicos Sem Fronteiras, para quem a Certsign doou o certificado, para garantir a segurança dos dados nas transações financeiras, realizadas via o site da ONG.

    Segundo Heloisa Granja, responsável pelas ações de web da ONG, implementar o certificado no site beneficia os doadores brasileiros.

    “Com essa tecnologia podemos oferecer mais tranquilidade e segurança para que as pessoas façam as doações online”, diz ela. Até porque a Médicos Sem Fronteiras é uma organização financiada quase que exclusivamente por doações de pessoas físicas. Por isso, estimular a doação individual é extremamente importante para nós”, completa.

    A sinalização lembra a de sinais de trânsito, e funciona em qualquer browser. A cor verde identifica o maior nível de segurança possível. Portanto, liberdade para seguir em frente e concluir as transações. A cor amarela identifica sites com certificação Web tradicional e que  merecem atenção do usuário, que devem checar se realmente estão onde deveriam estar. Já  a cor vermelha identifica sites inseguros. Melhor parar, não prosseguir com a transação.

    O preço do Certificado para Servidor Web EV SSL é equivalente ao dos certificados de 128 bits, com validade variando entre um e dois anos, quando precisa ter a licença renovada, informa Cosentino.

    quinta-feira, 24 de fevereiro de 2011

    É remediando que se aprende. Hackers invadem Twitter da Bovespa

    Regina Tupinambá
    A invasão no Twitter da Bovespa hoje, dia 24 de fevereiro, foi uma ação que poderíamos chamar de "institucional" do grupo Anonymous, que ganhou notoriedade após iniciar uma “guerra” em defesa do Wikileaks. 

    Grave seria se tivessem divulgado informações que influenciassem tendências em aplicações financeiras. O caminho dos hackers para a publicação de falsas notícias seria o mesmo.

    Trabalho com TI, mais precisamente em segurança da informação há muitos anos e nunca divulguei terror para vender segurança, mas fato é que os frequentes vazamentos de informações e "pichações" em sites  e em páginas de redes sociais de organizações consagradas não nos faz mais terroristas em causa própria. 

    A realidade esta ai estampada todos os dias nas páginas da grande rede.  Já é hora das organizações entenderem que se precisam aderir à Internet, que façam corretamente.

    Já dizia minha bisavó, é melhor prevenir do que remediar.

    Assim como as empresas colocam trancas em seus portões, seguranças armados, sistema de filmagens, sensores de presença em seus corredores  etc. Na WEB precisam se cercar de mecanismos adequados. Tecnologias já existentes, comprovadas e disponíveis.

    Eu me admiro até hoje com a ousadia de empresas de grande porte, muitas empresas de grande porte, diga-se de passagem, que sequer utilizam corretamente os certificados para servidores, os chamados certificados SSL ( Secure Sockets Layer). Aquele cadeadinho que aparece na barra inferior ou superior dos navegadores.

    Esses certificados digitais têm basicamente duas finalidades: identificar o site de forma inequívoca  e proteger com a criptografia os dados trafegados entre os usuários do site e os servidores web da organização.

    Utilizar no site da organização um certificado digital emitido para a empresa que produz o site é um total desrespeito aos visitantes deste site por que essa prática impede a verificação da autenticidade e a identidade do site visitado. 

    Isso parece básico, mas este procedimento é utilizado até hoje a exemplo de uma das líderes mundiais do seguimento de refrigerantes. Incrível, investe fortunas em sua imagem nos meios de comunicação e não sabe utilizar adequadamente a Internet. Sim, porque ai não se trata de economia, mas de total falta de conhecimentos das boas práticas de segurança e o protocolo de conduta ética no meio eletrônico, entre eles a Internet.

    De forma alguma faço apologia aos hackers, mas se nós da indústria de segurança da informação não conseguimos chamar atenção para os riscos de se colocar um site no ar ou uma página nas redes sociais, trafegar documentos eletrônicos sem criptografia,  eles, os hackers, estão ai para ensinar. Sendo assim, é “remediando” que se aprende. 

    No caso específico do episódio da Bovespa não se trata de desconhecimento porque a Bovespa é uma das  instituiçôes que melhor cuida dos aspectos de segurança e confiabilidade na internet. O Twitter é que não está preparado para o uso corporativo, pois deveria ter a possibilidade das empresas controlarem melhor suas publicações com certificados digitais e não com frágeis senhas .

    Regina Tupinambá 

    Artigos escritos por mim expressam, exclusivamente, minha opinião pessoal sem vínculo a nenhuma organização 

     

    Leia:@rtupinamba @g1seguranca Hackers invadem Twitter da Bovespa...

    segunda-feira, 6 de dezembro de 2010

    Vírus brasileiro falsifica "cadeado de segurança" para roubar senhas

    Um “mandamento” frequentemente repetido sugere que usuários verifiquem a presença do cadeado de segurança no navegador web. O cadeado serve para confirmar que o site que se está visitando é o site verdadeiro – o que está na barra de endereços – e que a comunicação é segura. Mas pragas digitais conseguem “falsificar” o cadeado. A coluna Segurança para o PC explica como isso acontece.

    Se você tem alguma dúvida sobre segurança da informação (antivírus, invasões, cibercrime, roubo de dados, etc), vá até o fim da reportagem e utilize a seção de comentários. A coluna responde perguntas deixadas por leitores todas as quartas-feiras.

    Cadeado de segurança autentica a página e criptografa o conteúdo para proteger senhas de interceptação.

    Um vírus capaz de realizar a façanha de falsificação do cadeado foi recentemente encontrado por Fabio Assolini, pesquisador antivírus brasileiro da fabricante russa Kaspersky Lab. Assolini investigou a praga e verificou que ela instala uma “autoridade certificadora” (AC, ou CA, na sigla em inglês) no Windows.

    O “cadeado de segurança” que aparece nos navegadores web é um certificado SSL. O certificado diz ao navegador como ele deve embaralhar a informação para impedir que ela seja decodificada, caso alguém consiga interceptá-la. Nesse mesmo processo, o certificado precisa informar qual é seu dono, autenticando o site e informando ao usuário que esse é mesmo o site legítimo – pois não devem existir dois certificados para o mesmo site.

    O navegador (seja ele o Internet Explorer, o Firefox, o Chrome, Opera, Safari ou outros) confia nessa informação porque o certificado é assinado por uma autoridade certificadora, que funciona como um “cartório digital”. Cada certificado precisa ser “carimbado” por uma autoridade certificadora e o navegador web traz consigo meios de reconhecer os carimbos dados pelos “cartórios” em que ele confia.

    Se o certificado não tiver um “carimbo” dessas organizações, o navegador exibirá um erro apontando os problemas encontrados no certificado.

    Em um ataque de phishing – em que o internauta recebe um e-mail falso em nome do banco que imediatamente solicita as informações –, o criminoso não tem o controle sobre o computador da vítima. No entanto, quando o usuário instala um vírus no PC, as possibilidades de ataque são mais variadas.
    Nos detalhes do certificado, o campo 'emitido por' é diferente do certificado original.

    A praga identificada pela Kaspersky redireciona os sites de bancos por meio do arquivo hosts, cujo funcionamento foi explicado por essa coluna anteriormente. O “problema”, para o criminoso, é que o site falso terá exatamente o mesmo endereço do site do banco e, por isso, não irá exibir um certificado – e não é possível obter um certificado para um site que já tem um certificado emitido (as autoridades certificadoras devem conversar entre si para não assinarem dois certificados idênticos).

    Os criminosos arranjam outro jeito: o vírus adiciona um novo “cartório confiável” na lista dos navegadores. Com isso, os criminosos podem carimbar certificados para qualquer site e o navegador irá ver que a assinatura é de uma autoridade confiável, mostrando o cadeado e nenhuma mensagem de alerta.

    “Com o ataque concluído, as vítimas passam a ser direcionadas para páginas falsas de bancos com cadeados de segurança e com o https na barra de endereço. Nenhum alerta será exibido na tela no acesso ao site falso, nem quanto a veracidade do certificado digital que está sendo usado, pois ele foi atestado como “legítimo”pela Autoridade Certificadora falsa”, escreveu o especialista da Kaspersky.

    Infecção e remoção de programas de segurança
    A Kaspersky identificou que a praga usa applets Java para se instalar no sistema. Nesse ataque, mais sofisticado, o internauta visita uma página e é imediatamente infectado caso a versão do Java esteja vulnerável. Após a infecção, o vírus apaga uma chave no registro que avisa o usuário a respeito de atualizações do Java, garantindo que a versão vulnerável permaneça instalada.

    Lista de certificados instalados no sistema. Vírus precisa adicionar servidor do criminoso a esta lista.Lista de certificados instalados no sistema.

    Em seguida, o vírus instala um driver de sistema com o intuito de garantir a resistência da infecção. Drivers são programas especiais que rodam com privilégios elevados, normalmente usados para permitir que o sistema “converse” corretamente com periféricos (hardware). O driver malicioso tem o intuito de impedir que o vírus seja removido enquanto apaga os softwares de segurança usados pelos bancos.

    Finalmente, a praga instala a autoridade certificadora falsa e um arquivo hosts que irá redirecionar os sites de bancos para sites idênticos controlados pelos criminosos. Com isso, o vírus dispensa a criação de janelas falsas ou captura de teclas (keylogging). Afinal, o usuário estará visitando o site “verdadeiro” (inclusive com o cadeado de segurança), mas com o criminoso como ponte entre as duas pontas da conexão, garantindo o roubo dos dados.

    Vale ressaltar que essa não é uma vulnerabilidade no protocolo de segurança dos cadeados. Uma vez infectados, computadores não podem mais ser confiados – e isso inclui o cadeado. A Kaspersky recomenda que um computador exclusivo seja usado para acesso ao internet banking quando possível, demonstrando a dificuldade em detectar esse tipo de ataque. Fora isso, a única possibilidade é verificando manualmente o certificado – coisa que poucos usuários fazem ou mesmo saberiam fazer.

    Assolini também recomenda que usuários falem com o banco no caso de suspeita de irregularidades na página e, claro que um antivírus atualizado seja usado.

    A lição que fica é a de que está cada vez mais difícil combater ataques depois que eles já tiveram início. O melhor a se fazer é ficar prevenido: atualizando o navegador, sistema e plugins e desconfiando de links maliciosos em e-mails.

    A coluna Segurança para o PC de hoje fica por aqui. Se você tem alguma dúvida ou sugestão, deixe-a na área de comentários, porque quarta-feira tem o pacotão com respostas a leitores. Fique também atento para notícias e alertas a qualquer momento aqui no G1. Até a próxima!

    * Altieres Rohr é especialista em segurança de computadores e, nesta coluna, vai responder dúvidas, explicar conceitos e dar dicas e esclarecimentos sobre antivírus, firewalls, crimes virtuais, proteção de dados e outros. Ele criou e edita o Linha Defensiva, site e fórum de segurança que oferece um serviço gratuito de remoção de pragas digitais, entre outras atividades.

    Na coluna “Segurança para o PC”, o especialista também vai tirar dúvidas deixadas pelos leitores na seção de comentários. Acompanhe também o Twitter da coluna, na página http://twitter.com/g1seguranca.

    Fonte: G1

    Leia também: Vírus brasileiro falsifica "cadeado de segurança" para roubar senhas 
    Por: Altieres Rohr Especial para o G1

    sexta-feira, 3 de dezembro de 2010

    WikiLeaks e Certificação Digital

     
    Entenda a forte relação entre WikiLeaks e Certificação Digital 

    WikiLeaks é uma organização transnacional sem fins lucrativos, sediada na Suécia, que publica, em seu site, posts de fontes anônimas, documentos, fotos e informações confidenciais, vazadas de governos ou empresas, sobre assuntos sensíveis.

    O site foi construído com base em vários pacotes de softwares. Apesar do seu nome, WikiLeaks não é um wiki.  Leitores que não têm as permissões adequadas não podem editar o seu conteúdo.

    Para a postagem, WikiLeaks utiliza o TOR visando preservar a privacidade dos seus usuários, e garante que a informação colocada pelos usuários não é rastreável. 

    TOR - The Onion Router, é uma rede de computadores distribuída com o intuito de prover meios de comunicação anônima na Internet. 

    A rede TOR é uma rede de túneis http (com tls), onde os roteadores da rede são computadores de usuários comuns rodando um programa e com acesso web. O objetivo principal da infraestrutura de segurança do projeto é garantir o anonimato do usuário que está acessando a web.

    TLS -Transport Layer Security - (em português: Segurança da Camada de Transporte) e o seu predecessor, Secure Sockets Layer - SSL (em português: Protocolo de Camada de Sockets Segura).

    São protocolos criptográficos que conferem segurança de comunicação na Internet para serviços como email (SMTP), navegação por páginas (HTTP) e outros tipos de transferência de dados. 

    O protocolo SSL provê a privacidade e a integridade de dados entre duas aplicações que comuniquem pela Internet. Isto ocorre através da autenticação das partes envolvidas e da cifra dos dados transmitidos entre as partes. Esse protocolo ajuda a prevenir que intermediários entre as duas pontas da comunicação tenham acesso indevido ou falsifiquem os dados transmitidos.

    É o certificado digital utilizado por sites que exibem selos de sites seguros, o cadeadinho na barra inferior do seu navegador.

    O site WikiLeaks foi lançado em Dezembro de 2006 e, em meados de Novembro de 2007, já continha 1,2 milhões de documentos. 
    No site, a organização informa ter sido fundada por dissidentes chineses, jornalistas, matemáticos e tecnólogos dos Estados Unidos, Taiwan, Europa, Austrália e África do Sul. 

    Julian Paul Assange
    Seu diretor é o australiano Julian Assange, jornalista e ciberativista.

    WikiLeaks recebeu vários prêmios para novas mídias, incluindo o New Media Award 2008 da revista The Economist.

    Em junho de 2009, a WikiLeaks e Julian Assange ganharam o Media Award 2009 (categoria "New Media") da Anistia Internacional, pela publicação de Kenya: The Cry of Blood - Extra Judicial Killings and Disappearances, em 2008 um relatório da Comissão Nacional Queniana de Direitos Humanos sobre a política de extermínio no Quênia. Em maio de 2010, WikiLeaks foi referido como o número 1 entre os "websites que poderiam mudar completamente o formato atual das notícias".

    Em abril de 2010, WikiLeaks postou, no website Collateral murder, um vídeo feito em 12 de julho de 2007, que mostrava civis iraquianos sendo mortos durante um ataque aéreo das forças militares dos Estados Unidos.

    Em julho do mesmo ano, a organização ganhou maior visibilidade mundial, ao divulgar o Afghan War Diary, uma compilação de mais de 76.900 documentos secretos do governo americano sobre a Guerra do Afeganistão.

    No mês de outubro, em articulação com grandes organizações da mídia, WikiLeaks publicou um pacote com quase 400.000 documentos secretos, denominado Iraq War Logs, reportanto torturas de prisioneiros e ataques a civis pelos norte-americanos e seus aliandos, na Guerra do Iraque.

    Em 28 de novembro, publicou uma série de telegramas secretos de embaixadas e do Governo estadunidense.

    Dois dias depois, em 30 de novembro, a pedido da justiça da Suécia, a Interpol distribuiu em 188 países, uma notificação vermelha, ou seja, um chamado àqueles que souberem do paradeiro de Julian Assange, para que entrem em contato com a polícia - o que equivale aproximadamente a uma ordem internacional de prisão. Isto porque, em agosto, duas mulheres suecas denunciaram Assange por violência sexual.

    Em 1º de dezembro, WikiLeaks anunciou que a Amazon.com o expulsara dos seus servidores, onde estava hospedado desde que começaram os ataques contra seu hospedeiro sueco, Bahnhof, em 28 de novembro, o que tornou o acesso instável. 

    Kevin Mitnick

    Segundo Kevin Mitnick, considerado o mais famoso Hacker do mundo: "Roubar dados é muito mais fácil do que protegê-los".


    O WikiLeaks e Julian Assange  estão apontando o quanto as empresas e autoridades governamentais do mundo todo não tratam suas informações sensíveis como deveriam.

    A Tecnologia para evitar ou pelo menos reduzir os riscos de vazamento de informações existe! Cabe à autoridades entender os riscos a que estão expostos e aplicar a tecnologia.

    A Certificação Digital e a tecnologia que evitaria o vazamento de muitas das informações divulgadas, principalmente as que foram capturadas através de e-mails entre empresas, organizações governamentais ou profissionais de comunição e jornalismo.

    No controle de acesso aos arquivos eletrôinicos e físicos deveria ser aplicada a combinação de certificados digitais, certificados de atributo e o time stamp. Winlogon com certificação digital e não senhas e identificação biométrica. 

    A Biometria sozinha não garante nada porque seu “segredo” é compartilhado em um servidor para ser checado no momento  do acesso. Digitais humanas são facilmente reproduzidas com a ajuda de um simples silicone. Salvo se utilizados leitores ultra sofisticados o silicone não funciona, pois são consideradas correntes sanguíneas etc ou se as digitais forem gravadas em mídia criptográficas (Met-on-Card) como esta previsto, por exemplo, no projteo brasileiro do  RIC - Registro de Identificação Civil .

    No caso do controle de acesso ser feito através de senhas, é brincadeira, não vale nem comentar. 

    Se fzermos uma analogia entre as senhas de acesso com a história do chapeuzinho vermelho, a senha é a casinha de palha. Se desfaz num sopro.

    O controle de acesso com certificados digitais permite trilha de auditoria com logs de acesso aos arquivos confidenciais, transferência para mídias e impressão em papel. Até mesmo faz o controle dos acessos à ambientes físicos.

    A comunicação interna nessas organizações e entre Governos de Estado deveriam ser resguardadas por certificados de assinatura, certificados de atributo e certificados de sigilo. E a tempestividade  da ação deveria ser conferida pelo uso do carimbo de tempo, o time stamp.

    Não tenho a pretensão de resolver a questão da segurança internacional e existem inúmeros outros recursos  e aspectos técnicos que não  domino e não citei neste artigo. Quero apenas alertar para o fato de que a tecnologia já existe e está disponível para empresas, indústrias e organizações governamentais agregarem mais segurança a troca e guarda de suas informações.

    WikiLeaks nesse episódio veio expor a ferida da sociedade eletrônica e das organizações com o "descompromisso" com a proteção e troca de dados sensíveis. 

    É claro que em muitos casos os documentos divulgados são antigos e foram “coletados” numa época em que não existiam recursos tecnológicos dos quais estamos falando. Também alguns vídeos publicados que não faziam parte de nenhum acervo governamental. 

    Mas fato é que a entrega desses materiais é feita diretamente aos servidores protegidos da WikiLeaks ou via colaboradores que transmitem aos servidores  utilizando justamente a proteção  da tecnologia de criptografia que os detentores das informações deveriam utilizar.

    Não faço aqui apologia ao crime, mas é um tanto ridículo as autoridades mundiais e a mídia internacional tentarem jogar a opinião pública contra Julian Assange por conta do crime de violência sexual supostamente praticado por ele.

    Pelo amor de Deus, o cara é um gênio. Se é do bem ou do mau, não cabe a mim julgar, porém as atenções da mídia e da opinião pública deveriam se voltar para a questão da troca e a guarda das informações "Top Secret" e a  responsabilidade da publicação de documentos e vídeos não autorizados por parte da  Winkileaks.

    Próximo alvo anunciado: EMPRESAS, começando por grande banco americano, cujos memorandos internos supostamente mostrariam algum tipo de negócio escuso.


    Regina Tupinambá

    Este Blog publica matérias e artigos extraídos da mídia que expressam a opinião dos respectivos autores e artigos escritos por mim que expressam, exclusivamente, minha opinião pessoal sem vínculo a nenhuma organização.