Tag Archives: SSL

The New 39-Month SSL Certificate Maximum Validity

Hacker Medic February 17, 2015 No Comments

Changes in CA/B Forum Baseline Requirements

Twitter Card Style:

summary

The past few years within the SSL certificate industry have been busy with changes. 1024-bit RSA certificates are long gone, using public SSL certificates on servers with internal domain names is starting to disappear, and the SHA-1 hash algorithm is starting to see its final days. So what is next?

Starting 1 April 2015, Certification Authorities (CAs) are not permitted to issue SSL certificates (issued from a public root) with a validity period greater than 39 months. SSL certificates have limited validity periods so that the certificate’s holder identity information is re-authenticated more frequently. Plus it’s a best practice to limit the amount of time that any key is used, to allow less time to attack it.

In line with the latest Certification Authority/Browser Forum Baseline Requirements, CAs will stop issuing 4 and 5-year SSL certificates in the near future. Symantec plans on eliminating these options in late February 2015 on all SSL management consoles. Extended Validation (EV) SSL certificates still have a max validity period of 27 months but Organizational Validated (OV) and Domain Validated (DV) certificates (DV not offered by Symantec) will have this new 39-month lifespan.

So how will this affect those who install SSL certificates? The average person installing certificates in a large enterprise will have to go through the enrollment process a little more often. If the organization on that level and scale finds this detracts from employee productivity they may want to look at leveraging Symantec Certificate Intelligence Center Automation. To someone in a small organization who only issues SSL certificates on a very infrequent basis, they may find themselves looking for SSL installation instructions a little more often. To help you, Symantec has always offered a wealth of information online via our Knowledge Base (the preceding site will be migrating to this location in the near future) and offers amazing support by phone.

Hourglass 350x350.jpg

Please let us know what you think below in the comment section.

Gogo Inflight Internet is Intentionally Issuing Fake SSL Certificates

Hacker Medic January 7, 2015 No Comments

Twitter Card Style:

summary

It was recently disclosed that Gogo, a provider of Wi-Fi Internet services on commercial aircraft, has been issuing spoofed SSL certificates for Google sites that were viewed by customers of Gogo’s service. It appears that Gogo Inflight Internet was acting as an SSL Man-in-the-middle (MITM), a technique used within some enterprises to allow themselves to inspect and control all web traffic, even traffic to secure web sites. To understand what this means, let me explain MITM in a bit more detail.

While not very common, there are enterprises that use SSL MITM technology to protect their employees and assets. For example, the enterprise can see when their employees visit sites that attempt to deliver malware to eventually block it. Some enterprises might want to ensure that their employees don’t visit inappropriate web sites using company equipment. The enterprise may also deploy a Data Loss Prevention (DLP) solution to guard against company secrets being divulged on public web sites. These uses are justified since the enterprise has an interest in securing its employees and their assets (laptops, desktops, corporate data, etc.)

Here’s how an SSL MITM works: a browser user tries to open an SSL connection to a web server. The connection attempt is intercepted by the SSL MITM, which opens its own SSL connection to the intended web server. When that web server returns its SSL certificate, the SSL MITM crafts a copy of the certificate using its own public-private key pair and signed by the SSL MITM’s private root certificate. It returns that copy of the certificate to the browser user, who sees a certificate containing the name of the intended web server. Essentially, two SSL connections are set up: one between the browser user and the SSL MITM, the other between the SSL MITM and the web server. The SSL MITM copies traffic back and forth between the parties so they are generally unaware of the SSL MITM. All SSL traffic is encrypted on the wire, but unencrypted in the SSL MITM. This allows the SSL MITM to see everything and even modify traffic in either direction.

It’s surprising to see a company use an SSL MITM with its customers. When used within an enterprise, the root certificate used by the SSL MITM can be installed and trusted in employee computers because the enterprise has complete control over those devices. But this can’t be done with the enterprise’s customers, who control their own devices. As a result, these customers will receive a warning when they visit a secure site intercepted by an SSL MITM. It’s clear from the screen shot in the articles related to this issue that the user’s browser warned them that the site’s certificate was signed by an untrusted issuer.

