Raspberry Pi OS 2026-04-13 ya está disponible. Esta versión introduce mejoras generales en el sistema y en el centro de control, pero destaca especialmente por un ajuste clave en la gestión de privilegios. La decisión responde al aumento de amenazas de ciberseguridad y a la necesidad de evitar accesos indebidos en dispositivos que se utilizan en entornos educativos, domésticos o profesionales.

El cambio más relevante es que el uso de sudo sin contraseña queda desactivado por defecto en nuevas instalaciones. Esto significa que, a partir de ahora, los usuarios deberán introducir su contraseña cada vez que ejecuten comandos con privilegios de administrador. La medida busca evitar accesos no autorizados si alguien accede al dispositivo, ya sea de forma física o remota.

Hasta ahora, Raspberry Pi OS permitía ejecutar tareas administrativas sin autenticación adicional, lo que facilitaba el uso diario, especialmente para quienes están aprendiendo. Sin embargo, ese enfoque podía facilitar abusos si el sistema caía en manos equivocadas. Con este cambio, el sistema se alinea con otras distribuciones Linux donde introducir la contraseña al usar sudo es una práctica estándar. Además, tras introducirla por primera vez, la contraseña no será necesaria durante un breve periodo, lo que mantiene un equilibrio entre seguridad y comodidad.

Para quienes prefieran el comportamiento anterior, los desarrolladores han añadido una opción para reactivar el modo sin contraseña desde el centro de control o mediante herramientas como raspi-config. Esto demuestra que la prioridad actual es la seguridad, pero se mantiene la flexibilidad para distintos perfiles de usuario.

En conjunto, Raspberry Pi OS 2026-04-13 no solo trae mejoras visuales y de rendimiento, sino que marca un paso importante hacia sistemas más seguros por defecto, algo cada vez más necesario en un ecosistema de dispositivos conectados. Si gestionas equipos en un entorno educativo o corporativo, esta tendencia refuerza la recomendación de adoptar buenas prácticas de autenticación y actualizaciones regulares.

from Linux Adictos https://ift.tt/TWRrIHS
via IFTTT

La llegada de OpenSSL 4.0 marca una ruptura importante con versiones anteriores de esta biblioteca de referencia para SSL/TLS y criptografía, ampliamente usada en servidores web, aplicaciones empresariales y dispositivos de red. El salto de versión mayor no es solo simbólico: arrastra cambios incompatibles, nuevas funciones centradas en privacidad y seguridad futura, y la retirada de tecnologías que llevaban años en desuso.

Para administradores de sistemas, responsables de ciberseguridad y desarrolladores, esta versión supone un punto de inflexión a la hora de actualizar infraestructuras: introduce mejoras como Encrypted Client Hello y soporte avanzado de criptografía post‑cuántica, pero también elimina soporte para protocolos antiguos, el sistema de engines y varias APIs, obligando a revisar el código y los procesos de compilación antes de dar el salto.

Novedades principales de OpenSSL 4.0

La rama 4.0 de OpenSSL se presenta como una actualización de gran calado, con un enfoque claro en reforzar la privacidad, modernizar la base de código y limpiar lastre heredado. El equipo del proyecto ha aprovechado el cambio de versión mayor para introducir modificaciones incompatibles, eliminar soporte para plataformas marginales y ajustar el comportamiento por defecto de varios componentes internos.

Entre los cambios más visibles se encuentra la incorporación de Encrypted Client Hello (ECH), la ampliación del catálogo de algoritmos para entornos post‑cuánticos, la deprecación y eliminación de funciones históricas en el tratamiento de certificados y tiempos X.509, así como la revisión de opciones de compilación, scripts y objetivos de construcción en distintos sistemas operativos.

Privacidad reforzada con Encrypted Client Hello (ECH)

Uno de los avances más comentados es la integración de Encrypted Client Hello conforme al RFC 9849. ECH permite cifrar el mensaje Client Hello de TLS, de modo que un observador pasivo en la red no pueda acceder al Server Name Indication (SNI), es decir, al nombre del servidor al que se conecta el cliente.

Este cambio es especialmente relevante, donde la protección de la privacidad y los metadatos de conexión tiene un peso creciente en el marco regulatorio y en las políticas de muchas organizaciones. La adopción de ECH contribuye a reducir la capacidad de terceros para perfilar el tráfico TLS identificando dominios concretos a los que acceden usuarios y empresas.

