Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SSLV3_ALERT_HANDSHAKE FAILURE #351

Open
aschneid-cnrfc opened this issue Oct 28, 2024 · 91 comments
Open

SSLV3_ALERT_HANDSHAKE FAILURE #351

aschneid-cnrfc opened this issue Oct 28, 2024 · 91 comments
Labels
user support

Comments

@aschneid-cnrfc
Copy link

My evaluations through the COWRES suddenly stopped working. I thought that there may be a problem connecting to the server but I am able to access the WRES website in windows. When I run my script I am getting an SSLV3_ALERT_HANDSHAKE_FAILURE error. I have not changed the certificate or the location of the certificate. Is anything going on in the back end with the COWRES?
@HankHerr-NOAA
Copy link
Contributor

Anna,

The proxy in the DMZ was updated today to a newer version. I just confirmed that the change was made and completed, and that I have access to the services via the proxy. Can you please double check to confirm if you are continuing to have the issue now? If not, then those reported errors and your check via Windows may have happened when the proxy was temporarily down. That would point to a mistake on my part failing to communicate the short outage before hand. If the problem is still occurring, then it points to a more general problem impacting RFCs that doesn't impact OWP.

Thanks,

Hank

@HankHerr-NOAA HankHerr-NOAA added this to the v6.28 milestone Oct 28, 2024
@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 28, 2024 via email

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email

@epag
Copy link
Collaborator

epag commented Oct 29, 2024

Sorry for the delayed response, I was on lunch, Hank took off for the day. I was just able to visit the proxy, could you check again on your side

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email

@epag
Copy link
Collaborator

epag commented Oct 29, 2024

You are able to access things via the website correct? Can you attach the full error statement, Ill try out the script to see if I can reproduce

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email

@epag
Copy link
Collaborator

epag commented Oct 29, 2024

Hmmmm, maybe when they were messing with the DMZ stuff they changed cert information. Let me try using the cert you all are using and see if that is the issue. It seems like an issue with the cert though based on what you are saying though

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email

@epag
Copy link
Collaborator

epag commented Oct 29, 2024

An interim solution you can try is to change this line in the python script to ignore SSL verification:

verify = wres_ca_file, -> verify = False,

Ill look into the cert now and see if it works for me. Nothing should have changed there, but thats my best guess at the issue

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email

@epag
Copy link
Collaborator

epag commented Oct 29, 2024

Hm, I tried using the cert that you had posted about using in a previous ticket and I had no issue making a call to the proxy to post a job but it could be that im on the internal networks so I don't need to use the DMZ

Let me know if my workaround works or not, otherwise this may be an IT issue on either your or our side.

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email

@epag
Copy link
Collaborator

epag commented Oct 29, 2024

Huh, I checked the database and it looks like people are still submitting evaluations so at least this doesn't appear to be an issue with our backend service. If you can access the GUI as well then there shouldn't be some special issue with using a script. If you need to use it before the issue is resolved you can run evaluations via the front end but I will work with Hank tomorrow to debug the proxy to see if we can see your requests coming through.

Sorry for the issue, seems like the updates to the proxy that our IT did may have broken something

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Anna,

Taking a brief look at this after work hours... I think you may be making HTTP requests using an SSL/TLS version that is too old; specifically SSL v3. Details are below, but, to be clear, I may be barking up the wrong tree, so please let me know if I am. This is a bit outside of my area of expertise.

My first clue was in the message:

ssl.SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:1131)

While I've heard of "ssl", obviously, I wasn't familiar with the specific prefix, "SSLV3". So I looked it up and discovered that SSL v3 is an older protocol, with following quote from a Google search:

SSLv3 is no longer considered secure and should be turned off in favor of more modern protocols. SSLv3 has several vulnerabilities, including:...

I also found this:

SSLv3 was renamed to TLS after SSL was upgraded to TLSv1.0. The latest standard version of SSL is TLSv1.2.

The reason I was not familiar with the "SSLV3" prefix is because we use TLSv1.2 (I think; Evan or James may be able to confirm more readily than I can). Noting that the latest changes to the proxy in the DMZ involve an upgrade to a newer version of HAProxy, I then wondered if they turned off use of SSLv3 in HAProxy much like the web search results are recommending.