What’s not clear is if Gogo performed a man-in-the-middle interception only for YouTube, or only for Google web properties, or for all web properties secured by SSL. There’s no reason to expect that Gogo intercepted only YouTube traffic. If done for all SSL traffic, it’s likely that a Gogo customer visiting their bank online, for example, would be subject to the same SSL MITM. This would be worrisome, because Gogo would then be able to collect usernames and passwords used on all such sites. Gogo’s CTO said “Gogo takes our customer’s privacy very seriously”, but Gogo’s actions raise a red flag. They could possibly have access to customer data that has nothing to do with Gogo or its services, and Internet users in a post-Snowden era are less willing to trust third parties with their personal information.

Gogo has a legitimate interest in limiting or blocking video streaming, but the way they’ve done it is far overreaching. Perhaps they hoped that customers would avoid using YouTube when they saw a scary security warning. Sadly, an unintended side effect might be to train users to ignore and to click through those warnings, which is counterproductive to the industry’s push for better end-user practices. Ultimately this would devalue all legitimate SSL certificates, and weaken the Certificate Authority/Browser trust model that Certificate Authorities and browser vendors have built and strengthened over the past 15+ years.

We urge Gogo to reconsider their actions and deploy bandwidth limiting solutions that do not involve the use of spoofed SSL certificates.

SSL; More than Encryption

Hacker Medic December 3, 2014 No Comments

Twitter Card Style:

summary

While doing an online search for “SSL Certificates” and one of the ads said “$4.99, Why Pay More?” Without clicking on the ad I know what they are going to offer me; a simple domain validated (DV) SSL certificate. This certificate will encrypt my site’s traffic at a basic level but this isn’t 1997; the business climate and threat landscape have changed and so have our requirements for security. SSL is more than encryption. We have to consider trust, security, service, certificate management & reliability. While many Certification Authorities are cutting corners to compete with each other on price, Symantec is working around the clock to continually deliver best-in-class solutions. At Symantec we believe in these core factors as does 91% of the fortune 500 and 94 of the top 100 financial institutions in the world. Here’s why:

1. Increased End-Consumer Trust

Trust Seal — Trust seals suggest that websites are safe to interact with. The Norton Secured Seal has been shown through independent research to be the most recognized trust seal on the Internet. Offered only by Symantec, it is seen about 4 billion times per month on websites all around the world. The seal ensures visitors that they are communicating with organizations that not only encrypt their traffic but also are legitimate organizations that have gone through Symantec’s strong authentication screening as well.

Visual Cue — The “Green Bar” also represent that a site is trustworthy. With Symantec EV Certificates, browsers will change the color of the address bar to green, serving as a cue for safe interaction. DV certificates won’t provide for a visual cue to website visitors

2. Stronger Business Authentication and Website Security

Authentication — With every Symantec certificate, Symantec performs strong authentication to ensure that a website visitor can trust who they are communicating with. Security-minded organizations realize that encryption alone is not enough and require, as a matter of policy, that all certificates issued for their organization have strong authentication. On the other hand, domain validated certificates, like those that Let’s Encrypt intends to offer, will only provide encryption of data. Thus, they will not prevent a credit card number or password from going to an encrypted website that may be fraudulent.

Scanning and Alerts — Symantec products also secure customer websites with scanning for critical vulnerabilities and active malware. Symantec proactively notifies customers about security risks within a customer’s unique environment and provides guidance to ensure that such issues are quickly and easily resolved.

3. Simplified Certificate Management and Live Worldwide Support

Management Tools — Symantec enables customers to track and manage large volumes of certificates with a wide range of tools. Organizations are often burdened with the complexity of managing a variety of SSL certificates that may include of self-signed, client certificates or SSL certificates that chain up to public roots.

Accessible Technical Support — Symantec provides 24/7/365 support worldwide to ensure that customers’ sites stay up and running and secure, with an optional premium support that include SLA’s on problem escalation and resolution. This is a critical component for organizations that need to ensure that their website operations remain. A free offering like Let’s Encrypt rarely comes with any form of live support.

4. Powerful Technical Capabilities and Advanced Options

Client Ubiquity — As the longest operating Certification Authority, Symantec’s roots are in more clients than any other Certification Authority. Organizations that want to support Always on SSL and connectivity with the greatest number of users choose Symantec to secure their transactions.

Advanced Certificate Options — Symantec Secure Site Pro products include both RSA 2048 bit certificates and ECC 256 bit certificates which are optimal within Perfect Forward Secrecy. These high security, high performance certificates are the future of SSL/TLS encryption and Symantec’s ECC roots are in more clients than any other Certification Authority.

