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/9cda0f58e659cd8470945e833926da98af841cb1.camel%40gmail.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/CAF8BbLbsC4fDWTWQYXaURRRRWLksRgg91F9gO6PZpnsAOjMLAg%40mail.gmail.com.
