El SSL no anda bien desde Azure

[facundobatista]

WAT?

Atendé: si deployamos en Azure, y quiero generar facturas, tengo un traceback que termina en

ssl.SSLError: [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:852)

Esto lo "soluciono" con el siguiente hack ESPANTOSO: edito /usr/local/lib/python3.6/ssl.py y hago que la variable _DEFAULT_CIPHERS sea 'AES128-SHA'.

Por otro lado, si lo pruebo localmente, no en Azure, funciona todo ok de entrada.

La forma de probarlo fácil: con este script (van a tener que poner el contenido de este zip en /tmp/).

Cuando ese script "funciona" el resultado es:

pysimplesoap.client.SoapFault: ns1:cms.cert.expired: Certificado expirado

(que muestra que el script dialoga con AFIP, más allá que a AFIP no le gusten los tokens)

Qué loco, ¿no?

[maurom]

Disculpas por la intromisión. ¿Qué valores tienen MinProtocol y CipherString en /etc/ssl/openssl.cnf en local y en Azure?

[aenima-x]

Me parece que falta aclarar algo medio importante, por lo que vi en twitter están usando docker. Lo que hace el error mas raro todavía

[facundobatista]

WOW SON DISTINTOS!!! @gilgamezh como puede ser?

Son practicamente iguales, pero el de Azure al final tiene esto que el del docker local NO tiene:

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

[gilgamezh]

@facundobatista de dónde sacaste lo que pegaste ahi? con el script?

una posibilidad es que ese comportamiento cambie con el kernel. En Docker tu kernel es el del host.

[aenima-x]

@gilgamezh te parece??
que relación puede tener el kernel con ciphers?

@facundobatista
Si usas un container deberia valer el del container siempre no importa donde lo corras, quiero creer.
No entiendo como puede haber relacion entre el /etc/ssl/openssl.cnf del server y del container

[gilgamezh]

ah! ya entendí! esa data sale de /etc/ssl/openssl.cnf

[aenima-x]

@gilgamezh si, la unica que se me ocurre es que la imagen de docker que esten usando por alguna razon tome ese archivo fuera del container

[gilgamezh]

@facundobatista pasame el output de tu local con esto mismo

root@production-admin-asoc-members-99b895fd8-868z8:/code/website# uname -a
Linux production-admin-asoc-members-99b895fd8-868z8 4.15.0-1061-azure #66-Ubuntu SMP Thu Oct 3 02:00:50 UTC 2019 x86_64 GNU/Linux
root@production-admin-asoc-members-99b895fd8-868z8:/code/website# dpkg -l | grep ssl
ii  libcurl4-openssl-dev:amd64           7.64.0-4                     amd64        development files and documentation for libcurl (OpenSSL flavour)
ii  libevent-openssl-2.1-6:amd64         2.1.8-stable-4               amd64        Asynchronous event notification library (openssl)
ii  libgnutls-openssl27:amd64            3.6.7-4                      amd64        GNU TLS library - OpenSSL wrapper
ii  libssl-dev:amd64                     1.1.1c-1                     amd64        Secure Sockets Layer toolkit - development files
ii  libssl1.1:amd64                      1.1.1c-1                     amd64        Secure Sockets Layer toolkit - shared libraries
ii  libzstd1:amd64                       1.3.8+dfsg-3                 amd64        fast lossless compression algorithm
ii  openssl                              1.1.1c-1                     amd64        Secure Sockets Layer toolkit - cryptographic utility

y después confirmame si estas usando esta imagen pyar/asoc_members:prod-0.1.4 (que es la que hay en prod)

[maurom]

Tal como comentan, no tiene que ver con el kernel sino con la configuración de openssl, que por algún motivo se inyecta al contenedor por algún lado.

No está mal, porque requiere TLS 1.2 y evita realizar DH exchanges con claves débiles, pero el endpoint de AFIP es un tanto antiguo y adolece de algunos inconvenientes (test con ssllabs) que un cliente TLS moderno rechaza.

Alternativamente puede forzarse CipherString = DEFAULT@SECLEVEL=1

Pero lo importante es saber de dónde sale la configuración adicional.

[aenima-x]

che ahi levante la ultima imagen de pyar/asoc_members y el openssl.cnf tiene esas lineas.
Puede ser que el problema sea que en tu local estes corriendo una version vieja?
Deben haber actualizado la imagen de debían de la que hereda python

[gilgamezh]

@facundobatista proba ejecutar la imagen que pasé a ver si falla como en prod. creo que con eso confirmamos que son diferentes imagenes

[facundobatista]

Yo creí haber borrado todo lo que tenía en mi máquina antes de regenerar y revisar. Pero puede fallar, docker es muy lindo porque te cachea las imágenes (velocidad y ancho de banda), pero es una mierda porque te cachea las imágenes (nunca sabés del todo cuanto regeneraste de verdad).

