Tipos de Certificados SSL para proteger seu site

Vale a pena ler de novo!

Matéria Publicada em 2013

Apesar de todos os avanços tecnológicos, incluindo o crescimento das transações comerciais no ambiente virtual, a questão da segurança para usuários e empresas ainda é um fator preocupante, pois muitos consumidores ainda não sabem identificar uma loja idônea daquela que pode prejudicá-los.

Porém, para ajudar neste momento e não perder vendas, os varejistas da internet já podem contar com os Certificados Digitais, ferramentas que identificam pessoas, empresas, equipamentos, aplicações e sites. Para plataformas de e-commerce a solução traz até mais de uma função. “Para os sites, o Certificado Digital tem duas funções: identificar de forma inquestionável o site e estabelecer uma conexão segura entre o visitante e os servidores do site por meio de um canal de criptografia”, evidencia Regina Tupinambá, Diretora Comercial e Marketing da Certisign Certificadora Digital ao E-Commerce News.

Regina

Regina explica ainda que no segmento de e-commerce, os Certificados para Servidores Web ou simplesmente Certificados SSL/TLS, são os que identificam os web sites e garantem a autenticidade, privacidade e a integridade dos dados de um portal na rede, proporcionando aos visitantes a garantia de que estão realmente acessando um site original e seguro, e não a uma cópia operada por criptografia, possibilita a prática do comércio eletrônico de forma segura e é sinalizado pelo Selo Site Seguro – cadeado que aparece fechado na barra inferior do browser; “S” na URL HTTPS ou a barra do navegador na cor verde.

Quando você está em uma página com SSL, por exemplo, observe a barra de endereços.

O HTTP:// mostra HTTPS://. Desta forma, ao acessar um site, o internauta deve atentar para essas características, pois, estes sinais atestam que a comunicação entre o usuário e o site é protegida por criptografia e não pode ser interceptada por terceiros Ou seja: é um ambiente seguro para efetuar compras e navegar tranquilamente”, assegura a diretora.

De acordo com ela, existem três classes de Certificados SSL, e vale aos varejistas, observar que a classificação está diretamente relacionada à forma como a titularidade do certificado é verificada e validada. “O valor do Certificado Digital SSL –Secure Sockets Layer, está no processo de validação das credenciais da organização para a qual será emitido o certificado. A diferença entre os certificados, fundamentalmente, é a validação de propriedade do domínio para o qual será emitido o certificado”, esclarece.

São eles:

Auto-assinados (self-signed) - Certificados gerados pela própria empresa. São de uso interno e não possuem interoperabilidade com os navegadores de internet.

Validação de Domínio (domain validated) – A Autoridade Certificadora apenas valida, de forma automática, a existência do domínio. A validação é feita com base nos dados cadastrados na entidade responsáveis pelo registro de domínio.

Validação de Organização (fully authenticated) – A Autoridade Certificadora valida se a empresa solicitante do Certificado SSL é proprietária do domínio configurado na solicitação do Certificado, se a entidade é legalmente constituída e se a pessoa que solicitou certificado tem poder para efetuar o pedido.

Para as operações no comércio eletrônico, os certificados com Validação de Organização (fully authenticated) são os mais indicados por proporcionarem maior segurança à empresa, aos usuários e aos clientes. “Além de certificar que a empresa está legalmente constituída, assegura que a mesma está em operação e que o domínio do Certificado é de sua propriedade”, justifica Regina Tupinambá

É possível encontrá-los em duas categorias:

Certificados SSL/TLS – se apresenta por meio da figura de uma chave ou cadeado na barra do browser para indicar a comunicação segura.

Certificado SSL/TLS EV (Extended Validation) – se apresenta por meio das cores nos navegadores da web: verde para seguro e vermelho para sites com algum problema de identidade.

A diretora enfatiza ainda que estes certificados são acompanhados pelo selo de segurança das Autoridades Certificadoras emissoras, mas, adverte que apenas o selo não é garantia de proteção. “O visitante deve verificar se o selo é verdadeiro.

A verificação leva menos de 5 segundos e, as empresas precisam entender o quanto a ação de educar os clientes e usuários a verificarem os selos pode beneficiá-las. O clique e verifique dá muito conforto aos visitantes e faz com que pesquisas transformem-se em compras”, garante.

Atenção redobrada na escolha:

É importante observar também que os Certificados Digitais de Validação de Domínio (domain validated) não trazem valor às relações de confiança na internet. Pelo contrário, confundem os visitantes que imaginam estar seguros pela presença da criptografia. “Na verdade, a criptografia pode estar levando os dados diretamente para hackers. São certificados muito frágeis pela falta de processo de verificação de propriedade, pois só faz a criptografia dos dados, não cumprindo a função fundamental de um Certificado Digital que é identificar a titularidade para o qual o Certificado é emitido.

Os Certificados de validação de domínios são utilizados por sites muito pequenos e por empresas que iniciam no e-commerce. O preço de mercado é muito inferior aos SSLs, pois é emitido por máquinas sem nenhuma interação humana”, orienta.

Outro tipo de Certificado não recomendável ao e-commerce são os chamados Certificados WildCards, pois permitem que uma única chave seja instalada em mais de um servidor. “Não é utilizado por empresas que movimentam muitas informações sensíveis de clientes, pois segue na direção contrária das boas práticas de segurança da informação. Mesmo as pequenas empresas só utilizam em servidores internos, nunca nos servidores que abrigam os sites da organização. Não é comum, mas algumas empresas de porte utilizam este tipo de certificado em servidores internos, porém possuem políticas de segurança de alto nível e fazem o gerenciamento das chaves com rigorosos processos de segurança lógica e física”, justifica.

