TLS hostname verifier: reverse resolves peer addresses?

Bernd Eckenfels ecki at
Sun Nov 2 23:15:28 UTC 2014


while playing around(*) with JSSE and I noticed, that the
Java 8 hostname verifier (algorithm https configured) will reverse
resolve hostnames and use them.

This has two problems, for one it is a performance problem, but for
two, it will verify the cert against an untrusted (DNS response)
parameter. I dont think it is speced that way (at least I could not
find it). So it could fall back to IP literal instead.

This is not a problem if I generate the InetAddr with a ip literal:

destination = InetAddr.getByName("");

but it is a problem if I construct an unresolved address:

destination = InetAddress.getByAddress(
  new byte[] {54,(byte)245,(byte)228,(byte)141});

In the first case, it will result in (expected):

Caused by: No subject
  alternative names matching IP address found

In the second case, however it will result in:

Caused by:
  No subject alternative DNS name matching found.

I typically use the getByAddress form as it allows me to control
resolving. It is enough to use this form:

destination = InetAddress.getByAddress("",
  new byte[] {54,(byte)245,(byte)228,(byte)141});

However I noticed in the code there are some conditionals for
unresolved peer addresses. I just wonder if they should catch this and
avoid the reverse lookup, or not?

(I actually wanted to make sure hostname verification is not skipped,
no matter how I configure it).



More information about the security-dev mailing list