sslv3 alert handshake failure

[suryavaddiraju]

Trying to connect https://www.irctc.co.in using requests module but it raises the ssl error when using requests==2.31.0 but not on when using requests==2.29.0 but have not tried it on v2.30

Expected Result

The web page html text content

Actual Result

raise SSLError(e, request=request)
requests.exceptions.SSLError: HTTPSConnectionPool(host='www.irctc.co.in', port=443): Max retries exceeded with url: /nget/train-search (Caused by SSLError(SSLError(1, '[SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:1006)')))

Reproduction Steps

import requests
r = requests.get("https://www.irctc.co.in/nget/train-search")
print(r.text)

System Information

$ python -m requests.help

{
  "chardet": {
    "version": null
  },
  "charset_normalizer": {
    "version": "2.0.12"
  },
  "cryptography": {
    "version": ""
  },
  "idna": {
    "version": "3.6"
  },
  "implementation": {
    "name": "CPython",
    "version": "3.11.7"
  },
  "platform": {
    "release": "10",
    "system": "Windows"
  },
  "pyOpenSSL": {
    "openssl_version": "",
    "version": null
  },
  "requests": {
    "version": "2.28.0"
  },
  "system_ssl": {
    "version": "300000b0"
  },
  "urllib3": {
    "version": "1.26.18"
  },
  "using_charset_normalizer": true,
  "using_pyopenssl": false
}

[sigmavirus24]

Hi there! Thanks for opening this issue. Unfortunately, it seems this is a request for help instead of a report of a defect in the project. Please use StackOverflow for general usage questions instead and only report defects here.

[notabeatle]

This (and some similar recent issues reported here) are probably a result of the CVE fix in 2.31.0. I'm seeing the same thing with a system we connect to with Requests, after upgrading to 2.31.0, and the problem goes away on downgrade to 2.30.0, all else remaining the same. It's not yet clear to me exactly what's going wrong from reading either the error message or the release log for 2.31.0, so I'm not sure whether this is misconfig of the system we're trying to connect to (correctly tripping this new CVE fix, and erroring) and Requests is behaving as it should, or if this is a regression in Requests and our systems are fine. Commenting here so others who end up here have some kind of pointer to what's behind this issue, don't yet have enough info to file this as a bug (indeed, it may not be one).

[nateprewitt]

Hi @notabeatle,

Nothing should have changed in Requests between those two versions unless you were using a non-https scheme and somehow requiring Proxy-Authorization being sent beyond your proxy to the destination host. There shouldn't be any standard configuration doing this. You can find the full list of changes here but I wouldn't expect this to do anything to your TLS handshake.

You may want to note which version of urllib3 you're using in each deployment. Requests<=2.29.0 does not use urllib3 2.0 which made a change to stop using a fixed set of ciphers and instead relies on system configuration from OpenSSL.

[notabeatle]

Yep, it's almost certainly that @nateprewitt . Setting a custom SSL context for urllib ended up being the fix. I'm glad, because I was scratching my head, looking at that tiny diff between 2.30 and 2.31 and trying to figure out how that could be the problem.

Helpful link for anyone else who arrives in this thread: https://quentin.pradet.me/blog/fixing-sslv3_alert_handshake_failure-with-urllib3-20.html