Buscar este blog

sábado, 28 de julio de 2018

Autofirma - Gestión de actualizaciones

Un tema bastante molesto relacionado con Autofirma es el control de las actualizaciones. Al ser un componente instalado en el equipo del usuario es él quien, en última instancia, decide qué versión instalar y cuándo actualizarla.

Cuando se desarrolla una aplicación web generalmente se prueba contra una versión concreta de @Firma, Autofirma incluida, y se certifica para su uso con ella. La parte de servidor no presenta ningún problema, puesto que se tiene control total sobre ella, no así la parte cliente. En cualquier momento puede publicarse una nueva versión de Autofirma y, gracias a la función automática de comprobación de actualizaciones, el usuario puede actualizarla. En este caso podrían presentarse problemas si esta nueva versión no es totalmente compatible con la anterior.

En este post se explicará cómo hace Autofirma la gestión y control de las actualizaciones y de qué forma se podría intervenir para prevenir los avisos al usuario.


Cada vez que se inicia Autofirma, ésta revisa si está configurada para comprobar de forma automática si existe una nueva actualización. En caso afirmativo, consulta en una URL pública cuál es la última versión disponible y la compara con su versión interna. Si la primera es mayor a la segunda, entonces redirige al usuario a una segunda URL para que proceda a su descarga manual.


Concretamente, al URL de descarga a día de hoy es http://firmaelectronica.gob.es/Home/Descargas.html



Existe una opción de configuración del componente que permite deshabilitar la consulta automática de actualizaciones, pero debe establecerlo explícitamente así el usuario, puesto que por defecto ya viene marcada.




A nivel técnico, el proceso descrito se controla de dos modos:
  1. Gestión de preferencias de usuario
  2. Consulta de actualizaciones
La gestión de preferencias de usuario se hace desde la  clase es.gob.afirma.standalone.ui.preferences.PreferencesManager. Esta clase gestiona dos objetos de propiedades, las preferencias guardadas y las preferencias por defecto.
static {
 preferences = Preferences.userNodeForPackage(PreferencesManager.class);

 properties = new Properties();
 try {

  properties.load(PreferencesManager.class.getResourceAsStream("/properties/preferences.properties" //$NON-NLS-1$
  ));
 } catch (final Exception e) {
  LOGGER.severe(
    "No han podido cargarse los valores por defecto del fichero de configuracion de preferencias, se usaran los valores por defecto: " //$NON-NLS-1$
      + e);
 }

}

Las preferencias se guardan empleando la clase java.util.java.util.prefs.Preferences, que en el caso de windows, persiste bajo la clave de registro HKEY_CURRENT_USER\Software\JavaSoft\Prefs\es\gob\afirma\standalone\ui\preferences.
Las preferencias por defecto se guardan dentro del propio jar,en el fichero preferences.properties.
(...)
#Panel General de Preferencias
signatureAlgorithm = SHA256withRSA
omitAskOnClose = false
hideDnieStartScreen = false
checkForUpdates = true
useAnalytics = true
enabledJmulticard = true
defaultSignatureFormatPdf = PAdES
defaultSignatureFormatOoxml = OOXML (Office Open XML)
defaultSignatureFormatFacturae = FacturaE
defaultSignatureFormatOdf = ODF (Open Document Format)
defaultSignatureFormatXml = XAdES
defaultSignatureFormatBin = CAdES
(...)

La consulta de actualizaciones se hace desde la clase es.gob.afirma.standalone.updater.
private static void loadProperties() {
 if (updaterProperties != null) {
  return;
 }
 updaterProperties = new Properties();
 try {
  updaterProperties.load(Updater.class.getResourceAsStream("/properties/updater.properties")); //$NON-NLS-1$
 }
 catch (final Exception e) {
  LOGGER.severe(
   "No se ha podido cargar el archivo de recursos del actualizador: " + e //$NON-NLS-1$
  );
  updaterProperties = new Properties();
 }
}

Las propiedades de consulta de versión se mantienen en un fichero independiente llamado updater.properties:
# Numero de version visible
currentVersionText.WINDOWS=1.6.4
currentVersionText.LINUX=1.6.4
currentVersionText.MACOSX=1.6.4

# Numero de version interno (numero entero). Si es par se trata de una version preliminar.
# Este numero no avanzara dentro de las distintas versiones preliminares anteriores a una
# version final. Cuando se establezca un numero impar, se identifica una version final.
currentVersion.WINDOWS=10
currentVersion.LINUX=10
currentVersion.MACOSX=10

# AutoFirma en Windows buscara si hay nuevas versiones y lo notificara al
# usuario remitiendole a la pagina de descargas
url=http://estaticos.redsara.es/comunes/autofirma/autofirma.version
updateSite=http://firmaelectronica.gob.es/Home/Descargas.html

Tal y como se aprecia la URL de consulta de versión es http://estaticos.redsara.es/comunes/autofirma/autofirma.version, que actualmente devuelve el valor 8.


Por tanto, de cara a tener un mayor control sobre el proceso de actualización se podrían hacer las siguientes modificaciones sobre estos ficheros:
  1. En el fichero preferences.properties configurar que no se marque por defecto la opción de comprobación de actualizaciones. Bastaría con cambiar la propiedad checkForUpdates.
  2. En el fichero updater.properties configurar la URL de comprobación de versión a una dirección controlada, y que se devuelva la versión compatible con la aplicación en la que se use. Bastaría con cambiar la propiedad url.


En cualquier caso, una vez hecho el cambio habría que recompilar el código y generar de nuevo el instalador: Autofirma - Compilación manual para Windows

2 comentarios:

  1. Hola, a ver si me puede responder...
    Algo que no entiendo es que autofirma NO TIENE posibilidad de sello de tiempo (timestamp) ¿que les cuesta ponerlo?

    gracias..

    ResponderEliminar
  2. Hola

    Antes de nada, aclarar que no tengo nada que ver con el equipo de Autorfirma. Soy un mero usuario desarrollador.

    Dicho esto, entiendo que es un tema de seguridad. Autofirma trabaja en el equipo del usuario, con lo que todas las comunicaciones que tenga que hacer las hará partiendo de ahí. Es decir, de un entorno salvaje e incontrolado.

    Por otro lado, los servicios de timestamp son un recurso crítico que suele estar securizado, y que se tarifica por volumen de uso.

    Hacer que Autofirma se conecte con un servicio de timestamp directamente desde internet implica que las credenciales de conexión (o certificados de autenticación) se distribuyan dentro del componente, o al menos la forma de obtenerlas. Sería relativamente fácil hacer ingeniería inversa, obtener esas credenciales y acceder al servicio para cualquier otro uso.

    También entiendo que el servicio de timestamp estará servido únicamente desde dentro de la red sara, y puede que aún ahí, sólo desde algunas direcciones concretas. Todo ello para ofrecer todavía más seguridad.

    Un saludo

    ResponderEliminar