SSL error about duo_client_python

[brian-snopek]

I am having the same issue - also using AL2, but I've tried several other things without any luck:

• tried locally (macOS) from command line
• tried in both alpine and ubuntu containers
• I've also tried tried version 3.8 and 3.7
• tried adding ndg-httpsclient, pyopenssl, pyasn1 and requests[security]
• tried unsetting https_proxywith the same results.
• tried both connected and disconnected from my VPN

The only thing that really changes is the line number in (_ssl.c:####)

This was working correctly on Thursday April 23rd (2021) in the evening (PST) - I dont recall if I had tried or not on Friday, but it started failing when I started it back up on Saturday (2021-04-25)

Any assistance on this would be GREATLY appreciated

[glennbach]

Because I was desperate to finish my work, I cloned and modified my local copy (quick and dirty) by replacing your api requests with one from the python module 'requests':

    def _attempt_single_request(self, method, uri, body, headers):
        print('Trying:', method, uri, body, headers)
        if method == 'GET':
            response = requests.get(f"https://{self.host}{uri}", headers=headers, data=body)
        elif method == 'POST':
            response = requests.post(f"https://{self.host}{uri}", headers=headers, data=body)
        data = response.json()
        return (response, data)

it worked perfectly, so it isn't a fundamental system issue. (and I know that this is a stupid way to switch between get and put. As I said, it was just quick and dirty...) I did have to make a few other changes to accommodate this change.

[brian-snopek]

Thanks @glennbach - I attempted what you suggested here - and it did make the request without generating the SSLEOF error - but the response and data returned are missing a lot of properties that caused several other errors.

I think its a great start into identifying where the problem is - and I'll continue looking into this myself in the meantime, but I'm still hoping for a full solution that doesn't require a one-off patch ;)

Thanks again for the info - appreciated

[mbish]

Sorry to hear you've been having issues with the client. I'm looking into this issue now.
Which API host are you connecting to?
Are you specifying any extra configuration options besides the ikey/skey/host?

[brian-snopek]

I have no extra configuration - I'm specifically connecting through the admin api, and updating user status only. Thanks

[mbish]

Which URL are you using to access the admin api?

[brian-snopek]

This is the exact (and only) method we have using the duo_client_python:

def set_duo_status(status='disabled'):
status = status if status in ('disabled', 'bypass') else 'disabled'

admin_api = duo_client.Admin(
    ikey=get_param('duo-api-key'),
    skey=get_param('duo-api-secret'),
    host=get_param('duo-api-host'),
)
userData = admin_api.update_user(
    user_id=get_param('duo-api-userid'),
    status=status
)

[brian-snopek]

are you asking what host we're passing ?

[mbish]

yeah. If you could post the value of your duo-api-host that would be helpful.

[brian-snopek]

No problem: api-7cafe99d.duosecurity.com

Thanks again.

[glennbach]

Mine is api-a3b78b57.duosecurity.com

[mbish]

Can you post the output of curl -vvI https://<insert api URL> from the AL2 machine having this issue?

[brian-snopek]

bash-4.2# curl -vvI https://api-7cafe99d.duosecurity.com
* Rebuilt URL to: https://api-7cafe99d.duosecurity.com/
*   Trying 54.241.191.167...
* TCP_NODELAY set
* Connected to api-7cafe99d.duosecurity.com (54.241.191.167) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=Michigan; L=Ann Arbor; O=Duo Security, Inc.; CN=*.duosecurity.com
*  start date: Dec 18 00:00:00 2019 GMT
*  expire date: Mar  9 12:00:00 2022 GMT
*  subjectAltName: host "api-7cafe99d.duosecurity.com" matched cert's "*.duosecurity.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*  SSL certificate verify ok.
> HEAD / HTTP/1.1
> Host: api-7cafe99d.duosecurity.com
> User-Agent: curl/7.61.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Server: Duo/1.0
Server: Duo/1.0
< Date: Mon, 26 Apr 2021 18:15:48 GMT
Date: Mon, 26 Apr 2021 18:15:48 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 180
Content-Length: 180
< Connection: keep-alive
Connection: keep-alive
< Location: https://duo.com/
Location: https://duo.com/
< Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000
< Content-Security-Policy: default-src 'self'; frame-src 'self' ; img-src 'self'  ; connect-src 'self'    
Content-Security-Policy: default-src 'self'; frame-src 'self' ; img-src 'self'  ; connect-src 'self'    

< 
* Connection #0 to host api-7cafe99d.duosecurity.com left intact
bash-4.2# 

[glennbach]

Mine shows:

* Rebuilt URL to: https://api-a3b78b57.duosecurity.com/
*   Trying 54.241.191.183...
* TCP_NODELAY set
* Connected to api-a3b78b57.duosecurity.com (54.241.191.183) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=US; ST=Michigan; L=Ann Arbor; O=Duo Security, Inc.; CN=*.duosecurity.com
*  start date: Dec 18 00:00:00 2019 GMT
*  expire date: Mar  9 12:00:00 2022 GMT
*  subjectAltName: host "api-a3b78b57.duosecurity.com" matched cert's "*.duosecurity.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*  SSL certificate verify ok.
> HEAD / HTTP/1.1
> Host: api-a3b78b57.duosecurity.com
> User-Agent: curl/7.61.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< Server: Duo/1.0
Server: Duo/1.0
< Date: Mon, 26 Apr 2021 18:21:19 GMT
Date: Mon, 26 Apr 2021 18:21:19 GMT
< Content-Type: text/html
Content-Type: text/html
< Content-Length: 180
Content-Length: 180
< Connection: keep-alive
Connection: keep-alive
< Location: https://duo.com/
Location: https://duo.com/
< Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000
< Content-Security-Policy: default-src 'self'; frame-src 'self' ; img-src 'self'  ; connect-src 'self'    
Content-Security-Policy: default-src 'self'; frame-src 'self' ; img-src 'self'  ; connect-src 'self'    

< * Connection #0 to host api-a3b78b57.duosecurity.com left intact

[brian-snopek]

is it possible this is related to the recent tls 1.1 deprecation ?

[mbish]

I wish I had better news but I haven't been able to reproduce this using the AL2 container (or anything else for that matter). Nothing looks suspicious in the curl output and those api hosts are operating as expected. At this point the next step would be to get a packet capture of the api request / TLS negotiation and analyze that but that's not something I'd want on a public github issue. Could you file a support request with Duo, link this issue, and tell them you've been speaking with the applications team? That way we can have a private / secure way of exchanging information.

[brian-snopek]

Thanks @mbish - Request sent - if you can let me know there details on what you need in the dump, I'll get it generated right away..

Additionally, its running in container - I could give you a dockerfile that should produce the same error

[mbish]

Yeah if there's nothing sensitive in the dockerfile that would be great to have.

[glennbach]

Mine is docker as well.

[ragrella]

I've been fighting with this in a Docker container also. Adding ca_certs="DISABLE" to my duo_client.Admin(...) line got the client working. Still trying to figure out how to get it working without setting ca_certs to DISABLE

doing the follow does not seem to fix the issue either:
root@75fd7785ad90:/usr/src/app# apt-get update
root@75fd7785ad90:/usr/src/app# apt-get install ca-certificates
root@75fd7785ad90:/usr/src/app# update-ca-certificates

root@75fd7785ad90:/usr/src/app# export SSL_CERT_FILE=/usr/lib/ssl/ca-certificates.crt
OR
root@75fd7785ad90:/usr/src/app# export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt