On Thu, Jun 04, 2015 at 03:56:09PM -0400, Michael Richardson wrote:
> Now, www.us.tcpdump.org shares a host with www.wireshark.org, and
> https://www.wireshark.org also exists, and my impression is that some
> browsers are now doing things like trying port-443, and if it works,
> assuming that the same content is there. (No, you can't exactly try, because
> I pulled that IP from www.tcpdump.org pending resolution)
Assuming that port 443 is semantically identical to port 80 is
rather unwise. Are browsers really doing that, or is the host in
question configured to publish alternative service access via 443?
> In theory, one could have a dozen TLSA RR in DNS, and fortunately they won't
> clog up the apex; but in practice are browsers that support DANE smart enough
> at this point to search all the records? Going DANE assumes browsers new
> enough to do SNI, which I guess is good.
There are essentially no browsers that support DANE. There are
some experimental plugins, but nothing mainstream anyone should
rely on.
> Am I missing some piece of the puzzle? Some contemplated aspect of TLSA
> which might let me say, "www.wireshark.org is an allowed name for
> www.tcpdump.org"?
Unfortunately, HTTP does not use SRV records. If HTTP had used
SRV records, and if browsers supported DANE, then the DANE SRV
draft (approved and in the RFC editor queue) would do precisely
what you want, in that each target host's own name from the SRV
record would be used for TLSA record lookup and any peername checks.
This is not how HTTPS works today. There is no service indirection
via DNS for HTTP, so you have to do that at the application layer
via an HTTPS redirector (that can somehow guess which servers are
up and reachable by the client).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
