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/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 ansible-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CAF8BbLbsC4fDWTWQYXaURRRRWLksRgg91F9gO6PZpnsAOjMLAg%40mail.gmail.com.

Reply via email to