Con OpenSSL 4.0, los desarrolladores que implementen ECH podrán ocultar información sensible del handshake inicial, dificultando la inspección pasiva e incrementando el nivel de confidencialidad de las conexiones, tanto en servicios públicos como en entornos corporativos donde se prioriza el cumplimiento normativo y la protección de datos.

Adiós a SSLv3, SSLv2 Client Hello y al sistema de engines

La nueva versión rompe definitivamente con parte del pasado del protocolo, ya que elimina el soporte para SSLv3, un estándar que llevaba años considerado inseguro y que estaba deshabilitado por defecto en OpenSSL desde la versión 1.1.0. De este modo, cualquier aplicación que todavía dependiera de SSLv3 tendrá que migrar a TLS moderno para poder funcionar con la rama 4.0.

También desaparece el soporte para el Client Hello de SSLv2, que se mantenía por compatibilidad histórica pero estaba completamente fuera de las prácticas recomendadas de seguridad. Su retirada contribuye a reducir la superficie de ataque y simplificar el código, alineando OpenSSL con las exigencias actuales de cifrado robusto en infraestructuras.

Otro cambio estructural es la eliminación completa del engine API utilizado para integrar hardware y software criptográfico externo. A partir de OpenSSL 4.0, la opción de compilación no-engine pasa a ser la única disponible, y la macro OPENSSL_NO_ENGINE está siempre presente. Esto obliga a revisar implementaciones que explotaban engines personalizados para tareas como aceleración criptográfica o uso de módulos HSM.

En paralelo, se recortan también métodos personalizados heredados de EVP_CIPHER, EVP_MD, EVP_PKEY y EVP_PKEY_ASN1, junto con métodos de versión SSL/TLS ya obsoletos y funciones de gestión de estados de error (como ERR_get_state() y sus variantes de eliminación de estado), consolidando una API más limpia y coherente con las necesidades actuales.

Impulso a la criptografía post‑cuántica y nuevos algoritmos

De cara al futuro, OpenSSL 4.0 avanza en su estrategia de prepararse frente a amenazas derivadas de la computación cuántica. La versión introduce nuevas capacidades de criptografía híbrida y digestión, orientadas a fortalecer los intercambios de clave ante posibles ataques en un escenario post‑cuántico.

Entre las novedades se incorpora el grupo de intercambio de claves híbrido curveSM2MLKEM768, que combina elementos clásicos con esquemas post‑cuánticos, así como el algoritmo de huella ML-DSA-MU y la función cSHAKE según NIST SP 800‑185. Estos elementos amplían las posibilidades para diseñar protocolos más resistentes a futuros avances criptanalíticos.

Además, el proyecto suma soporte para el intercambio de claves FFDHE negociado en TLS 1.2, siguiendo lo establecido en el RFC 7919. Esto permite a las implementaciones que aún operan con TLS 1.2 beneficiarse de mejores parámetros de Diffie‑Hellman de grupo finito, elevando el nivel de seguridad en escenarios donde la actualización inmediata a TLS 1.3 no es viable.

Cambios de API y comportamiento que afectan a integradores

Para quienes mantienen aplicaciones que enlazan con OpenSSL, la versión 4.0 introduce modificaciones directas en la API que pueden romper compilaciones existentes. Una de las transformaciones clave es que el tipo ASN1_STRING pasa a ser opaco, lo que limita el acceso directo a su estructura interna y obliga a utilizar funciones de alto nivel.

Muchas funciones, especialmente vinculadas al procesamiento de certificados X.509, incorporan ahora calificadores const en sus firmas, ajustando la semántica de inmutabilidad y forzando ajustes en código que hacía supuestos menos estrictos. Esto puede generar advertencias o errores de compilación en proyectos que no actualicen las definiciones correspondientes.

En el ámbito del control de tiempos, se han declarado obsoletas funciones como X509_cmp_time(), X509_cmp_current_time() y X509_cmp_timeframe(). El uso recomendado pasa a ser X509_check_certificate_times(), lo que implica adaptar rutinas de validación de certificados que hasta ahora se apoyaban en las funciones antiguas.