Sure enough, Google's AI summary says this:

HAProxy 1.5 and later versions disallow SSLv3 (Secure Socket Layer):

We upgraded the HAProxy to 2.4; the previous version was 1.something, but I can't recall the something. So, this makes me think your code needs to be modified to use TLS v1.2 instead of SSLv3.

Unfortunately, my knowledge of Python is limited, so I can't be exactly sure what code recommendation to make to ensure you are using a newer TLS version. Our script is provided and described in this wiki:

https://github.com/NOAA-OWP/wres/wiki/WRES-Scripts-Usage-Guide

Perhaps Evan can provide more details.

If you have any reason to disagree with what I said above, please let me know. Again, this is just my best guess based on the message you provided and what I'm finding in a web search. If I am "barking up the wrong tree", I can revisit this tomorrow with Evan and we can figure it out from there. Thanks,

Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Interesting, I'm not sure why though this would suddenly turn into a problem right after you all did an update. It was working fine all morning and then suddenly gave me that error.

Based on the timing you described, it appears that the error didn't start happening until after the upgrade to HAProxy 2.4. So it makes sense that 2.4 exposes the error, while before that upgrade, HAProxy didn't complain.

I was worried your Python snippets would show nothing obvious. Again, Evan may be able to help tomorrow. Also, if I'm right about the HAProxy rejecting your attempt to connect because of the SSL version, then I should see something in the HAProxy traffic log stating as much in a message (I hope; log messaging can be finicky).

Can you please let me know the time of your last attempt to connect? The HAProxy traffic log is likely to be very big and difficult to parse through, so the timing may help. I'm also hoping I can trigger off of your postInput and keepInput settings, both of which are somewhat rare, particularly keepInput.

More tomorrow. Have a great evening!

Hank

@HankHerr-NOAA
Copy link
Contributor

One more quick test you can perform from the same machine where you are running Python...

curl -v --cacert cowres_dod_ca_chain.pem https://wres.nwc.nws.noaa.gov/job

If it works, then, at the very end, you see just "Up". The verbose output should also include a 200 response. Let me know what happens when you run the above command.

Again, more tomorrow,

Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Oh... If this is tied to an AWIPS version, and that AWIPS version is too old, then, yeah, that's a problem.

I think your Python venv will include a version for requests and urllib3. Can you get those versions? My apologies for not being sure how best to do that off the top of my head. I'm already being called down by my family, so I really need to get off of the computer. Maybe I'll check back in later this evening.

Have a great evening,

Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Because this is bugging me so much, I decided to take a look at the server logs.

First, I think the "SSLV3" stuff is just a distraction. I think that is some sort of general message Python returns when the handshake fails that doesn't actually indicate you are using SSL v3. Something else is going wrong, as indicated by the failure of your curl command to connection.

Server side, the HAProxy is logging the failed handshakes as exactly that with no details. Here are the messages around the time you provided:

<134>Oct 29 21:46:01 haproxy[8]: [IP omitted]:47068 [29/Oct/2024:21:46:01.207] https-in/1: SSL handshake failure
<134>Oct 29 21:46:34 haproxy[8]: [IP omitted]:47112 [29/Oct/2024:21:46:34.445] https-in/1: SSL handshake failure
<134>Oct 29 21:50:55 haproxy[8]: [IP omitted]:48044 [29/Oct/2024:21:50:55.830] https-in/1: SSL handshake failure

Using the curl command I shared, I saw the verbose logging below. Connection was successful (as expected).

If you can, Anna, please share the complete, verbose logging you get from your curl command (you may want to remove any references to IP addresses; if you prefer you can email me the output).

At this point, there is nothing more I can investigate without more verbose output from curl or Python explaining why the handshake failed. Thanks,

Hank

==========