Ahora estoy en la laptop, borré todo (o al menos me parece) y rearmé todo desde cero (creo), haciendo make start-dev. Crasheó espantosamente porque para la migración no se pudo conectar a 172.20.0.4 (?), pero el container está creado y....

root@daf859c7033f:/code/website# uname -a
Linux daf859c7033f 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 GNU/Linux
root@daf859c7033f:/code/website# dpkg -l | grep ssl
ii  libcurl4-openssl-dev:amd64           7.64.0-4                     amd64        development files and documentation for libcurl (OpenSSL flavour)
ii  libevent-openssl-2.1-6:amd64         2.1.8-stable-4               amd64        Asynchronous event notification library (openssl)
ii  libgnutls-openssl27:amd64            3.6.7-4                      amd64        GNU TLS library - OpenSSL wrapper
ii  libssl-dev:amd64                     1.1.1d-0+deb10u2             amd64        Secure Sockets Layer toolkit - development files
ii  libssl1.1:amd64                      1.1.1d-0+deb10u2             amd64        Secure Sockets Layer toolkit - shared libraries
ii  libzstd1:amd64                       1.3.8+dfsg-3                 amd64        fast lossless compression algorithm
ii  openssl                              1.1.1d-0+deb10u2             amd64        Secure Sockets Layer toolkit - cryptographic utility

Por otro lado, no sé qué imagen de docker estoy usando, pero no creo que sea la de producción porque esa la arma dockerhub en función de lo que tageamos, y la local es en función del branch donde uno está parado, no?

[facundobatista]

FTR, tengo

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

[facundobatista]

Aaaaaaaand localmente me falla como falla en Azure.

Ergo, docker es una mierda (?) y me escondía en sus cachés distintas construcciones con configs distintos.

Más allá de eso... ¿cómo hago para hablarle a la AFIP?

[facundobatista]

Si pruebo toqueteando CipherString = DEFAULT@SECLEVEL=1 como dice @maurom , funca ok

[facundobatista]

Entonces, deberíamos meter ese "fix" como parte del Dockerfile, como dice @aenima-x , ¿cierto?

[aenima-x]

@facundobatista No se cual seria la solución menos "ciruja".
O tener nuestra version del cnf y meterlo en el container o en el dockerfile hacer un sed horrible y cambiarlo

@gilgamezh usted que sabe mas dira

[gilgamezh]

Ergo, docker es una mierda (?) y me escondía en sus cachés distintas construcciones con configs distintos.

docker inspect te da la data de la imagen y con docker images poder ver cuál estás usando.
A mi me suena que tal vez tenemos una config para deb que construye una imagen vieja o algo asi. Voy a pegarle una revizada luego.

Con respecto al fix lo estudio un poco mas para ver cuál sería la mejor manera de "parchearlo"

[tzulberti]

Perdon, en que quedo este tema?

[facundobatista]

Todavía roto

[maurom]

Vuelvo a este bug por una comunicación reciente de AFIP que está relacionada:

Buenos Aires, 21 de Septiembre de 2020

Debido a los problemas de vulnerabilidades del protocolo TLS (v 1.0 y 1.1) y dado que estas versiones se consideran obsoletas, los navegadores utilizados en la actualidad planifican eliminar la compatibilidad con estos para implementar versiones más modernas con una criptografía avanzada y asegurando una mejor protección en la navegación de los usuarios.

A raíz de ello, desde la Dirección de Seguridad de la Información, junto con las áreas de desarrollo de sistemas, se encuentran trabajando en la implementación de las nuevas versiones y actualización del firewall de aplicaciones web.

Esta situación podría llevar a la adaptación y/o modificación de distintos aplicativos y servicios web (webservices) utilizados por los contribuyentes y organizaciones para el intercambio de información con la AFIP.

En consecuencia de lo expuesto, queremos informarte que en estos días podrían verse afectados los servicios y que, en caso de estar utilizando las versiones 1.0 o 1.1 de TLS, también deberán adaptarse los aplicativos que se encuentran en destino.

Lamentamos las molestias que puedan llegar a generar pero comprendemos que este nuevo modelo de trabajo no solo es más seguro sino también es necesario.

[facundobatista]

Quizás lo más piola que podemos hacer, teniendo en cuenta que la AFIP va a cambiar (cambió?) cosas, es ir a una plataforma, a un python y a un django más modernos.

[facundobatista]

Sigue pasando con todo actualizado (Python 3.9, django 3.1, etc..).

[facundobatista]

Bueno, estoy agregando esta linea al Dockerfile...

sed -i 's/CipherString = DEFAULT@SECLEVEL=2/CipherString = DEFAULT@SECLEVEL=1/' /etc/ssl/openssl.cnf

[maurom]

Efectivamente, en AFIP corrigieron el tema del protocolo (ahora sólo se acepta TLS 1.2) pero no resolvieron el problema de la longitud de clave DH que sigue siendo de 1024 bits, por lo que no hay forma de conectarse con SECLEVEL=2.