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);
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
On 26/05/15 18.29, Daniel Kahn Gillmor wrote:> On Tue 2015-05-26 17:42:40 -0400, Kasper Dupont wrote: > > 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 :)My requirements only said no software changes on the server. It was clear to me very early on, that some changes were needed on the client side. Whether the client side changes can be done as a ProxyCommand remains an open question. But it is certain that a modification of the ssh client would cover all my needs.> > > > 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.I need the proxy to communicate with an unmodified server. And I need this communication to include the hostname for the administrator of said server to see. Whether the administrator would have to look in a logfile or a packet capture in order to see the hostname is not important. I believe that once I have an answer to how the proxy can communicate the hostname to the server, then everything else will follow.> > 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.None of my requirements say the hostname must remain hidden from a passive attacker. So for me it only makes sense to first look for a solution which satisfy my requirements, and only once the requirements are satisfied look for ways to improve the solution to have other nice properties. Sending the hostname after key exchange is impossible. The proxy need to know which server to communicate with, that's the point of sending the hostname in the first place. That means key exchange can only start after the hostname has been sent to the proxy. I don't yet know a way to acheive my desired result using just a ProxyCommand. But with the following change and a ProxyCommand, I believe I would be able to achieve what I am looking for. diff -up openssh-6.6p1/sshconnect.c.original openssh-6.6p1/sshconnect.c --- openssh-6.6p1/sshconnect.c.original 2015-05-23 11:56:55.235217137 +0200 +++ openssh-6.6p1/sshconnect.c 2015-05-27 01:14:02.563652677 +0200 @@ -560,6 +560,9 @@ ssh_exchange_identification(int timeout_ if (options.protocol == SSH_PROTO_2) { enable_compat20(); send_client_banner(connection_out, 0); + packet_send_ignore(0); + packet_send(); + packet_write_wait(); client_banner_sent = 1; } The question then is, would the security implications of adding these three lines be much worse than my original patch? -- 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 26/05/15 23:42, Kasper Dupont wrote:>> > 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.Why do you want the hostname being used to "be visible to the administrator of the SSH server"? I assumed you wanted to send the final hostname to the *proxying SSH server*. In which case, you don't need such thing if using a HTTP CONNECT proxy (the hostname is now given to the HTTP proxy). And if you use a ssh server like the ssh tunneling I proposed, the final hostname is already provided, too. If you want instead to give the hostname used to the *final* sshd, that's a different requirement for which you provided no rationale (and I suspect you are not really interested in). Much more interesting at the final end than the requested would be to have the original client IP (ie. X-Forwarded-For) but that would open a different can of worms (and required software changes) about proxies whose forwarded IPs should be trusted. Something I would prefer not to enter into. A similar idea I had thought in the past was the ability to transparently forward a connection after authentication to a different machine (after the PrivSep step, the new sshd would be in a different host in the LAN). It differs from Kasper proxy in that the proxy would be trusted (seen as the real machine from the outside).
On 27/05/15 01.42, ?ngel Gonz?lez wrote:> Why do you want the hostname being used to "be visible to the administrator > of the SSH server"?In case the AAAA record used by the proxy to find the server for some reason points to the wrong IP address, I want to ensure that the administrator of the server has the opportunity to see the DNS record causing connections to end up on their server. That's only possible if the hostname is sent to the server somehow.> > I assumed you wanted to send the final hostname to the *proxying SSH > server*.Sorry if I didn't express that clearly enough. I need the hostname to be visible to both proxy and the target server.> In which case, you don't need such thing if using a HTTP CONNECT proxy (the > hostname is now given to the HTTP proxy). And if you use a ssh server > like the ssh > tunneling I proposed, the final hostname is already provided, too.Communicating the hostname to the proxy is probably going to be the easy part. The tricky part is to make it visible to the administrator of the target server.> > If you want instead to give the hostname used to the *final* sshd, > that's a different > requirement for which you provided no rationale (and I suspect you are > not really > interested in).That's definitely what I am interested in. The rationale is that the administrator of the final server is to have access to this information.> > > Much more interesting at the final end than the requested would be to > have the > original client IP (ie. X-Forwarded-For) but that would open a different > can of worms > (and required software changes) about proxies whose forwarded IPs should > be trusted.Actually for my specific ussage, that is a solved problem. Communication from client to proxy is IPv4. Communication from proxy to server is IPv6. The proxy simply embed the client IPv4 as the last 32 bits of the client IPv6 visible to the server.> Something I would prefer not to enter into.You don't have to. At least I am not going to be the one asking you to. -- 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 26 May 2015, at 23:42, Kasper Dupont <kasperd at kdxdx.23.may.2015.kasperd.net> wrote: > > 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 thingsAs a practical suggestion - we ran for a while with a hack where we abuse the version human readable string with a base64 string of a _salted_ hash of the server we where trying to get to. Sharing both salt and hash. This let the server figure out the right key to present without too much ado; but without leaking all that much*. The idea was to make it a tiny bit more costly to get a decent selector really early in a connection. However - as keeping a few 10?s of packets in state is no longer that costly; key init and exchange always start at a packet; And the DH modulus (identical but for its last for bytes) in the DH group exchange (31) and what not follow soon thereafter; it seems all a bit superfluous. Dw. *; Except of course - the fairly unqiue Key Kexchange Init and then the very unique Key Exchange Init of the server following in the clear - so one has to be careful with these; or intentionally reuse them. Which is why it fell in disuse soon thereafter.
On 27/05/15 11.07, Dirk-Willem van Gulik wrote:> As a practical suggestion - we ran for a while with a hack where we abuse the version human readable string with a > base64 string of a _salted_ hash of the server we where trying to get to. > > Sharing both salt and hash. > > This let the server figure out the right key to present without too much ado; but without leaking all that much*. The idea was to make it a tiny bit more costly to get a decent selector really early in a connection.That approach seems to rely on the proxy knowing the full list of possible hostnames in advance. In my case the proxy doesn't know the list of hostnames in advance.> > However - as keeping a few 10?s of packets in state is no longer that costly; key init and exchange always start at a packet; And the DH modulus (identical but for its last for bytes) in the DH group exchange (31) and what not follow soon thereafter; it seems all a bit superfluous.That sentence I did not understand. Could you elaborate or explain it differently? -- 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);