[hank.herr@owpal-d-ised01 issue103897]$ curl -v --cacert cowres_dod_ca_chain.pem https://wres.nwc.nws.noaa.gov/job
*   Trying [IP address omitted]...
* TCP_NODELAY set
* Connected to wres.nwc.nws.noaa.gov ([IP address  omitted]) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: cowres_dod_ca_chain.pem
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, [no content] (0):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: C=US; O=U.S. Government; OU=DoD; OU=PKI; OU=DISA; CN=wres.nwc.nws.noaa.gov
*  start date: Mar 12 18:39:17 2024 GMT
*  expire date: Mar 12 18:39:17 2027 GMT
*  subjectAltName: host "wres.nwc.nws.noaa.gov" matched cert's "wres.nwc.nws.noaa.gov"
*  issuer: C=US; O=U.S. Government; OU=DoD; OU=PKI; CN=DOD SW CA-66
*  SSL certificate verify ok.
* TLSv1.3 (OUT), TLS app data, [no content] (0):
> GET /job HTTP/1.1
> Host: wres.nwc.nws.noaa.gov
> User-Agent: curl/7.61.1
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, [no content] (0):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS app data, [no content] (0):
< HTTP/1.1 200 OK
< date: Tue, 29 Oct 2024 23:08:26 GMT
< content-type: text/plain;charset=utf-8
< vary: Accept-Encoding
< content-length: 2
< server: Jetty(11.0.24)
< x-frame-options: DENY
< x-xss-pz`rotection: 1;mode=block
< x-content-type-options: nosniff
< strict-transport-security: max-age=31536000; includeSubDomains; preload;
< cache-control: no-cache, max-age=0
< 
* Connection #0 to host wres.nwc.nws.noaa.gov left intact

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 29, 2024 via email •
edited by HankHerr-NOAA
Loading

@james-d-brown
Copy link
Collaborator

Anna,

Can you double-check that you are using https in your curl? The following shows http, not https:

ls2-rsa.wr.awips.noaa.gov{ldad}102: curl -v --cacert cowres_dod_ca_chain.pem http://wres.nwc.nws.noaa.gov/job

Thanks,

James

@james-d-brown
Copy link
Collaborator

As an aside, bumping the major version of the proxy server software should entail a fairly rigorous staging/testing protocol because the major version bump implies breaking changes. Most likely, the major version bump has brought about some changes to legacy tls settings that are incompatible with an old version of python and/or the requests package. Educated guess. It may help to turn on debug logging within python requests. Most likely, the curl failure is a distraction here and that will succeed when https is used, but we'll see...

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 30, 2024 via email

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 30, 2024 via email

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 30, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Ann:

The older version of the HAProxy is back up and running. Please let me know if you are able to connect. If not, then it means something else has gone awry,

Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 30, 2024 via email

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 30, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Thanks. I'm glad your scripts are working again. That confirms it was something with the HAProxy upgrade combined with your AWIPS environment that is causing the issue.

Hank

@HankHerr-NOAA
Copy link
Contributor

This web search would appear to agree largely with what James was saying about incompatible ciphers (based on the AI summary):

https://www.google.com/search?q=SSLV3_ALERT_HANDSHAKE_FAILURE+Python+HAProxy&rlz=1C1GCEA_enUS1057US1057&oq=SSLV3_ALERT_HANDSHAKE_FAILURE+Python+HAProxy&gs_lcrp=EgZjaHJvbWUyCQgAEEUYORigATIHCAEQIRigATIHCAIQIRigAdIBCTIwNDQwajBqNKgCALACAA&sourceid=chrome&ie=UTF-8

Protocol mismatch should not be an issue so long as the HAProxy 1.8 (now running) respects this line in its configuration:

        ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

That line disallows anything before TLS v1.2. Since Anna's scripts are now working, they must be using v1.2 or later.

The certificate should also be valid. I was able to use the file cowres_dod_ca_chain.pem to authenticate the COWRES, as was Anna (now that we've reverted to 1.8).

However, we still need to confirm ciphers is the cause by reproducing the issue locally. Since this is a user support ticket, I'll create a development ticket tomorrow and start trying to reproduce the issue. I'll obtain an RHEL 7 image (trying to match versions with whatever AWIPS uses), install the correct version of Python on it, hop into the container, and try to reproduce the problem.

Next time I comment in this ticket, it should be to confirm that we reproduced the problem locally.

Thanks,

Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 30, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Anna,

I'm not certain just updating requests will be enough. In fact, it may have something do with the AWIPS machine, itself. I was unable to reproduce your error when deploying Python 3.8.18 and requests 2.22.0 in a Docker container, so I'm not entirely sure the ciphers are coming from Python/requests or coming from the AWIPS machine.

My investigation has barely begun, so I could be wrong, and there certainly is value in updating requests as well as Python, if they allow it, regardless of this ticket. So I'm not saying don't ask for it; I'm just not sure that will fix this issue.

Thanks,
Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 30, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

The problem reported here is very much OWP/NWC specific, so I'm tracking reproducing and fixing it in a VLab ticket #136136.

Anna:

Since I think this may be a cipher issue, when you can, please identify for me the cipher suite being used by your Python requests when you make calls to the COWRES. The AI summary in this search should tell you how to do it. However, I haven't had a chance to test it myself. If you know of a better way to do it, let me know. Python is not my first language.

My hope is to somehow force my tests to use your cipher suite to determine if that is the cause of the handshake failure.

Thanks,

Hank

@james-d-brown
Copy link
Collaborator

The negotiation of the cipher should be part of the debug logging information for the handshake on both sides and I would expect a message somewhere about the failure to negotiate a common cipher between the client and server if that is indeed the issue. In general, it can be hard to debug tls because limited information is provided for obvious reasons, but the debug logging of the client and server should reveal a lot. I am not sure how this is turned on in python requests, however.

@HankHerr-NOAA
Copy link
Contributor

True. Anna could turn on debugging on her end and run the same evaluation to see what ciphers are reported in the logging. Whether that is easier than running the command Google identified in Python is up to her.

I'll see what I can do on our end to identify the HAProxy cipher suite in staging. Hopefully, it matches what would be in the DMZ using HAProxy 2.4, but I can't be absolutely certain. Reproducing the issue using Anna's cipher would give me more confidence, however.

Hank

@HankHerr-NOAA
Copy link
Contributor

Anna: I have a series of Python lines-of-code for you to run that should allow you to identify the cipher. Please run them when you have time. I'm hoping you'll see a different cipher than I'm seeing.

So, I tried a few different ways to get at the cipher being used in Python. It wasn't as easy as just turning on debug, but that may be because of my own ignorance of Python. Eventually, I settled on this approach found via web search that wraps around the request to dump the cipher:

$ python
Python 3.8.18 (default, Mar 12 2024, 12:46:23) 
[GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>> from http.client import HTTPConnection
>>> from http.client import HTTPConnection
>>> 
>>> 
>>> def request(self, method, url, body=None, headers={}, *,
...             encode_chunked=False):
...     self._send_request(method, url, body, headers, encode_chunked)
...     print(self.sock.cipher())
... 
>>> HTTPConnection.request = request
>>> response = requests.get("https://wres.nwc.nws.noaa.gov/job",verify='cowres_dod_ca_chain.pem')
('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)
>>>

You can see that the cipher being used is ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256) and that seems to work for accessing either the old or the new proxy. I did confirm by running `print(response)' that I get a 200 response, so it connects. I also get a 200 visiting the staging proxy, which is still using the new HAProxy 2.4.

