The list of TLS versions was added by
8bd2b6eb13 when hackney version was
pinned to 1.15.2. Later hackney version was upgraded
(166455c884) but the list of TLS
versions wasn't removed. From the hackney point of view, this list has
been replaced by the OTP defaults since 0.16.0
(734694ea4e24f267864c459a2f050e943adc6694).
It looks like the same issue already occurred before:
0cb7b0ea84.
A way to test this issue (where example.com is an ActivityPub site
which uses TLSv1.3 only):
$ PLEROMA_CONFIG_PATH=/path/to/config.exs pleroma start_iex
Erlang/OTP 22 [erts-10.7.2.16] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe]
Erlang/OTP 22 [erts-10.7.2.16] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1] [hipe]
Interactive Elixir (1.10.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(pleroma@127.0.0.1)2> Pleroma.Object.Fetcher.fetch_and_contain_remote_object_from_id("https://example.com/@/Nick/")
{:error,
{:tls_alert,
{:protocol_version,
'TLS client: In state hello received SERVER ALERT: Fatal - Protocol Version\n'}}}
With this patch, the output is the expected one:
iex(pleroma@127.0.0.1)3> Pleroma.Object.Fetcher.fetch_and_contain_remote_object_from_id("https://example.com/@/Nick/")
{:error,
{:ok,
%{
"@context" => [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1",
%{
"Emoji" => "toot:Emoji",
"Hashtag" => "as:Hashtag",
"atomUri" => "ostatus:atomUri",
"conversation" => "ostatus:conversation",
"featured" => "toot:featured",
"focalPoint" => %{"@container" => "@list", "@id" => "toot:focalPoint"},
"inReplyToAtomUri" => "ostatus:inReplyToAtomUri",
"manuallyApprovesFollowers" => "as:manuallyApprovesFollowers",
"movedTo" => "as:movedTo",
"ostatus" => "http://ostatus.org#",
"sensitive" => "as:sensitive",
"toot" => "http://joinmastodon.org/ns#"
}
],
"endpoints" => %{"sharedInbox" => "https://example.com/inbox"},
"followers" => "https://example.com/@/Nick/followers",
"following" => nil,
"icon" => %{
"type" => "Image",
"url" => "https://example.com/static/media/[...].png"
},
"id" => "https://example.com/@/Nick/",
"inbox" => "https://example.com/@/Nick/inbox",
"liked" => nil,
"name" => "Nick",
"outbox" => "https://example.com/@/Nick/outbox",
"preferredUsername" => "Nick",
"publicKey" => %{
"id" => "https://example.com/@/Nick/#main-key",
"owner" => "https://example.com/@/Nick/",
"publicKeyPem" => "[...]
},
"summary" => "",
"type" => "Person",
"url" => "https://example.com/@/Nick/"
}}
A way to test the reverse proxy bits of this issue (where example.com allows TLSv1.3 only):
iex(pleroma@127.0.0.1)1> Pleroma.ReverseProxy.Client.Hackney.request("GET", "https://example.com", [], [])
{:error,
{:tls_alert,
{:protocol_version,
'TLS client: In state hello received SERVER ALERT: Fatal - Protocol Version\n'}}}
Use a custom tesla middleware instead of adapter helper function +
custom redirect middleware.
This will also fix "Client died before releasing the connection"
messages when the request pool is overloaded. Since the checkout is
now done after passing ConcurrentLimiter.
This is technically less efficient, since the connection needs to be
checked in/out every time the middleware is left or entered respectively.
But I don't think the nanoseconds we might lose on redirects
to the same host are worth the complexity.
- fix for gun worker termination in some circumstances
- pool for http clients (ex_aws, tzdata)
- default pool timeouts for gun
- gun retries on gun_down messages
- s3 upload timeout if streaming enabled
- `verify_fun` is not useful now
- use `customize_check_hostname` (OTP 20+ so OK)
- `partial_chain` is useless as of OTP 21.1 (wasn't there, but hackney/..
uses it)
When the application restarts (which happens after certain config
changes), the limiters are not destroyed, so `ConcurrentLimiter.new`
will produce {:error, :existing}
See https://bugs.erlang.org/browse/ERL-1260 for more info.
The ssl match function is basically copied from mint, except
that `:string.lowercase/1` was replaced by `:string.casefold`.
It was a TODO in mint's code, so might as well do it since we don't need
to support OTP <20.
Closes#1834
This patch refactors gun pooling to use Elixir process registry and
simplifies adapter option insertion.
Having the pool use process registry instead of a GenServer has a number of advantages:
- Simpler code: the initial implementation adds about half the lines of code it deletes
- Concurrency: unlike a GenServer, ETS-based registry can handle multiple checkout/checkin
requests at the same time
- Precise and easy idle connection clousure: current proposal for closing idle connections in
the GenServer-based pool needs to filter through all connections once a minute and compare their
last active time with closing time. With Elixir process registry this can be done
by just using `Process.send_after`/`Process.cancel_timer` in the worker process.
- Lower memory footprint: In my tests `gun-memory-leak` branch uses about 290mb on peak load (250 connections)
and 235mb on idle (5-10 connections). Registry-based pool uses 210mb on idle and 240mb on peak load
- partitial_chain is no longer exported, but it seems to be the default anyway.
- The bug that caused sni to not be sent automatically seems to be fixed -
https://github.com/benoitc/hackney/issues/612
Mark Felder
![https://example.com/static/media/[...].png](https://example.com/static/media/[...].png){kind=link}