Resumen de seguridad de septiembre de 2020

¡Bienvenido a la edición de septiembre del Resumen de seguridad mensual de SSL.com! Hoy hablaremos de:

¡Anunciamos el boletín de SSL.com!

¡SSL.com se enorgullece de anunciar nuestro nuevo boletín mensual por correo electrónico! Cada mes le enviaremos noticias e información sobre seguridad en Internet, PKIy certificados digitales, junto con información sobre nuevos productos y servicios ofrecidos por SSL.com. Para registrarse, simplemente complete el formulario a continuación. (Puede darse de baja fácilmente en cualquier momento haciendo clic en el darse de baja enlace en cada correo electrónico que enviamos.):




CA / B Forum Ballot SC30: Cambios en las pautas del certificado SSL con EV

En noticias de interés para SSL.com's SSL EV clientes, la versión actual (1.7.3) de CA / Browser Forum's Directrices del certificado SSL con EV, que entró en vigor el 20 de agosto de 2020, tiene algunos requisitos nuevos. Específicamente, como se describe en CA / B Forum Boleta SC30, las autoridades de certificación (CA), como SSL.com, ahora deben publicar la lista de agencias de registro e incorporación que utilizan al validar las solicitudes de certificado SSL con EV. (La medida está en línea con un objetivo más amplio de hacer que las fuentes de validación de EV sean consistentes entre las CA).

Como resultado, SSL.com publicará una lista de las fuentes de información que usamos al validar empresas y otras organizaciones para certificados EV. Cuando no podamos ubicar la organización de un solicitante en nuestra lista actual de fuentes, intentaremos ubicar otra fuente de información viable y agregarla a nuestra lista publicada antes de validar el pedido y emitir el certificado.

Para llevar de SSL.com: SSL.com apoya estos cambios en las pautas de SSL con EV y votó "sí" en la boleta SC30, que fue aprobada por unanimidad por la CA y los miembros del navegador del Foro CA / B. Si tiene alguna pregunta sobre estos cambios y cómo podrían afectarlo, no dude en contactarnos en Support@SSL.com.

Rusia planea prohibir protocolos que ocultan el destino del tráfico

Esta historia puede parecerle familiar si se ha mantenido al día con las noticias de seguridad digital. De hecho, el mes pasado informamos en una historia de que el "Gran Cortafuegos" de China ahora bloquea el tráfico HTTPS que usa TLS 1.3 y ENSI (Indicación de nombre de servidor cifrado) en un esfuerzo por facilitar a los censores chinos ver qué sitios están intentando visitar los ciudadanos y controlar el acceso a dichos sitios.

Este mes, un informe de Catalin Cimpanu en ZDNet explicó que Rusia ahora está buscando prohibir el uso de algunos protocolos con una actualización de las leyes de tecnología que "harían ilegal el uso de protocolos de cifrado que oculten completamente el destino del tráfico". Como se señala en el artículo, estos protocolos incluirían TLS 1.3, Departamento de Salud, DoT y ESNI. El razonamiento es, por supuesto, muy parecido al razonamiento detrás de la prohibición de China: los protocolos impiden el alcance de la vigilancia y la censura por parte del estado. Del artículo:

Rusia no usa un sistema de firewall nacional, pero el régimen de Moscú se basa en un sistema llamado SORM que permite a las fuerzas del orden interceptar el tráfico de Internet con fines de aplicación de la ley directamente en la fuente, en los centros de datos de telecomunicaciones.
Además, el Ministerio de Telecomunicaciones de Rusia, Roskomnadzor, ha estado ejecutando un firewall nacional de facto a través de su poder regulador sobre los ISP locales. Durante la última década, Roskomnadzor ha estado prohibiendo los sitios web que considera peligrosos y pidiendo a los ISP que filtren su tráfico y bloqueen el acceso a los sitios respectivos.
Con un TLS 1.3, DoH, DoT y ESNI se están adoptando, todas las herramientas de vigilancia y censura actuales de Rusia se volverán inútiles, ya que dependen de tener acceso a los identificadores de sitios web que se filtran del tráfico web cifrado.

La ley se encuentra actualmente bajo consideración, pendiente de comentarios del público, y se volverá a votar a principios de octubre. ZDNet señala que, dado el clima, "es casi seguro que la enmienda se aprobará".

Para llevar de SSL.com: Como las noticias del mes pasado sobre China Gran cortafuegos, este es otro ejemplo de un estado autoritario que espía las actividades en línea de sus ciudadanos. SSL.com se mantiene firme en su oposición a la vigilancia gubernamental de la navegación web.