Thanks,

Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 31, 2024 via email

@james-d-brown
Copy link
Collaborator

Not sure if that is reporting accurately, but TLSv1.0 is going to be a problem as that is ancient/insecure. I wonder if there is a setting in Python to enforce/request TLS1.2 or above. We only support TLS1.2 and TLS1.3, I assume for the proxy too, but certainly the backend. The cipher looks fine, but I'm not even sure that meshes with TLSv1.0.

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 31, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Thanks, Anna! I think we are definitely closer to identifying the problem now.

TLSv1/SSLv3 should be a problem. Given that we are disallowing access to the proxy using TLS older the v1.2 in the configuration,

        ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

I'm surprised that you are even able to connect to the old proxy. I think Brock from ITSG wondered if the 1.8 HAProxy is respecting that configuration line; now I'm wondering the same. I'll look into that.

I'm hoping its possible set the cipher and TLS version in Python, as James says. I'll start by trying to use your cipher and TLS to see what happens.

Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 31, 2024 via email

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 31, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Anna,

I don't think this is an issue with your TLS version. I was able to prove that the proxy does reject requests that are using an old TLS. So, if you were using SSLv3/TLSv1, then you would have been encountering issues all along.

Hence, I think this is cipher specific. I've been trying to reproduce your problem using your cipher, but have not had luck so far. You can visit VLab ticket #136136 if you want to follow my progress.

Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 31, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Okay. I'm not really sure what to make of the None response when using the adapter as you did before. One thing that might be worth testing is forcing it to use "TLSv1" instead of 1.2. If I'm right, based on my tests, you should fail to access the services.

