IPv6 and GPG

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

IPv6 and GPG

David Shaw
What with the recent discussion of IPv6, I'm curious if anyone has  
tested GPG against it for key retrieval and submission.  It should  
"just work" with the curl backend, but when GPG is built on a system  
without curl, an internal HTTP handler is used instead.  I believe  
this handler code should work fine as written, but I don't believe the  
IPv6 piece of it has been tested extensively.  If someone could give  
it a whirl, I'd appreciate it.  To force the use of the internal HTTP  
handler even when you do have curl installed, you can build GPG with  
"configure --without-libcurl".

David



_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 and GPG

Phil Pennock-17
On 2009-03-09 at 09:19 -0400, David Shaw wrote:
> What with the recent discussion of IPv6, I'm curious if anyone has  
> tested GPG against it for key retrieval and submission.  It should  
> "just work" with the curl backend, but when GPG is built on a system  
> without curl, an internal HTTP handler is used instead.  I believe  
> this handler code should work fine as written, but I don't believe the  
> IPv6 piece of it has been tested extensively.  If someone could give  
> it a whirl, I'd appreciate it.  To force the use of the internal HTTP  
> handler even when you do have curl installed, you can build GPG with  
> "configure --without-libcurl".

Yes; using gpg was my test case that I had the HKP port stuff working.
I even mentioned this, but it'll be buried deep in a long post.  The
keyserver is open for public querying, so anyone can test against it.
Demos of gpg with curl working are below.  Yes, it just works.  :)

I don't have time right now to rebuild gpg; I use FreeBSD Ports builds
though and the options files record that I'm using curl (although ldd
doesn't report it (static linkage of that lib?) and an objdump of the
dynamic strings doesn't list anything matching Curl*).  As a feature
suggestion, it would be nice if gpg --version reported the optional
libraries it's linked against (not just libgcrypt).

Another idea is that on a line like:
  gpg: requesting key 0x99242560 from hkp server sks.spodhuis.org
you could follow the hostname with the IP address tried.


  $ gpg --keyserver 'hkp://[2001:980:fff:31::10]' --recv-key $keyid

% gpg --keyserver 'hkp://[2001:980:fff:31::10]' --recv-key 0x99242560
gpg: requesting key 0x99242560 from hkp server [2001:980:fff:31::10]
gpg: key 0x99242560: "David M. Shaw <[hidden email]>" 1 new signature
gpg: Total number processed: 1
gpg:         new signatures: 1

% gpg --version
gpg (GnuPG) 1.4.9
[...]

% gpg2 --keyserver 'hkp://[2001:980:fff:31::10]' --recv-key 0x99242560
gpg: WARNING: This version has been built with support for the Camellia cipher.
gpg:          It is for testing only and is NOT for production use!
gpg: requesting key 0x99242560 from hkp server [2001:980:fff:31::10]
gpg: key 0x99242560: "David M. Shaw <[hidden email]>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1

% gpg2 --version
gpg (GnuPG) 2.0.11
libgcrypt 1.4.4
[...]


Regards,
-Phil

PS: IPv6 renumbering within the next month, so if you're reading this
    late and the above IPv6 address fails, look up sks.spodhuis.org and
    grab the IPv6 address from that.


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 and GPG

David Shaw
On Mon, Mar 09, 2009 at 02:49:52PM -0700, Phil Pennock wrote:

> On 2009-03-09 at 09:19 -0400, David Shaw wrote:
> > What with the recent discussion of IPv6, I'm curious if anyone has  
> > tested GPG against it for key retrieval and submission.  It should  
> > "just work" with the curl backend, but when GPG is built on a system  
> > without curl, an internal HTTP handler is used instead.  I believe  
> > this handler code should work fine as written, but I don't believe the  
> > IPv6 piece of it has been tested extensively.  If someone could give  
> > it a whirl, I'd appreciate it.  To force the use of the internal HTTP  
> > handler even when you do have curl installed, you can build GPG with  
> > "configure --without-libcurl".
>
> Yes; using gpg was my test case that I had the HKP port stuff working.
> I even mentioned this, but it'll be buried deep in a long post.  The
> keyserver is open for public querying, so anyone can test against it.
> Demos of gpg with curl working are below.  Yes, it just works.  :)

