TLS 1.3 - post handshake authentication failure - certificate authentication on Win Server 2022 / Windows 11

[cccscdev]

Summary

This is a continuation of issues 79432 and 77768, as those issues are now locked from further comment.

I have been working with Microsoft support on this failure and they have confirmed what has been previously reported:

The TLS 1.3 handshake fails because the TLS client (in this case Ansible) does not send a post handshake authentication extension in the TLS 1.3 "Client Hello" message. This is visible in the network trace: when the network trace is open with Wireshark and one examines the TLS Client Hello message, it is missing the Extension: post_handshake_auth extension. In general TLS 1.3 authentication can be done either in handshake or post handshake.

I know that Ansible relies on underlying Python libraries, which themselves rely on underlying OpenSSL libraries. However, my research would suggest that both Python and OpenSSL have now been updated to support post handshake authentication and TLS 1.3. This is based on the following:

openssl/openssl#6933
python/cpython#81621
python-trio/trio#741

Is it now the case that the Ansible code needs to be updated to take advantage of the new capability in Python? Or have I misunderstood the current status?

Issue Type

Bug Report

Component Name

apt

Ansible Version

$ ansible --version
ansible [core 2.11.12] 
  config file = None
  configured module search path = ['/home/jbloggs/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /jbloggs_virtualenvs/ansible-2.11/lib/python3.6/site-packages/ansible
  ansible collection location = /home/jbloggs/.ansible/collections:/usr/share/ansible/collections
  executable location = ./ansible
  python version = 3.6.9 (default, Jun 29 2022, 11:45:57) [GCC 8.4.0]
  jinja version = 3.0.3
  libyaml = True

Configuration

# if using a version older than ansible-core 2.12 you should omit the '-t all'
$ ansible-config dump --only-changed -t all

No output returned.

OS / Environment

NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"

Steps to Reproduce

cat /tmp/myinv
testwin:
  hosts:
    10.100.100.100:
      ansible_port: 5986
      ansible_winrm_transport: certificate
      ansible_connection: winrm
      ansible_winrm_cert_key_pem: /tmp/private_key.pem
      ansible_winrm_cert_pem: /tmp/public_cert.pem
      ansible_winrm_server_cert_validation: ignore
      ansible_winrm_read_timeout_sec: 180

./ansible testwin -i /tmp/myinv -m win_shell -a "ipconfig"

Expected Results

Output from ipconfig should be returned and displayed.

Actual Results

10.100.100.100 | UNREACHABLE! => {
    "changed": false,
    "msg": "certificate: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer'))",
    "unreachable": true
}

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibot]

Files identified in the description:

• lib/ansible/modules/apt.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[jborean93]

You are correct in your assessment but the implementation is quite difficult. Essentially Python exposes the OpenSSL option SSLContext.post_handshake_auth which can be set to True to allow the post handshake authentication. The difficulty comes with pywinrm or pypsrp actually setting this option for a few reasons. It is only supported on Python 3.8+ (you are on Python 3.6 so can't take advantage of it). The underlying HTTP library requests and while they do support custom transport adapters where this can be set I'm unsure whether it's feasible to do so. For example we still need to use the existing certificate loading logic which some platforms override in their requests package. This coupled with the fact that certificate authentication isn't really that easy to set up and that the keys need to be in plaintext makes it a lower priority in terms of fixes we look at.

IMO you are better off just using basic or NTLM authentication instead of messing with certificates. Using TLS negates the disadvantages of both options (weak to no encryption and no server authentication) and you no longer have to mess with generating certificates and mapping the user with the certificate on each Windows target. Finally you no longer have to maintain the certificate key as a file, you can use tools like ansible-vault to encrypt the password which you cannot do with certificate keys.

In saying all that I do have a working implementation that uses the psrp connection plugin but currently it is in the beta stage. The latest unreleased changes of pypsrp include support for this new option with these lines. Unfortunately it is being held up by a few things right now so isn't available for use in the existing connection plugins. If you wanted to try it out you will need to:

• Upgrade to Python 3.8 as the minimum
• Install pypsrp from the master branch to include the new TLS changes
• Use the psrp_winrm connection plugin from this test collection

Remember that this is just a POC right now and isn't available in a supported release. It will eventually be available at some point in the future.

[cccscdev]

@jborean93 thanks for the quick and detailed explanation of the current situation. I am taking these findings to my management, to determine our path forwards.