La seguridad de comunicaciones de red es una prioridad alta para el proyecto Fedora, con TLS fuerte proporcionando la primera línea de defensa frente a la inspección de tráfico. Dos sistemas negociando una conexión TLS deben acordar en un cifrado común para cifrar sus comunicaciones, y como los cifrados se vuelven obsoletos, es importante excluirlos.

Los cifrados que un administrador podría considerar adecuadamente seguro son determinados por vulnerabilidades publicadas frente a los cifrados específicos. El cifrado aceptable aplica a todas las comunicaciones en Internet, y no es específico a cualquier sistema o demonio. Para facilitar administración e incrementar confidencia de administrador en su postura de seguridad del sistema, Fedora ha estado configurando vario software para utilizar una configuración global del sistema tan que el cifrado TLS necesite solo ser actualizado en un lugar.

Con Fedora 26, dos o más cosas utilizarán la normativa de cifrado por todo el sistema, OpenSSH y Java.

Los clientes OpenSSH utilizarán algoritmos de intercambio de claves preferidas del sistema, cifrados de encriptado, y código de autenticación de mensaje con algoritmos (MAC). Esto está activado por una directiva Include en /etc/ssh/ssh_config para incluir directivas en /etc/ssh/ssh_config.d/*.conf, el cual utiliza en /etc/crypto-policies/back-end/openssh.config.

OpenJDK ha sido modificado para lectura adicional de propiedades de seguridad desde las normativas cripto generadas del archivo en /etc/ctypto-policies/back-end/java.config

Este cambio puede afectar las conexiones a sistemas heredados que no admiten normativas de cifrado más estrictas. Si bien es posible cambiar el perfil del sistema de DEFAULT a LEGACY, o establecer security.useSystemPropertiesFile=false en el archivo java.security de un proyecto (referido a link: https://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html[]), conviene también actualizar las aplicaciones heredadas a los estándares de seguridad modernos.

La introducción de OpenSSL 1.1.0 en Fedora 26 trae consigo múltiples importantes mejoras, nuevos algoritmos criptográficos y cambios en API que permiten mantener la estabilidad de la ABI en futuras actualizaciones. Además, Fedora incluye ahora el paquete compat-openssl10 que proporciona OpenSSL 1.0.2 para las aplicaciones dependientes que aún no pueden migrar a la versión 1.1.0.

Hay más información sobre OpenSSL 1.1.0 en el wiki OpenSSL.

Fedora 26 por defecto no incluye el módulo Coolkey PKCS#11 en la base de datos NSS. En su lugar, se incluirá el módulo OpenSC PKCS#11, compatible con más tarjetas inteligentes distintas. El paquete Coolkey se eliminará en Fedora 27. Si otras aplicaciones usaban Coolkey, deberían poder migrar a OpenSC.

En caso de que aún necesite Coolkey en la base de datos NSS, puede agregarlo manualmente usando modutil -dbdir /etc/pki/nssdb -add "CoolKey PKCS #11 Module (manual)" -libfile libcoolkeypk11.so -force (el nombre diferente se usa para evitar eliminaciones automáticas al actualizar el paquete coolkey).

Pronto (durante el ciclo F26) habrá una actualización completa 0.17.0 de OpenSC con todas las características y tarjetas probadas que deberían servir como un reemplazo completo de Coolkey.

SSSD se ha distribuido con una caché de memoria muy rápida en las últimas dos versiones de Fedora. Sin embargo, el uso de esta caché entra en conflicto con el almacenamiento en caché de nscd, que está deshabilitado por defecto. Esto reduce el rendimiento, ya que cada búsqueda de usuario o grupo debe abrir los archivos locales.

A partir de Fedora 26, un nuevo proveedor de archivos SSSD resolverá usuarios desde los archivos locales. De esta forma, el módulo NSS "sss" puede configurarse antes que el módulo de archivos en nsswitch.conf y el sistema puede aprovechar el almacenamiento en caché sss_nss para usuarios locales y remotos. Como resultado, la resolución de usuarios y grupos en Fedora será mucho más rápida.

Código obsoleto y no mantenido fue retirados desde authconfig. Notablemente:

La eliminación se debe a que los entornos modernos actuales admiten la configuración automática de identidades de usuarios remotos mediante Realmd y SSSD y no requieren configuración manual mediante una interfaz interactiva como el paquete system-config-authentication. Se conservan algunas de las funciones de la línea de comandos authconfig, ya que aún conservan cierta utilidad en ciertos entornos y para ser compatibles con el comando auth en Kickstart. La eliminación de partes del código base que ya no son mantenibles facilita la continuidad de esta funcionalidad.