<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Dave Allured - NOAA Affiliate via macports-dev <macports-dev@lists.macports.org> wrote:</div><div dir="ltr"><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Several of us have now reproduced the SSL problem. I see two things in common:</div><div>(1) Older curl/SSL versions bundled into older MacOS versions, such as Catalina.</div><div>(2) The target website, <a href="http://wias-berlin.de">wias-berlin.de</a>.<br></div><div><br></div><div>I suspect <a href="http://wias-berlin.de">wias-berlin.de</a> is misconfigured somehow. Mark, consider showing this problem to them, and ask them to check their server configuration.</div></div></div></blockquote><div><br></div><div>According to SSL Labs their server configuration is pretty good: <a href="https://www.ssllabs.com/ssltest/analyze.html?d=wias-berlin.de&hideResults=on">https://www.ssllabs.com/ssltest/analyze.html?d=wias-berlin.de&hideResults=on</a> reports an A-. <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">The main remark in the report is that the server doesn’t support Secure Renegotiation, which causes the grade to be reduced to A-.</span></div><div><br></div><div>The server supports TLS 1.2 and 1.3 only. Not supporting broken SSL/TLS versions is generally a good thing from a security perspective, but might leave older clients unable to connect. E.g. macports.org also only supports TLS 1.2 and 1.3. As far as I know not supporting a compatible TLS version would have resulted in a message saying so, so I guess that is not the issue.</div><div><br></div><div>The report for wias-berlin.de does show a couple of SSL handshake failures for simulated clients:</div><div><br></div><div>* Chrome 67 / Win 7</div><div>* Firefox 62 / Win 7</div><div>* Googlebot Feb 2018</div><div>* IE 11 / Win Phone 8.1</div><div>* Edge 15-18 / Win 10</div><div>* OpenSSL 1.1.0k (but the older 1.0.1l and 1.0.2s and the newer 1.1.1c are ok!)</div><div>* Safari 6 / iOS 6.0.1</div><div>* Safari 7 / iOS 7.1</div><div>* Safari 7 / OS X 10.9</div><div>* Safari 8 / iOS 8.4</div><div>* Safari 8 / OS X 10.10 (tested version of Safari 9 and later are ok)</div><div><br></div><div>SSL Labs doesn’t seem to be testing any versions of LibreSSL for the simulated handshake test, but I do find it remarkable that OpenSSL 1.1.0k fails, while both older (1.0.1l, 1.0.2s) and newer (1.1.1c) versions of OpenSSL succeed.</div><div><br></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">All of the simulated handshakes that failed for wias-berlin.de do succeed for macports.org. </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">I don’t know if these handshake failures are caused by the server not offering any cipher suites supported by the client.</span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">You could indeed try to contact the admin for wias-berlin.de to tell them that downloads from their domain are not working on macOS 11 Intel’s curl if that’s been established, and see if they know what to do (and care enough) to fix that.</span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></span></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0);">The only other fix seems switching out the client for one that works (e.g. MacPorts curl).</span></font></div><div><br></div><div>Nils.</div></body></html>