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 <[email protected]> > 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 <[email protected]> > > > > 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 > > > > <[email protected]> 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 > > > > > > > <[email protected]> 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 [email protected]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 [email protected]. > > > > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/7eda6be1bdba7cb54ebcd0e868b0ecac5a8819bc.camel%40gmail.com.
