TLS hostname verification using hostname from DNS instead of supplied hostname
Closed, ResolvedPublic

Description

This looks very much like the old https://dev.gnupg.org/T1447 where it looks like the fixes might have been applied only for SRV records, not the general case?

David Gray reported an issue with subject GnuPG 2.2.4 on Windows - problems accessing some HKPS keyservers. When I reproduce, using gpg --keyserver hkps://keys.mailvelope.com --recv-key $XYZ, my dirmngr log includes:

2018-01-23 21:28:10 dirmngr[70787.6] TLS verification of peer failed: hostname does not match
2018-01-23 21:28:10 dirmngr[70787.6] DBG: expected hostname: keyserver-prod.v3jierkpjv.eu-west-1.elasticbeanstalk.com

That hostname should not have been expected. DNS is untrusted (mailvelope.com doesn't appear to be signed, but changing behavior for that would be confusing) so the hostname to be verified should be the hostname which was supplied from a trusted source.

syscomet created this task.Jan 24 2018, 3:51 AM
syscomet created this object in space S1 Public.

Oh. T1447 only referenced SRV records, which is why the CNAME case wasn't handled. So T1447 was fixed completely but T1447 did not cover the full extent of the underlying problem.

werner triaged this task as High priority.Jan 24 2018, 8:47 AM
werner added projects: dirmngr, dns.

Is there any ETA for when this might get fixed? We are having the same issue with our keyserver since it's behind a cname.

werner edited projects, added gnupg (gpg22); removed gnupg.Apr 9 2018, 10:45 PM
werner added a subscriber: werner.

That slipped my attention due to the missing gpg22 tag I should have added. Sorry.

werner changed the task status from Open to Testing.Apr 26 2018, 4:41 PM
werner closed this task as Resolved.Jun 19 2018, 1:34 PM
werner claimed this task.