Otro punto relevante es que libcrypto deja de realizar limpieza global de datos asignados a través de atexit(). En su lugar, OPENSSL_cleanup() se ejecuta como un destructor global o no se lanza por defecto, dependiendo de la configuración. Esto puede afectar a aplicaciones que confiaban en la limpieza automática al finalizar el proceso, obligando a gestionar de forma más explícita el ciclo de vida de los recursos.

Asimismo, se elimina BIO_f_reliable(), una funcionalidad que llevaba rota desde la rama 3.0 y que ahora desaparece sin sustituto directo. Los proyectos que aún lo utilizasen tendrán que rediseñar la lógica asociada o adoptar otras primitivas de la biblioteca para cubrir necesidades similares.

Mayor rigor en verificación de certificados y derivación de claves

OpenSSL 4.0 refuerza la verificación estricta de certificados X.509 cuando se activa X509_V_FLAG_X509_STRICT. Con esta bandera habilitada, se ejecutan comprobaciones adicionales de la extensión AKID (Authority Key Identifier), endureciendo los criterios de validación y alineando la biblioteca con prácticas de seguridad más exigentes.

En el proceso de comprobación de listas de revocación (CRL), la nueva versión añade controles adicionales para asegurar que la validación de certificados revocados sea más exhaustiva. Estos cambios impactan en entornos donde la gestión de PKI es especialmente sensible, como administraciones públicas, banca o grandes corporaciones que dependen de cadenas de confianza robustas.

También se introducen límites inferiores obligatorios en el uso de PKCS5_PBKDF2_HMAC cuando se recurre al proveedor FIPS. Este ajuste busca evitar configuraciones demasiado débiles en la derivación de claves a partir de contraseñas, lo que en la práctica obliga a usar parámetros mínimamente fuertes en entornos donde se exige conformidad con FIPS, muy habituales en sectores críticos.

Ajustes en compilación, plataformas soportadas y herramientas

En la parte de compilación y soporte de plataformas, OpenSSL 4.0 da pasos hacia una configuración más moderna y simplificada. El proyecto deshabilita por defecto el soporte para curvas elípticas obsoletas en TLS, tal y como se precisa en el RFC 8422, así como el uso de curvas elípticas explícitas. No obstante, se mantienen opciones de configuración para quienes necesiten reactivarlas por motivos de compatibilidad puntual.

Respecto a los objetivos de construcción, se eliminan las variantes darwin‑i386 y darwin‑ppc, lo que deja fuera oficialmente a sistemas muy antiguos de Apple basados en arquitecturas i386 y PowerPC/PPC64. En la práctica, esto no debería afectar a la mayoría de despliegues actuales, donde esas plataformas llevan tiempo en desuso, pero formaliza su salida del soporte principal.

En cuanto a herramientas, se retira el script histórico , que pasa a ser la forma recomendada de generar índices de hashes para certificados en directorios. Además, para instalaciones FIPS se introduce la opción -defer_tests en la utilidad openssl fipsinstall, permitiendo aplazar ciertos auto‑tests, lo que puede facilitar despliegues en entornos con restricciones de tiempo de arranque.

En sistemas Windows, la actualización añade capacidad para elegir entre enlace estático o dinámico del runtime de Visual C++. Esta flexibilidad resulta útil para desarrolladores y equipos DevOps que empaquetan aplicaciones para diferentes escenarios de distribución, ya que pueden ajustar el tipo de runtime en función de requisitos de compatibilidad o tamaño de los binarios.

Impacto para organizaciones y desarrolladores

En el contexto donde gran parte de la infraestructura de Internet y servicios críticos se apoya en OpenSSL, la versión 4.0 supone un cambio estratégico que requiere planificación. Organizaciones públicas, proveedores cloud, entidades financieras y empresas tecnológicas deberán evaluar cuidadosamente los efectos de los cambios de API y la retirada de protocolos, especialmente en sistemas heredados o aplicaciones poco mantenidas.

La incorporación de ECH y el refuerzo de la criptografía post‑cuántica pueden verse como oportunidades para elevar el nivel de protección por defecto, pero al mismo tiempo exigen pruebas exhaustivas en entornos de preproducción. En muchos casos será necesario coordinar a equipos de desarrollo, seguridad y operaciones para garantizar que la transición no rompe servicios ni introduce regresiones.

