2014-03-09 06:21:15 +08:00
|
|
|
_ _ ____ _
|
|
|
|
___| | | | _ \| |
|
|
|
|
/ __| | | | |_) | |
|
|
|
|
| (__| |_| | _ <| |___
|
|
|
|
\___|\___/|_| \_\_____|
|
|
|
|
|
2016-08-09 20:47:20 +08:00
|
|
|
# SSL problems
|
2014-03-09 06:21:15 +08:00
|
|
|
|
2014-03-13 11:48:38 +08:00
|
|
|
First, let's establish that we often refer to TLS and SSL interchangeably as
|
2014-03-09 06:21:15 +08:00
|
|
|
SSL here. The current protocol is called TLS, it was called SSL a long time
|
|
|
|
ago.
|
|
|
|
|
|
|
|
There are several known reasons why a connection that involves SSL might
|
2022-01-27 09:12:50 +08:00
|
|
|
fail. This is a document that attempts to detail the most common ones and
|
2014-03-09 06:21:15 +08:00
|
|
|
how to mitigate them.
|
|
|
|
|
2016-08-09 20:47:20 +08:00
|
|
|
## CA certs
|
2014-03-09 06:21:15 +08:00
|
|
|
|
|
|
|
CA certs are used to digitally verify the server's certificate. You need a
|
2022-09-21 05:30:19 +08:00
|
|
|
"ca bundle" for this. See lots of more details on this in the `SSLCERTS`
|
2014-03-09 06:21:15 +08:00
|
|
|
document.
|
|
|
|
|
2016-08-09 20:47:20 +08:00
|
|
|
## CA bundle missing intermediate certificates
|
2014-03-09 23:55:13 +08:00
|
|
|
|
|
|
|
When using said CA bundle to verify a server cert, you will experience
|
2021-02-05 17:50:51 +08:00
|
|
|
problems if your CA store does not contain the certificates for the
|
2021-10-31 23:34:44 +08:00
|
|
|
intermediates if the server does not provide them.
|
2021-02-05 17:50:51 +08:00
|
|
|
|
|
|
|
The TLS protocol mandates that the intermediate certificates are sent in the
|
|
|
|
handshake, but as browsers have ways to survive or work around such
|
|
|
|
omissions, missing intermediates in TLS handshakes still happen that
|
2021-10-31 23:34:44 +08:00
|
|
|
browser-users will not notice.
|
2021-02-05 17:50:51 +08:00
|
|
|
|
|
|
|
Browsers work around this problem in two ways: they cache intermediate
|
|
|
|
certificates from previous transfers and some implement the TLS "AIA"
|
2021-07-09 20:21:32 +08:00
|
|
|
extension that lets the client explicitly download such certificates on
|
2021-02-05 17:50:51 +08:00
|
|
|
demand.
|
2014-03-09 23:55:13 +08:00
|
|
|
|
2016-08-09 20:47:20 +08:00
|
|
|
## Protocol version
|
2014-03-09 06:21:15 +08:00
|
|
|
|
|
|
|
Some broken servers fail to support the protocol negotiation properly that
|
|
|
|
SSL servers are supposed to handle. This may cause the connection to fail
|
2014-03-13 11:48:38 +08:00
|
|
|
completely. Sometimes you may need to explicitly select a SSL version to use
|
2014-03-09 06:21:15 +08:00
|
|
|
when connecting to make the connection succeed.
|
|
|
|
|
|
|
|
An additional complication can be that modern SSL libraries sometimes are
|
|
|
|
built with support for older SSL and TLS versions disabled!
|
|
|
|
|
2021-02-05 17:50:51 +08:00
|
|
|
All versions of SSL and the TLS versions before 1.2 are considered insecure
|
|
|
|
and should be avoided. Use TLS 1.2 or later.
|
2015-06-29 21:03:56 +08:00
|
|
|
|
2016-08-09 20:47:20 +08:00
|
|
|
## Ciphers
|
2014-03-09 06:21:15 +08:00
|
|
|
|
2021-10-31 23:34:44 +08:00
|
|
|
Clients give servers a list of ciphers to select from. If the list does not
|
2014-03-09 06:21:15 +08:00
|
|
|
include any ciphers the server wants/can use, the connection handshake
|
|
|
|
fails.
|
|
|
|
|
|
|
|
curl has recently disabled the user of a whole bunch of seriously insecure
|
|
|
|
ciphers from its default set (slightly depending on SSL backend in use).
|
|
|
|
|
|
|
|
You may have to explicitly provide an alternative list of ciphers for curl
|
2022-09-21 05:30:19 +08:00
|
|
|
to use to allow the server to use a weak cipher for you.
|
2014-03-09 06:21:15 +08:00
|
|
|
|
|
|
|
Note that these weak ciphers are identified as flawed. For example, this
|
|
|
|
includes symmetric ciphers with less than 128 bit keys and RC4.
|
|
|
|
|
2019-05-17 06:11:27 +08:00
|
|
|
Schannel in Windows XP is not able to connect to servers that no longer
|
2015-06-29 21:03:56 +08:00
|
|
|
support the legacy handshakes and algorithms used by those versions, so we
|
2022-10-26 14:59:35 +08:00
|
|
|
advise against building curl to use Schannel on really old Windows versions.
|
2015-06-29 21:03:56 +08:00
|
|
|
|
2022-09-21 05:30:19 +08:00
|
|
|
Reference: [Prohibiting RC4 Cipher
|
|
|
|
Suites](https://datatracker.ietf.org/doc/html/draft-popov-tls-prohibiting-rc4-01)
|
2016-02-02 07:24:30 +08:00
|
|
|
|
2016-08-09 20:47:20 +08:00
|
|
|
## Allow BEAST
|
2014-03-09 06:21:15 +08:00
|
|
|
|
|
|
|
BEAST is the name of a TLS 1.0 attack that surfaced 2011. When adding means
|
|
|
|
to mitigate this attack, it turned out that some broken servers out there in
|
2021-10-31 23:34:44 +08:00
|
|
|
the wild did not work properly with the BEAST mitigation in place.
|
2014-03-09 06:21:15 +08:00
|
|
|
|
|
|
|
To make such broken servers work, the --ssl-allow-beast option was
|
|
|
|
introduced. Exactly as it sounds, it re-introduces the BEAST vulnerability
|
|
|
|
but on the other hand it allows curl to connect to that kind of strange
|
|
|
|
servers.
|
2015-07-17 14:40:16 +08:00
|
|
|
|
2016-08-09 20:47:20 +08:00
|
|
|
## Disabling certificate revocation checks
|
2015-07-17 14:40:16 +08:00
|
|
|
|
|
|
|
Some SSL backends may do certificate revocation checks (CRL, OCSP, etc)
|
|
|
|
depending on the OS or build configuration. The --ssl-no-revoke option was
|
|
|
|
introduced in 7.44.0 to disable revocation checking but currently is only
|
2019-05-17 06:11:27 +08:00
|
|
|
supported for Schannel (the native Windows SSL library), with an exception
|
2021-10-31 23:34:44 +08:00
|
|
|
in the case of Windows' Untrusted Publishers block list which it seems cannot
|
2019-05-17 06:11:27 +08:00
|
|
|
be bypassed. This option may have broader support to accommodate other SSL
|
2015-07-17 14:40:16 +08:00
|
|
|
backends in the future.
|
|
|
|
|
|
|
|
References:
|
|
|
|
|
2020-11-04 21:02:01 +08:00
|
|
|
https://curl.se/docs/ssl-compared.html
|