Non-blocking connect for dirmngr

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Non-blocking connect for dirmngr

Werner Koch
Hi!

When using --auto-key-retrieve or --auto-key-locate to automagically
retrieve keys from the Web Key Directory (WKD) or keyservers it often
happens that a server does not respond timely.

Keyservers may be down and dirmngr would then select another keyserver.
However, it may take several minutes until the connect call returns an
error.  Annoying.

Even more annoying are WKD queries to servers which don't support this
service and - worse - don't run a web server at all at the expected
address.  For example one of our core hackers has an address at iki.fi.
Now when dirmngr want to lookup an address it tries
https://iki.fi/foo/bar and hangs (plain http redirects to www.iki.fo and
works).  After it times out the code tries the next server listed for
that address, until that one times out as well.  Finally after 3 times
the default timeout you get an error message back.  That can be 15
minutes or more.  Clearly not acceptable.

The obvious solution to this is to use a lower timeout.  However, Unix
has no easy way to do this because connect(2) has no timeout parameter
and the way it can be done used to be non-portable: You switch the
socket into blocking mode, call connect and then the select on the
socket.  Now this works, but according to Stevens, systems use slightly
different semantics to tell you the outcome of the operation.
This is unfortunate but let's assume it works with todays systems
without too much trouble.

I implemented that in master and there are now default timeouts of 15
seconds for regular operations and 2 seconds for "unimportant"
operations (looking up a key for verification).  Works nice on my Linux
box but I have not yet tested on any other system.  There is code for
Windows which builds but it has not yet been tested.

I like to ask those of you who are using master on non Debian/Linux
boxes to try it out.  For example put

  debug ipc,dns,network
  verbose
  log-file socket://

into dirmngr.conf, fireup watchgnupg

  watchgnupg --time-only --force $(gpgconf --list-dirs socketdir)/S.log

and in another term/screen run

  gpg-connect-agent --dirmngr

as test shell.   Entering for example

  WKD_GET --quick --submission-address -- [hidden email]

should give you a Connection Refused after just a few seconds.  Or does
it not on your system?


Shalom-Salam,

   Werner


p.s
The new options we have are:

   --connect-timeout n
   --connect-quick-timeout n

          Set the timeout for HTTP and generic TCP connection
          attempts to N seconds.  The value set with the quick
          variant is used when the --quick option has been given to
          certain Assuan commands.  The quick value is capped at the
          value of the regular connect timeout.  The default values
          are 15 and 2 seconds.  Note that the timeout values are
          for each connection attempt; the connection code will
          attempt to connect all addresses listed for a server.


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non-blocking connect for dirmngr

Daniel Kahn Gillmor-7
On Thu 2017-06-08 18:28:18 +0200, Werner Koch wrote:
> When using --auto-key-retrieve or --auto-key-locate to automagically
> retrieve keys from the Web Key Directory (WKD) or keyservers it often
> happens that a server does not respond timely.
>
> Keyservers may be down and dirmngr would then select another keyserver.
> However, it may take several minutes until the connect call returns an
> error.  Annoying.

thanks for working on fixing this, Werner!  It's definitely important if
GnuPG is going to be making these queries.

> Even more annoying are WKD queries to servers which don't support this
> service and - worse - don't run a web server at all at the expected
> address.  For example one of our core hackers has an address at iki.fi.
> Now when dirmngr want to lookup an address it tries
> https://iki.fi/foo/bar and hangs (plain http redirects to www.iki.fo and
> works).  After it times out the code tries the next server listed for
> that address, until that one times out as well.  Finally after 3 times
> the default timeout you get an error message back.  That can be 15
> minutes or more.  Clearly not acceptable.

Another approach could be "happy eyeballs" -- if the name resolves to 2
IP addresses, connect to both of them concurrently and take the first
connection that completes.  You wouldn't want to do this if there was a
hundred IP addresses, but there's probably a reasonable middle-ground
that gets you both resiliency when one host is down, and avoids flodding
the network.  perhaps up to 4 outstanding concurrent connections?  And
as they fail, if there are as-yet-untried addresses, they could launch
them.

that'd allow you to keep a reasonable timeout so that sluggish servers
have a chance to respond, while not having responsive servers get stuck
behind sluggish servers if they exist.

     --dkg

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non-blocking connect for dirmngr

