On 25/05/15 09.51, Damien Miller wrote:> I'm not sure it should be part of the banner exchange, though there is > no other trivial way to do it and maintain backwards compatibility.Even if backwards compatibility wasn't a requirement, I don't see any better way it could be done.> I don't much like it because it reveals host identity information > in the clear.So does the DNS lookup performed before the TCP connection is being established. So that can hardly be considered a secret.> > A better way would be to exchange this after the connection has > been keyed, but that would require extensive changes to the key > exchange protocol.How would that work? The proxy doesn't hold the server key. The proxy doesn't even know which server holds the key.> > I don't really want to implement a half-measure in OpenSSH...All the proxy needs to know is the hostname which was previously send in clear to multiple DNS servers. And the only concern you have brought up is that you don't want this to be send in clear. I need a little bit of help to understand what your concern is here. I'll try to explain my usage scenario in a bit more detail. I have a number of servers each running IPv6 only. Since some clients will only have access to IPv4, I have deployed a proxy on a dual stack host. But the proxy only has a single IPv4 address. Clients connect to this address, and the proxy performs a DNS lookup to find the IPv6 address which this client wants to connect to. Currently this works for HTTP, HTTPS, SMTP, and DNS. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6);
On Mon, May 25, 2015 at 5:39 PM, Kasper Dupont < kasperd at kdxdx.23.may.2015.kasperd.net> wrote: [...]> I'll try to explain my usage scenario in a bit more detail. > I have a number of servers each running IPv6 only. Since > some clients will only have access to IPv4, I have deployed > a proxy on a dual stack host. But the proxy only has a > single IPv4 address.Assuming you have sufficient CPU and an account on the dual stack host (but it could be a single restricted one), we already have a pretty functional SSH proxy: ssh "netcat mode". It takes a little bit of client side configuration, but basically it looks like this in ~/.ssh/config Host v6host1 v6host2 v6host3 ProxyCommand ssh -W %h:%p dualstackhost -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
On 25/05/15 21.16, Darren Tucker wrote:> On Mon, May 25, 2015 at 5:39 PM, Kasper Dupont < > kasperd at kdxdx.23.may.2015.kasperd.net> wrote: > [...] > > > I'll try to explain my usage scenario in a bit more detail. > > I have a number of servers each running IPv6 only. Since > > some clients will only have access to IPv4, I have deployed > > a proxy on a dual stack host. But the proxy only has a > > single IPv4 address. > > > Assuming you have sufficient CPU and an account on the dual stack host (but > it could be a single restricted one), we already have a pretty functional > SSH proxy: ssh "netcat mode".I don't know if CPU usage is going to be an issue for me. Given an approach where CPU usage was the only known issue, I would surely give it a try.> > It takes a little bit of client side configuration, but basically it looks > like this in ~/.ssh/config > > Host v6host1 v6host2 v6host3 > ProxyCommand ssh -W %h:%p dualstackhostI know of this approach and occasionally use it in other scenarios, but I don't think it could address all of the needs my proxy would have. First of all, the proxy is only supposed to be used as fallback when the client does not have IPv6 connectivity. The client might move between different networks, and when it is on a network with IPv6 connectivity, I want it to connect directly to the target. The ProxyCommand approach works great when there is a desire to not put the target host directly on a publicly reachable IP address for security reasons. That is however not the scenario I am trying to address. The scenario I am trying to address is when the only reason for not having the target on a public address is shortage of IPv4 addresses. A ProxyCommand which attempts direct IPv6 connectivity and then falls back to a proxy if direct access didn't work is surely an option. There is however a few other concerns which apply to my specific usage scenario. The proxy I am operating will be publicly accessible, and due to that I have a few additional requirements: 1. The proxy have to guarantee that the hostname being used will be easily visible to the administrator of the server which the backend eventually connects to. 2. The proxy doesn't trust the users. Hence the users don't have an SSH login on the proxy. 3. The users don't trust the proxy anymore than they would trust a random router which the SSH connection got routed through. Point 3 might not really be a problem. Having the users store a host key for the proxy doesn't itself pose any problems. Point 2 I could probably work around with sufficient sandboxing. But point 1 on my list appears seems to be a bit of a blocker. Any approach used by the proxy to embed the hostname into the TCP connection would mean a change of data that is subject to integrity check between client and server. So I am at loss as to how the proxy could communicate the hostname to the server. Also. There is nothing in the requirements for my usage scenario, which would benefit from the communication between client and proxy to be embedded in another layer of SSH. And since it would require configuration changes on the client anyway, I would most likely replace that part with something with less overhead such as possibly using an HTTP proxy supporting a restricted version of the CONNECT command. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6);
On Mon 2015-05-25 03:39:27 -0400, Kasper Dupont wrote:> On 25/05/15 09.51, Damien Miller wrote: >> I don't much like it because it reveals host identity information >> in the clear. > > So does the DNS lookup performed before the TCP connection > is being established. So that can hardly be considered a > secret.I hope we do not introduce a cleartext SNI into the SSH protocol. This leaks far too much sensitive metadata for passive monitors. TLS has cleartext SNI, and it is quite difficult to figure out how to protect it from passive monitors (and i think impossible to protect from active attackers who are willing to cause connection failures to learn the client's intended SNI). We should not add this additional layer of metadata leakage to SSH as well. The argument that the DNS lookup leaks this metadata is a bad argument: if we followed this line of reasoning, then every problem that has multiple contributors could never be solved (A says "but my fixing things is useless if B does nothing", while B says "but my fixing things is useless if A does nothing" -- a classic collective action problem). In practice, there is work done today to protect DNS queries as well (see the DNS Privacy working group in the IETF, the latest versions of libunbound and the getdns API, etc). Let's not introduce a new layer of the same problem. 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. Changing everyone else's SSH connections to leak that metadata for the sake of this corner case would be a bad tradeoff. Regards, --dkg
On 26/05/15 15.50, Daniel Kahn Gillmor wrote:> The argument that the DNS lookup leaks this metadata is a bad argument: > if we followed this line of reasoning, then every problem that has > multiple contributors could never be solved (A says "but my fixing > things is useless if B does nothing", while B says "but my fixing things > is useless if A does nothing" -- a classic collective action problem).That sort of excuse certainly exists out there. In fact that's the only reason anybody is still using IPv4. If people had put just a little bit more effort into long term solutions, we would all have been running IPv6 years ago. 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. This leads me to my next question. Would it be sensible to modify my patch to make it configurable with three options for when to send the hostname? The three options I would have in mind are: always, only on IPv4, and never.> > In practice, there is work done today to protect DNS queries as well > (see the DNS Privacy working group in the IETF, the latest versions of > libunbound and the getdns API, etc).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.> > 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. Sending the hostname in clear from proxy to server would address that concern. 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. Assuming I could find a way to embed that information inside the stream from proxy to server, then there is nothing stopping me from embeding the information inside the connection from client to proxy as well. And it would certainly be desirable for me if the proxy did not have to modify the data in transit at all. So if I could write a ProxyCommand which would embed the hostname into the stream from client to proxy, then the proxy could simply pick out the hostname and pass the traffic unmodified to the server. I carefully read the relevant RFCs in order to figure out which information is covered by integrity checks and which is not. I found a method which would work according to the RFC, but it turns out OpenSSH doesn't behave as specified by the RFC. 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? 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. -- Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer #define _(_)"d.%.4s%."_"2s" /* This is my email address */ char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6);