Best in Class Revocation — Symantec provides revocation information to clients through both the Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs). Both of these services are updated continually to communicate certificate revocation activity to clients worldwide. The services are tuned to provide the fastest response times possible. In the case of websites, OCSP response times can impact page load times and Symantec has invested in its infrastructure to provide OCSP responses in about 50 milliseconds for almost every major region in the world.

5. Reliable Security and Business Assurances

Warranties — Symantec offers the highest warranties of any Certification Authority. These warranties can cover customers for losses of up to $1,750,000 from incorrect information contained on Symantec certificates.

Military-Grade Data Centers — Symantec’s roots and signing services are protected by the most stringent physical, network, and logical security and process controls. The hardened facilities provide our customers with confidence that certificate issuance for their domains will not be compromised. With ten years of continuous uptime, Symantec’s robust continuity practices are the best in the industry.

Contractual Commitments — Symantec customers have a contractual commitment from Symantec to maintain their products for the term of their contract. Let’s Encrypt, as a non-profit, open-source Certification Authority, it will be difficult to offer such contractual guarantees, given the significant expenses associated with operating a publicly audited Certification Authority.

Focused investment – As the world’s largest security company, Symantec has both the resources and the motivation to ensure that the our SSL products are uncompromised. Vulnerabilities like Heartbleed have clearly demonstrated that, despite the good intentions of OpenSSL, a non-profit organization with limited resources will be challenged to keep up with the rapidly-changing security threat landscape.

Modern Security for Modern Needs

Companies that know security understand they need to use modern-day security solutions in today’s environment and that SSL is more than just simple encryption.Please keep all of these factors in mind as you are building out your webserver security plans.For more information on Symantec SSL, please visit our website.

Poodle: ???????? SSL ??????????????

Hacker Medic October 19, 2014 No Comments

SSL 3.0 の新しい脆弱性により、安全なはずの接続から攻撃者がデータを盗み出す可能性があります。

Poodle: Vulnerability in old version of SSL represents new threat

Hacker Medic October 16, 2014 No Comments

New vulnerability in SSL 3.0 can allow attackers to extract data from supposedly secure connections.

New vulnerability in SSL 3.0 can allow attackers to extract data from supposedly secure connec…

Poodle: Una vulnerabilidad en versión vieja de SSL representa nueva amenaza

Hacker Medic October 16, 2014 No Comments

Poodle, una vulnerabilidad descubierta recientemente en una versión antigua del protocolo SSL representa una amenaza para un gran número de servidores web.

“Poodle” security hole has a nasty bite

Avast Blog October 15, 2014 No Comments

A security hole called Poodle could allow hackers to take over your banking and social media accounts. Yesterday, Google researchers announced the discovery of a security bug in version 3 of the Secure Sockets Layer protocol (SSLv3). This web technology is used to encrypt traffic between a browser and a web site, and can give […]

“Poodle” security hole has a nasty bite

Avast Blog October 15, 2014 No Comments

The SSL 3.0 Vulnerability – POODLE Bug (AKA POODLEbleed)

Hacker Medic October 15, 2014 No Comments

A bug has been found in the Secure Sockets Layer (SSL) 3.0 cryptography protocol (SSLv3) which could be exploited to intercept data that’s supposed to be encrypted between computers and servers. Three Google security researchers discovered the flaw and detailed how it could be exploited through what they called a Padding Oracle On Downgraded Legacy Encryption (POODLE) attack (CVE-2014-3566).

Información sobre la vulnerabilidad POODLE (o POODLEbleed) del protocolo SSL 3.0

Hacker Medic October 15, 2014 No Comments

Se ha detectado una vulnerabilidad que afecta al protocolo criptográfico Secure Sockets Layer 3.0 (SSLv3) y que podría utilizarse para interceptar los datos transmitidos de un equipo a un servidor o viceversa, que en principio deberían estar cifrados. Tres investigadores de seguridad de Google dieron recientemente con el problema, al que denominaron Padding Oracle On Downgraded Legacy Encryption (POODLE) y asignaron el identificador CVE-2014-3566.

Es importante recalcar que se trata de una vulnerabilidad del protocolo SSLv3, no de un defecto de los certificados SSL, de su diseño ni de sus claves privadas. Los certificados no presentan problema alguno y, aunque se utilicen para proteger servidores compatibles con el protocolo SSL 3.0, no es necesario sustituirlos.

