Un cordial saludo todos los participantes y lectores.
Quiero aportar mi experiencia con AutoFirma en Gentoo a fecha 31 de Mayo de 2022.
Paquetes instaladosCode: Select all
www-client/firefox-bin-91.9.0::gentoo was built with the following:
USE="alsa ffmpeg gmp-autoupdate pulseaudio wayland (-selinux)" ABI_X86="(64)" L10N="-ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -ca-valencia -cak -cs -cy -da -de -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -ne -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tl -tr -trs -uk -ur -uz -vi -xh -zh-CN -zh-TW"
dev-java/openjdk-bin-8.322_p06::gentoo was built with the following:
USE="alsa cups -examples -headless-awt (-selinux) -source" ABI_X86="(64)"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
dev-java/icedtea-web-1.8.4-r1::gentoo was built with the following:
USE="-debug -doc" ABI_X86="(64)"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
dev-java/icedtea-bin-3.16.0::gentoo was built with the following:
USE="alsa cups gtk pulseaudio (-big-endian) -doc -examples -headless-awt (-selinux) -source" ABI_X86="(64) -32 (-x32)"
dev-libs/openssl-1.1.1o::gentoo was built with the following:
USE="asm -rfc3779 -sctp -sslv3 -static-libs -test -tls-compression -tls-heartbeat -vanilla -verify-sig -weak-ssl-ciphers" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="(sse2)"
CFLAGS="-march=skylake -O2 -pipe -fno-strict-aliasing -Wa,--noexecstack"
CXXFLAGS="-march=skylake -O2 -pipe -fno-strict-aliasing -Wa,--noexecstack"
FEATURES="binpkg-logs distlocks xattr config-protect-if-modified ebuild-locks news unknown-features-warn merge-sync parallel-fetch sandbox unmerge-logs network-sandbox strict fixlafiles binpkg-docompress usersandbox qa-unresolved-soname-deps pid-sandbox sfperms unmerge-orphans userpriv ipc-sandbox assume-digests protect-owned usersync userfetch multilib-strict binpkg-dostrip preserve-libs"
Java en usoCode: Select all
eselect java-vm list
Available Java Virtual Machines:
[1] icedtea-bin-8
[2] openjdk-bin-8 system-vm
[3] openjdk-bin-11
java -version
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on
openjdk version "1.8.0_322"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_322-b06)
OpenJDK 64-Bit Server VM (Temurin)(build 25.322-b06, mixed mode)
Resultados
- AutoFirma (manual) -> Funciona
- AutoFirma (Firefox)
_____________
(1) No funciona: Sólo funciona al cambiar de openjdk a icedtea (sudo eselect java-vm set system icedtea-bin)
Investigación
Al editar el fichero
/usr/bin/AutoFirma activando la depuración SSL:
java
-Djavax.net.debug=ssl -Djdk.tls.maxHandshakeMessageSize=50000 -jar /usr/lib/AutoFirma/AutoFirma.jar $*, descubrí el origen del fallo:
Code: Select all
javax.net.ssl|FINE|01|main|2022-05-31 15:57:57.957 CEST|SSLCipher.java:438|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
javax.net.ssl|SEVERE|1C|WebSocketSelector-28|2022-05-31 15:58:00.405 CEST|TransportContext.java:316|Fatal (INTERNAL_ERROR): problem wrapping app data (
"throwable" : {
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.HandshakeContext.<init>(HandshakeContext.java:171)
at sun.security.ssl.ServerHandshakeContext.<init>(ServerHandshakeContext.java:62)
at sun.security.ssl.TransportContext.kickstart(TransportContext.java:220)
at sun.security.ssl.SSLEngineImpl.writeRecord(SSLEngineImpl.java:159)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:130)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:110)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)
at org.java_websocket.SSLSocketChannel2.wrap(SSLSocketChannel2.java:182)
at org.java_websocket.SSLSocketChannel2.<init>(SSLSocketChannel2.java:112)
at org.java_websocket.server.DefaultSSLWebSocketServerFactory.wrapChannel(DefaultSSLWebSocketServerFactory.java:71)
at org.java_websocket.server.WebSocketServer.doAccept(WebSocketServer.java:429)
at org.java_websocket.server.WebSocketServer.run(WebSocketServer.java:344)
at java.lang.Thread.run(Thread.java:750)}
)
Esto se debe a que se utiliza protocolos y algoritmo de cifrado deshabilitado por motivos de seguridad.
Para comprobarlo he deshabilitado
temporalmente dicha característica, comentando la siguiente entrada en fichero /opt/openjdk-bin-8/jre/lib/security/java.security:
Code: Select all
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
Al volver a ralizar la prueba (sin haber cerrado el navegador ni haber salido de la página), funciona.
A diferencia de openjdk, icedtea no deshabilita los protocolos TLS previos a la versión 1.2 ni tampoco los algoritmos de cifrado vulnerables. En java.security de icedtea:
Code: Select all
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
EC keySize < 224, 3DES_EDE_CBC, anon, NULL
Solución
Usar openjdk en lugar de icedtea y usar únicamente los sitios web actualizados, exigiendo a las administraciones públicas actualizar sus servicios que ponen en riesgo la seguridad y privacidad de nuestros datos y dispositivos.
Notas
No estoy de acuerdo en absoluto con esta mala práctica de ejecutar código remoto en los dispositivos de los usuarios. Aún existen sitios de la administración que descargan código bytecode de java en jnlp y lo ejecuta.
En lugar de desarrollar software en WebAssembly que se ejecuta directamente en el navegador, lo hacen en Java porque es más fácil, complicando la vida a los usuarois.
Aún así, Java 8 está en camino de la obsolescencia, y a partir de la versión 9 de Java (la 10, 11,12,13,14,15,16,17) se incorporaron los módulos, lo que exige al desarrollador proporcionar una versión reducida de la máquina virtual de Java en el própio paquete que instala el usuario.
Por otro lado, tampoco estoy de acuerdo con estos instaladores que aparecen en las distribuciones ArchLinux, Gentoo, Debian, etc.
¿Qué es eso de ejecutar java como superusuario root?
... java -jar AutoFirmaConfigurador.jar...
Somos usuarios de Linux y Unix por motivos de privacidad y seguridad, pero parece que no se respeta eso, y el resultado es una falsa sensación de seguridad y de privacidad.
En mis sistemas ninguna aplicación tiene acceso a internet. Todas las que tienen acceso a internet están aisladas en un sandbox bwrap (bubblewrap), y sólo tienen acceso cuando yo lo activo explícitamente (activando un flag en el momento de ejecución) y al sitio o sitios web concreto/s (dominio/subdominio/IP).
Las garras de los espías están en todas partes. Hay muchísimas aplicaciones que recopilan información del usuario: Android Studio, plugins de vim/nvim para el desarrollo de software, Signal Private Messenger, etc.
En el ejemplo de Signal, aunque incorpore cifrado de extremo a extremo, utiliza librerías de Google que se conectan constantemente a los servidores de Google. Nadie se preocupa por nada últimamente.