Damien Goutte-Gattat
In reply to this post by Werner Koch
Hi,

On 06/08/2017 06:28 PM, Werner Koch wrote:
> should give you a Connection Refused after just a few seconds.  Or does
> it not on your system?

Connection Refused after 4 seconds here:

   4 - 19:50:58 dirmngr[25707.5]: DBG: dns: resolve_dns_name(iki.fi):
Success
   4 - 19:51:02 dirmngr[25707.5]: can't connect to 'iki.fi': Connection
refused

The box is a Slackware64 14.2, running linux-4.10.13 with glibc-2.23.

Damien


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non-blocking connect for dirmngr

Filipp Gunbin
In reply to this post by Werner Koch
Hi, I'm on macOS 10.12.5, built gnupg master today and getting 20 sec
timeout before getting error.

This is what watchgnupg outputs:

[client at fd 4 connected (local)]
  4 - 21:56:32 dirmngr[91488]: listening on socket '/Users/fgunbin/.gnupg/S.dirmngr'
  4 - 21:56:33 dirmngr[91489.0]: permanently loaded certificates: 49
  4 - 21:56:33 dirmngr[91489.0]:     runtime cached certificates: 0
  4 - 21:56:33 dirmngr[91489.0]:            trusted certificates: 49 (48,0,0,1)
  4 - 21:56:33 dirmngr[91489.6]: handler for fd 6 started
  4 - 21:56:33 dirmngr[91489.6]: DBG: chan_6 -> # Home: /Users/fgunbin/.gnupg
  4 - 21:56:33 dirmngr[91489.6]: DBG: chan_6 -> # Config: /Users/fgunbin/.gnupg/dirmngr.conf
  4 - 21:56:33 dirmngr[91489.6]: DBG: chan_6 -> OK Dirmngr 2.1.22-beta44 at your service
  4 - 21:56:33 dirmngr[91489.6]: connection from process -1 (501:20)
  4 - 21:56:37 dirmngr[91489.6]: DBG: chan_6 <- WKD_GET --quick --submission-address -- [hidden email]
  4 - 21:56:37 dirmngr[91489.6]: DBG: dns: fallback resolution order, files then DNS
  4 - 21:56:37 dirmngr[91489.6]: DBG: dns: libdns initialized
  4 - 21:56:57 dirmngr[91489.6]: DBG: dns: getsrv(_openpgpkey._tcp.iki.fi): Server indicated a failure
  4 - 21:56:57 dirmngr[91489.6]: command 'WKD_GET' failed: Server indicated a failure <Unspecified source>
  4 - 21:56:57 dirmngr[91489.6]: DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>

Filipp

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non-blocking connect for dirmngr

Patrick Brunschwig-2
On 09.06.17 21:02, Filipp Gunbin wrote:

> Hi, I'm on macOS 10.12.5, built gnupg master today and getting 20 sec
> timeout before getting error.
>
> This is what watchgnupg outputs:
>
> [client at fd 4 connected (local)]
>   4 - 21:56:32 dirmngr[91488]: listening on socket '/Users/fgunbin/.gnupg/S.dirmngr'
>   4 - 21:56:33 dirmngr[91489.0]: permanently loaded certificates: 49
>   4 - 21:56:33 dirmngr[91489.0]:     runtime cached certificates: 0
>   4 - 21:56:33 dirmngr[91489.0]:            trusted certificates: 49 (48,0,0,1)
>   4 - 21:56:33 dirmngr[91489.6]: handler for fd 6 started
>   4 - 21:56:33 dirmngr[91489.6]: DBG: chan_6 -> # Home: /Users/fgunbin/.gnupg
>   4 - 21:56:33 dirmngr[91489.6]: DBG: chan_6 -> # Config: /Users/fgunbin/.gnupg/dirmngr.conf
>   4 - 21:56:33 dirmngr[91489.6]: DBG: chan_6 -> OK Dirmngr 2.1.22-beta44 at your service
>   4 - 21:56:33 dirmngr[91489.6]: connection from process -1 (501:20)
>   4 - 21:56:37 dirmngr[91489.6]: DBG: chan_6 <- WKD_GET --quick --submission-address -- [hidden email]
>   4 - 21:56:37 dirmngr[91489.6]: DBG: dns: fallback resolution order, files then DNS
>   4 - 21:56:37 dirmngr[91489.6]: DBG: dns: libdns initialized
>   4 - 21:56:57 dirmngr[91489.6]: DBG: dns: getsrv(_openpgpkey._tcp.iki.fi): Server indicated a failure
>   4 - 21:56:57 dirmngr[91489.6]: command 'WKD_GET' failed: Server indicated a failure <Unspecified source>
>   4 - 21:56:57 dirmngr[91489.6]: DBG: chan_6 -> ERR 219 Server indicated a failure <Unspecified source>