Ainda existem os Certificados Digitais para os Múltiplos Domínios, que é um Certificado SSL desenvolvido principalmente para o uso em soluções baseadas em Comunicações Unificadas (Unified Communications), como por exemplo, Microsoft Exchange (2007 ou superior), Live Communications Server (2005 ou superior). “Uma das características deste certificado é permitir a inclusão, no campo Subject Alternative Name (SAN), vários endereços de internet, intranet e IP’s adicionais. Com este certificado, as soluções baseadas em Comunicações Unificadas conseguem estabelecer conexões seguras (SSL/TLS) com todos os endereços e/ou IP’s que estão presentes no Certificado (Campos:Common Name e SAN)”, assegura.

Para finalizar a diretora comercial e marketing da Certisign Certificadora Digital, reforça que, diante de tantas peculiaridades é muito importante que ao decidir por um Certificado Digital os varejistas verifiquem se a Autoridade Certificadora responsável pela comercialização do Certificado SSL segue as boas práticas de segurança e se é auditada por terceiros de “boa fé”.

“A Certificação Digital é baseada numa cadeia de confiança até chegar ao usuário final, mas, muitas Certificadoras criadas recentemente para baratear o preço dos Certificados SSL e ganhar mercado, emitem os certificados sem verificação de propriedade do uso de domínio”, sintetiza Regina Tupinambá

Fonte: e-commerce | E-Commerce News
Regina Tupinamba - Autora do Blog Certificação Digital

Desde 1995 se dedica ao comércio eletrônico em especial ao segmento da Certificação Digital.
Formada em Publicidade e Propaganda pela PUC Rio.

Trabalhou por 14 anos na Certisign Certificadora Digital como diretora responsável pelas áreas de Marketing e Comercial.
Hoje é CEO da Insania Publicidade, agência de marketing interativo.
e-mail regina@insania.com.br

Cloudflare lança SSL gratuito

Matthew Prince, CEO e co-fundador do  Cloudflare

Os certificados SSL serão emitidos gratuitamente para todos clientes do CloudFlare.

Como já diziam nossas avós: Quando a esmola é demais o santo desconfia!






Em declaração a imprensa o CEO e co-fundador do CloudFlare. Matthew Prince disse que estava liberando o serviço de SSL gratuito para todos os clientes interessados.

Explicou que ele resolveu fazer isso porque ele entendeu que essa seria sua missão: Ajudar a construir uma internet melhor e uma das coisas mais importantes que ele podia fazer era ativar o SSL Universal para todos os clientes pagantes e os não pagantes..

Ele disse: "Mesmo que isso faz mal a receita no curto prazo, é a coisa certa a fazer. Tendo criptografia de ponta pode não parecer importante para um pequeno blog, mas é fundamental para o avanço futuro criptografada por padrão da internet.

"Cada byte, porém aparentemente banais, que flui criptografados através da Internet faz com que seja mais difícil para aqueles que desejam interceptar, acelerador ou censurar a web.

"A internet é um sistema de crenças. No CloudFlare, temos orgulho de estarmos contribuindo para o sistema de crenças. E, depois de ter provado que SSL Universal é possível em nossa escala, esperamos muitas outras organizações nos siga e libere o SSL por todos os seus clientes e sem nenhum custo adicional. "

Ele reconheceu que o maior problema é o uso de navegadores antigos que não suportam a assinatura Elliptic Curve Digital Algorithm ( ECDSA ), no entanto, mais de 80% dos pedidos vêm de navegadores modernos (menos de seis anos de idade), e ele disse que percentual está crescendo rapidamente.

Ele disse também que espera que o SSL Universal incentive as pessoas a atualizarem seus navegadores e sistemas operacionais. "Às vezes, o progresso exige sacrificar alguma compatibilidade com versões anteriores", disse ele. "A boa notícia é que nenhum dos atuais clientes free do CloudFlare tinham anteriormente qualquer versão do SSL.

Matthew Príncipe disse ainda que este movimento irá dobrar o número de usuários de sites criptografados: "Ontem, havia cerca de dois milhões de sites ativos na internet com criptografia e até o final do dia de hoje, nós vamos ter que dobrou, declarou ele nessa quarta-feira dia 1º de outubro.

"Para um site que não tem atualmente SSL, será o padrão para o nosso modo SSL flexível, o que significa que o tráfego de navegadores para CloudFlare será criptografado, mas o tráfego de CloudFlare para servidor de origem não será criptografado. Para ser criptografado o proprietário do site precisará instalar um certificado em seu servidor web para que possamos criptografar o tráfego para a origem. Depois de instalar o certificado no servidor web e o modo SSL completo é possível criptografar o tráfego de origem e fornecer maior nível de segurança”.

Assim como os navegadores, ainda existe desafios com a carga da CPU e esgotamento do IPv4.

Ao ser questionado se os outros provedores vão seguir o seu exemplo, ele disse: "Nós não acreditamos que outros provedores sigam o mesmo caminho, pelo menos até que alguma pressão seja feita sobre eles.”

"No entanto, nós precisamos de mais navegadores de segurança avançada. Nós gostamos do que Cloudfare está fazendo e eles estão liderando o caminho para colocar a segurança do usuário em primeiro lugar. Nossa esperança é que a pressão o suficiente pode ser aplicada aos prestadores de serviços de comunicação e envergonhá-los para seguir o exemplo. "