I'm not too surprised it works with curl.  That has been very well
tested against IPv6.  It's the internal handler that hasn't had a lot
of IPv6 testing.

> I don't have time right now to rebuild gpg; I use FreeBSD Ports builds
> though and the options files record that I'm using curl (although ldd
> doesn't report it (static linkage of that lib?) and an objdump of the
> dynamic strings doesn't list anything matching Curl*).

It wouldn't be linked to gpg.  It would be linked to the HKP "helper",
gpgkeys_hkp.  GPG calls a different handler for each keyserver type
(HKP, LDAP, HTTP, etc).

> As a feature
> suggestion, it would be nice if gpg --version reported the optional
> libraries it's linked against (not just libgcrypt).

As it happens, this is actually part of the next release:

$ /usr/local/libexec/gnupg/gpgkeys_hkp --version
gpgkeys_hkp (GnuPG) 1.4.10-svn4878
Uses: libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 libidn/0.6.14 libssh2/0.18

> Another idea is that on a line like:
>   gpg: requesting key 0x99242560 from hkp server sks.spodhuis.org
> you could follow the hostname with the IP address tried.

This is harder than it seems to do.  Given that most keyserver
addresses round-robin a large set of IPs, there is no way to know
until we're into the HTTP call which IP was chosen.  It would require
quite a bit of plumbing to fetch the IP earlier and then force the
HTTP engine to fetch by IP.  This would also remove any optimizations
that the HTTP engine might apply - such as trying more than one of
multiple IPs until one succeeds.

If you really need to know what IP is being used, add
"keyserver-options debug"" to your config file.  That tells the engine
(either curl or the internal engine) to print each IP it tries during
a key operation.

David


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 and GPG

Phil Pennock-17
On 2009-03-10 at 12:52 -0400, David Shaw wrote:
> It wouldn't be linked to gpg.  It would be linked to the HKP "helper",
> gpgkeys_hkp.  GPG calls a different handler for each keyserver type
> (HKP, LDAP, HTTP, etc).

Thanks.

> As it happens, this is actually part of the next release:
>
> $ /usr/local/libexec/gnupg/gpgkeys_hkp --version
> gpgkeys_hkp (GnuPG) 1.4.10-svn4878
> Uses: libcurl/7.18.2 NSS/3.12.2.0 zlib/1.2.3 libidn/0.6.14 libssh2/0.18

Neat.  :)

> If you really need to know what IP is being used, add
> "keyserver-options debug"" to your config file.  That tells the engine
> (either curl or the internal engine) to print each IP it tries during
> a key operation.

Thanks, that's what I really needed, just a way to test that the client
was using IPv6 from DNS AAAA records and that it was succeeding.

Note that this appears to be undocumented; keyserver-options verbose is
documented but didn't help.  (I happen to have:
  keyserver-options no-auto-key-retrieve,verbose
set in my config and repeating verbose didn't up the level enough to
give IPs).

-Phil

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 and GPG

David Shaw
On Tue, Mar 10, 2009 at 12:53:09PM -0700, Phil Pennock wrote:

> > If you really need to know what IP is being used, add
> > "keyserver-options debug"" to your config file.  That tells the engine
> > (either curl or the internal engine) to print each IP it tries during
> > a key operation.
>
> Thanks, that's what I really needed, just a way to test that the client
> was using IPv6 from DNS AAAA records and that it was succeeding.
>
> Note that this appears to be undocumented; keyserver-options verbose is
> documented but didn't help.  (I happen to have:
>   keyserver-options no-auto-key-retrieve,verbose
> set in my config and repeating verbose didn't up the level enough to
> give IPs).

Good point.  I'll add it to the docs.

David


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 and GPG

Phil Pennock-17
In reply to this post by David Shaw
On 2009-03-09 at 09:19 -0400, David Shaw wrote:
> What with the recent discussion of IPv6, I'm curious if anyone has  
> tested GPG against it for key retrieval and submission.  It should  
> "just work" with the curl backend, but when GPG is built on a system  
> without curl, an internal HTTP handler is used instead.  I believe  
> this handler code should work fine as written, but I don't believe the  
> IPv6 piece of it has been tested extensively.  If someone could give  
> it a whirl, I'd appreciate it.  To force the use of the internal HTTP  
> handler even when you do have curl installed, you can build GPG with  
> "configure --without-libcurl".