I got a timeout after 4 seconds on my macOS 10.12.5

-Patrick

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non-blocking connect for dirmngr

Werner Koch
In reply to this post by Filipp Gunbin
On Fri,  9 Jun 2017 21:02, [hidden email] said:
>   4 - 21:56:33 dirmngr[91489.6]: connection from process -1 (501:20)
>   4 - 21:56:37 dirmngr[91489.6]: DBG: chan_6 <- WKD_GET --quick --submission-address -- [hidden email]

I wonder why it takes 4 seconds that gpg sends the command after the
connection has already been setup.

>   4 - 21:56:37 dirmngr[91489.6]: DBG: dns: libdns initialized
>   4 - 21:56:57 dirmngr[91489.6]: DBG: dns: getsrv(_openpgpkey._tcp.iki.fi): Server indicated a failure

Here we have a 20 second delay but it comes from the resolver - there
has been no connection attempt.  I noticed that Patrick has the same
problem.  Is your connection toi the resolver IPv4 or IPv6?  (Justus
fixed a v6 bug today).


Shalom-Salam,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non-blocking connect for dirmngr

Werner Koch
In reply to this post by Damien Goutte-Gattat
On Fri,  9 Jun 2017 12:17, [hidden email] said:

> Connection Refused after 4 seconds here:

Okay, so as expectecd it works on Linux ;-).  Thanks.


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non-blocking connect for dirmngr

Werner Koch
In reply to this post by Daniel Kahn Gillmor-7
On Thu,  8 Jun 2017 21:55, [hidden email] said:

> thanks for working on fixing this, Werner!  It's definitely important if
> GnuPG is going to be making these queries.

For whatever reasons, bugs which affecting me get a high priority ;-)

> Another approach could be "happy eyeballs" -- if the name resolves to 2
> IP addresses, connect to both of them concurrently and take the first
> connection that completes.  You wouldn't want to do this if there was a

That would make a bad netizen.  A more acceptable approach would be be
to start a second connection attempt after one or two seconds.  In that
case we can assume that there is a problem with the first address.  Also
randomly selecting from 3 addresses could make sense.

Anyway, such an optimization requires a larger rework and we need to get
2.2 out of the door before we do such things.


Shalom-Salam,

   Werner


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Non-blocking connect for dirmngr

Filipp Gunbin
In reply to this post by Werner Koch
On 13/06/2017 15:13 +0200, Werner Koch wrote:

> On Fri,  9 Jun 2017 21:02, [hidden email] said:
>>   4 - 21:56:33 dirmngr[91489.6]: connection from process -1 (501:20)
>>   4 - 21:56:37 dirmngr[91489.6]: DBG: chan_6 <- WKD_GET --quick --submission-address -- [hidden email]
>
> I wonder why it takes 4 seconds that gpg sends the command after the
> connection has already been setup.

It's just me who sent the WKD_GET command 4 seconds after the
connection.

>>   4 - 21:56:37 dirmngr[91489.6]: DBG: dns: libdns initialized
>>   4 - 21:56:57 dirmngr[91489.6]: DBG: dns: getsrv(_openpgpkey._tcp.iki.fi): Server indicated a failure
>
> Here we have a 20 second delay but it comes from the resolver - there
> has been no connection attempt.  I noticed that Patrick has the same
> problem.  Is your connection toi the resolver IPv4 or IPv6?  (Justus
> fixed a v6 bug today).

I'm getting the same thing on the current master.

How can I check v4/v6 connection type?

Filipp

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

signature.asc (497 bytes) Download Attachment
Loading...