Ontem no Grupo do Linkedin sobre Certificação digital foram colocados os seguintes pots sobre o assunto:




Parar de seguir Sergio

Cloudflare lança SSL gratuito

Sergio LealVP of Research and Development at ittruPrincipal contribuidor

Além de operar uma CDN de primeira linha gratuitamente, eles passam a ofecer certificados SSL de graça.

Como será que o mercado vai responder?
http://secutiryguru.blogspot.com.br/2014/09/cloudflare-lanca-ssl-gratuito.html
Security Guru: Cloudflare lança SSL gratuitosecutiryguru.blogspot.com.br
Security Guru: Cloudflare lança SSL gratuito



Eder Alvares. P.
Eder Alvares. P. Souza

Senior security consultant and co-founder at e-Safer Consultoria em Tecnologia da Informação

Sérgio pelo que eu entendi será um certificado provisionado pelo cloudflare que será implantado no servidor deles que atendem ao domínio do cliente. Assim, o cliente não irá gerar um par de chaves e receber o certificado e sim o pessoal da cloudflare irá gerar e disponibilizar um para o cliente. Inclusive o método que será praticado irá cifrar a conexão entre o visitando do site e o servidor da cloudflare e entre o servidor da cloudflare e o servidor do cliente não haverá cifra. Com isso, provavelmente o certificado utilizado será um simples domain validation e eles nem irão valiar a organização.

Pelo menos foi isso que eu entendi.

Abs.,
Eder Souza



Regina Tupinambá
CEO da Insania Publicidade e autora do Blog Certificação Digital

Isso é inacreditável!! Estamos vivendo uma enxorada de vulnerabilidades e ataques como nunca vistos e ainda existe espaço no mercado para certificados com apenas validação de domínio??




Eder Alvares. P. Souza
Senior security consultant and co-founder at e-Safer Consultoria em Tecnologia da Informação

Regina, sabemos quando custa uma validação segura e bem feita. Assim, sem custo somente certificado como esse e é a mesma prática adotada por empresas de hosting, isso quando o cara não compra um SAN DV e insere diversos clientes no mesmo certificado. Tudo para reduzir o custo ao máximo e segurança fica em segundo plano.

Abs.,

Eder Souza




Regina Tupinambá
CEO da Insania Publicidade e autora do Blog Certificação Digital

Eder, o problema é que nem todos os clientes entenderão que o que vale num SSL não é só a criptografia. Acreditarão que a Cloudflare está realmente proporcionando um item de segurança. Que bonzinhos...

A identificação numa cadeia de confiança é fundamental para a internet segura, como o Ceo da Cloudflare afirmou ontem que seria sua missão. Sem essa cadeia de confiança quem garante que o site do Bradesco é mesmo do Bradesco?

Um site idêntico pode estar criptografado por um hacker e as informações vão direto para os cibercrimonosos. SSL com validação de domínio não vale nada! E acho que o Prince - CEO da Cloldflare, não tem ideia do risco que ele esta expondo sua empresa.

Fácil assim: os hackers não precisam invadir servidores, basta colocarem um site clonado com criptografia, enviar uns spans e fisgar os iludidos para a armadilha! Muito mais simples que invadir o site, não acha?



Sergio
Sergio Leal

VP of Research and Development at ittru

Principal contribuidor

Amigos,

Esse assunto é bastante controvertido, ótima discussão.
Sempre apoiei a ideia de que pra cada tipo de necessidade existirá uma solução na medida certa. Assim, existe espaço para os certificados validados por organização (OV) e por domínio (DV).
Com a decisão do Google em favorecer os sites com HTTPS, a demanda de DV tinha tudo para disparar.
No caso do Cloudflare, a validação DV é automática, já que você teve que direcionar o seu DNS para apontar pra eles.
De qualquer maneira, estamos falando de operações que não exigem tanta segurança assim, uma vez que o Cloudflare já faz um man-in-the-middle.

Abs,
Sergio

Cuidado com a onda de golpes Online com o mote da Copa do Mundo

Estamos assistindo agora a uma nova onda de sites falsos utilizando o mote da Copa do Mundo para ludibriar os internautas. Não há nenhuma novidade nesses golpes. Nem na forma nem na tecnologia utilizada pelos hackers.

É o velho e manjado esquema utilizado pelos cibercriminosos conhecido como phishing. 

Um falso site apresenta uma oferta tentadora para fisgar a atenção do consumidor e pegar os dados de cartão de créditos ou faz com que o internauta deposite diretamente na conta do bandido.

É claro que para aplicar esse golpe os criminosos não criam seus próprios sites, eles utilizam a credibilidade dos grandes varejistas e clonam com perfeição os sites conhecidos e confiáveis. Clonam em minutos.

A única coisa que os hackers não conseguem replicar é o cerificado digital emitido por uma Autoridade Certificadora que atesta a identidade, a propriedade da empresa e também fornece a criptografia dos dados que garante a privacidade das transações.

Mas se seu consumidor não é avisado, alertado, lembrado e educado a verificar sua identidade, de nada vale ter um certificado SSL/TLS emitido por Autoridade Certificadora de primeira linha pois, sem que eles verifiquem, vão cair no golpe tão manjado no mundo virtual. 

