Name based SSH proxy

[Daniel Kahn Gillmor]

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