Para proyectos open source que dependen fuertemente de OpenSSL, la adaptación implicará ajustar firmas de funciones, revisar el uso de tipos ahora opacos y sustituir componentes retirados como engines o funciones de tiempo X.509. La ventaja es que, una vez actualizados, estos proyectos se beneficiarán de una base criptográfica más alineada con los estándares actuales y con menor deuda técnica.

En conjunto, OpenSSL 4.0 se posiciona como una versión de limpieza, modernización y preparación a medio y largo plazo, que obliga a invertir esfuerzo en migración pero ofrece a cambio mejoras claras en privacidad, seguridad y coherencia interna de la biblioteca, aspectos clave para seguir sosteniendo la infraestructura digital sobre cimientos criptográficos sólidos.

from Linux Adictos https://ift.tt/cUqOxJB
via IFTTT

La aparición de GPT-5.4-Cyber marca un nuevo capítulo en el uso de la inteligencia artificial para la ciberseguridad. OpenAI ha comenzado a probar esta variante de su modelo insignia GPT-5.4 en un entorno muy controlado, con el objetivo de reforzar la defensa de sistemas críticos frente a vulnerabilidades de software cada vez más sofisticadas.

El modelo llega en un momento en el que crece la preocupación por el doble uso de la IA, capaz tanto de reforzar la seguridad como de facilitar ciberataques. En este contexto, OpenAI apuesta por un despliegue escalonado y por requisitos estrictos de acceso, buscando un equilibrio entre aprovechar el potencial de la tecnología y reducir al mínimo los riesgos asociados.

Qué es GPT-5.4-Cyber y en qué se diferencia del GPT-5.4 estándar

GPT-5.4-Cyber es una versión ajustada específicamente para ciberseguridad del modelo GPT-5.4. No se trata de un sistema pensado para el público general, ni para el uso cotidiano en chatbots, sino de una herramienta dirigida a equipos especializados en defensa digital, auditoría de código y análisis de vulnerabilidades.

OpenAI describe esta variante como un modelo “ciberpermisivo”, es decir, con un umbral de rechazo más bajo para solicitudes relacionadas con trabajos legítimos de ciberseguridad. Mientras que el GPT-5.4 convencional tiende a bloquear o limitar respuestas en tareas sensibles, GPT-5.4-Cyber acepta con mayor facilidad consultas avanzadas si se enmarcan en flujos de trabajo defensivos y de investigación.

La compañía explica que GPT-5.4-Cyber reduce las restricciones habituales en operaciones relacionadas con la identificación de fallos y el análisis técnico, pero manteniendo controles de acceso estrictos. El objetivo declarado es permitir pruebas más profundas, sin abrir la puerta indiscriminadamente a usos potencialmente dañinos.

Capacidades técnicas: análisis profundo de software y vulnerabilidades

Una de las características más destacadas de GPT-5.4-Cyber es su enfoque en tareas técnicas avanzadas de ciberseguridad. OpenAI señala que el modelo está optimizado para mejorar los flujos de trabajo defensivos y ofrece funciones que van más allá de la simple explicación de código.

Entre las capacidades clave se incluyen herramientas de ingeniería inversa binaria, que permiten a profesionales de seguridad analizar software ya compilado, sin necesidad de acceder al código fuente. Esto resulta especialmente relevante para revisar programas propietarios, componentes de terceros o binarios heredados en infraestructuras críticas.

El modelo puede asistir en la detección de posibles malware, vulnerabilidades y debilidades en la robustez del código, así como en la priorización de riesgos. Con ello, se pretende que los equipos de seguridad puedan localizar fallos con mayor rapidez y evaluar su impacto potencial antes de que sean explotados.

Además del análisis binario, GPT-5.4-Cyber está diseñado para auditar configuraciones, revisar patrones en el comportamiento del software y apoyar tareas de evaluación de riesgos en entornos complejos. El modelo actúa como una especie de asistente técnico de alto nivel, capaz de combinar conocimiento general de seguridad con detalle técnico específico de cada entorno.

Despliegue limitado: quién puede acceder a GPT-5.4-Cyber

