Python 10+ EOS SSLV3_ALERT_HANDSHAKE_FAILURE

[rifen]

Description of Issue/Question

With Python 10+ the strength of the TLS stack is stronger. You have 2 options it seems:

1. Increase web server cipher suite.
2. Tell the eAPI client to use 'DEFAULT' ciphers.

Our team doesn't make the calls to be able to use option 1 and option 2 NAPALM seems to not support (at least that I am aware of)

eapi supporting documentation: https://pyeapi.readthedocs.io/_/downloads/en/develop/pdf/ (Page 28)

Our pyeapi implementation:

import pyeapi


def connect(switch):
    eapi_param = pyeapi.client.connect(
        transport='https',
        host=switch,
        username=username,
        password=password,
        port=443,
    )
    eapi_param.transport._context.set_ciphers('DEFAULT')
    return pyeapi.client.Node(eapi_param)

Did you follow the steps from https://github.com/napalm-automation/napalm#faq

(Place an x between the square brackets where applicable)

• Yes
• [] No

Setup

napalm version

(Paste verbatim output from pip freeze | grep napalm between quotes below)

We removed NAPALM from this specific use case because it wasn't working but we were using 3.3.1

Network operating system version

(Paste verbatim output from show version - or equivalent - between quotes below)

EOS 4.24.6M

Steps to Reproduce the Issue

1. Install Python 10+
2. Install NAPALM
3. Utilize it with EOS devices.

Error Traceback

(Paste the complete traceback of the exception between quotes below)

 [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure.

[bewing]

FWIW, the following does work on 3.10 and the current version of NAPALM:

import ssl
from napalm.eos import EOSDriver

ctx = ssl.create_default_context()
ctx.set_ciphers("DEFAULT")
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE

with EOSDriver("ceos", "eos", "eos", optional_args={"context": ctx}) as d:
    print(d.get_facts())

[ktbyers]

@bewing What do you think we should do here?

The main two options I see:

1. Do nothing i.e. the above fix works and people can use it.
2. Put a little helper function that does the above (if we did that I would want to research some of the setting some more as I would want to make sure they were proper).

FYI, the SSL issue also goes away in newer versions of EOS (i.e. they default to better security settings than older versions).

[ktbyers]

I am going to close this as I don't think there is any action to take. The fix above let's you workaround this issue.

[ktbyers]

Here is another workaround you can do (entirely via Arista device configuration):

security pki key generate rsa 2048 self-signed.key

security pki certificate generate self-signed self-signed.crt key self-signed.key validity 365 parameters common-name bogus.domain.com country US state CA locality SF organization BigCo organization-unit OPS

config term
  management security 
  ssl profile selfSignedSSLProfile
    certificate self-signed.crt key self-signed.key
  management api http-commands
    protocol https ssl profile selfSignedSSLProfile

Solution courtesy this Reddit thread:

https://www.reddit.com/r/Arista/comments/wnm3m0/eos_and_nornirnapalmpyeapi_default_cipher_suite/

[bewing]

Anyone figure out a way to make the playbook listed idempotent?
Haven't found a CLI command that exposes the current key length.

I guess you could just gate on the presence of the protocol https ssl profile selfSignedSSLProfile line, and/or tie it in with ACME type of solution to have real signed certs

[ktbyers]

I pushed this part out via NAPALM-ansible and it looks idempotent (full config replace though)

  management security 
  ssl profile selfSignedSSLProfile
    certificate self-signed.crt key self-signed.key
  management api http-commands
    protocol https ssl profile selfSignedSSLProfile

I did the other two security pki commands as one offs though using netmiko-tools.

I did run into a bit of a strange error on the config change using napalm-ansible.Incomplete read (44 bytes) would show up in the output (sometimes), but the config change would go through.