Uma nova vulnerabilidade envolvendo o SSL v3.0 foi divulgada pelo time de segurança da Google. Mais informações, e em inglês, logo abaixo:

Para quem não tem muito tempo para ler todo o texto ou que o inglês ainda está em desenvolvimento, a vulnerabilidade em questão pode ser explorada via o ataque Padding Oracle On Downgraded Legacy Encryption, daí o nome POODLE.

E a recomendação, até o momento, é que seja desabilitado o protocolo SSL v 3.0 de clientes e servidores, principalmente os web servers, como apache e nginx da vida. Email e seus protocolos também são afetados, já que muitos utilizam esta versão de protocolo para assegurar a comunicação entre seus usuários.

Dentro em breve, o pessoal que mantêm o openssl lançará uma nova versão, onde seremos obrigados a instalá-la e compilar tudo que funciona ou depende dele. Que lindo este mundo, não é mesmo…

Three researchers from Google have published findings about a vulnerability in SSL 3.0, a cryptographic protocol designed to provide secure communication over the internet. Although SSL 3.0 is nearly 15 years old, it’s still used all over the place – browsers, VPNs, email clients, etc. In other words, this bug is pretty widespread.


Successful exploitation of this vulnerability can result in an attacker exposing data encrypted between an SSL 3.0 compatible client and a SSL 3.0 compatible server.  We’re talking about the kind of data you encrypt because you want it to stay confidential. Overall, the issue is relatively difficult to exploit but you’re still going to want to address it quickly.

Where does the dog come in?

POODLE (Padding Oracle On Downgraded Legacy Encryption) is the attack that exploits this vulnerability. It allows an attacker to steal information over time by altering communications between the SSL client and the server (also known as a man in the middle attack, or MITM). This means that exploitation is NOT trivial; it takes some work.  That doesn’t necessarily mean its bark is worse than its bite given the type of information that can be stolen through successful exploitation, but it does limit the impact.


If both the client and server support SSL 3.0, the attacker can leak approximately one byte of clear-text for every 256 requests. To give you an idea of the amount of effort required to get anything useful out of this, it would take approximately 2,000 forced requests to leak enough data for the attacker to hijack a typical HTTP over SSL session. This would take a few minutes if exploited by a hostile website that was silently forcing connections to another server in the background.


A couple of additional notes on exploitability:

  • If SSL2 and SSL3 is disabled in the web browser, the issue is not exploitable
  • If SSL2 and SSL3 is disabled on the server, the issue is not exploitable

How do you muzzle the POODLE?


For Businesses


The recommendation is to disable SSL 3.0 on all clients and servers. We suggest you start with your most business critical, high value assets, eg. VPNs, PCI websites, Point of Sale systems, other line of business applications, etc.  Don’t forget about your STARTTLS-compliant services, such as IMAP, POP3, and SMTP.


Disabling SSL 3.0 on clients and servers is a change that will have impact and that you may need to stage over time. If you’re going to do this, it’s advisable to evaluate the likely impact for your internal and external customers and communicate clearly to them so they understand the implications too. Getting a log summary of which encryption ciphers clients and browsers are using will help you understand how many people will be impacted by SSL 3.0 being disabled. This will also potentially give you the ability to detect if the attack is happening over time.


One note: If for some reason you still have Windows XP users running Internet Explorer 6, this will prevent them from accessing TLS-only services. Keep in mind that these users will not be able access most of the internet once SSL 3.0 is blocked by major service providers. Windows XP users can switch to Chrome or Firefox as alternatives to Internet Explorer.


In cases where disabling SSL 3.0 is not possible, some workarounds have been provided, but they are generally not as effective.


Both Google and Akamai are recommending enabling TLS_FALLBACK_SCSV as a longer term solution, and are predicting the demise of SSL.

For Consumers

It’s pretty difficult for consumers to protect themselves.  There are options in Firefox and Chrome that enable you to turn SSL 3.0 off, but you need to set them up manually and most consumers probably won’t. Older network 2devices may only support SSL and disabling SSL 3.0 could prevent them from being able to configure their modem, router, or printer. This makes it even more imperative for businesses to protect their customers, and consumers should be looking to their vendors to provide updates on whether they have taken the necessary steps to protect themselves.


Encontrei neste link da rapid7


Atualização:  O pessoal da fundação Mozila acaba de passar mais detalhes sobre esta mesma vulnerabilidade e algumas recomendações para os usuários do seu browser, o Firefox.

Atualização 2: o artigo publicado pelo pessoal da openssl foundation e escrito pelo time da google que encontrou o problema.

Atualização 3:  O pessoal da netcraft acaba de informar que, muito provavelmente, esta nova vulnerabilidade afeta, nada mais nada menos, que 97% dos werb servers que rodam com HTTPS em todo o mundo. (Google’s POODLE affects oodles – 97% of SSL web servers likely affected. news)


As dicas para desabilitar o SSL 3.0 no firefox, nginx e apache encontram-se no link da netcraft indicado logo acima ou se preferir, neste link aqui.


Acabei colando o processo para desabilitar o SSL 3.0 no apache e no nginx, logo abaixo, para facilitar a vida da galera:

Disabling SSLv3 in nginx

Modify the ssl_protocols directive to only use TLSv1, TLSv1.1, and TLSv1.2. If you do not have a ssl_protocols directive, add it to the top of your configuration file.

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

Disabling SSLv3 in Apache

The SSL configuration file changed slightly in httpd version 2.2.23. For httpd version 2.2.23 and newer, specify TLSv1, TLSv1.1, and TLSv1.2.

SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2

For httpd version 2.2.22 and older, only specify TLSv1. This is treated as a wildcard for all TLS versions.

SSLProtocol TLSv1



Deixe um comentário