Hi Dick, Hmm, very interesting ... Thank you so much for your replication efforts!
Then it seems indeed a local problem of mine. In my case, Ansible is executed in a Docker container python:3-slim, which is based on debian:bookworm-slim. Within the container, 'ansible==10.*' is installed into a normal user's directory with pip, and Ansible commands are executed on behalf of that normal user. I will check if this setup somehow affects the TLS negotiation. I will update the thread once I find the culprit. Thank you. Regards, Garri On Sat, 2024-08-17 at 13:09 +0200, Dick Visser wrote: > Hii > I tried to replicate what you see. To help debug I spun up an old web > server that is only doing TLSv1. > Then, on a clean Debian 12 VM, initially the URL fails to fetch with > curl, as expected: > > (venv) vagrant@debian-12:~$ curl -Ikv https://tlsv1.tienhuis.nl > * Trying [2001:648:2ffc:1225:a800:4ff:fec1:7353]:443... > * Connected to tlsv1.tienhuis.nl > (2001:648:2ffc:1225:a800:4ff:fec1:7353) port 443 (#0) > * ALPN: offers h2,http/1.1 > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > * TLSv1.3 (IN), TLS handshake, Server hello (2): > * TLSv1.0 (IN), TLS handshake, Certificate (11): > * TLSv1.0 (IN), TLS handshake, Server key exchange (12): > * TLSv1.0 (OUT), TLS alert, internal error (592): > * OpenSSL/3.0.13: error:0A00014D:SSL routines::legacy sigalg > disallowed or unsupported > * Closing connection 0 > curl: (35) OpenSSL/3.0.13: error:0A00014D:SSL routines::legacy sigalg > disallowed or unsupported > > Likewise, this playbook: > > --- > - name: legacy test > hosts: localhost > gather_facts: false > connection: local > tasks: > - name: fetch URL > ansible.builtin.uri: > url: https://tlsv1.tienhuis.nl > validate_certs: false > register: out > - ansible.builtin.debug: var=out > > also fails at the uri task: > > TASK [fetch URL] > ********************************************************************* > ************************************************ > fatal: [localhost]: FAILED! => {"changed": false, "elapsed": 0, > "msg": "Status code was -1 and not [200]: Request failed: <urlopen > error [SSL] legacy sigalg disallowed or unsupported (_ssl.c:992)>", > "redirected": false, "status": -1, "url": > "https://tlsv1.tienhuis.nl"} > > Replacing /etc/ssl/openssl.cnf with the small version that you have > > (venv) vagrant@debian-12:~$ cat /etc/ssl/openssl.cnf > openssl_conf = openssl_init > [openssl_init] > ssl_conf = ssl_sect > [ssl_sect] > system_default = system_default_sect > [system_default_sect] > MinProtocol = TLSv1 > CipherString = DEFAULT@SECLEVEL=0 > Options = UnsafeLegacyRenegotiation > > makes curl work: > > (venv) vagrant@debian-12:~$ curl -Ikv https://tlsv1.tienhuis.nl > * Trying [2001:648:2ffc:1225:a800:4ff:fec1:7353]:443... > * Connected to tlsv1.tienhuis.nl > (2001:648:2ffc:1225:a800:4ff:fec1:7353) port 443 (#0) > * ALPN: offers h2,http/1.1 > * TLSv1.3 (OUT), TLS handshake, Client hello (1): > * TLSv1.3 (IN), TLS handshake, Server hello (2): > * TLSv1.0 (IN), TLS handshake, Certificate (11): > * TLSv1.0 (IN), TLS handshake, Server key exchange (12): > * TLSv1.0 (IN), TLS handshake, Server finished (14): > * TLSv1.0 (OUT), TLS handshake, Client key exchange (16): > * TLSv1.0 (OUT), TLS change cipher, Change cipher spec (1): > * TLSv1.0 (OUT), TLS handshake, Finished (20): > * TLSv1.0 (IN), TLS handshake, Finished (20): > * SSL connection using TLSv1 / ECDHE-RSA-AES256-SHA > * ALPN: server did not agree on a protocol. Uses default. > * Server certificate: > * subject: CN=tlsv1.tienhuis.nl > * start date: Aug 17 10:25:11 2024 GMT > * expire date: Jan 17 10:25:11 2038 GMT > * issuer: CN=tlsv1.tienhuis.nl > * SSL certificate verify result: self-signed certificate (18), > continuing anyway. > * using HTTP/1.x > > HEAD / HTTP/1.1 > > Host: tlsv1.tienhuis.nl > > User-Agent: curl/7.88.1 > > Accept: */* > > > < HTTP/1.1 200 OK > > BUT, it also makes the uri task in the ansible playbook work: > > TASK [ansible.builtin.debug] > ********************************************************************* > ************************************ > ok: [localhost] => { > "out": { > "accept_ranges": "bytes", > "changed": false, > "connection": "close", > "content_length": "10701", > "content_type": "text/html", > "cookies": {}, > "cookies_string": "", > "date": "Sat, 17 Aug 2024 11:02:40 GMT", > "elapsed": 0, > "etag": "\"29cd-61fde5e24e55f\"", > "failed": false, > "last_modified": "Sat, 17 Aug 2024 10:16:22 GMT", > "msg": "OK (10701 bytes)", > "redirected": false, > "server": "Apache/2.4.10 (Debian)", > "status": 200, > "url": "https://tlsv1.tienhuis.nl";, > "vary": "Accept-Encoding" > } > } > > This seems to indicate a local problem somewhere on your side.... > FYI, on my control node: > > (venv) vagrant@debian-12:~$ ansible --version > ansible [core 2.17.3] > config file = None > configured module search path = > ['/home/vagrant/.ansible/plugins/modules', > '/usr/share/ansible/plugins/modules'] > ansible python module location = > /home/vagrant/venv/lib/python3.11/site-packages/ansible > ansible collection location = > /home/vagrant/.ansible/collections:/usr/share/ansible/collections > executable location = /home/vagrant/venv/bin/ansible > python version = 3.11.2 (main, May 2 2024, 11:59:08) [GCC 12.2.0] > (/home/vagrant/venv/bin/python3) > jinja version = 3.1.4 > libyaml = True > (venv) vagrant@debian-12:~$ pip list > Package Version > ------------ ------- > ansible-core 2.17.3 > cffi 1.17.0 > cryptography 43.0.0 > Jinja2 3.1.4 > MarkupSafe 2.1.5 > packaging 24.1 > pip 24.2 > pycparser 2.22 > PyYAML 6.0.2 > resolvelib 1.0.1 > setuptools 66.1.1 > wheel 0.44.0 > (venv) vagrant@debian-12:~$ openssl version > OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024) > (venv) vagrant@debian-12:~$ uname -a > Linux debian-12 6.1.0-23-arm64 #1 SMP Debian 6.1.99-1 (2024-07-15) > aarch64 GNU/Linux > > > On Sat, 17 Aug 2024 at 00:33, Garri Djavadyan <g.djavad...@gmail.com> > wrote: > > Hi Dick, Walter, and all, > > > > Dick, I totally agree that patching Ansible to support insecure > > protocols should be discouraged in general, and I am totally fine > > to > > continue using my current curl-based playbook until the legacy > > devices > > are decommissioned. I was just curious if it would be possible to > > use > > 'ansible.builtin.uri' in an unsafe OpenSSL context without touching > > the > > Ansible code. > > > > Walter, as far as I know, Linux kernel's TLS sockets (ktls) [1] > > only > > provide encryption offloading capabilities to the user space > > libraries, > > such as OpenSSL. As far as I can see, the handshake still should be > > handled by the user space library. > > > > As far as I know, 'ansible.builtin.uri' depends on the Python > > standard > > library's 'urllib' [2], which depends on the 'ssl' module [3], also > > from the standard library. The latter, depends on the user space > > OpenSSL library. > > > > Also, as I mentioned before, I can successfully talk to my legacy > > devices using "curl" and loosened OpenSSL configuration, that I > > shared > > earlier, from the same Debian 12.6 system. Therefore, I do not > > think > > the kernel prohibits 'uri' from negotiating TLS 1.0 connections. > > > > Thank you. > > > > Regards, > > Garri > > > > > > [1] https://www.kernel.org/doc/html/latest/networking/tls.html > > [2] > > https://github.com/ansible/ansible/blob/v2.17.3/lib/ansible/module_utils/urls.py#L54 > > [3] https://docs.python.org/3/library/ssl.html > > > > > > On Fri, 2024-08-16 at 11:13 +0000, 'Rowe, Walter P. (Fed)' via > > Ansible > > Project wrote: > > > If the kernel / OS won't allow lowering the TLS then a custom > > > openssl.conf likely won't either. You can't override the kernel / > > > OS > > > to lower security. > > > > > > Walter > > > -- > > > Walter Rowe, Division Chief > > > Infrastructure Services Division > > > Mobile: 202.355.4123 > > > > > > > On Aug 16, 2024, at 5:23 AM, Dick Visser <dnmvis...@gmail.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hii > > > > > > > > Hacking ansible to make it work with its native uri module may > > > > work, but it will likely make the hack go under the radar. > > > > > > > > > > > > Since it is already a security lowering snowflake, IMHO it is > > > > good > > > > to make this explicit by having it done in a custom > > > > shell/command. > > > > It is simple, easy, and makes it very clear what is going on > > > > for > > > > this specific device. > > > > > > > > > > > > > > > > > > > > On Thu, 15 Aug 2024 at 23:31, Garri Djavadyan > > > > <g.djavad...@gmail.com> wrote: > > > > > Hi Walter, > > > > > > > > > > > Your system may not allow older TLS connections. > > > > > > > > > > Exactly, and this is why I currently have to use a custom > > > > > weakened openssl.cnf by the curl-based Ansible playbook. > > > > > However, > > > > > the environment variable OPENSSL_CONF, referring to the > > > > > custom > > > > > OpenSSL config, is ignored when I use "ansible.builtin.uri". > > > > > Actually, "ansible.builtin.uri" even ignores by OpenSSL > > > > > config > > > > > located in the default path /etc/ssl/openssl.cnf on my Debian > > > > > 12.6 system: > > > > > > > > > > -----BEGIN SHELL----- > > > > > $ cat /etc/ssl/openssl.cnf > > > > > openssl_conf = openssl_init > > > > > > > > > > [openssl_init] > > > > > ssl_conf = ssl_sect > > > > > > > > > > [ssl_sect] > > > > > system_default = system_default_sect > > > > > > > > > > [system_default_sect] > > > > > MinProtocol = TLSv1 > > > > > CipherString = DEFAULT@SECLEVEL=0 > > > > > Options = UnsafeLegacyRenegotiation > > > > > > > > > > > > > > > $ ansible-playbook -vvv test.yml > > > > > ... > > > > > "msg": "Status code was -1 and not [200]: Request failed: > > > > > <urlopen error [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 > > > > > alert > > > > > handshake failure (_ssl.c:1000)>", > > > > > ... > > > > > -----END SHELL----- > > > > > > > > > > > > > > > Thank you. > > > > > > > > > > Regards, > > > > > Garri > > > > > > > > > > > > > > > > > > > > On Thursday, August 15, 2024 at 1:15:22 PM UTC+2 Rowe, Walter > > > > > P. > > > > > (Fed) wrote: > > > > > > Check your system settings. Your system may not allow older > > > > > > TLS > > > > > > connections. TLS 1.0 is compromised and therefore no longer > > > > > > allowed by many systems. > > > > > > > > > > > > What platform is your control host? > > > > > > > > > > > > Walter > > > > > > -- > > > > > > Walter Rowe, Division Chief > > > > > > Infrastructure Services Division > > > > > > Mobile: 202.355.4123 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Aug 15, 2024, at 5:00 AM, Garri Djavadyan > > > > > > > <g.dja...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Steve, > > > > > > > > > > > > > > > Did you try with SECLEVEL=0 ? > > > > > > > > > > > > > > Yes, I did. However, the result is the same: Ansible > > > > > > > controller is not happy with the bare TLS 1.0 reply from > > > > > > > the > > > > > > > legacy box: > > > > > > > > > > > > > > "msg": "Status code was -1 and not [200]: Request failed: > > > > > > > <urlopen error [SSL: UNSUPPORTED_PROTOCOL] unsupported > > > > > > > protocol (_ssl.c:1000)>" > > > > > > > > > > > > > > > > > > > > > - name: Query legacy boxes > > > > > > > hosts: legacyboxes > > > > > > > gather_facts: false > > > > > > > connection: local > > > > > > > tasks: > > > > > > > - name: GET the home page > > > > > > > ansible.builtin.uri: > > > > > > > url: https://{{ ansible_host }} > > > > > > > ciphers: > > > > > > > - 'DEFAULT@SECLEVEL=0' > > > > > > > > > > > > > > > > > > > > > Again, ciphers-wise, the setup is fine, but I do not > > > > > > > think it > > > > > > > is possible to enforce the minimum TLS protocol version > > > > > > > with > > > > > > > the cipher string. > > > > > > > > > > > > > > Thank you. > > > > > > > > > > > > > > Regards, > > > > > > > Garri > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > You received this message because you are subscribed to > > > > > > > the > > > > > > > Google Groups "Ansible Project" group. > > > > > > > To unsubscribe from this group and stop receiving emails > > > > > > > from > > > > > > > it, send an email toansible-proje...@googlegroups.com. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To view this discussion on the web visit > > > > > > > https://groups.google.com/d/msgid/ansible-project/85e58522-271e-45aa-832a-8a2a7c6b5a38n%40googlegroups.com > > > > > > > . > > > > > > > > > > > > > > > > > > > > > > -- > > > > > You received this message because you are subscribed to the > > > > > Google Groups "Ansible Project" group. > > > > > To unsubscribe from this group and stop receiving emails from > > > > > it, > > > > > send an email toansible-project+unsubscr...@googlegroups.com. > > > > > To view this discussion on the web visit > > > > > https://groups.google.com/d/msgid/ansible-project/fe2f9e80-a54e-4ffc-87f1-bdfe8788c858n%40googlegroups.com > > > > > . > > > > > > > > > > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/7eda6be1bdba7cb54ebcd0e868b0ecac5a8819bc.camel%40gmail.com.