Os consumidores precisam verificar se o certificado foi emitido pela Autoridade Certificadora escolhida para identificar seu site, porque também não é nada difícil os hackers utilizarem criptografia nos falsos sites emitidos por Autoridades Certificadoras que não seguem os processos de validação das credenciais de quem solicita o certificado digital. Então atenção aos que estão orientando as pessoas. O cadiadinho ou o "S"no endereço HTTP não é nenhuma garantia de que o site é 'o seu. As pessoas precisam conferir o endereço do site mesmo! E se vc não ensina-las qual é o endereço certo....

Também clientes podem conferir é se o certificado digital foi emitido pela Autoridade Certificadora correta, eleita por seu site.

Enquanto vocês, os donos das lojas online, não educarem sua audiência  a fazer a verificação da identidade do seu site, seus clientes serão alvos fáceis nas mãos dos hackers.

Autor: Regina Tupinambá

Leia da matéria veiculada na Exame.

São Paulo - Inspirada pela proximidade com a Copa do Mundo, uma página falsa do Walmart atrai curtidas e cliques de usuários com algumas “ofertas exclusivas para a copa do mundo FIFA 2014”.

CASC Heartbleed Response

The recent Heartbleed issue has reawakened interest in SSL certificate revocation (see Adam Langley’s blog, Larry Seltzer’s articles here and here, and Steve Gibson’s web pages)

Several years ago, the CA Browser Forum convened a special Revocation Working Group to explore issues and solutions. Leading CAs were actively involved in that group, and many of them invested in moving their OCSP responders to high-performance, high-availability Content Delivery Networks (CDNs) to respond to browser vendors’ requests for increased performance and reliability.

Google was part of the Revocation Working Group and announced CRLSets to that group and the wider CA Browser Forum. CAs were disappointed that Chrome wouldn’t actively retrieve OCSP responses from them, but we were under the impression that CRLSets would include most revoked certificates. Adam did ask CAs to help CRLSets by telling Google about important revocations, and CAs largely complied, for example, when the CA had to revoke intermediate certificates. But CAs have no reliable way of knowing which end-entity certificate revocations are important, since certificate owners don’t reliably tell CAs whether or not the revocation is important. Many CAs allow the customer to choose from a list of “revocation reasons”, but just as companies are hesitant to reveal that they’ve suffered a security breach, it’s assumed that they are hesitant to tell the CA that their private key had been compromised (this would constitute an important revocation).

Posted by the CA Security Council on May 8, 2014

As a result, end users and browsers have no way to determine whether a certificate was revoked because of the server’s loss of control over the key, fraudulent activity by the server administrator, the presence of malware on site, or simply out of an abundance of caution. Heartbleed is a perfect example of why revocation is important even without identified key compromise. No one can say for certain that their server’s private key was compromised. Most of the revocations that have occurred are going on CRLs for “business reasons” (as Adam defines it) and not picked up by CRLSets.

It’s now clear that CRLSets are simply a blacklist of high-profile revoked certificates. Other browsers have similar blacklists, and these can be effective at times (for example, to indicate revocation of an intermediate certificate that may be several years old and does not contain an OCSP pointer). But they’re not a substitute for OCSP checking of end-entity certificates.

Google moved away from supporting OCSP without adequately informing Chrome users of this fact. Although IE and Safari also soft-fail if an OCSP response is not received, those browsers still use OCSP by default. The engineers creating those browsers apparently have not concluded that OCSP is broken. Even if revocation checking by OCSP isn’t 100 percent accurate, it can still protect a high percentage of users who navigate to a site with a revoked certificate and receive an OCSP response indicating revocation. Turning off revocation checking for everyone means that no one is protected.

All browsers compete on speed and performance, and OCSP checking can slow page loading. We think many browser users would tradeoff a small performance hit for increased confidence in the authenticity of the web site.

Revocation is a very complex issue, with lots of room for debate. Reasonable people can disagree on the effectiveness of using OCSP. The CASC agrees that OCSP Stapling, and putting OCSP Must-Staple extensions in certificates, is one of the best solutions to address many issues with revocation at this time. But until that happens, we oppose browsers removing (non-stapled) OCSP checks.

A criptografia das notícias como proteção aos leitores

O tradicional jornal de papel pode estar ultrapassado, mas tem uma vantagem sobre as alternativas tecnológicas: você o lê, mas ele nunca lê você. 

As plataformas digitais, em contrapartida, transmitem informações em toda a esfera fundamentalmente pública da rede, deixando rastros para qualquer pessoa munida das ferramentas adequadas de monitoramento, seja ela seu empregador, seu provedor de Internet, seu governo ou o hacker sentado ao seu lado num café, dividindo o sinal do Wi-Fi com você.

É por isso que os defensores da privacidade online começaram a pressionar as empresas de comunicação para que criptografassem seus sites, do mesmo jeito que muitas empresas de tecnologia já fazem com e-mails, chats e pesquisas.

A criptografia nada mais é do que a codificação do conteúdo. Um site criptografado transforma textos e dados legíveis em um amontoado de letras e números sem sentido. Quando fazemos uma compra online, por exemplo, normalmente o site é criptografado, para que nossos dados bancários não sejam identificados facilmente. Normalmente, um site criptografado é sinalizado pelo ícone de um pequeno cadeado na barra de endereços do navegador.

Proteção da privacidade

O crescente uso de criptografia emergiu talvez como a resposta mais concreta às revelações de Edward Snowden sobre a capacidade da NSA (Agência Nacional de Segurança americana) de coletar quase toda informação existente em formato digital, incluindo localizações, atividades online e toda a comunicação entre pessoas de diferentes partes do mundo.