En esta fase inicial, OpenAI ha optado por un despliegue muy restringido de GPT-5.4-Cyber. El modelo se está poniendo a disposición de un grupo selecto de proveedores de seguridad, organizaciones e investigadores verificados, que deben superar un proceso de autenticación riguroso.

El acceso se articula a través del programa Trusted Access for Cyber (TAC), lanzado a comienzos de año. Este programa establece varios niveles de verificación, de forma que las capacidades más sensibles del modelo solo se desbloquean para aquellos usuarios que acreditan ser defensores de la ciberseguridad y aceptan trabajar estrechamente con OpenAI bajo condiciones específicas.

Según la compañía, el nivel más alto de verificación dentro de TAC es el que permite utilizar GPT-5.4-Cyber. Inicialmente, este sistema está siendo probado por cientos de usuarios, con la previsión de ampliar gradualmente el alcance a miles de especialistas y equipos responsables de proteger software crítico y servicios esenciales.

El planteamiento es claramente iterativo: OpenAI recopila comentarios de estos evaluadores para entender mejor los beneficios concretos del modelo, reforzar su resistencia frente a intentos de “jailbreak” u otros ataques adversarios y ajustar los límites de uso para evitar filtraciones o abusos.

Trusted Access for Cyber: un filtro de seguridad adicional

El programa Trusted Access for Cyber se ha convertido en el principal mecanismo de control para acceder a GPT-5.4-Cyber y a futuras herramientas similares. OpenAI plantea TAC como una vía para que organizaciones y expertos acreditados puedan probar modelos avanzados en condiciones supervisadas.

Dentro de TAC, los usuarios deben autenticarse como defensores de la ciberseguridad, demostrar experiencia en el ámbito y aceptar unas políticas de uso que restringen el empleo del modelo estrictamente a tareas defensivas y de investigación legítima. Solo tras cumplir esas condiciones se les permite acceder a variantes más potentes y menos limitadas.

La empresa detalla que GPT-5.4-Cyber forma parte de una ampliación del alcance de TAC, con nuevos niveles de acceso y una estructura más granular de permisos. En la práctica, esto se traduce en que no todos los integrantes del programa ven las mismas capacidades del modelo: únicamente los que alcanzan el máximo nivel pueden utilizar las funciones más sensibles, como el análisis binario avanzado.

Este modelo de gobernanza busca responder a un reto evidente: la misma tecnología que ayuda a defender sistemas podría, en manos equivocadas, servir para encontrar puntos débiles y preparar ataques. De ahí que la compañía insista en mantener el acceso cerrado a perfiles concretos, al menos durante las primeras fases.

Competencia con Anthropic y el papel de Mythos

El anuncio de GPT-5.4-Cyber llega apenas días después de que Anthropic diera a conocer Mythos, su propio modelo de ciberseguridad. Mythos se está desplegando bajo el paraguas del llamado Project Glasswing, una iniciativa en la que solo unas pocas organizaciones de confianza pueden experimentar con Claude Mythos Preview, aún no disponible de forma general.

Según la información publicada, Mythos habría detectado miles de vulnerabilidades críticas en sistemas operativos, navegadores y otras aplicaciones de software. Esto refuerza la idea de que tanto Anthropic como OpenAI están compitiendo de forma directa por liderar el uso de IA avanzada aplicada a la seguridad digital.

Project Glasswing está concebido como un entorno altamente controlado, similar al TAC de OpenAI, en el que socios seleccionados —incluyendo grandes tecnológicas y entidades que gestionan infraestructuras clave— ponen a prueba el modelo en escenarios reales. La atención que este proyecto ha generado en sectores como el financiero o el gubernamental, especialmente en Estados Unidos, pone de manifiesto el peso estratégico de estas herramientas.

Dentro de este contexto, GPT-5.4-Cyber puede interpretarse como la respuesta de OpenAI a la presión competitiva. La empresa reconoce que está ajustando GPT-5.4-Cyber para “allanar el camino” a modelos todavía más capaces que se presentarán en los próximos meses, lo que sugiere una hoja de ruta en la que la ciberseguridad tendrá un papel destacado.

Riesgos de doble uso y preocupación regulatoria

El desarrollo de modelos como GPT-5.4-Cyber o Mythos ha puesto sobre la mesa un debate delicado: las mismas capacidades que sirven para proteger sistemas permiten también identificar vulnerabilidades con un nivel de detalle que podría resultar muy útil para ciberatacantes.

