On Tue 2015-05-26 17:42:40 -0400, Kasper Dupont wrote: > And in that case, we wouldn't be having this discussion, > because there would be enough IP addresses that SNI would > never have been invented. unless people wanted to co-tenant anyway, which is conceivable for other reasons like minimizing inference that can be drawn from metadata. In these metadata-sensitive co-tenanted arrangements, we'd want protected SNI, not cleartext. > I haven't seen any of the work done in those areas. But > considering how little traction DNSSEC has, I would > imagine that DNS privacy initiatives would take decades > to get any traction. > > If you have any pointers, I am very curious as to exactly > how they intend to do get any privacy into the DNS > protocol. https://datatracker.ietf.org/wg/dprive/documents/ the goal is to start with protection of the stub-to-recursive link, and think about protecting the recursive-to-authoritative link later. https://datatracker.ietf.org/doc/draft-ietf-dprive-start-tls-for-dns/ is the most promising one at the moment. This is completely orthogonal to DNSSEC, and the folks working on it are well aware of the failings there. >> I think the ProxyCommand Kasper ended up describing (checking for v6 >> connectivity or using a constrained HTTP CONNECT proxy) is a acceptable >> way to go for people in the particular scenario he's concerned about. > > But it does not address all my requirements. I have a > requirement that the hostname being used must be visible > to the administrator of the SSH server. And it must be > visible with minimal effort without requiring any software > changes on the server. The patch you're sending is a software change :) > But there are not many opportunities for a proxy to inject > data into the data stream from client to server without > breaking integrity checks on the packets. no, the proxycommand has to wrap the ssh traffic in an outer-layer tunnel. > One thing I found was RFC 4253 saying: > > An implementation MUST respond to all unrecognized messages with an > SSH_MSG_UNIMPLEMENTED message in the order in which the messages were > received. Such messages MUST be otherwise ignored. Later protocol > versions may define other meanings for these message types. > > However what I found OpenSSH to be doing was for every > unrecognized message it would either ignore it and not > send an SSH_MSG_UNIMPLEMENTED, or send an error and > disconnect. > > Is it deliberate that OpenSSH doesn't do what RFC 4253 > says MUST be done? This is a separate question, which i haven't done enough reading or testing to answer. hopefully Damien or Darren can comment on it. > I am still pondering on whether there are other ways to > get the hostname communicated across to the server without > breaking the integrity of the connection. If you're going to prevent passive attackers from sniffing it, it would have to be done after the key exchange, which would suggest that the proxy would need to know the secret key material for the session. That seems like a bad outcome either way. --dkg _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