Quando você lê artigos online, por exemplo, expõe, ainda que indiretamente, suas preocupações com a saúde, suas ansiedades financeiras, sua orientação sexual e suas inclinações políticas. Um único artigo pode significar pouco, mas as empresas especializadas em Big Data (volume de informações digitais com o qual as empresas têm de lidar) coletam e analisam constantemente uma ampla gama de informações pessoais para produzir o perfil de consumo de cada um de nós.

“É possível pintar uma imagem bastante detalhada de um indivíduo, seus gostos e repulsas, se você puder ter acesso aos artigos que ele lê”, diz Trevor Timm, diretor-executivo da Freedom of the Press Foundation, um dos vários grupos que pressionam pelo uso mais amplo da criptografia.

Nem sempre somos espionados por nossos pertences. Mas atualmente quase todos eles são capazes de fazê-lo: telefones, computadores, conversores digitais de TV a cabo, carros com acesso à Internet e, em breve, óculos, relógios e até os eletrodomésticos que fazem um rastreio constante sob o pretexto de acessar uma rede “inteligente”. Sempre que a informação é transmitida através da Internet sem criptografia, qualquer indivíduo pode vê-la, coletá-la e analisá-la.

Contra a censura política

“Todos os sites de notícias deveriam criptografar seu conteúdo”, defende Martin Johnson, um dos fundadores da GreatFire.org, instituição que rastreia os passos da Grande Firewall, na China. (Tal como outros membros do grupo, ele usa um pseudônimo para evitar a detecção por parte do governo chinês.) “Não criptografar seu conteúdo é o mesmo que dizer: ‘Estamos felizes em permitir que os censores ao redor do mundo filtrem seletivamente nosso conteúdo’.”

A perspectiva de censura pura e simples não deve ser uma preocupação pequena para as empresas de comunicação. Quando um usuário da internet chinesa, por exemplo, tenta acompanhar a cobertura internacional sobre o 25º aniversário dos protestos na Praça da Paz Celestial (ocorridos em 13 de maio de 1989), o sistema de vigilância de Internet e censura do governo (conhecido como a Grande Firewall da China) vai saber.

O governo chinês também já chegou a bloquear – em diferentes graus e em diferentes épocas – algumas das maiores empresas de comunicação ocidentais quando estas publicaram reportagens consideradas inadequadas sobre seus líderes políticos e suas respectivas famílias. O jornal New York Times e a agência de notícias Bloomberg News estão indisponíveis online para os leitores chineses desde 2012, e o diário britânico The Guardian, desde janeiro deste ano. O site do Wall Street Journal em chinês também chegou a ser bloqueado de maneira intermitente.

Não é só a China que procura controlar a torneira de notícias e informação digital. Várias nações bloquearam o YouTube em 2012 para impedir o download de um filme controverso intitulado Innocence of Muslims(“Inocência dos muçulmanos”, em tradução livre). No mês passado, a Turquia bloqueou o YouTube e o Twitter para evitar a propagação de uma gravação de áudio envolvendo membros do governo e empresários locais envolvidos em suposta corrupção.

Não há forma de prever como tais nações iriam reagir a um novo grande movimento em direção à criptografia. No entanto, ao mesmo tempo em que as empresas de comunicação combatem a censura, as questões de privacidade ainda correm em uma trilha separada, paralela.

Obstáculos técnicos

De acordo com especialistas técnicos do ramo da informática, a adesão ainda é pequena porque criptografar algo tão complexo como um site de notícias é extremamente difícil. Várias grandes empresas de comunicação passaram a oferecer, nos últimos anos, a criptografia em alguns trechos de seus sites. “Mas a maioria delas parou de fazê-lo ao se deparar com problemas na exibição de conteúdo de forma rápida e limpa”, ressalta Peter Eckersley, diretor de projetos de tecnologia para a Electronic Frontier Foundation.

A First Look Media, empresa de comunicação sem fins lucrativos criada por Pierre Omidyar, fundador do eBay, e pelo ex-jornalista do Guardian Glenn Greenwald – responsável pelos primeiros furos do vazamento de Edward Snowden – lançou sua primeira revista digital, a Intercept, usando criptografia, abastecendo leitores com artigos muito mais seguros de olhares indiscretos. A ProPublica, outra organização sem fins lucrativos voltada a jornalismo investigativo, oferece criptografia como uma opção para leitores que sabem ativá-la. Nenhum dos dois projetos depende de receita publicitária.

“O Washington Post está cogitando mudança semelhante e, nas últimas semanas, tem começado a experimentar a criptografia”, diz Shailesh Prakash, diretor de tecnologia e vice-presidente de desenvolvimento de produtos digitais no Washington Post. Se os testes em andamento forem bem-sucedidos e a criptografia for facilmente disponibilizada em todo o site, o Post se tornaria o primeiro grande veículo jornalístico tradicional a proteger a privacidade de seus usuários desta forma.

No entanto, criptografar um site tão elaborado como o do Post, por exemplo, exigiria recursos substanciais, bem como tempo para solucionar quaisquer problemas. Prakash conta que, em seu teste inicial, o Post teve problemas para exibir anúncios corretamente quando os técnicos tentaram criptografar as páginas.