Anyway, I'm going to spend a bit more time on this tomorrow, but it might point at us having to be patient and wait for AWIPS to upgrade to RHEL 8 (in hopes that the Python cipher is updated) before updating HAProxy to 2.4. More tomorrow,

Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 31, 2024 via email

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Oct 31, 2024 via email

@HankHerr-NOAA
Copy link
Contributor

Thanks, Anna. So you are using a correct version of TLS (1.2 or higher), but the cipher used is one associated with TLSv1/SSLv3 that HAProxy 2.4 will not allow, but HAProxy 1.8 does allow. At least, that's my theory. I just wish I could reproduce the error so that I could explore fixes and mitigations with 2.4.

Have a good weekend,

Hank

@james-d-brown
Copy link
Collaborator

james-d-brown commented Nov 1, 2024 •
edited
Loading

I'm not so sure, tbh. The ECDHE-RSA key exchange algorithms (so, not actually a cipher in itself, but the key exchange part of a cipher suite) are supported in TLSv1.2 and are FIPS compliant, based on my searching (ECDHE = Diffie Hellman Exchange with Eliptic Curve). I think the ECDHE-RSA algorithms are actually supported in all versions of TLS. So, actually, I doubt that is the issue and it may be something more subtle. Either way, it will probably disappear when upgrading Python/Requests/RHEL7, but that may be some time away. This may be a situation where you make a note of the problem and don't sink a ton more time into it until absolutely necessary as these issues can be very hard to reproduce and debug.

@HankHerr-NOAA
Copy link
Contributor

Thanks, James, for digging deeper. That would explain why its so hard for me to reproduce the error. There must be some other check involved with the handshake that is failing under the specific conditions in which the call is made from the CNRFC AWIPS machine. We've confirmed the TLS version is okay and the cipher appears usable (both by your research and what I did using Docker running Python). Some other part of that handshake is failing, and I'm not sure what. And it appears HAProxy can't communicate it from its end without turning on an option that wasn't available until sometime after 2.4. I saw folks using wire shark or other tools to identify issues, but that's way beyond me and would require we put 2.4 back in production so that Anna can run against it.

I agree that spending more time investigating this from my end is probably not worth it. It would be too hard to mirror the CNRFC AWIPS machine precisely enough in Docker.

I'm going to check with the CHPS team to see when the RFCs are slated to move to RHEL 8 so that we can try HAProxy 2.4 at that time. Until then, we won't have proper traffic logging in production. We'll have to cross our fingers that we are able to work around it for a while longer.

Hank

@aschneid-cnrfc
Copy link
Author

aschneid-cnrfc commented Nov 4, 2024 via email

@HankHerr-NOAA HankHerr-NOAA removed this from the v6.28 milestone Nov 6, 2024
@HankHerr-NOAA
Copy link
Contributor

Moving this ticket to the backlog (i.e., removing the milestone).

The HAProxy 2.4 was backed up to 1.8 to support access from the CNRFC AWIPS machine. Until the RFCs move to RHEL 8, and hopefully get a newer version of Python with newer ciphers, we will not be able to return to 2.4. That is, unless IT security folks force us to stop accepting the old ciphers.

Shaif said that the RHEL 8 migration schedule is still up in the air, but hopefully it happens in Anna's time frame of "next year". I guess we'll see. Once all RFCs are on RHEL 8, we'll move to HAProxy 2.4, and ask Anna to test access again via the ticket.

Thanks, Anna, for reporting this issue and let us know if you have any questions or new information,

Hank

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
user support
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@epag @HankHerr-NOAA @james-d-brown @aschneid-cnrfc