Según parece, la vulnerabilidad no es tan grave como Heartbleed (que afectaba a OpenSSL), ya que, para explotarla, el atacante debe tener un rol privilegiado en la red. No obstante, el riesgo de que se produzca un ataque de interposición «Man-in-the-Middle» aumenta si se utilizan puntos de acceso o redes Wi-Fi públicas.

Información adicional

Aunque SSL 3.0 es un protocolo criptográfico bastante antiguo (se introdujo en 1996), según el último informe de Netcraft, casi el 95 % de los navegadores web siguen permitiendo su uso. Al conectarse con servidores antiguos, muchos clientes que usan habitualmente el cifrado TLS (Transport Layer Security) pasan a utilizar automáticamente SSL 3.0, que resulta menos seguro. Según Google, un atacante que controle la red mediante la que se conectan el equipo y el servidor podría interferir con el handshake (el proceso que comprueba qué protocolo criptográfico admite el servidor) y hacer que la transmisión de datos se proteja con el protocolo SSL 3.0 en vez de usar otro más reciente. Un ataque de interposición «Man-in-the-Middle» realizado en estas condiciones permite descifrar las cookies HTTP seguras y, de este modo, robar datos o apropiarse de cuentas de servicios online. En el momento en el que se redactó esta entrada, muchos administradores de sitios web ya habían tomado medidas para que el servidor utilizara obligatoriamente el protocolo TLSv1 o versiones posteriores en lugar de SSL 3.0, pero no todo el mundo reacciona con la misma rapidez. Heartbleed ya demostró que las grandes empresas responden enseguida a problemas de este tipo, pero las de menor tamaño suelen tardar más en resolver las vulnerabilidades críticas.

Recomendaciones para las empresas

Para reducir los riesgos, recomendamos:

usar la caja de herramientas de SSL, un recurso gratuito de Symantec, para comprobar si los servidores web de la empresa corren peligro;
utilizar herramientas compatibles con el mecanismo TLS_FALLBACK_SCSV, que impide que los atacantes obliguen a los navegadores web a establecer una conexión mediante el protocolo SSL 3.0;
desactivar el uso de conexiones SSL 3.0 o el cifrado en modo CBC con SSL 3.0;
usar un firewall para aplicaciones web basado en la nube para extremar las precauciones (más información en nuestro sitio web);
desconfiar de los mensajes sospechosos, ya que habrá quien pretenda aprovecharse de la incertidumbre y de la falta de conocimientos técnicos de algunas personas.

Mi compañero Christoffer Olausson aconseja lo siguiente para resolver el problema en Apache:

> SSLProtocol All -SSLv2 -SSLv3 <- Elimina SSLv2 y SSLv3

> apachectl configtest <- Prueba la configuración

> sudo service apache restart <- Reinicia el servidor

Google ya ha anunciado que, en cuestión de unos meses, sus productos dejarán de ser compatibles con el protocolo SSL 3.0, y Mozilla también ha anunciado que Firefox 34 (que saldrá a finales de noviembre) tampoco admitirá su uso.

Recomendaciones para los internautas

En el caso de los internautas, Symantec recomienda:

comprobar si el navegador que usan permite el uso del protocolo SSL 3.0 (por ejemplo, en Internet Explorer se puede comprobar yendo a Opciones de Internet > Opciones avanzadas);
asegurarse de que la URL de los sitios web que visitan empiece siempre por «https», lo que reduce el riesgo de ataques «Man-in-the-Middle»;
estar pendiente de los avisos que reciban de sus proveedores de servicios y cambiar las contraseñas o actualizar el software si es necesario;
comprobar la procedencia de los mensajes de correo electrónico en los que se solicita un cambio de contraseña y asegurarse de que los enlaces conducen al sitio web oficial, ya que podría tratarse de intentos de phishing.

Más información

Symantec ya ha publicado varios artículos relacionados con este tema en la base de conocimientos.

Artículo para usuarios de Symantec Managed PKI for SSL

https://knowledge.verisign.com/support/mpki-for-ssl-support/index?page=content&id=AR2182

Artículo para usuarios de Symantec Trust Center/Trust Center Enterprise

https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR2183

Manténgase al tanto de las novedades

¿Quiere que le informemos de todo lo relacionado con esta u otras vulnerabilidades? Síganos en Twitter o Facebook. Si tiene algún problema para gestionar sus certificados SSL o Code Signing, le invitamos a pasarse por nuestros foros técnicos.