O Ars Technica, site voltado a notícias de tecnologia, vem tentando criptografar seu tráfego há um ano, mas continua enfrentando problemas inesperados, como a forma de lidar com links para vídeos e outros conteúdos externos não criptografados. O site quer avançar, mas admite que não é prático criptografar tudo o que está embutido em suas páginas.

A solução poderia ser emitir avisos aos leitores de que eles estão saindo de uma página criptografada para uma página de conteúdo desprotegido. No entanto, alguns navegadores se recusam a exibir páginas que possuem uma mistura de elementos criptografados e não criptografados – obstáculo que tem esfriado a experimentação por parte de alguns sites de notícias.

“Tecnicamente, isso é algo muito difícil de fazer, e muitos sites resistem”, afirma Matthew Prince, diretor-executivo da CloudFlare, empresa que fornece conteúdo criptografado para sites de forma segura e sem grandes custos extras. Ele disse que menos de três milhões dentre os cerca de 650 milhões de sites existentes fazem uso do SSL, a forma mais popular de criptografia.

Vigilância em massa

Sites que criptografam o tráfego ainda são capazes de rastrear seus usuários para coletar informações valiosas. O Google, por exemplo, adota a criptografia por padrão, mas também analisa e-mails, consultas de pesquisa e navegação de seus usuários em busca de pistas para veicular anúncios personalizados. É assim que a empresa gera seus lucros multibilionários.

Jornalistas e executivos de mídia têm demorado a compreender o papel que desempenham na vigilância crescente na Internet. A questão é simples: no instante em que os jornais colocam seu trabalho online, as escolhas dos leitores ficam expostas à coleta e análise em potencial. Ainda que a criptografia não seja perfeita, a implantação de rotina desta tecnologia ao menos dificulta a vigilância em massa.

 The Washington Post, 4/4/141