Building with --without-libcurl:

----------------------------8< cut here >8------------------------------
gpg1 gnupg-1.4.9:
% ./bin/gpg --keyserver-options debug --keyserver 'hkp://[2001:980:fff:31::10]'  --recv-key $gpg_key
gpg: requesting key 0x3903637F from hkp server [2001:980:fff:31::10]
gpgkeys: curl version = GnuPG curl-shim 1.4.9
* HTTP proxy is "null"
* HTTP URL is "http://[2001:980:fff:31::10]:11371/pks/lookup?op=get&options=mr&search=0x3903637F"
* HTTP auth is "null"
* HTTP method is GET
?: [2001: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Unknown error: 0
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

gpg2 gnupg-2.0.11:
% ./bin/gpg2 --keyserver-options debug --keyserver 'hkp://[2001:980:fff:31::10]'  --recv-key $gpg_key
gpg: requesting key 0x3903637F from hkp server [2001:980:fff:31::10]
gpgkeys: curl version = GnuPG curl-shim 2.0.11
* HTTP proxy is "null"
* HTTP URL is "http://[2001:980:fff:31::10]:11371/pks/lookup?op=get&options=mr&search=0x3903637F"
* HTTP auth is "null"
* HTTP method is GET
: can't connect to `[2001': host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Not found
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
----------------------------8< cut here >8------------------------------

With the attached patch against gnupg-1.4.9, the key retrieval works.
It's just a matter of handling IP address literals in square brackets.

Reference is RFC3986 / STD66 "Uniform Resource Identifier (URI): Generic
Syntax"

      host        = IP-literal / IPv4address / reg-name
      IP-literal = "[" ( IPv6address / IPvFuture  ) "]"
      IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

In practice, I just check for something in square brackets and take that
as the host portion; a more paranoid check would validate at least the
character set of the enclosed contents and do something other than treat
it as a normal hostname.  But hey, I can confirm that this fix is
sufficient to let retrieval work, so the only issue left is how cautious
you want to be here.

Regards,
-Phil

diff -ur gnupg-1.4.9/util/http.c gnupg-work/util/http.c
--- gnupg-1.4.9/util/http.c 2007-10-23 00:55:31.000000000 -0700
+++ gnupg-work/util/http.c 2009-03-10 22:39:18.000000000 -0700
@@ -343,13 +343,23 @@
       }
 
     strlwr( p );
-    uri->host = p;
+
+    /* Handle a host of [IP] so that [IP:V6]:port works */
+    if( *p == '[' && (p3=strchr( p, ']' )) ) {
+ *p3++ = '\0';
+ /* worst case, uri->host should have length 0, points to \0 */
+ uri->host = p + 1;
+ p = p3;
+    } else {
+ uri->host = p;
+    }
+
     if( (p3=strchr( p, ':' )) ) {
- *p3++ = 0;
+ *p3++ = '\0';
  uri->port = atoi( p3 );
     }
 
-    uri->host = p;
+    p = uri->host;
     if( (n = remove_escapes( uri->host )) < 0 )
  return G10ERR_BAD_URI;
     if( n != strlen( p ) )

_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel

attachment0 (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IPv6 and GPG

David Shaw
On Tue, Mar 10, 2009 at 10:48:46PM -0700, Phil Pennock wrote:

> With the attached patch against gnupg-1.4.9, the key retrieval works.
> It's just a matter of handling IP address literals in square brackets.

Ah, right.  I did do a conversion to using getaddrinfo a few years ago
for IPv6 support, but I believe it was only tested with hostnames (not
many IPv6 hosts out there then).

> Reference is RFC3986 / STD66 "Uniform Resource Identifier (URI): Generic
> Syntax"
>
>       host        = IP-literal / IPv4address / reg-name
>       IP-literal = "[" ( IPv6address / IPvFuture  ) "]"
>       IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
>
> In practice, I just check for something in square brackets and take that
> as the host portion; a more paranoid check would validate at least the
> character set of the enclosed contents and do something other than treat
> it as a normal hostname.

I think that is okay.  We treat IPv4 addresses as hostnames as well,
so at least this is consistent.

Thanks for the patch.  I've applied it with a few minor changes and
it'll be in the next release.

David


_______________________________________________
Sks-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/sks-devel