Page MenuHome GnuPG

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


This looks very much like the old 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:// --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:

That hostname should not have been expected. DNS is untrusted ( 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.



Event Timeline

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 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 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 claimed this task.