Tradução: Fernanda Lizardo, edição de Leticia Nunes. Com informações de Craig Timberg [“In a prying world, news organizations are struggling to encrypt their online products”,5/04/2014 na edição 794

Entendendo e resolvendo o problema da Vulnerabilidade #Heartbleed

A Vulnerabilidade Heartbleed é um bug severo na popular biblioteca de criptografia chamada OpenSSL. 














A falha permite roubo de informação protegida pelas criptografias nos protocolos SSL/TLS, esta que é de comum uso para segurança na internet. Os protocolos SSL/TLS fornecem comunicação segura e privacidade em conexões de internet, muito utilizados em aplicações web, email, mensageiros instantâneos (IM) e redes de comunicação privadas (VPNs).

Este bug permite que qualquer pessoa na internet seja capaz de ler uma parte da memória ram dos sistemas protegidos pelo OpenSSL. Assim comprometendo as chaves de identificação que os serviços utilizam para criptografar o tráfego, este que pode conter usuários, senhas e o conteúdo enviado pelo usuário. Isso permite que invasores que estão monitorando sua comunicação, sejam capazes de roubar suas informações que estariam criptografadas inicialmente.

Como posso identificar sites vulneráveis?

Existe uma lista com os principais sites do mundo que estão sofrendo verificações periódicas, você pode ver esta lista aqui: https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt

Também é possível testar um site específico de sua preferência por uma ferramenta chamada Heartbleed Test

Além disso você pode instalar uma extensão para o Google Chrome que irá te avisar se o site navegado está vulnerável: ChromeBleed

O que é CVE-2014-0160?

CVE-2014-0160 é a referência oficial da falha. CVE (Common Vulnerabilities and Exposures, Vulnerabilidades e Exposições públicas) é um padrão para catalogar e padronizar as vulnerabilidades de segurança da informação, a CVE é mantida pelo MITRE. Como houve uma dupla descoberta da falha, existe um outro registro de CVE , o CVE-2014-0346, este que não deve ser utilizado, pois a falha se tornou pública pelo CVE-2014-0160.

Por quê esta falha é chamada de Heartbleed?

A falha está na implementação TLS/DTLS proveniente da extensão heartbeat (RFC6520) do OpenSSL. Quando ela é explorada ela vaza informações da memória do servidor para o cliente, assim como do cliente para o servidor. Pelo fato do vazamento, bleed em inglês e o nome da extensão se chamar heartbeat, a faha foi apelidada de Heartbleed.

O que torna a falha Heartbleed única?

A falha está presente apenas em um software, este que já está corrigido nas versões mais novas, porém esta falha permitiu que uma enorme quantidade de chaves privadas de criptografia fossem expostas a internet, considerando esta exposição e a facilidade de ataque e exploração da falha de forma imperceptível, tornou esta falha extremamente séria e perigosa.

Isso é uma falha na concepção da especificação do protocolo SSL/TLS?

Não. Este é um problema de implementação, no caso, um erro de programação na popular biblioteca OpenSSL, que provê serviços de criptografia como o SSL/TLS para aplicações e serviços.

Na prática, como a negação e a reemissão dos certificados funciona?

Se você é um provedor de serviços, em algum momento você se registrou com a sua autoridade de Certificado digital ( Certificate Authority (CA)). Então você deve checar como chaves comprometidas podem ser checadas e reemitidas. Algumas CAs fazem esta reemissão de forma gratuida, outras cobram.

Eu estou afetado pela vulnerabilidade?

É provável que você seja afetado direto ou indiretamente. A OpenSSL é a mais popular biblioteca de criptografica e implementação TLS (Segurança da camada de transporte) de código aberto utilizada em encriptação de tráfico na internet. Sua rede social, o site da sua empresa, os sites comerciais, sites que você utiliza para instalar softwares ou até os sites que seu governo utiliza estão vulneráveis com o OpenSSL. Muitos serviços online usam TLS para identificar eles mesmo para você e para proteger sua privacidade e suas transações. Você pode ter soluções em rede com logins protegidos pela implementação do TLS com a vulnerabilidade. Além disso você pode ter aplicações no seu computador que poderiam expor seus dados se você estiver conectado a serviços comprometidos.

O quão a falha está difundida?

Software mais notável usando OpenSSL são os servidores web de código aberto como Apache e nginx. A combinação desses dois servidores detém aproximadamente 66% dos sites ativos na internet, veja Netcraft\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'s April 2014 Web Server Survey. Além disso o OpenSSL é utilizado para proteger por exemplo: servidores de e-mail (protocolos SMTP, POP e IMAP), servidores de bate-papo (protocolo XMPP ), rede virtual privada (SSL VPNs), soluções de rede e uma ampla variedade de aplicações ao lado do cliente. Felizmente grandes sites comerciais estão salvos pela escolha conservadora de seus equipamentos de terminais SSL/TLS e software. Ironicamente serviços menores e mais progressivos ou aqueles que atualizaram para a melhor e última criptação serão os mais afetados. Além disso o OpenSSL é muito popular em aplicações do lado do cliente e de alguma forma popular em soluções de rede que são mais atraídos em se atualizar.

Quais as versões afetadas do OpenSSL?

Relação de diferentes versões: 

OpenSSL 1.0.1 até 1.0.1f (inclusive) estão vulneráveis 

OpenSSL 1.0.1g NÃO está vulnerável 

OpenSSL ramificação 1.0.0 NÃO está vulnerável 

OpenSSL ramificação 0.9.8 NÃO está vulnerável 

A falha está incluída no OpenSSL desde dezembro de 2011, e foi amplamente difundida desde o OpenSSL versão 1.0.1 de 14 de março de 2012. A versão do OpenSSL 1.0.1g que foi liberada em 7 de abril de 2014 contém a correção da falha.

Quão difundidas são as versões vulneráveis do OpenSSL?

As versões vulneráveis estão disponívels há dois anos agora e elas foram adotas rapidamente pelos sistemas operacionais modernos. O maior fator de contribuição foi que as versões TLS 1.1 e 1.2 ficaram disponíveis com a primeira versão OpenSSL (1.0.1) vulnerável e a comunidade de segurança vem forçando a TLS 1.2 devido a ataques mais antigos contra TLS (como o BEAST).

E os Sistemas Operacionais?

Algumas distribuições de sistemas operacionais que possuem a versão com a vulnerabilidade no OpenSSL: 

Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4 

Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11 

CentOS 6.5, OpenSSL 1.0.1e-15 

Fedora 18, OpenSSL 1.0.1e-4 

OpenBSD 5.3 (OpenSSL 1.0.1c 10 maio 2012) e 5.4 (OpenSSL 1.0.1c 10 maio 2012) 

FreeBSD 10.0 - OpenSSL 1.0.1e 11 fevereiro 2013 

NetBSD 5.0.2 (OpenSSL 1.0.1e) 

OpenSUSE 12.2 (OpenSSL 1.0.1c) 

Algumas distribuições de sistemas operacionais que NÃO possuem a versão com a vulnerabilidade no OpenSSL: 

Debian Squeeze (Versão estável antiga), OpenSSL 0.9.8o-4squeeze14 

SUSE Linux Enterprise Server 

FreeBSD 8.4 - OpenSSL 0.9.8y 5 fevereiro de 2013 

FreeBSD 9.2 - OpenSSL 0.9.8y 5 fevereiro de 2013 

FreeBSD Ports - OpenSSL 1.0.1g (Em 7 de abril às 21:46:40 2014 UTC) 

Como o OpenSSL pode ser corrigido?

Mesmo que a correção pareça trivial, o time da OpenSSL está expert em resolver de maneira apropriada a falha, assim a última versão 1.0.1g ou mais novas devem ser usadas por estarem corrigidas. Se isso não for possível, desenvolvedores pode recompilar o OpenSSL sem o parâmetro do heartbeat utilizando a opção -DOPENSSL_NO_HEARTBEATS no momento da compilação.

A extensão heartbeat deve ser removida com o intuito de ajudar na deteção de serviços vulneráveis?

A recuperação dessa vulnerabilidade poderia beneficiar se a nova versão do OpenSSL corrigisse a falha como desabilitasse temporariamente o heartbeat até algumas futuras versões. Parece que a maioria se não quase todas implementações TLS que respondem a requisição heartbeat hoje são versões vulneráveis de OpenSSL. Se somente versões vulneráveis de OpenSSL continuassem a a responder ao heartbeat pelos próximos meses se tornaria mais factível alcançar proprietários de serviços vulneráveis.

É possível detectar se alguém aproveitou a falha e usou contra mim?

O abuso desta falha não deixa qualquer tipo de vestígio ou informações incomuns nos logs.

É possível que IDS/IPS possam detectar e bloquear o ataque?

Mesmo o conteúdo da requisição heartbeat seja encriptado ele tem seu próprio tipo de registro no protocolo. Isto deve possibilitar detecção de intrusos e a prevenção de sistemas (IDS/IPS) de ser treinado para detectar o uso da requisição heartbeat. Devido a criptografia diferenciar entre o uso legítimo e ataque não pode ser baseado no conteúdo da requisição, mas a invasão pode ser detectada pela comparação do tamanho da requisição pelo tamanho da resposta. Isso parece implicar que IDS/IPS pode ser programado para detectar a invasão mas não bloquear a menos que todas as requisições heatbeat sejam bloquedas juntas.

Já houveram muitos ataques?

Nós não sabemos. A comunidade de segurança deve implantar TLS/DTLS honeypots que capturam invasores e alertam sobre a tentativa de invasão.

O invasor pode acessar realmente só 64 kilobytes da memória?

Não há uma limitação de 64 kilobytes no ataque, esse limite se aplica somente a um único heartbeat. O invasor pode fazer diversas conexões durante uma sessão TLS ativa e continuar extraindo setores de 64 Kilobytes até que o conteúdo desejado seja totalmente revelado.

Este é um ataque man in the middle como ocorreu na Apple?

Não, essa vulnerabilidade não requer man in the middle (MITM). O invasor pode diretamente contatar o serviço vulnerável ou atacar qualquer usuário conectado a um serviço malicioso. Entretanto, além da ameaça direta o ladrão da chave possibilita aos invasores man in the middle personificar serviços comprometidos.

Os clientes de autenticação TLS conseguem lidar com isso?

Não, a requisição heartbeat pode ser enviada e respondida durante a etapa de pareamento do protocolo. Isso ocorre antes da autenticação do certificado do cliente.

O modo FIPS do OpenSSL consegue lidar com isso?

Não, o OpenSSL Federal Information Processing Standard (FIPS) não possui efeito algum sobre essa vulnerabilidade.

O Perfect Forward Secrecy (PFS) minimiza esta vulnerabilidade?

O uso do Perfect Forward Secrecy (PFS), o que, infelizmente, é raro mas poderoso, pode proteger comunicações antigas de descriptografia retrospectiva. Por favor, veja https://twitter.com/ivanristic/status/453280081897467905 como chaves que vazaram podem afetar este recurso.

A extensão heartbeat pode ser desabilitada durante o pareamento do protocolo TLS?

Não, o código da extensão vulnerável heartbeat é ativado independemente do resultado da etapa de negociação e pareamento. O único caminho para se proteger é fazendo a atualização para uma versão corrigida do OpenSSL ou recompilar o OpenSSL sem a extensão heartbeat.

Quem encontrou a vulnerabilidade Heartbleed?

Esta falha foi uma descoberta independente feita pelo time de engenheiros de segurança (Riku, Antti and Matti) no Codenomicon e Neel Mehta do Google Security, o qual foi o primeiro a reportar isso ao time da OpenSSL. O time da Codenomicon encontrou a vulnerabilidade heartbleed enquanto melhoravam o SafeGuard, recurso do Codenomicon\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\'s Defensics, ferramenta de testes de segurança que reportou essa falha ao NCSC-FI para a coordenação de vulnerabilidade e reportou ao time OpenSSL.

O que é Defensics SafeGuard?

A SafeGuard, recurso da Codenomicon Defensics, é uma ferramenta de segurança que automaticamente testa o sistema alvo procurando fraquezas que comprometam a integridade, proteção ou privacidade. Esta é uma solução sistemática que expõe falhas em certificados de criptografia, vazamentos de privacidade ou fraquezas na autenticação que tenham exposto os usuários da internet ao ataque man in the middle e ao hacking eavesdropping. Além da falha HeartBleed o novo recurso da Defensics TLS Safeguard pode detectar por exemplo a falha de segurança no amplamente utilizado GnuTLS, aplicação de código aberto que implementa a funcionalidade SSL/TLS no \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\"goto fail;\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\", falha na implementação TLS/SSL da Apple que foi corrigida em Fevereiro 2014.

Quem coordena a resposta a esta vulnerabilidade?

NCSC-FI tomou a tarefa de informar os autores do OpenSSL, softwares, sistemas operacionais e fornecedores de soluções, que foram potencialmente afetados. Entretanto, esta vulnerabilidade foi encontrada e os detalhes foram lançados de forma independente por outros, antes que este trabalho estivesse completo. Fornecedores de serviços pela internet devem notificar seus usuário onde e quando uma ação deve ser tomada.

Existe um lado bom de tudo isso?

Para aqueles provedores de serviços que foram afetados esta é uma boa hora de melhorar a segurança das chaves de criptografia utilizadas. Muitos softwares receberam updates, estes que geralmente não são atualizados. Mesmo que isso seja muito doloroso para a comunidade de segurança, nós temos certeza que a infra-estrutura de criminosos virtuais e seus segredos foram expostos também.

Onde encontrar mais informação?

Este Q&A foi publicado como sequência ao aviso da OpenSSL, desde de que sua vulnerabilidade tornou-se pública em 7 de abril de 2014. O projeto OpenSSL fez uma declaração oficial em seu site https://www.openssl.org/news/secadv_20140407.txt. NCSC-FI publicou um aviso em https://www.cert.fi/en/reports/2014/vulnerability788210.html. Fornecedores individuais de distribuições de sistemas operacionais, proprietários afetados de serviços de Internet, pacotes de software e fornecedores de soluções podem emitir seus próprios avisos.

Fonte: Via Alcyon Ferreira de Souza Junior  e  http://www.portaltic.com
http://heartbleed.com (texto original, publicado 7 de abril de 2014, ~19:00 UTC)
Renato Mendes Figueiredo | Renatomefi IT Solutions
Samuel Mendes
 https://github.com/renatomefidf/heartbleed