Expertos y autoridades advierten de que la frontera entre uso defensivo y ofensivo se está difuminando. Herramientas capaces de localizar fallos críticos en cuestión de minutos, proponer vectores de explotación o automatizar análisis de gran escala pueden convertirse en armas muy eficaces en manos malintencionadas.

De hecho, empiezan a surgir indicios de que tecnologías de IA ya se están empleando para facilitar ataques informáticos, optimizar campañas maliciosas o escanear masivamente sistemas en busca de puntos débiles. Esto ha llevado a gobiernos y reguladores, especialmente en economías avanzadas, a reclamar marcos más estrictos de control y supervisión.

En Europa, aunque GPT-5.4-Cyber se está implantando inicialmente en un contexto global, el debate se cruza con la nueva regulación de IA impulsada por la Unión Europea. El enfoque comunitario, más restrictivo en materia de riesgos y transparencia, apunta a que herramientas de este tipo deberán someterse a evaluaciones específicas, sobre todo si se utilizan en sectores como el financiero, las telecomunicaciones o la gestión de infraestructuras críticas.

Impacto potencial en empresas y administraciones

Para empresas y administraciones públicas, la llegada de GPT-5.4-Cyber abre un escenario en el que la automatización avanzada del análisis de seguridad puede convertirse en un pilar de las estrategias de ciberdefensa.

Organizaciones con grandes bases de código heredado, sistemas complejos o dependencia de soluciones de terceros podrían beneficiarse especialmente de las capacidades de análisis binario, al permitirles revisar componentes para los que no disponen de código fuente o documentación completa. Esto es habitual en bancos, operadores energéticos, empresas de telecomunicaciones o administraciones con sistemas antiguos integrados en infraestructuras modernas.

Sin embargo, el acceso restringido y el énfasis en usuarios verificados significa que, al menos en el corto plazo, GPT-5.4-Cyber será una herramienta al alcance de equipos de seguridad especializados, más que de pequeñas empresas o perfiles generalistas. Es previsible que los primeros en probarlo en Europa sean grandes proveedores de ciberseguridad, operadores críticos y centros de respuesta a incidentes (CSIRT) con convenios o acuerdos específicos.

Además, las organizaciones europeas deberán encajar el uso de GPT-5.4-Cyber en su marco normativo, cumpliendo con las exigencias de protección de datos, gestión de riesgo de terceros y obligaciones de reporte de incidentes, que en la UE son cada vez más estrictas. La adopción de estas tecnologías no será solo una cuestión técnica, sino también de gobernanza y cumplimiento.

GPT-5.4-Cyber está diseñado para aprender de la práctica

OpenAI presenta GPT-5.4-Cyber como una pieza dentro de una estrategia más amplia orientada a modelos de IA más potentes y especializados. La compañía insiste en que la fase actual es de prueba controlada, en la que el feedback de proveedores y defensores de seguridad resulta clave para pulir el sistema.

La experiencia con GPT-5.4-Cyber servirá para mejorar las defensas integradas en futuros modelos, endurecer sus barreras frente a abusos y afinar los criterios que determinan qué uso se considera legítimo. Aunque el modelo tenga menos restricciones que la versión estándar de GPT-5.4, esta permisividad se compensa con exigencias de autenticación y monitorización más estrictas.

En paralelo, la propia dinámica competitiva con Anthropic y otros actores del sector está acelerando la evolución de la ciberseguridad basada en IA. La carrera no se limita a quién tiene el modelo más potente, sino a quién es capaz de ofrecer mejores garantías de seguridad, gobernanza y control de riesgos en un entorno cada vez más vigilado por reguladores y mercados.

Con GPT-5.4-Cyber, OpenAI posiciona su tecnología en el centro del debate sobre cómo deben gestionarse las herramientas de inteligencia artificial capaces de detectar y analizar vulnerabilidades críticas. La combinación de acceso limitado, capacidades avanzadas y supervisión estrecha refleja un intento de aprovechar el potencial de estos modelos sin perder de vista los riesgos de su uso indebido, un equilibrio que será determinante para su adopción en España, Europa y el resto del mundo.

from Linux Adictos https://ift.tt/1xN7siw
via IFTTT