Nuevo TLS Ataque: mapache

Ya tenemos un del blog sobre el "ataque de mapache", pero vale la pena mencionarlo nuevamente, ya que el ataque puede permitir que terceros rompan SSL /TLS cifrado para leer la comunicación destinada a mantenerse segura. Como se explica en un artículo académico, el ataque explota una vulnerabilidad de sincronización en TLS versiones 1.2 y anteriores, y podría descifrar comunicaciones que incluyen nombres de usuario, contraseñas, datos de tarjetas de crédito y otra información confidencial. De nuestra publicación a principios de este mes:

Si bien suena aterrador, tenga en cuenta que este ataque solo puede tener lugar en circunstancias muy específicas y raras: el servidor debe reutilizar claves públicas Diffie-Hellman en el apretón de manos (ya se considera una mala práctica), y el atacante debe ser capaz de realizar mediciones de tiempo precisas. Además, el navegador debe admitir los conjuntos de cifrado vulnerables (a partir de junio de 2020, todos los navegadores principales los han descartado).

Para llevar de SSL.com: Aunque las posibilidades de un ataque de mapache exitoso son raras, hay algunas cosas simples que puede hacer para prevenirlo por completo: Desactivar TLS 1.2 o asegúrese de que su servidor no reutilice claves públicas Diffie-Hellman. Por favor vea nuestro del blog para obtener más información.

Internet de las cosas (vulnerables), Coffee Maker Edition

Si bien la historia anterior no fue sobre los ataques de los mapaches, esta historia es realmente sobre cafeteras. Para ser más precisos, el artículo de Dan Goodin en Ars Technica se trata de cómo una cafetera se convirtió en una "máquina de rescate" aprovechando las debilidades comunes en los dispositivos de Internet de las cosas (IoT).

Básicamente, el iKettle de los productos Smarter (mal nombrado) ha sido durante mucho tiempo un objetivo para aquellos que buscan ilustrar los peligros de los dispositivos fáciles de piratear. Desde 2015, versiones del hervidor han sido requisados ​​de forma remota mediante ingeniería inversa. Aunque la compañía ha lanzado una nueva versión del bote desde entonces, las viejas todavía están en uso, y son vulnerables a lo que las notas del artículo son ataques "listos para usar". Recientemente, un programador llamado Martin Hron decidió probar los límites de cómo se vería una brecha de seguridad en una cafetera, en el peor de los casos:

Cuando Hron conectó por primera vez su cafetera Smarter, descubrió que inmediatamente actuaba como un punto de acceso Wi-Fi que usaba una conexión no segura para comunicarse con una aplicación de teléfono inteligente. La aplicación, a su vez, se utiliza para configurar el dispositivo y, si el usuario lo elige, conectarlo a una red Wi-Fi doméstica. Sin cifrado, el investigador no tuvo problemas para aprender cómo el teléfono controlaba la cafetera y, dado que tampoco había autenticación, cómo una aplicación de teléfono no autorizada podía hacer lo mismo.
Esa capacidad todavía dejaba a Hron con solo un pequeño menú de comandos, ninguno de ellos especialmente dañino. Entonces examinó el mecanismo que usaba la cafetera para recibir actualizaciones de firmware. Resultó que se recibieron desde el teléfono, lo adivinó, sin cifrado, sin autenticación y sin firma de código.

Hay una publicación de blog extensa sobre el truco de la cafetera llamada "El fresco olor del café rescatado. " Hay también un video divertido demostrando el caos que siguió a la explotación de las vulnerabilidades de la máquina de café. Si bien es poco probable que un ataque como este llegue pronto a la cocina de alguien, es un buen recordatorio de que "inteligente" significa más que "conveniente".

Para llevar de SSL.com: Este experimento y artículo es una ventana a lo que podría ser posible en el mundo en expansión de Internet de las cosas. Hay mucho en el artículo y el blog de Ars Technica sobre cómo uno puede estar mejor a salvo, y le sugerimos que lea tanto para obtener ideas prácticas como un marco para pensar sobre lo que invitamos a nuestros hogares a medida que se vuelven "más inteligentes" y más inteligente.

Para los fabricantes de IoT, SSL.com ofrece todas las herramientas y experiencia necesario para proteger los dispositivos con certificados X.509 de confianza. Consulte estos artículos de SSL.com para obtener mucha más información:

Suscríbase al boletín de SSL.com

No se pierda los nuevos artículos y actualizaciones de SSL.com

Nos encantaría recibir tus comentarios

Responda nuestra encuesta y háganos saber lo que piensa sobre su compra reciente.