Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: curl with openssl not honoring MaxProtocol in openssl conf
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Jeffrey Walton via curl-users <curl-users_at_lists.haxx.se>
Date: Tue, 3 Jan 2023 12:07:06 -0500
On Tue, Jan 3, 2023 at 11:53 AM Andreas Hasenack via curl-users
<curl-users_at_lists.haxx.se> wrote:
> [...]
> In the case of curl, it seems to work fine for other parameters (well,
> one I tested). For example, I can use "MinProtocol = TLSv1.3", and
> when I try to use curl to connect to a TLSv1.2-only server, it
> correctly fails:
>
> Client:
> openssl config:
> [system_default_sect]
> CipherString = DEFAULT:_at_SECLEVEL=2
> MinProtocol = TLSv1.3
>
> $ curl -o /dev/null https:/j-server.lxd:4433
> % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
> curl: (35) error:0A00042E:SSL routines::tlsv1 alert protocol version
>
> Server:
> $ openssl s_server -cert j-server.pem -key j-server.key -tls1_2
> Using default temp DH parameters
> ACCEPT
> ERROR
> 4037AA6B3E7F0000:error:0A000102:SSL
> routines:tls_early_post_process_client_hello:unsupported
> protocol:../ssl/statem/statem_srvr.c:1657:
> shutting down SSL
> CONNECTION CLOSED
>
> So for this combo Max/MinProtocol, it's just the MaxProtocol one that
> isn't being followed. Granted it's the less useful one, as usually we
> want to restrict old suites.
A small nit... SSL/TLS does _not_ have a min and max protocol version.
There's a record layer version,[1] and a handshake version.[2]
Specifying record layer version = TLS v1.0 and handshake version = TLS
1.3 does not mean the set of protocols in the range [v1.0, v1.3].
The record layer carries all of the protocol messages. It is usually
selected as the minimum version the client and server can use to
communicate. The record layer carries the Hello's and other
administrative messages.
The handshake version is agreed upon, and selects the key exchange and
bulk encryption algorithms. TLS v1.2 is usually desired because it
MACs more fields than TLS 1.0 and below. You won't know which fields
to MAC until you select a handshake version. (TLS v1.1 did not change
anything. It merely added elliptic curve gear). TLS v1.3 is also
desired because it offers cipher suites with strong authentication
properties.
The TLS Working group declined to make the versions a range. Their
argument was there may be "holes" in the range. For example, a web
server might offer TLS v1.0 and v1.3, but not v1.1 and v1.2.
Jeff
[1] https://www.rfc-editor.org/rfc/rfc5246.html#section-6.2
[2] https://www.rfc-editor.org/rfc/rfc5246.html#section-7.3
Date: Tue, 3 Jan 2023 12:07:06 -0500
On Tue, Jan 3, 2023 at 11:53 AM Andreas Hasenack via curl-users
<curl-users_at_lists.haxx.se> wrote:
> [...]
> In the case of curl, it seems to work fine for other parameters (well,
> one I tested). For example, I can use "MinProtocol = TLSv1.3", and
> when I try to use curl to connect to a TLSv1.2-only server, it
> correctly fails:
>
> Client:
> openssl config:
> [system_default_sect]
> CipherString = DEFAULT:_at_SECLEVEL=2
> MinProtocol = TLSv1.3
>
> $ curl -o /dev/null https:/j-server.lxd:4433
> % Total % Received % Xferd Average Speed Time Time Time Current
> Dload Upload Total Spent Left Speed
> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
> curl: (35) error:0A00042E:SSL routines::tlsv1 alert protocol version
>
> Server:
> $ openssl s_server -cert j-server.pem -key j-server.key -tls1_2
> Using default temp DH parameters
> ACCEPT
> ERROR
> 4037AA6B3E7F0000:error:0A000102:SSL
> routines:tls_early_post_process_client_hello:unsupported
> protocol:../ssl/statem/statem_srvr.c:1657:
> shutting down SSL
> CONNECTION CLOSED
>
> So for this combo Max/MinProtocol, it's just the MaxProtocol one that
> isn't being followed. Granted it's the less useful one, as usually we
> want to restrict old suites.
A small nit... SSL/TLS does _not_ have a min and max protocol version.
There's a record layer version,[1] and a handshake version.[2]
Specifying record layer version = TLS v1.0 and handshake version = TLS
1.3 does not mean the set of protocols in the range [v1.0, v1.3].
The record layer carries all of the protocol messages. It is usually
selected as the minimum version the client and server can use to
communicate. The record layer carries the Hello's and other
administrative messages.
The handshake version is agreed upon, and selects the key exchange and
bulk encryption algorithms. TLS v1.2 is usually desired because it
MACs more fields than TLS 1.0 and below. You won't know which fields
to MAC until you select a handshake version. (TLS v1.1 did not change
anything. It merely added elliptic curve gear). TLS v1.3 is also
desired because it offers cipher suites with strong authentication
properties.
The TLS Working group declined to make the versions a range. Their
argument was there may be "holes" in the range. For example, a web
server might offer TLS v1.0 and v1.3, but not v1.1 and v1.2.
Jeff
[1] https://www.rfc-editor.org/rfc/rfc5246.html#section-6.2
[2] https://www.rfc-editor.org/rfc/rfc5246.html#section-7.3
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-01-03